アプリケーションの設計に関する考慮事項

API を呼び出す前に、アプリケーションのロケールを設定しておく必要があります。 ロケールをデフォルト値に設定するには、次のコードをアプリケーションに追加します。

setlocale(LC_ALL,"");

ロケールを別の値に設定するには、2 番目のパラメーターに適切なロケールを指定した、同じ呼び出しを使用します。 詳しくは、使用する各オペレーティング・システムに関する資料を調べてください。

セッション制御に、以下の指針を適用します。

• IBM Storage Protect バックアップ/アーカイブ・クライアントおよび IBM Storage Protect API クライアント製品ごとに固有のノード名を割り当てます。 以下の製品は、これらのクライアントの例です。
  • IBM Storage 保護メール
  • または IBM Storage Protect HSM for Windows
• バックアップ手順とリストア手順を通して一貫した所有者名を使用します。
• passwordaccess オプションを使用して、保護パスワード・ファイルへのアクセスを管理します。
• データ移動のセッションは、タスク完了後に終了して、サーバー上の装置が他のセッション用に解放されるようにしてください。
• LAN フリー・データ転送を許可するには、 multithread フラグをオンに設定して dsmSetup 関数呼び出しを使用します。
• AIX®では、マルチスレッド・アプリケーションまたは LAN フリーを使用している場合 (特に複数のプロセッサーを持つマシン上で実行している場合)、アプリケーションを開始する前に環境変数 AIXTHREAD_SCOPE を S に設定すると、パフォーマンスが向上し、より確かなスケジューリングを行うことができます。 例えば次のとおりです。

    EXPORT AIXTHREAD_SCOPE=S

  AIXTHREAD_SCOPE を S に設定すると、デフォルトの属性で作成されたユーザー・スレッドが、システム全体の競合スコープに置かれます。 このユーザー・スレッドはカーネル・スレッドにバインドされ、カーネルによってスケジュールされます。 基盤となるカーネル・スレッドは、その他のユーザー・スレッドとは共用されません。 詳しくは、 マルチスレッド化の使用を参照してください。
• どの時点でも、ある API 関数を呼び出すスレッドが 1 つのセッション内で 1 つだけであるようにしてください。 同じセッション・ハンドルを使用して複数のスレッドを使用する各アプリケーションは、API 呼び出しを同期化する必要があります。 例えば、mutex を使用して次のように API 呼び出しを同期化します。
  • getTSMMutex()
  • issue TSM API call
  • releaseTSMMutex()
  この手法は、スレッドがハンドルを共有する場合にのみ使用してください。 各呼び出しが異なるセッション・ハンドルを使用する場合は、API 関数の並列呼び出しを使用できます。

• データ移動のための消費先/作成元のスレッド化モデルを実装してください。 API 呼び出しは同期され、 dsmGetData function および dsmSendData function の呼び出しは終了するまでブロックされます。 消費先/作成元モデルを使用することにより、アプリケーションは、ネットワークの待機期間中に次のバッファーを読み取ることができます。 また、データの読み取り/書き込みとネットワークの分離により、ネットワークのボトルネックや遅延がある場合でもパフォーマンスが向上します。 一般に、次のようになります。

  Data thread <---> shared queue of buffers <---> communication
  thread (issue calls to the IBM Storage Protect API)

• オーバーヘッドを生じないように、複数の操作に同じセッションを使用します。 多数の小さなオブジェクトを取り扱うアプリケーションでは、同じセッションを複数の小さな操作にわたって使用できるよう、セッション・プールを実装します。 オーバーヘッドは、 IBM Storage Protect サーバーへのセッションのオープンとクローズに関連しています。 dsmInit/dsmInitEX 呼び出しは、たとえマルチスレッド・アプリケーションでも一度に 1 つのスレッドだけがサインオンできるよう、直列化されます。 また、サインオン時に、API はサーバーがすべての操作を実行できるよう、サーバーに対していくつかの一回限りの照会を送信します。 これらの照会には、ポリシー、オプション、ファイル・スペース、およびローカル構成が含まれます。

IBM Storage Protect サーバーは、一部の操作中にファイル・スペース・データベース項目をロックします。 IBM Storage Protect API アプリケーションを設計する場合は、以下の規則が適用されます。

• 照会によって、トランザクション全体にわたってファイル・スペースがロックされます。
• 照会によるロックは、他の照会操作と共有できるため、同一のファイル・スペースで複数の照会操作を並行して実行することができます。
• IBM Storage Protect サーバー・データベース (DB Chg) を変更するには、send、get、rename、update、および delete 操作を使用します。
• DB Chg 操作を完了するには、トランザクションの最後 でデータベース変更の間、ファイル・スペースをロックする必要があります。
• 同一ファイル・スペースで複数の DB Chg 操作を並行して実行することができます。 トランザクションの終了時に、シーケンスがロックを待っている間に遅延が生じる場合があります。
• 照会ロックを DB Chg 操作と共有することはできません。 DB Chg 操作は同一ファイル・スペースでの照会の開始を遅らせるため、同一ファイル・スペースの DB Chg 操作から照会を分離して直列化するようにアプリケーションを設計してください。

• 具体的なオブジェクト名は、高位オブジェクト名および低位オブジェクト名です。 例えば、日付スタンプのような固有 ID が名前に含まれている場合、バックアップ ・オブジェクトは常に活動状態です。 オブジェクトは、dsmDeleteObj 関数呼び出しによって非活動としてマーク付けされた場合にのみ、有効期限が切れます。
• オブジェクトのリストア方式によって、照会が容易な名前の形式が決まります。 部分オブジェクト・リストア (POR) を使用する場合は、圧縮は使用できません。 圧縮を抑止するには、 dsmSendObj objAttr objCompressed=bTrue 関数を使用します。

リストア時には、リストアの順序に特に注意してください。 照会の後、リストアの前に上記の ID 値に基づいてソートを行います。 複数のタイプのシリアル・メディアを使用している場合は、さまざまなタイプのメディアに別々のセッションでアクセスしてください。 詳しくは、次のトピックを参照してください。

リストア順序によるオブジェクトの選択およびソート