tivoli workload scheduler - ibm...本書「ibm ®tivoli workload scheduler...

Tivoli Workload Schedulerバージョン 8.6 (2012 年 6 月改訂)

計画およびインストール

SC88-9679-08(英文原典：SC32-1273-11)

��

お願い本書および本書で紹介する製品をご使用になる前に、特記事項に記載されている情報をお読みください。

本書は、IBM Tivoli Workload Scheduler バージョン 8、リリース 6、モディフィケーション・レベル 0 フィックスパック 1 (プログラム番号 5698-WSH)、および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

本書は、SC88-9679-07 の改訂版です。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： SC32–1273–11

Workload Scheduler

Version 8.6 (Revised June 2012)

Planning and Installation

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

第1刷 2012.6

© Copyright IBM Corporation 1999, 2012.

目次図 . . . . . . . . . . . . . . . . . v

表 . . . . . . . . . . . . . . . . . vii

この資料について . . . . . . . . . . . ix当リリースでの新規機能 . . . . . . . . . . ix本書の対象読者 . . . . . . . . . . . . . ix資料 . . . . . . . . . . . . . . . . . ixアクセシビリティー . . . . . . . . . . . . ixTivoli 技術研修 . . . . . . . . . . . . . xサポート情報 . . . . . . . . . . . . . . x

第 1 部計画 . . . . . . . . . . . . . 1ネットワーク計画 . . . . . . . . . . . . . 1

Tivoli Workload Scheduler 環境 . . . . . . . 1環境の計画 . . . . . . . . . . . . . . 8ドメインの計画 . . . . . . . . . . . . 18ワークステーション・クラス . . . . . . . 25時間帯に関する考慮事項 . . . . . . . . . 25

第 2 部 Tivoli Workload Scheduler . . 27インストールの準備 . . . . . . . . . . . 27インストールの概要 . . . . . . . . . . 27前提条件の検査 (UNIX および Linux) . . . . 28インストールの注意点 . . . . . . . . . . 29インストール・メディア . . . . . . . . . 31Tivoli Workload Automation のインスタンス . . 32リレーショナル・データベース管理システム . . 34インストール方法の選択 . . . . . . . . . 35インストール・ログ・ファイル . . . . . . . 38Tivoli Workload Scheduler ユーザー . . . . . 40Windows サービス . . . . . . . . . . . 43

インストールまたはアップグレード前の TivoliWorkload Scheduler データベース表の作成またはアップグレード . . . . . . . . . . . . . . 43

DB2 を使用している場合のデータベース表の作成またはアップグレード . . . . . . . . . . 44Oracle を使用している場合のデータベース表の作成またはアップグレード . . . . . . . . . 56

インストール中 . . . . . . . . . . . . . 70ユーザー許可要件 . . . . . . . . . . . 70DB2 のインストール . . . . . . . . . . 70インストール・ウィザードの使用 . . . . . . 71サイレント・インストールの実行 . . . . . . 100twsinst を使ったエージェントのインストール 106Software Distribution を使ったエージェントのインストール . . . . . . . . . . . . . 115Job Brokering Definition Console のインストール 125Tivoli Workload Scheduler for Additional Plug-insの使用による追加プラグインのインストール . . 126

アップグレード . . . . . . . . . . . . . 133

エンジンの共存およびアップグレードに関する注意事項 . . . . . . . . . . . . . . . 134ユーザー許可要件 . . . . . . . . . . . 135前提条件の検査 (UNIX および Linux) . . . . 136マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインスタンスのアップグレード . . . . . . . 136エージェントおよびドメイン・マネージャーのアップグレード . . . . . . . . . . . . 168コマンド行クライアントのアップグレード . . . 186レジストリー・ファイルが破損している場合のアップグレード . . . . . . . . . . . . 187機能の追加 . . . . . . . . . . . . . 190

構成 . . . . . . . . . . . . . . . . 190環境変数の設定 . . . . . . . . . . . . 191マスター・ドメイン・マネージャーの構成 . . . 191バックアップ・マスター・ドメイン・マネージャーの構成 . . . . . . . . . . . . . . 192ドメイン・マネージャーの構成 . . . . . . 194バックアップ・ドメイン・マネージャーの構成 194動的ドメイン・マネージャーの構成 . . . . 195バックアップ・動的ドメイン・マネージャーの構成 . . . . . . . . . . . . . . . . 195フォールト・トレラント・エージェントの構成 196動的エージェントの構成 . . . . . . . . . 197コマンド行クライアントの構成 . . . . . . 198WebSphere Application Server の構成 . . . . 198機能の追加 . . . . . . . . . . . . . 198インストール後の動的スケジューリングの使用可能化 . . . . . . . . . . . . . . . 201

アンインストール中 . . . . . . . . . . . 203ユーザー許可要件 . . . . . . . . . . . 204動的ドメイン・マネージャーのアンインストール . . . . . . . . . . . . . . . . 205ウィザードを使用したアンインストール . . . 206サイレント・アンインストールの実行 . . . . 206twsinst スクリプトの使用によるエージェントのアンインストール . . . . . . . . . . . 207Software Distribution CLI の使用によるアンインストール . . . . . . . . . . . . . . 209コマンド行クライアントのアンインストール . . 209Tivoli Workload Scheduler for Additional Plug-insを使用した追加プラグインのアンインストール . 210

インストール、マイグレーション、およびアンインストールのトラブルシューティング . . . . . . 214インストール・プロセスのログ・ファイル . . . 215失敗した対話式 InstallShield ウィザード・インストールのリカバリー . . . . . . . . . 216失敗したサイレント InstallShield ウィザード・インストールのリカバリー . . . . . . . . 227失敗したアップグレードのリカバリー . . . . 228

© Copyright IBM Corp. 1999, 2012 iii

Tivoli Workload Scheduler for Additional Plug-insサイレント・インストールの戻りコードの分析 . 228問題のシナリオ: インストール、再インストール、アップグレード、マイグレーション、およびアンインストール . . . . . . . . . . . 232インストールのセキュリティーの影響 . . . . 281インストールの検証 . . . . . . . . . . 282Tivoli Workload Scheduler の手動によるアンインストール . . . . . . . . . . . . . . 283Tivoli Workload Scheduler コネクターの手動によるアンインストール . . . . . . . . . . 288Windows レジストリー・キーの除去 . . . . . 291

第 3 部 Dynamic Workload Console 295準備 . . . . . . . . . . . . . . . . 295

Dynamic Workload Console の概要 . . . . . 295インストールの概要 . . . . . . . . . . 295インストールの注意点 . . . . . . . . . 296

構成 . . . . . . . . . . . . . . . . 300始めに . . . . . . . . . . . . . . . . 301

Tivoli Workload Scheduler ポートフォリオ . . . 302Dynamic workload broker ポートフォリオ . . . 303最初に実行する操作 . . . . . . . . . . 304

アップグレード . . . . . . . . . . . . . 306認証の更新 . . . . . . . . . . . . . 306組み込み WebSphere Application Server にインストールされたコンソールのアップグレード . . . 307アップグレードの実行 . . . . . . . . . 309

アンインストール中 . . . . . . . . . . . 310ウィザードを使用したアンインストール . . . 310サイレント・モードでのアンインストール . . . 311

インストール、アップグレード、およびアンインストールのトラブルシューティング . . . . . . . 311インストールおよびアンインストールのログ・ファイルとトレース・ファイル . . . . . . . 312失敗した InstallShield ウィザード・インストールのリカバリー . . . . . . . . . . . . 312失敗したアップグレードのリカバリー . . . . 313統合 Dynamic Workload Console の手動でのアンインストール . . . . . . . . . . . . 313スタンドアロン Dynamic Workload Console バージョン 8.6.0 インスタンスの手動でのアンインストール . . . . . . . . . . . . . . . 314トラブルシューティング・シナリオ . . . . . 316

第 4 部チュートリアル . . . . . . . 325

Tivoli Workload Scheduler チュートリアル・ユーティリティーの使用法 . . . . . . . . . . . 325

Tivoli Workload Scheduler データベースへのデータの取り込み . . . . . . . . . . . . 325スケジューリング・シナリオの概要 . . . . . 327実動計画の作成と処理 . . . . . . . . . 328スケジューリング・シナリオの実行 . . . . . 329データベースからのチュートリアル・オブジェクトの除去 . . . . . . . . . . . . . . 333

付録 . . . . . . . . . . . . . . . 335レジストリー・ファイル . . . . . . . . . . 335応答ファイルの使用 . . . . . . . . . . . 336Tivoli Workload Scheduler 応答ファイルのプロパティー . . . . . . . . . . . . . . . . 336Dynamic Workload Console 応答ファイルのプロパティー . . . . . . . . . . . . . . . . 349Job Brokering Definition Console 応答ファイルのプロパティー . . . . . . . . . . . . . . 354Tivoli Workload Scheduler Integration Workbench のインストールおよびアップグレード . . . . . . 355

Tivoli Workload Scheduler Integration Workbenchを Eclipse のバンドル・バージョンと共にインストールする . . . . . . . . . . . . . 356Eclipse サイトを使用して Tivoli WorkloadScheduler Integration Workbench を Eclipse の既存のインスタンスと共にインストールする . . . 356リモート Eclipse サイトを使用して TivoliWorkload Scheduler Integration Workbench をEclipse の既存のインスタンスと共にインストールする . . . . . . . . . . . . . . . 357Eclipse のバンドル・バージョンを使用してインストールされている Tivoli Workload SchedulerIntegration Workbench をアップグレードする . . 357プラグインとしてインストールされている TivoliWorkload Scheduler Integration Workbench をアップグレードする . . . . . . . . . . . 358

インストールされている製品の検出 . . . . . . 358Tivoli Workload Scheduler のアップグレード中にバックアップされるファイル . . . . . . . . . 359DB2 表スペースの相対パス. . . . . . . . . 360

特記事項. . . . . . . . . . . . . . 361商標 . . . . . . . . . . . . . . . . 362

索引 . . . . . . . . . . . . . . . 365

iv IBM Tivoli Workload Scheduler: 計画およびインストール

図1. 静的ワークロードを実行する Tivoli Workload

Scheduler 環境の概要を示す図 . . . . . . . 22. Tivoli Workload Scheduler 動的環境の概要を示す図 . . . . . . . . . . . . . . . 5

3. 静的スケジューリング機能を持つ分散ワークロード環境 . . . . . . . . . . . . . 10

4. 動的なスケジューリング機能付きの分散ワークロード環境 . . . . . . . . . . . . . 12

5. 静的および動的スケジューリング機能を持つ分散ワークロード環境 . . . . . . . . . . 14

6. 外部システムと統合されたワークロード環境 16

7. z/OS の分散ドリブン・ワークロード環境 188. 単一ドメイン・トポロジー . . . . . . . 229. 複数サイトでの単一ドメイン・トポロジー 23

10. 複数ドメイン・トポロジー . . . . . . . 2411. アップグレード手順のフローチャート 13812. インストール失敗後のウィザード・パネル 21613. 障害が起きたステップを示しているステッ

プ・リスト・ウィンドウ . . . . . . . . 21814. ステップの「状況」タブ . . . . . . . . 21915. ステップの「プロパティー」タブ . . . . . 22016. ステップの「出力」タブ . . . . . . . . 221

© Copyright IBM Corp. 1999, 2012 v

vi IBM Tivoli Workload Scheduler: 計画およびインストール

表1. シンボリック・リンクのオプション . . . . 312. Tivoli Workload Automation の既存のインスタンスへのインストール . . . . . . . . . 34

3. インストール・ログ・ファイル . . . . . . 384. DB2 セットアップ・ファイル . . . . . . 715. 応答ファイル . . . . . . . . . . . 1006. 言語パックをインストールするためのパラメーターのリスト . . . . . . . . . . . 124

7. サイレント・インストールを実行するオプション . . . . . . . . . . . . . . 130

8. インストール・ログ・ファイル . . . . . 1329. Tivoli Workload Scheduler コンポーネントのアップグレードの可用性 . . . . . . . . 134

10. 直接アップグレードのシナリオ . . . . . 13911. 並列アップグレードのシナリオ . . . . . 14012. アンインストール・ログ・ファイル . . . . 21113. サイレント・アンインストールを実行するオ

プション . . . . . . . . . . . . . 213

14. デフォルトの InstallAnywhere エラー・メッセージ . . . . . . . . . . . . . . 229

15. 追加プラグインの InstallAnywhere エラー・メッセージ . . . . . . . . . . . . . 231

16. Dynamic Workload Console 応答ファイル 26817. Tivoli Workload Automation の既存のインスタ

ンスへのインストール . . . . . . . . 29718. インストール・ログ・ファイル . . . . . 30019. チュートリアル・ユーティリティーによって

ダウンロードされるオブジェクト . . . . . 32620. スケジューリング・シナリオのリスト 32721. レジストリー・ファイルの属性 . . . . . 33522. Tivoli Workload Scheduler 応答ファイルのプ

ロパティー . . . . . . . . . . . . 33723. Dynamic Workload Console 応答ファイルのプ

ロパティー . . . . . . . . . . . . 35024. Job Brokering Definition Console 応答ファイル

のプロパティー . . . . . . . . . . . 355

© Copyright IBM Corp. 1999, 2012 vii

viii IBM Tivoli Workload Scheduler: 計画およびインストール

この資料について

本書「IBM® Tivoli® Workload Scheduler 計画およびインストール」は、IBM Tivoli

Workload Scheduler ネットワークの計画、インストール、マイグレーション、および構成に関する情報を提供します。

当リリースでの新規機能このリリースの新機能またはこのリリースで変更された機能については、「Tivoli

Workload Automation: 概要」を参照してください。

このリリースが対応する APAR について詳しくは、http://www.ibm.com/support/

docview.wss?rs=672&uid=swg24027501 の Tivoli Workload Scheduler のダウンロード文書、および http://www.ibm.com/support/docview.wss?rs=672&uid=swg24029125 のDynamic Workload Console のダウンロード文書を参照してください。

本書の対象読者

本書は、以下のような読者を対象としています。

v ネットワークの計画およびインストールを実行する Tivoli Workload Scheduler IT

管理者

v 製品の計画およびインストールを実行する Dynamic Workload Console IT 管理者

v ネットワーク・トポロジーを計画するスペシャリスト

v ネットワークをインストールする IT 管理者

v システム構築の担当者

資料Tivoli Workload Automation の資料の詳細については、「Tivoli Workload Automation

資料」に記載されています。この文書には、各資料で使用される規則に関する情報も含まれています。

この製品で使用されている用語の用語集は、「Tivoli Workload Automation 用語集」にあります。

これらは両方とも、別個の資料としてインフォメーション・センターに置かれています。

アクセシビリティーアクセシビリティー機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるようにサポートします。この製品では、支援テクノロジーを使用して、音声に従ってインターフェースをナビゲートすることができます。また、グラフィカル・ユーザー・インターフェースの機能はすべて、マウスの代わりにキーボードを使用して操作することもできます。

© Copyright IBM Corp. 1999, 2012 ix

http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501



Dynamic Workload Console について詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」(SC88-9680) の付録『アクセシビリティー』を参照してください。

Tivoli 技術研修以下は英語のみの対応となります。 Tivoli 技術研修の情報については、以下のIBM Tivoli Education Web サイトを参照してください。

http://www.ibm.com/software/tivoli/education

サポート情報以下は英語のみの対応となります。ご使用の IBM ソフトウェアに問題がある場合は、早く解決する必要があります。IBM では、次のような方法で、お客様が必要とされるサポートを提供しています。

オンラインIBM Software Support サイト (http://www.ibm.com/software/support/

probsub.html) にアクセスして、指示に従います。

IBM Support AssistantIBM Support Assistant (ISA) は無償で提供されるローカルのソフトウェア保守容易性ワークベンチで、IBM ソフトウェア製品に関する疑問や問題の解決に役立ちます。 ISA を使用することで、問題判別のためのサポート関連情報およびサービス・ツールに素早くアクセスすることができます。 ISA

ソフトウェアのインストールについては、http://www.ibm.com/software/

support/isa を参照してください。

トラブルシューティング・ガイド問題の解決について詳しくは、本製品の問題判別情報を参照してください。

問題を解決するためのこれら 3 つの方法に関する詳細は、『サポート情報』を参照してください。

これら 3 つの問題解決の方法について詳しくは、「Tivoli Workload Scheduler トラブルシューティング・ガイド」(SC88-9681) のサポート情報に関する付録を参照してください。

x IBM Tivoli Workload Scheduler: 計画およびインストール

http://www.ibm.com/software/tivoli/education

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/isa

http://www.ibm.com/software/support/isa

第 1 部計画

ネットワーク計画

このセクションでは、Tivoli Workload Scheduler ネットワークの計画に役立つ情報を提供します。

Tivoli Workload Scheduler 環境

Tivoli Workload Scheduler ネットワークは、ジョブ処理を実行するリンクされた複数のワークステーションのセットから構成されます。ネットワークは、それぞれが管理ハブとして機能するドメイン・マネージャー・ワークステーションがある 1

つ以上のドメイン、および 1 つ以上のエージェント・ワークステーションから構成されます。

Tivoli Workload Scheduler を使用して、以下の方法のいずれかでワークロードを実行できます。

静的既存のジョブ・タイプ、例えばフォールト・トレラント・エージェントの特定のワークステーション上の docommand とスクリプト、または標準のエージェント・タイプを実行する方法。

動的既存のジョブ・タイプおよび拡張オプション付きジョブ・タイプを実行して、製品がそれを実行するために必要なハードウェアとソフトウェアの要件を最も満たすワークステーションにそれを割り当てることができるようにする方法。

拡張オプション付きジョブ・タイプとは、製品と共に提供されているものとカスタム・プラグインを通して実装された追加タイプの両方です。例えば、製品と共に提供されるものとしては、DB2®、ファイル転送、および Web

サービスがあります。カスタム・プラグインを通して実装されたものとは、Software Development Kit (SDK) の Integration Workbench を使用してユーザーが開発したものです。

ワークロードをそのように実行するかに応じて、ネットワークにさまざまなコンポーネントをインストールして構成する必要があります。

2ページの図 1 は、静的ワークロードを実行する典型的な Tivoli Workload

Scheduler 環境の概要をグラフィカルに示しています。

© Copyright IBM Corp. 1999, 2012 1

図 1 で、マスター・ドメインはワークロードを静的に実行する主要なコンポーネント、および 2 つのレベルのサブドメインと共に示されています。使用可能なユーザー・インターフェースも示されています。基本的なドメイン階層構造の例が示されています。各ドメインの名前は、「D1」、「D2」、等です。これらの概念すべては、以下のセクションで説明されます。

ワークロードを静的に実行するには、以下のコンポーネントをインストールします。

マスター・ドメイン・マネージャーマスター・ドメイン・マネージャーは、Tivoli Workload Scheduler ネットワークの最上位のワークステーションです。これは、スケジューリング・オブジェクト定義を保管するリレーショナル・データベースを含むか、またはそれに接続されています。これはプランが作成または拡張されるときに実動ファイルを作成または更新して、そのファイルをネットワークに配布します。これはネットワーク用のすべてのロギングおよびレポート作成を行います。

�ドメインその-(Dn)

�ドメインその-(Dn)

MD

D1 D2

D3 D4 D5

ユーザー・インターフェースユーザー・インターフェース

マスター・ドメイン(MD)


ドメイン��の�

データベースデータベースマスター・

ドメイン・

マネージャー

マスター・

ドメイン・

マネージャー

Tivoli DynamicWorkload

Console


Console

コマンド�クライアント

リモート( )


リモート( )

バックアップ・マスター・ドメイン・マネージャーエージェント( )


フォールト・トレラント・エージェント

フォールト・トレラント・エージェント

�ドメイン・マネージャーエージェント( )




コマンド・

ライン

コマンド・

ライン

Webブラウザー

Webブラウザー

D6

バックアップ・ドメイン・マネージャーエージェント( )

バックアップ・ドメイン・マネージャーエージェント( )

フォールト・

トレラント・

エージェント

フォールト・

トレラント・

エージェント

図 1. 静的ワークロードを実行する Tivoli Workload Scheduler 環境の概要を示す図

2 IBM Tivoli Workload Scheduler: 計画およびインストール

これはイベント・ドリブン・ワークロード自動化フィーチャーのためのイベント処理サーバーの役割を果たすことができます。

バックアップ・マスター・ドメイン・マネージャー

インストール時にバックアップ・マスター・ドメイン・マネージャーを定義して、マスター・ドメイン・マネージャーによって使用されるデータベースまたはそのデータベースのミラーを指すようにします。この方法で、バックアップ・マスター・ドメイン・マネージャーでは常に最新のデータが使用可能となります。

ドメイン・マネージャーマルチドメイン・ネットワークを必要としており、ワークロードを静的に実行するように定義済みのワークステーションにワークロードを割り当てることによって管理する場合は、このコンポーネントをインストールします。マルチドメイン・ネットワークでは、マスター・ドメインの下のすべてのドメインに、そのドメイン内のワークステーションを管理するためのドメイン・マネージャーとして構成されたフォールト・トレラント・エージェントがあります。ドメイン・マネージャーは、フォールト・トレラント、標準、および拡張エージェントを管理できます。各ドメイン・マネージャーは、1 つ上位にあるドメインのフォールト・トレラント・エージェントです。ドメイン・マネージャーを定義するには、ワークステーションにフォールト・トレラント・エージェントをインストールしてから、ワークステーション定義でそれをマネージャーとして定義します。

バックアップ・ドメイン・マネージャードメイン・マネージャーに対するバックアップが必要な場合は、このコンポーネントをインストールします。ドメイン・マネージャーに問題が生じた場合、フォールト・トレラント・エージェントをドメイン・マネージャーとして構成して、簡単な手順でそれに切り替えることができます。

エージェントエージェントは、Tivoli Workload Scheduler マスター・ドメイン・マネージャーによって制御されるジョブを実行する、ネットワーク内のワークステーションです。 DVD からエージェント・インストールを選択して、またはPassport Advantage®・オンライン Web サイトを使用して eImage をダウンロードして、エージェントをインストールします。エージェントをインストールした後、ワークステーション定義を使用して、そのタイプを定義します。

フォールト・トレラント・エージェントフォールト・トレラント・エージェントは、ドメイン・マネージャーがない場合にローカルな依存関係を解決してジョブを起動することができます。それには、実動制御ファイルのコピーがあります。これにより、フォールト・トレラント・エージェントは、動的ドメイン・マネージャーまたはネットワーク接続がダウンした場合でも、処理を続けることができます。簡単な再構成によって、それらを従属のドメイン・マネージャーとすることができます。フォールト・トレラント・エージェントを定義するには、ワークステーションにフォールト・トレラント・エージェントをインストールしてから、ワークステーション定義でそれをフォールト・トレラントとして定義します。

第 1 部計画 3

標準エージェントそのドメイン・マネージャーの指示の下でのみジョブを起動するエージェント。これはフォールト・トレラントではありません。標準エージェントを定義するには、ワークステーションにフォールト・トレラント・エージェントをインストールしてから、ワークステーション定義でそれを標準エージェントとして定義します。

拡張エージェント拡張エージェントは、選択したアプリケーション (SAP R/3、Oracle

E-Business Suite、PeopleSoft、および z/OS®) に対する拡張されたジョブ処理に使用される論理定義 (物理ワークステーションによってホストされる)

です。拡張エージェントをインストールする方法については、「Tivoli

Workload Scheduler for Applications ユーザーズ・ガイド」を参照してください。

注: 特別な役割 (マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、ドメイン・マネージャー、バックアップ・ドメイン・マネージャー) を持つすべてのエージェントは、ジョブがスケジュールされたフォールト・トレラント・エージェントとしても機能できます。

5ページの図 2 は、動的ワークロードを実行する典型的な Tivoli Workload

Scheduler 環境の概要をグラフィカルに示しています。


図 2 で、マスター・ドメインはワークロードを動的に実行する主要なコンポーネント、および 2 つのレベルの動的サブドメインと共に示されています。使用可能なユーザー・インターフェースも示されています。基本的なドメイン階層構造の例が示されています。各ドメインの名前は、「D1」、「D2」、等です。これらの概念すべては、以下のセクションで説明されます。

ワークロードを動的に実行する場合は、以下のコンポーネントをインストールします。

マスター・ドメイン・マネージャーマスター・ドメイン・マネージャーは、Tivoli Workload Scheduler ネットワークの最上位のワークステーションです。これは、スケジューリング・オブジェクト定義を保管するリレーショナル・データベースを含むか、またはそれに接続されています。これはプランが作成または拡張されるときに実動ファイルを作成または更新して、そのファイルをネットワークに配布します。これはネットワーク用のすべてのロギングおよびレポート作成を行います。

�ドメインその(Dn) -

�ドメインその(Dn) -

MDMD

D1 D2

D3 D4 D5

ユーザー・インターフェースユーザー・インターフェース



ドメイン��の�

データベースデータベースマスター・

ドメイン・

マネージャー

マスター・

ドメイン・

マネージャー


Console


Console


リモート( )


リモート( )



,-エージェント,-

エージェント

�,-ドメイン・マネージャー�,-ドメイン・マネージャー

�,-ドメイン・マネージャーエージェント( )

�,-ドメイン・マネージャーエージェント( )

コマンド・

ライン

コマンド・

ライン

Webブラウザー

Webブラウザー

D6

バックアップ,-ドメイン・マネージャー

バックアップ,-ドメイン・マネージャー

,-

エージェント

,-

エージェント

図 2. Tivoli Workload Scheduler 動的環境の概要を示す図

第 1 部計画 5

これはイベント・ドリブン・ワークロード自動化フィーチャーのためのイベント処理サーバーの役割を果たすことができます。


インストール時にバックアップ・マスター・ドメイン・マネージャーを定義して、マスター・ドメイン・マネージャーによって使用されるデータベースまたはそのデータベースのミラーを指すようにします。この方法で、バックアップ・マスター・ドメイン・マネージャーでは常に最新のデータが使用可能となります。

動的ドメイン・マネージャーマルチドメイン・ネットワークを必要としており、ワークロードを静的にも動的にも管理する場合は、このコンポーネントをインストールします。マスター・ドメインの下のすべてのドメインに、そのドメイン内のワークステーションを管理するための動的ドメイン・マネージャーがあります。各動的ドメイン・マネージャーは、1 つ上位にあるドメインのエージェントです。動的ドメイン・マネージャーを定義するには、動的ドメイン・マネージャーをインストールしてから、 195ページの『動的ドメイン・マネージャーの構成』の手順を実行します。

バックアップ動的ドメイン・マネージャー動的ドメイン・マネージャーをバックアップする場合は、このコンポーネントをインストールします。ご使用の動的ドメイン・マネージャーに問題が発生した場合、簡単な手順でそれに切り替えることができます。

エージェントエージェントは、Tivoli Workload Scheduler マスター・ドメイン・マネージャーによって制御されるジョブを実行する、ネットワーク内のワークステーションです。 DVD からエージェント・インストールを選択して、またはパスポート・アドバンテージ・オンライン Web サイトを使用して eImage

をダウンロードして、エージェントをインストールします。

動的エージェント以下の機能を持つエージェントです。

ワークロードを動的に実行サーバーとそのリソースの状況について通信します。このように、この製品は、以下を実行して、最も有効なリソースに対してワークロードを動的に実行できます。v スケジューリング環境のリソースを自動的に検出v リソースの変更への自動的な対応v 必要に応じた付加的なリソースの要求v ジョブの要件と使用可能なリソースとを一致させることv リソース利用の制御と最適化

上記にリストした特性は、高可用性およびロード・バランシングの潜在可能性を環境に提供し、仮想化された環境によく対応します。

計画内のジョブ・ストリームの一部として、または特定のサブミットを通して、ジョブがサブミットされると、Tivoli

Workload Scheduler はジョブ要件、使用可能なリソース、お


よび関連する特性を検査し、それを実行するための要件を最も満たすリソースにジョブをサブミットします。

既存のジョブ・タイプおよび拡張オプション付きジョブ・タイプの両方の実行

以下を実行できます。

v 既存のジョブ・タイプ。例えば、docommand およびスクリプト。

v 拡張オプション付きジョブ・タイプ (製品と共に提供されているものとカスタム・プラグインを通して実装された追加タイプの両方)。例えば、製品と共に提供されるものとしては、DB2、ファイル転送、および Web サービスがあります。カスタム・プラグインを通して実装されたものとは、Software Development Kit (SDK) の Integration

Workbench を使用してユーザーが開発したものです。これらのジョブ・タイプを実行するには、Java ランタイムもインストールする必要があります。

Dynamic Workload Broker の論理リソースの管理サーバー上の Dynamic Workload Broker の resource コマンドをエージェントからリモートで実行できます。resourceコマンドを管理するには、Java ランタイムもインストールする必要があります。

エージェントをインストールした後に、 197ページの『動的エージェントの構成』を使用して、そのタイプを定義します。

注: 動的エージェントはマスター・ドメイン・マネージャーまたは動的ドメイン・マネージャーに直接接続されている必要があります。

拡張エージェント拡張エージェントは、選択したアプリケーション (SAP R/3、Oracle

E-Business Suite、PeopleSoft、および z/OS) に対する拡張されたジョブ処理に使用される論理定義 (物理ワークステーションによってホストされる) です。拡張エージェントをインストールする方法について詳しくは、Tivoli Workload Scheduler for Applications の「Tivoli Workload Scheduler for Applications ユーザーズ・ガイド」を参照してください。

Tivoli Workload Scheduler インターフェース

Tivoli Workload Scheduler には、実稼働環境を管理するための以下のユーザー・インターフェースが含まれています。

マスター・ドメイン・マネージャーのコマンド行マスター・ドメイン・マネージャーのコマンド行は、マスター・ドメイン・マネージャーをインストールするときに自動的にインストールされます。コマンド行インターフェースは、マスター・ドメイン・マネージャーとして機能しているワークステーションからのみ実行されます。コマンド行から、マスター固有のバイナリーおよびオプションを管理できます。バックアップ・

第 1 部計画 7

マスター・ドメイン・マネージャー上にも、バックアップ・マスター・ドメイン・マネージャーのコマンド行が存在します。

Dynamic Workload ConsoleTivoli Workload Scheduler オブジェクトを作成、変更、モニター、制御、および削除するための Web ベースのインターフェース。サポートされるWeb ブラウザーがインストールされているネットワーク内のいずれかのシステムから、コンソールとやりとりすることができます。詳しくは、『Dynamic Workload Console』を参照してください。

コマンド行クライアントマスター・ドメイン・マネージャー上で使用される以下のコマンドを他のワークステーションにインプリメントできるようにする Tivoli Workload

Scheduler のコンポーネント。使用できるコマンドは、次のとおりです。

v Composer

v Optman

v Planman showinfo および unlock (その他の planman コマンドは、マスター・ドメイン・マネージャー上でローカルに実行する必要があります。)

Tivoli Dynamic Workload Broker コマンド行マスター・インストール時に動的スケジューリング機能の使用可能化を選択すると、自動的にインストールおよび構成されます。これには、動的スケジューリングのジョブを直接実行依頼して管理するコマンドや、ジョブ JSDL

定義およびリソースを管理するコマンドなどが含まれます。「Tivoli

Workload Scheduler ワークロードの動的なスケジューリング」を参照してください。

Job Brokering Definition Console構造化された編集ツールで、Job Submission Description Language (JSDL) ファイルの作成および変更に使用します。これらのファイルは、ジョブ定義としてジョブ・リポジトリーに保存され、実行依頼の際に使用できるようになります。 JSDL ファイルは、JSDL スキーマで定義される XML の構文およびセマンティクスに従います。詳しくは、「Tivoli Workload Scheduler リファレンス・ガイド」(SC88-9680) を参照してください。

さらに、Tivoli Workload Automation には IBM Tivoli Workload Scheduler for z/OS

と Dynamic Workload Console を接続するコンポーネントである、z/OS Connectorが含まれています。詳しくは、「Tivoli Workload Scheduler for z/OS 計画およびインストール」を参照してください。

Tivoli Workload Scheduler コンポーネントに関する詳細な説明については、「Tivoli

Workload Automation 概要」を参照してください。

環境の計画

このセクションでは、Tivoli Workload Automation 製品とコンポーネントに関する標準的なインストール・シナリオをいくつか取り上げます。こうした標準的なシナリオでは、考え得る最小限のシステム・リソースに特定のソリューションをデプロイする方法が示されます。


静的スケジューリング機能を持つ分散ワークロード環境

分散ネットワークにまたがるワークロードを静的に実行するには、この構成を使用します。 10ページの図 3 は、十分に機能する Tivoli Workload Scheduler 環境をインストールし、分散ワークロードを管理するために必要なシステム・リソースを示しています。

第 1 部計画 9

TWSマスター・ドメイン・マネージャー


DBサーバー

DBサーバー

サーバー・システムサーバー・システム

コンポーネント34インフラストラクチャー

TDWCサーバーTDWCサーバー

TWAインスタンスTWAインスタンス

TWSエージェント・ネットワーク


TWSFTA

TWSFTA

図 3. 静的スケジューリング機能を持つ分散ワークロード環境


動的なスケジューリング機能付きの分散ワークロード環境

分散ネットワークにまたがるワークロードを動的に実行するには、この構成を使用します。この構成では、Java ジョブのためのランタイム環境をエージェントに追加するかどうかを選択できます。ランタイム環境は、以下の目的で使用されます。

v 拡張オプション付きエージェント・ジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) 上で実行するため。

v サーバー上の Dynamic Workload Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にするため。

動的スケジューリング、アプリケーション・ジョブ・プラグインの実行方法、およびサーバー上の Dynamic Workload Broker リソース・コマンドについては、「Tivoli

Workload Scheduler: ワークロードの動的なスケジューリング」を参照してください。

12ページの図 4 は、十分に機能する Tivoli Workload Scheduler 環境をインストールし、分散ワークロードを動的に実行するために必要なシステム・リソースを示しています。

注: 動的エージェントは、 12ページの図 4 に示されているように直接そのマスター・ドメイン・マネージャーに接続するか、 14ページの図 5 に示されているように動的ドメイン・マネージャーを通して接続することができます。

第 1 部計画 11


DBサーバー


コンポーネント*+インフラストラクチャー

TDWCサーバー

TWAインスタンス



TWS,-

エージェント

Javaランタイム

TWS,-

エージェント

TDWCサーバー

図 4. 動的なスケジューリング機能付きの分散ワークロード環境


静的および動的スケジューリング機能を持つ分散ワークロード環境

分散ネットワークにまたがるワークロードを静的および動的に実行するには、この構成を使用します。この構成では、Java ジョブのためのランタイム環境をエージェントに追加するかどうかを選択できます。ランタイム環境は、以下の目的で使用されます。



動的スケジューリング、アプリケーション・ジョブ・プラグインの実行方法、およびサーバー上の Dynamic Workload Broker リソース・コマンドについては、「Tivoli

Workload Scheduler: ワークロードの動的なスケジューリング」を参照してください。

14ページの図 5 は、十分に機能する Tivoli Workload Scheduler 環境をインストールし、分散ワークロードを静的にも動的にも実行するために必要なシステム・リソースを示しています。Tivoli Workload Scheduler は、ジョブが静的または動的にスケジュールされる各システムにフォールト・トレラント・エージェントと動的エージェントをインストールする必要があります。

注: 動的エージェントは、そのマスター・ドメイン・マネージャーに直接接続するか、 14ページの図 5 に示されているように動的ドメイン・マネージャーを通して接続することができます。

第 1 部計画 13

エンドツーエンド・ワークロード環境

エンドツーエンド環境 (エージェントが z/OS システムと接続されている) では、次のタイプの構成を定義できます。



DBサーバー

DBサーバー


コンポーネント*+インフラストラクチャーコンポーネント*+インフラストラクチャー





TWSドメイン・マネージャー

TWSドメイン・マネージャー

TWS,-

ドメイン・マネージャー

TWS,-


TWS

FTA

TWS

FTA

TWSFTA

TWS,-エー

ジェント

TWS,-エー

ジェント

TWS,-エー

ジェント

TWS,-エー

ジェント

,-エージェント

,-エージェント

DBサーバー

DBサーバー

Javaランタイム

Javaランタイム

図 5. 静的および動的スケジューリング機能を持つ分散ワークロード環境


ワークロードを静的に実行する場合

フォールト・トレラント・エージェントを使用フォールト・トレラント・エンドツーエンド・スケジューリング環境は、メインフレームから分散システムへの静的ワークロードをスケジュールおよび制御するために使用します。分散システムで、フォールト・トレラント・エージェントをインストールし、それらをz/OS サーバーに接続します。詳しくは、「Tivoli Workload

Scheduler for z/OS フォールト・トレランス機能付のエンドツーエンド・スケジューリング」を参照してください。

Tivoli Workload Scheduler for z/OS エージェント (z-セントリック) を使用 z-セントリック・エンドツーエンド・スケジューリング環境は、メ

インフレームから分散システムへの静的ワークロードを低い所有コストでスケジュールおよび制御するために使用します。分散システムで、Tivoli Workload Scheduler for z/OS エージェントをインストールし、それらを z/OS コントローラーに接続します。インストール方法については、「Tivoli Workload Scheduler for z/OS: 計画およびインストール」を参照してください。使用方法については、「Tivoli Workload Scheduler for z/OS: z-セントリック機能付のエンドツーエンド・スケジューリング」を参照してください。

ワークロードを動的に実行する場合

動的機能付き Tivoli Workload Scheduler for z/OS エージェント (z-セントリック) を使用

z-セントリック・エンドツーエンド・スケジューリング環境は、メインフレームから分散システムへの動的ワークロードを低い所有コストでスケジュールおよび制御するために使用します。分散システムで、Tivoli Workload Scheduler for z/OS エージェントをインストールし、動的スケジューリング機能を追加し、それらを z/OS コントローラーに接続される必要がある動的ドメイン・マネージャーに接続します。詳しくは、以下の資料を参照してください。

v 動的ドメイン・マネージャーのインストールの詳細については、85ページの『動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストール』

v Tivoli Workload Scheduler for z/OS エージェントのインストールについては、「Tivoli Workload Scheduler for z/OS: 計画およびインストール」

v Tivoli Workload Scheduler for z/OS エージェントの使用については、「Tivoli Workload Scheduler for z/OS: z-セントリック機能付のエンドツーエンド・スケジューリング」

外部システムと統合されたワークロード環境

この構成は、Tivoli Workload Scheduler を使用して SAP R/3 および PeopleSoft などの外部のアプリケーションにおいてスケジューリングするために Tivoli Workload

Scheduler 機能を拡張する場合に使用します。

16ページの図 6 は、Tivoli Workload Scheduler for Applications を使用して 1 つ以上の外部アプリケーション上の Tivoli Workload Scheduler スケジューリング機能を

第 1 部計画 15

拡張するために必要なエージェントを含むサンプル環境を示しています。マスター・ドメイン・マネージャー上、フォールト・トレラント・エージェント上、動的エージェント上、および Tivoli Workload Scheduler for z/OS エージェント上に、Tivoli Workload Scheduler for Applications をインストールできます。

Tivoli Workload Scheduler for Applications について詳しくは、「Tivoli Workload

Scheduler for Applications ユーザーズ・ガイド」を参照してください。

注: エージェント (マスター・ドメイン・マネージャー、ドメイン・マネージャー、フォールト・トレラント・エージェント、標準エージェント、動的エージェント、Tivoli Workload Scheduler for z/OS エージェント) に Tivoli Workload

Scheduler for Applications をインストールすることは、エンドツーエンド環境における正しいデプロイメント・シナリオです。



TWSFTATWSFTA

z/OS

OracleOracle

PeopleSoftPeopleSoft

SAP R/3

TWSfor

Applications

TWSfor

Applications

アプリケーション

TWSfor

Applications

TWSfor

Applications

TWSfor

Applications

TWSfor

Applications

TWSサーバー・システムTWSサーバー・システム

TWS./エージェント

TWS./エージェント

TWSfor Z/OSエージェント

TWSfor Z/OSエージェント

Javaランタイム

Javaランタイム

図 6. 外部システムと統合されたワークロード環境


z/OS の分散ドリブン・ワークロード環境

この構成は、z/OS システム上でワークロードを定義しないで、Tivoli Workload

Scheduler から (マスター・ドメイン・マネージャーまたは動的ドメイン・マネージャーを使用してインストールされた Dynamic Workload Broker コンポーネントを使用して) JES2 で処理されるワークロードをサブミットする場合に使用します。

16ページの図 6 は、分散ドリブン環境をインストールするために必要な最小システム・リソースを示しており、ここでは z/OS 用の Tivoli Workload Scheduler 分散エージェントが、JES2 によって処理される分散側のワークロード上でユーザーが定義および管理を行う、軽量のエンドツーエンド・スケジューリング・ソリューションを表しています。

Tivoli Workload Scheduler Distributed-Agent for z/OS については、「Tivoli Workload

Scheduler: Agent for z/OS のスケジューリング」を参照してください。

第 1 部計画 17

ドメインの計画

Tivoli Workload Scheduler ネットワークには、製品の管理ハブとして機能する、少なくとも 1 つのマスター・ドメインが含まれています。追加のドメインを使用して、広範囲に分散されたネットワークをローカルで管理されるワークステーションのグループに分割することができます。

単一ドメイン構成の場合は、ネットワーク内のすべてのワークステーションとの通信をマスター・ドメイン・マネージャーが維持します。

DBサーバー

DBサーバー




コンポーネント34インフラストラクチャー

TWSMDM

z/OSシステムz/OSシステム

TWSDistributed-

Agentfor z/OS

図 7. z/OS の分散ドリブン・ワークロード環境


複数ドメイン構成の場合、マスター・ドメイン・マネージャーは、自分のドメイン内のワークステーション、および直接従属するすべてのドメイン・マネージャーと通信します。従属のドメイン・マネージャーは、自分のドメイン内のワークステーション、およびそれらの直接従属するドメイン・マネージャーなどと通信します。ドメイン・マネージャーは、ドメインのすべてのアクティビティーをマスターに報告します。複数のドメインを使用すると、マスター・ドメイン・マネージャーとワークステーション間の直接の通信数が削減されるので、ネットワーク・トラフィックおよびマスターの負荷が削減されます。複数ドメインを採用すると、ドメイン・マネージャーの問題が原因で生じる障害が単一のドメインに限られるため、フォールト・トレランスも提供されます。影響をさらに小さく抑えるために、ドメイン・マネージャーが障害を起こした場合にそれを引き継ぐ、バックアップ・ドメイン・マネージャーを指定することができます。

新しいドメインを定義する場合、親ドメインとドメイン・マネージャーを識別する必要があります。親ドメインは、ドメイン階層で、新しいドメインのすぐ上のドメインです。あるドメインとの間の通信は、すべてその親ドメイン・マネージャーを介して経路指定されます。

ドメイン内でのローカライズ処理

処理をローカライズするということは、スケジューリングに関するニーズを共通する特性のセット (地理的位置、業務の役割、およびアプリケーションのグループ分けなど) に基づいて分離するということです。グループに関連する処理は、ドメイン間でやり取りする必要のある、相互に依存する情報の量を制限できます。ドメインごとのローカライズの利点は次のとおりです。

ネットワーク・トラフィックの減少処理をドメインごとにローカライズしておけば、ドメイン間通信を頻繁に行う必要が除かれます。

セキュリティーの強化および管理の単純化セキュリティーおよび管理をドメイン・レベルに制限し、ドメイン・レベルで定義することができます。ネットワーク全体の、または個々のワークステーションの管理ではなく、ドメインの管理が行えます。

最適化されたネットワークおよびワークステーション・フォールト・トレランス複数ドメイン・ネットワークでは、それぞれのドメイン・マネージャーごとにバックアップを定義して、1 つのドメインの問題が他のドメインの操作に影響しないようにできます。

ドメインの計画に関する考慮事項

Tivoli Workload Scheduler ネットワークをプランニングする際には、以下を検討してください。

ワークステーション、アプリケーション、およびジョブの数ネットワークを構成するワークステーションの数、およびネットワークが実行するアプリケーションとジョブの数を検討します。ワークステーション数が少ない場合、または制御するアプリケーションの数が少ない場合は、複数ドメインは必要ありません。

第 1 部計画 19

地理的位置の数ネットワークでカバーする地理的位置 (ロケーション) の数、およびロケーション間通信の信頼性と効率を検討します。地理的位置が複数であるということは、複数ドメイン・アーキテクチャーを選択する主な理由の 1 つです。各地理的な位置に 1 つのドメインを設けるというのが一般的な構成です。単一ドメイン・アーキテクチャーは、ネットワークでは連続的に処理が持続されることに依存します。

時間帯ネットワークが時間帯の異なる複数の地理的位置にまたがっている場合は、時間帯機能を活動化するかどうかを決定する必要があります。 25ページの『時間帯に関する考慮事項』を参照してください。

集中管理か非集中管理か単一ドメイン・ネットワークまたは複数ドメイン・ネットワークを単一のマスター・ドメイン・マネージャーから管理することができます。複数のロケーションを別々に管理したい場合は、各ロケーションで個別に Tivoli

Workload Scheduler ネットワークをインストールすることを考慮できます。ファイル・システムのマウントまたは共用によって、スタンドアロンのTivoli Workload Scheduler ネットワークでの、いくらかの非集中管理が可能です。

アプリケーションのタイプTivoli Workload Scheduler によって実行されるアプリケーションのタイプを検討します。互いに明確に分離されているアプリケーションが複数ある場合は、それぞれを別々のドメインに置くことを選択できます。

Windows ネットワークWindows ネットワークを使用する場合、Tivoli Workload Scheduler ドメインで Windows ドメインをミラーリングすることができます。

システム・パフォーマンスおよびその他の基準複数のドメインを定義して、パフォーマンスまたはオペレーティング・システムのタイプに基づいてシステムをローカライズできます。

ネットワーク・トラフィックの量ネットワーク・トラフィックが管理可能な程度であれば、複数ドメインの必要性は小さくなります。

ジョブ間の依存関係システムの境界、地理的境界、またはアプリケーションの境界にまたがるジョブの依存関係について計画する必要があるかどうかを検討してください。例えば、workstation1 での Job1 の開始が workstation2 で実行中の Job2 の完了に依存するか。ジョブ間の相互依存度は、ネットワークを計画する際の重要な考慮事項です。複数のドメインを使用する場合は、相互に依存するオブジェクトは同一のドメインに置くようにして、それによってネットワーク・トラフィックを減少させ、このドメイン・アーキテクチャーが生かされるよりよい使い方になるようにしてください。「Tivoli Workload Scheduler:

ユーザーズ・ガイドおよびリファレンス」(SC88-9680) を参照してください。

必要なフォールト・トレランスのレベル単一ドメイン構成の欠点の 1 つは、単一のドメイン・マネージャーに依存


しているということです。複数ドメイン・ネットワークでは、1 つのドメイン・マネージャーが失われても、そのドメイン内のエージェントにしか影響しません。

ファイアウォールネットワークにファイアウォールを含める場合は、ファイアウォールの周辺のドメインの構造を計画してください。「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

Secure Sockets Layer (SSL) または IBM Global Security Kit (GSKit) による暗号化ネットワークで SSL または GSKit による暗号化を使用したい場合は、そ

のプロトコルに従ってドメインを計画してください。

注: 連邦情報処理標準 (FIPS) に準拠させる場合は、GSKit を使用する必要があります。「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

単一ドメイン・ネットワーク

単一ドメイン・ネットワークは、1 つのマスター・ドメイン・マネージャーと任意の数のエージェントから構成されます。 22ページの図 8 は、単一ドメイン・ネットワークの例を示しています。単一ドメイン・ネットワークは、地理上の位置および業務の役割が少数の会社に適しています。ネットワーク内の通信は、すべてマスター・ドメイン・マネージャーを介して経路指定されます。ロケーションが単一であるため、ローカル・ネットワークの信頼性と、そのネットワークが処理できるトラフィックの量だけを考慮すればすみます。

第 1 部計画 21

単一ドメイン・ネットワークを他のネットワーク (単一ドメインまたは複数ドメイン) と組み合わせて、複数サイトの要件を満たすことができます。 Tivoli Workload

Scheduler は、複数の異なるネットワーク上で実行中のジョブ間のインターネットワーク依存関係をサポートします。

マスター・ドメイン・マネージャー

エージェント

図 8. 単一ドメイン・トポロジー


例 1 は、単一ドメイン・ネットワークを示しています。マスター・ドメイン・マネージャーといくつかのエージェントがアトランタにあります。デンバーにもエージェントがあります。デンバーのエージェントは、依存関係がデンバーで実行されるジョブにある場合であっても、エージェント間のすべての依存関係の解決をアトランタのマスター・ドメイン・マネージャーに依存します。また、例 2 に示されているように、アトランタとデンバーにそれぞれ別個の単一ドメイン・ネットワークを作成するという方法もあります。

複数ドメイン・ネットワーク

複数ドメイン・ネットワークは、複数のロケーション、部門、または業務の役割に分かれている会社に特に適しています。複数ドメイン・ネットワークは、1 つのマ

Tivoli DynamicWorkload Console


アトランタ

デンバー

アトランタデンバー

エージェント


または:



� 1

� 2


エージェント

エージェントエージェント

エージェントエージェントエージェントエージェント

図 9. 複数サイトでの単一ドメイン・トポロジー

第 1 部計画 23

スター・ドメイン・マネージャーと、任意の数の下層のドメイン・マネージャー、および各ドメイン内の任意の数のエージェントから構成されます。エージェントは、そのドメイン・マネージャーとのみ通信し、ドメイン・マネージャーはその親ドメイン・マネージャーと通信します。ドメインの階層は、任意のレベル数にまで深くすることができます。

図 10 が示すように、マスター・ドメイン・マネージャーはアトランタにあります。マスター・ドメイン・マネージャーには、スケジューリング・オブジェクトの文書化に使用されるデータベース・ファイルが入っており、Symphony ファイルを、自分のエージェントと、デンバーおよびロサンゼルスのドメイン・マネージャーに配布します。次にデンバーとロサンゼルスのドメイン・マネージャーは、Symphony

Tivoli DynamicWorkload Console


マスター・ドメイン

デンバー



< レベルのドメイン

2 ロサンゼルスドメイン・マネージャー

ニューヨーク


オーロラ


バーバンク


< レベルのドメイン

3

アトランタ

エージェントエージェントエージェントエージェント

エージェント

エージェント

エージェントエージェントエージェントエージェントエージェントエージェント

図 10. 複数ドメイン・トポロジー


ファイルを、自分のエージェントと、ニューヨーク、オーロラ、およびバーバンクにある従属ドメイン・マネージャーに配布します。アトランタのマスター・ドメイン・マネージャーは、ネットワーク全体のドメイン間の情報のブロードキャストの責任を担います。

ボールダーのドメイン・マネージャーとの間で行われる通信はすべて、デンバーの親ドメイン・マネージャーを介して経路指定されます。オーロラのドメインのスケジュールまたはジョブに依存するジョブまたはスケジュールがボールダーのドメインにある場合、これらの依存関係はデンバーのドメイン・マネージャーによって解決されます。エージェント間の依存関係の大部分が下層のドメイン・マネージャーによってローカルに処理されるので、ネットワークのトラフィックが大幅に削減されます。

ワークステーション・クラス

ワークステーションは、ネットワーク管理をより容易および効率的にするために、複数のドメインに編成されています。ただし、ジョブまたはジョブ・ストリームを実行する場所を選択するときに、ドメイン名は選択基準の 1 つではありません。ジョブ・スケジュール特性が類似しているために複数のワークステーションをグループ化する場合は、ワークステーション・クラスを使用します。任意の数のワークステーションをグループ化して 1 つのクラスにすることができ、 1 つのワークステーションを複数のクラスに属するようにすることができます。ジョブおよびジョブ・ストリームを、特定のワークステーション・クラスで実行するように割り当てることができます。

例えば、以下に基づいて複数のワークステーションをグループ化するためのワークステーション・クラスをセットアップできます。

v 社内の部門構造。これにより、1 つの部門内のすべてのワークステーションで実行するジョブを定義できます。

v それらにインストールされているソフトウェア。これにより、特定のアプリケーションがインストールされたすべてのワークステーションで実行するジョブを定義できます。

v ユーザーの役割。これにより、例えばマネージャーに属するすべてのワークステーションで実行するジョブを定義できます。

この例では、個々のワークステーションが、その部門に対応する 1 つのワークステーション・クラス、そのユーザーに対応する別のワークステーション・クラス、およびインストールされたソフトウェアに対応する他の複数のワークステーション・クラスに含まれることが可能です。

時間帯に関する考慮事項

時間帯サポートは、デフォルトで使用可能にされるオプション機能 (任意指定機能)

の 1 つです。これにより、グローバル・レベルでワークロードを管理できるようになります。時間帯を設定する方法について詳しくは、「Tivoli Workload Scheduler 管理ガイド」を参照してください。

第 1 部計画 25

また、時間帯のインプリメンテーションによって、複数の時間帯にわたるスケジューリングを容易に行うことができます。時間帯の機能の説明については、「Tivoli

Workload Scheduler ユーザーズ・ガイドおよびリファレンス」を参照してください。


第 2 部 Tivoli Workload Scheduler

インストールの準備

この章では、インストールの概要と、環境に関するいくつかの固有の考慮事項を記載します。この章には、以下のセクションが含まれています。

v 『インストールの概要』

v 28ページの『前提条件の検査 (UNIX および Linux)』

v 29ページの『インストールの注意点』

v 31ページの『インストール・メディア』

v 32ページの『Tivoli Workload Automation のインスタンス』

v 34ページの『リレーショナル・データベース管理システム』

v 35ページの『インストール方法の選択』

v 38ページの『インストール・ログ・ファイル』

v 40ページの『Tivoli Workload Scheduler ユーザー』

v 43ページの『Windows サービス』

インストールの概要

以下のステップを実行して、Tivoli Workload Scheduler のインストールおよび構成の準備を行います。

1. ご使用のネットワークの構成を確認して、インストールするワークステーションのタイプを判別します。 1ページの『ネットワーク計画』を参照してください。

2. http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 にあるインストール前提条件を調べて、ご使用のシステムが対応しているかどうか確認します。

3. DB2 データベースを使用するか、Oracle データベースを使用するかを決定します。

4. データベース管理者がデータベースに関するすべての機密情報 (データベース管理者のユーザー ID/パスワードなど) を管理していて、製品をインストールするIT 管理者はその機密情報を知らない場合に限り、 43ページの『インストールまたはアップグレード前の Tivoli Workload Scheduler データベース表の作成またはアップグレード』で説明されている手順を実行します。

5. Tivoli Workload Automation の既存のインスタンスにインストールするか Tivoli

Workload Automation の新規インスタンスをインストールするかを決定します。

6. インストールの際に必須フィールドに入力する必要のある情報を収集します。

7. オプションで、インストール/アップグレードの前に Tivoli Workload Scheduler

データベース表を作成/アップグレードします。データベース管理者がこの手順を実行するのは、製品をインストールする IT 管理者が、データベースに関連する機密情報を必ずしもすべて把握していない場合のみです。IT 管理者がインストール時にデータベース管理者のユーザー ID とパスワードを指定できる場合は、


|

|

|

|

|


データベース管理者はこれらの手順を実行する必要がありません。インストールにより自動的にデータベース表の作成およびアップグレードが行われるためです。

8. 70ページの『インストール中』に示されている指示に従って、Tivoli Workload

Scheduler をインストールします。

9. インストールしたワークステーション・タイプに必要な構成を実行します。190ページの『構成』を参照してください。

前提条件の検査 (UNIX および Linux)

UNIX および Linux オペレーティング・システムにインストールする準備をしている場合は、Tivoli Workload Scheduler によって自動的にご使用のシステム上で前提条件チェックが実行されます。Tivoli Workload Scheduler システム要件を満たす環境を持つことによって、遅延や混乱がなくインストールが成功するようになります。

注: 前提条件チェックは、ソフトウェア配布インストール方式を使用している場合は使用不可であり、UNIX および Linux オペレーティング・システム上のみで使用可能です。

前提条件チェックは以下を検証します。

v オペレーティング・システムが製品によってサポートされていること。

v 必要なエンジン・ソフトウェア・パッチ・レベルがインストールされていること。

v 永続的ディスク・スペースと一時ディスク・スペースが十分にあること。

v 十分なメモリーと仮想メモリー・スワップ・スペースがあること。

v 必要なカーネル・パラメーターが正しく構成されていること。

注: 前提条件チェックは、環境が Tivoli Workload Scheduler の要件を満たしているかどうかのみを検査します。DB2 などのその他のコンポーネントのインストール要件は検査しません。

これらの検査のいずれかが失敗すると、Tivoli Workload Scheduler には満たされなかった要件の通知が表示され、問題を解決するためにインストールを一時停止できます。このチェックをしないと、ソフトウェアをインストールできても、処理に障害が起こる可能性があります。

インストール・ウィザード、サイレント・インストール、または twsinst スクリプトを使用して Tivoli Workload Scheduler をインストールしている場合は、前提条件チェックがインストールを停止するのは、ブロッキング・エラーが発生した場合のみか、任意のタイプのエラーまたは警告が発生した場合かを制御できます。任意のエラーまたは警告のためにインストールを停止する場合は、インストールを起動するときに以下を実行します。

インストール・ウィザードSETUP.bin -W checkPrerequisites.stopOnCheckPrereq=true と入力します。


|

|

|

サイレント・インストールサイレント・インストールに使用する応答ファイルでパラメーター -W

checkPrerequisites.stopOnCheckPrereq=true を指定します。

twsinst パラメーター -stoponcheckprereq を指定します。

前提条件チェックの結果の詳細は、インストール・ログ ( 299ページの『インストール・ログ・ファイル』を参照) で確認できます。インストール・ログでは、任意の警告と同様に、ブロッキング・エラーの詳細と非ブロッキング・エラーの詳細が検出されます。

サポートされるオペレーティング・システムおよび製品の前提条件の詳細なリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 を参照してください。

インストールの注意点

インストール・ウィザードを使用してインストールを開始する前に、ご使用の環境に当てはまる可能性のある以下の項目を確認してください。

Windows オペレーティング・システムへのインストール

Windows にインストールする場合には、以下の項目を考慮してください。

v Windows Terminal Services を使用する場合は、コマンド change user

/install を使用してインストール・ユーザーを設定します。

v <TWS_user> がドメイン・ユーザーの場合は、Microsoft Computer

Browser Service がアクティブでなければなりません。これは IBM

WebSphere Application Server 認証に必要です。

v <TWS_user> がドメイン・ユーザーの場合は、インストールを実行するユーザーがドメイン管理者でなければなりません。

UNIX および Linux にインストールする場合

HP-UX オペレーション・システムにインストールする場合は、MAXDSIZパラメーターが最小で 128 MB に設定されているか確認します。

デフォルトの /tmp ディレクトリー内のインストール・ウィザードの一時データ用スペースが不足していることを示すエラー・メッセージが表示された場合、インストール・ウィザードを -is フラグを指定して起動し、代わりの一時ディレクトリーを設定することができます。例:

SETUP.sh [-is:tempdir <temporary_directory>]

インストール用のディスクやスペースの所要量に関する追加情報については、 28ページの『前提条件の検査 (UNIX および Linux)』を参照してください。

DB2 と共にインストールするか、またはマウントされた共用ディレクトリーから複数のコンピューターにインストールする場合

インストール DVD には、2 種類のインストール・スクリプトがあります。

v <operating_system>/SETUP.bin

v SETUP.sh

第 2 部 Tivoli Workload Scheduler 29


SETUP.sh によって、インストール・メディアのローカル・コピーが/tmp/_twscd に作成されます。この方式を使用する場合は、/tmp に適切なスペースがあることを確認します。詳しくは、http://www.ibm.com/support/

docview.wss?rs=672&uid=swg27019747 の Tivoli Workload Scheduler システム要件ドキュメントを参照してください。

言語設定と国別文字の選択特定の言語ロケールの文字を使用する場合、インストール・ウィザード用に選択する言語は、インストールするワークステーションの言語ロケール設定と一致している必要があります。マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインストール・パスに、国別文字を使用することはできません。また、インストール・パスに国別文字が使用されているエージェントに対して、分散コネクターを追加することもできません。

インストール・エラーインストールがエラーで終了した場合は、右上にある「クローズ」アイコンを使用してセッションを終了しないでください。この方法で終了すると、インストールの要約ログ・ファイルの作成が行われないからです。エラーが含まれる場合であっても、最後のパネルに到達するまで「次へ」をクリックし、その後に「終了」をクリックしてインストールを完了してください。

サイレント・インストールの実行Tivoli Workload Scheduler の最新バージョンをインストールするときには、初期インストールのパラメーターに基づいて応答ファイルを作成できます。その後、このカスタマイズされた応答ファイルを使用して、同じパラメーターを使用してサイレント・インストールを実行できます。初期インストールを実行する前に、このフィーチャーの使用を検討することもできます。詳しくは、 100ページの『サイレント・インストールの実行』を参照してください。

マップ・ドライブウィザードを使用するインストールのために特定のオペレーティング・システムのイメージをワークステーションにコピーする際には、インストールを実行するドライブに DVD のすべての内容をコピーする必要があります。そのドライブが UNC マップ・ドライブである場合は、そのリモート・パスをインストール先のワークステーションのドライブにマップする必要があります。サポートされるオペレーティング・システムおよび前提条件の完全なリストについては、Tivoli Workload Scheduler システム要件ドキュメントhttp://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 を参照してください。

リモート・インストールリモートの Samba でマウントしたファイル・システムから Windows ワークステーション上に Tivoli Workload Scheduler をインストールすることはできません。

エンドツーエンド・スケジューリング用のインストール

エンドツーエンド・スケジューリング用の分散エージェント (つまり、標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー) として使用されるワークステーションに Tivoli Workload

Scheduler をインストールする場合は、インストール・プロセス中にマスタ





ー・ドメイン・マネージャーの名前として OPCMASTER を指定する必要があります。エンドツーエンド・スケジューリング用のインストールに関するより詳細な情報については、「Tivoli Workload Scheduler Scheduling

End-to-end」を参照してください。

シンボリック・リンクの作成UNIX および Linux。インストール・ウィザードは、すべての実行可能ファイルを独自の .bin ディレクトリーにインストールします。Tivoli Workload

Scheduler コマンドを実行する前に、これらのファイルにアクセスするコマンド行環境を設定するスクリプトを実行します。スクリプト内から任意のコマンドを実行するたびに環境の設定が必要になることを避けるために、スクリプト内から最も頻繁に使用されるコマンドまたはユーティリティーへのシンボリック・リンクを作成するインストール・オプションを選択できます。表 1 は、バイナリー・パスおよびシンボリック・リンクを示します。

表 1. シンボリック・リンクのオプション

TWS バイナリー・パスシンボリック・リンク

<TWS_home>/bin/at usr/bin/mat

<TWS_home>/bin/batch usr/bin/mbatch

<TWS_home>/bin/datecalc usr/bin/datecalc

<TWS_home>/bin/jobstdl usr/bin/jobstdl

<TWS_home>/bin/maestro usr/bin/maestro

<TWS_home>/bin/mdemon usr/bin/mdemon

<TWS_home>/bin/morestdl usr/bin/morestdl

<TWS_home>/bin/muser usr/bin/muser

<TWS_home>/bin/parms usr/bin/parms

インストール・メディア

オペレーティング・システムに応じて、インストール DVD には以下のディレクトリーの一部またはすべてが含まれています。

TWS Tivoli Workload Scheduler をインストールするために必要なファイルが含まれています。

TDWCDynamic Workload Console のインストールに必要なファイルが含まれています。

DB2 DB2 のインストールに必要なファイルが含まれています。

DB2_activationDB2 の活動化に必要なファイルが含まれています。

IntegrationsTivoli Workload Scheduler を他の Tivoli 製品と統合するために必要なファイルが含まれています。

Launchpad起動埋め込みコードが含まれています。


Integration WorkbenchTivoli Workload Scheduler Integration Workbench をインストールするために必要なファイルが含まれています。

JBDC Windows または Linux システム上の Job Brokering Definition Console に必要なファイルが含まれています。

サポートされるオペレーティング・システムの完全なリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501 にある Tivoli

Workload Scheduler ダウンロード可能資料を参照してください。

Tivoli Workload Automation のインスタンス

Tivoli Workload Scheduler は TWS_user のファイルを selected path¥TWS¥ およびselected path¥eWAS¥ ディレクトリーにインストールします。selected path はインストール・ロケーションを表しています。

Windows オペレーティング・システムの場合、新規インストールのデフォルト・インストール・ロケーションは c:¥Program Files¥IBM¥TWA¥ です。

UNIX オペレーティング・システムの場合、デフォルトのインストール・ロケーションは /opt/IBM/TWA/ です。

Linux オペレーティング・システムの場合、製品はインストールの際に選択されるディレクトリーにインストールされます。デフォルトのインストール・ロケーションは /opt/ibm/TWA/ です。

Tivoli Workload Automation ディレクトリーには、Tivoli Workload Scheduler コンポーネントの各インスタンスを 1 つだけ置くことができます。個々のインスタンスの作成に固有の TWS_user とインストール・パスを使用する場合のみ、製品の複数のインスタンスを単一のワークステーションにインストールすることができます。

Tivoli Workload Automation の各インスタンスには以下が含まれます。

v 次のものを実行できる組み込み IBM WebSphere Application Server の 1 つのインスタンス

– マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、動的ドメイン・マネージャー、バックアップ動的ドメイン・マネージャー、分散コネクター付きドメイン・マネージャー、または分散コネクター付きフォールト・トレラント・エージェントの 1 つのインスタンス

– Dynamic Workload Console の 1 つのインスタンス

– Tivoli Workload Scheduler for z/OS Connector の 1 つのインスタンス

v 他の Tivoli Workload Scheduler コンポーネント (マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、動的ドメイン・マネージャー、バックアップ動的ドメイン・マネージャー、分散コネクター付きドメイン・マネージャー、または分散コネクター時フォールト・トレラント・エージェント) がインストールされていない場合、分散コネクターなしのドメイン・マネージャーまたはフォールト・トレラント・エージェントの 1 つのインスタンス。



Dynamic Workload Console を 1 つだけワークステーションにインストールして、それを次の場所にインストールすることができます。

v 既存の Tivoli Workload Automation インスタンス内

v 新規 Tivoli Workload Automation インスタンス内

v Tivoli Integrated Portal の既存の外部インスタンスを使用している Tivoli

Workload Automation インスタンスの外

既存の TWA ディレクトリーを持つコンピューターに新規 Tivoli Workload

Scheduler インスタンスをインストールする場合、新規のデフォルト・インストール・ディレクトリーは、TWA1、TWA2、などのように作成されます。

注: 本書および他のマニュアルでは、Tivoli Workload Automation インスタンス・ディレクトリーを TWA_home と呼んでいます。

例えば、/opt/ibm/TWA ディレクトリーに Tivoli Workload Scheduler がすでにインストールされている場合、次回そのワークステーションに Tivoli Workload

Scheduler をインストールする際、インストール・ディレクトリーは /opt/ibm/TWA1になります。ただし、最初に Dynamic Workload Console を /TWA/TDWC ディレクトリーにインストールした場合は、Tivoli Workload Scheduler の新規インスタンスを /opt/ibm/TWA/TWS ディレクトリーにインストールできます。同じ状態が Tivoli

Workload Scheduler、および Dynamic Workload Console に適用されます。Tivoli

Workload Automation ディレクトリーのインスタンスに置くことのできる各製品またはコンポーネントのインスタンスは 1 つだけです。

注: Tivoli Workload Scheduler のインスタンスはレジストリー・ファイルにのみ記録されます。Tivoli Workload Scheduler の以前のバージョンは、レジストリー・ファイルとコンポーネント・ファイルの両方に登録されていました。

Tivoli Workload Scheduler のインストールの際に、Tivoli Workload Automation の既存のインスタンスにインストールするか、新規インスタンスを作成するかを決定します。

Tivoli Workload Automation の既存のインスタンスにインストールを行う場合、特定の製品またはコンポーネントをインストールできるかどうかは、そのインスタンスに現時点で存在する製品またはコンポーネントによって決まります。 Tivoli

Workload Automation を既存のインスタンスに製品またはコンポーネントをインストールすることの利点は、コンポーネントを構成するために必要なデータがすべて用意され、ウィザードに表示されることです。場合によっては、既存のインスタンスから取り出されたデータが自動的に再利用されます。使用または編集することを選択できるデフォルト値としてデータが取り出されることもあります。

34ページの表 2 は、Tivoli Workload Scheduler コンポーネントの完全セットをインストールしている場合に各種シナリオで実行できるアクションについて説明しています。


表 2. Tivoli Workload Automation の既存のインスタンスへのインストール

既存の Tivoli Workload Automation インスタンスに含まれる製品またはコンポーネント実行できるアクション

前のバージョンの Tivoli Workload Scheduler

コンポーネントそのコンポーネントのアップグレード。

twsinst を使用してインストールされた、以前のバージョンの Tivoli Workload Scheduler

エージェント

twsinst を使用したコンポーネントのアップグレード。

Tivoli Workload Scheduler バージョン 8.6 マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャー

なし。この場合、Tivoli Workload Scheduler

をインストールすることはできません。

Tivoli Workload Scheduler バージョン 8.6 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャー



Tivoli Workload Scheduler バージョン 8.6 フォールト・トレラント・エージェント (コネクターなし)

コネクター・フィーチャーの追加。

Tivoli Workload Scheduler バージョン 8.6 フォールト・トレラント・エージェント (コネクター付き)



Tivoli Workload Scheduler バージョン 8.6 動的エージェント



Dynamic Workload Console バージョン 8.6 Tivoli Workload Scheduler をインストールします。

既存の外部 WebSphere Application Server 上の Dynamic Workload Console バージョン8.6



Tivoli Workload Scheduler for z/OS Agent のバージョン 8.6

なし。このインスタンスで別のエージェントをインストールすることはできません。

Tivoli Workload Scheduler for z/OS Connector Tivoli Workload Scheduler をインストールします。

コマンド行クライアントの現行バージョン言語パック・フィーチャーのみを追加します。

リレーショナル・データベース管理システム

リレーショナル・データベース管理システム (RDBMS) は、マスター・ドメイン・マネージャーおよびバックアップ・マスターの前提条件です。以下のいずれかのRDBMS を使用できます。

DB2 Enterprise Server Edition

DB2 のバージョンは、インストール DVD に組み込まれています。ランチパッドについては、 35ページの『インストール方法の選択』を参照してください。 DB2 のインストールは次のように行えます。


サーバーDB2 Server およびマスター・ドメイン・マネージャーを同じワークステーションにインストールします。

クライアントDB2 Server を 1 つのワークステーションにインストールします。DB2 クライアントおよびマスター・ドメイン・マネージャーは、別のワークステーションにインストールします。この構成の利点は、マスター・ドメイン・マネージャーとバックアップ・マスターとの切り替えを、必要に応じて簡単に行えることです。

Oracle

Oracle およびマスター・ドメイン・マネージャーを同じコンピューター上にインストールします。 Oracle のインストールは次のように行えます。

Oracle Enterprise EditionOracle Enterprise Edition を選択することの利点は、Oracle パーティショニング・フィーチャーをインプリメントすることにより、イベント・ドリブン・ワークロード自動化のパフォーマンスを向上させることができる点にあります。これにより、ルール管理パフォーマンスが向上します。特に event_rule_instance、action_run およびoperator_messages という照会のパフォーマンスが向上します。イベント・ドリブン・ワークロード自動化については、「概要」を参照してください。

Oracle Standard EditionOracle Standard Edition には Oracle パーティショニング・フィーチャーは含まれません。この版をインストールしても、イベント・ドリブン・ワークロード自動化のパフォーマンスは向上しません。

サポートされるバージョンについては、http://www.ibm.com/support/

docview.wss?rs=672&uid=swg27019747 にある Tivoli Workload Scheduler システム要件ドキュメントを参照してください。

RDBMS のインストールは Tivoli Workload Scheduler のインストールの前に行う必要があります。 Tivoli Workload Scheduler のインストールの際に、使用するRDBMS のインスタンスを指定します。

注: RDBMS が既に存在し、それをアップグレードする場合は、Tivoli Workload

Scheduler をアップグレードした後で、アップグレードする必要があります。RDBMS のアップグレードについては、「Tivoli Workload Scheduler 管理ガイド」のデータ保守に関する章を参照してください。

インストール方法の選択

Tivoli Workload Scheduler のインストールは、このセクションで説明されている方法のいずれかを使用して行うことができます。




Launchpad

Tivoli Workload Automation 製品のインストールもランチパッドがその開始点となります。 DB2 もランチパッドからインストールできます。ランチパッドはインストール・メディアに含まれています。ランチパッドを使用して、以下の操作を行うことができます。

v すべての Tivoli Workload Scheduler コンポーネントのインストールまたはアップグレード

v Dynamic Workload Console のインストールまたはアップグレード

v Tivoli Workload Scheduler for Applications のインストールまたはアップグレード

v Tivoli Workload Scheduler for z/OS Connector のインストール

v DB2 のインストール

v Job Brokering Definition Console のインストール

v 製品情報へのアクセス

v 「ニュースおよび更新」機能を使用して、常に素早く製品のニュース、更新、技術情報、APAR および修正についての情報を得てください。この機能を使用するには、インターネットに接続している必要があります。

ランチパッドは、関連するインストール・セットアップ・ファイルに自動的にアクセスし、このファイルを対話モードで実行します。選択した展開モデルに応じて、ランチパッドからインストールを駆動し、簡略化できます。

ランチパッドには追加の前提条件が必要です。詳しくは、http://www.ibm.com/

support/docview.wss?rs=672&uid=swg27019747 の Tivoli Workload Scheduler システム要件ドキュメントを参照してください。

自動実行を有効にしている場合、ランチパッドは自動的に始動します。マウントされているファイル・システムからランチパッドを始動する場合は、そのランチパッドを始動する前にそのファイル・システムへの書き込み権限があることを確認してください。

ランチパッド・インストール・プログラムを始動するには、以下の手順を実行してください。

1. インストールするコンポーネントが含まれている DVD から、次のようにランチパッドを実行します。

Windows オペレーティング・システム:DVD の root ディレクトリーから launchpad.exe を実行します。

UNIX オペレーティング・システム:

a. BROWSER 環境変数にブラウザーの場所をエクスポートします。

b. DVD の root ディレクトリーから launchpad.sh を実行します。

ランチパッドが開きます。

2. ランチパッドでは、希望する Tivoli Workload Scheduler の構成をクリックしてインストールします。関連するインストール・プログラムが始動します。選択した Tivoli Workload Scheduler コンポーネントのインストールを進めるには、以降のセクションに記述されている説明に従ってください。


|

|

|

|



製品のインストール前提条件に関する情報にアクセスするには、ランチパッドの左フレームにある各種オプションをクリックします。

インストール・ウィザード

Tivoli Workload Scheduler マスター・ドメイン・マネージャー、バックアップ・マスター、エージェント、コネクター、および Dynamic Workload Console のインストールは、サポートされる各プラットフォーム用の個々のセットアップ・ファイルを起動することによって行います。

このインストール・ウィザードは、対話モードまたはサイレント・モードで使用できます。対話モードでは、ウィザードがインストール手順をガイドします。サイレント・モードでは、関係する情報が応答ファイルによってインストール・プロセスに提供されます。このプロセスは、バックグラウンドで実行されます。

このインストール方法は、Java 仮想マシン (JVM) を使用します。したがって、固有のシステム要件があります。インストール要件について詳しくは、 28ページの『前提条件の検査 (UNIX および Linux)』を参照してください。

サイレント・モード

インストールの際に使用されるすべての構成設定を追加して、応答ファイルをカスタマイズします。その後、コマンド行から setup コマンドを実行します。この方法で、無人インストールをバックグラウンドで実行することができます。詳しくは、100ページの『サイレント・インストールの実行』を参照してください。

エージェント用の twsinst スクリプト

ワークステーション上で Java 仮想マシン (JVM) を実行していない場合は、twsinstのみを使用して Tivoli Workload Scheduler エージェントをインストールしてください。実行している場合は、代わりにサイレント・インストールを実行してください。 100ページの『サイレント・インストールの実行』を参照してください。

前のバージョンがインストール・ウィザードを使用してインストールされた Tivoli

Workload Scheduler を、twsinst スクリプトを使用してバージョン 8.6 にアップグレードした後に、Tivoli Workload Scheduler のそのインスタンスを再度アップグレードするには、twsinst 方式しか使用できなくなります。ただし、ウィザードを使用してその Tivoli Workload Scheduler インスタンスをアンインストールすることはできます。

twsinst について詳しくは、 106ページの『twsinst を使ったエージェントのインストール』を参照してください。

Software Distribution ソフトウェア・パッケージ・ブロック (SPB)

エージェントのインストールは、IBM Tivoli Configuration Manager バージョン4.1、4.2、4.2.1、4.2.2、または 4.2.3 の Software Distribution コンポーネントを使用して、ソフトウェア・パッケージ・ブロック (SPB) を配布することによって行います。 115ページの『Software Distribution を使ったエージェントのインストール』を参照してください。


JVM をワークステーション上で実行しない場合にのみ、Software Distribution を使用して Tivoli Workload Scheduler エージェントをインストールしてください。それ以外の状況のときには、代わりにサイレント・インストールを実行することができます。 100ページの『サイレント・インストールの実行』を参照してください。

インストール・ログ・ファイル

ご使用のシステム上にあるログ・ファイルのタイプは、実行したインストールのタイプによって異なります。このセクションでは、各種インストールに関連したログについて説明します。

ログ・ファイルについて詳しくは、「管理ガイド」を参照してください。

InstallShield ウィザードインストールおよびアンインストールのログ・ファイル

以下のログ・ファイルでインストールに関する情報を検査することができます。インストール・プロセスの詳細は、ローカル・ワークステーション上の以下のディレクトリーにあるログ・ファイルに保持されます。

Tivoli Workload Scheduler

Windows オペレーティング・システム:%Temp%¥TWA¥tws86

ここで、

%Temp% は Windows システム環境変数です。

UNIX および Linux オペレーティング・システム:/tmp/TWA/tws86

表 3 に InstallShield ウィザードログ・ファイルがリストされています。

表 3. インストール・ログ・ファイル

ログ・ファイル名内容

twsstatus.log Tivoli Workload Scheduler インストール状況ログ・ファイル。インストールが正常に完了したか、エラーが発生したかを報告します。エラーの場合、エラーの原因が、誤ったフィールド値にあるのか、手順の失敗にあるのかを示します。

twsismp.log Tivoli Workload Scheduler インストール・トレース・ファイル

summary.log Tivoli Workload Scheduler インストール・ログ・ファイル

同じワークステーション上に複数のインストールが実行された場合は、ログのヘッダーおよびフッターに、インストールが実行されたユーザー ID (<TWS_user>) が示されます。同じワークステーション上に複数のインストールが実行された場合は、ほとんどのログ・ファイルが上書きされます。例外は、以下のファイルです。これらは上書きではなく、追加されます。v twsismp.log

v summary.log


注: サイレント・インストールを実行しており、使用している応答ファイルに正しい構文が含まれていない場合、インストールは失敗し、ログ・ファイルは生成されません。

twsinst ログ・ファイル

twsinst ログ・ファイルは、以下のとおりです。

<tempDir>/twsinst_<operating_system>_<TWS_user>^8.6.0.00.log。ここで、各項目は次のとおりです。

<tempDir>

ユーザーの一時ディレクトリー:

UNIX /tmp および /tmp/TWA/tws86

Windows オペレーティング・システム%Temp%¥TWA¥tws86

<operating_system>

オペレーティング・システム。

<TWS_user>

Tivoli Workload Scheduler がインストールされたユーザーの名前 (インストールの際に指定した名前)

ソフトウェア・パッケージ・ブロックのログ・ファイル

IBM Tivoli Configuration Manager ソフトウェア・パッケージ・ブロックのログ・ファイルは次のとおりです。

v <tempDir>/TWA/tws86/FP_TWS_<operating_system>_<TWS_user>^8.6.0.00.log (エージェント SPB ログ・ファイル)

v <tempDir>/TWA/tws86/TWS_LP_<TWS_user>^8.6.0.00.log (エージェント NLS SPB

ログ・ファイル)

ここで、

<tempDir>ユーザーの一時ディレクトリー:

Windows オペレーティング・システムデフォルト値は、%Temp%¥TWA¥tws86 です。

UNIX および Linux オペレーティング・システム/tmp/TWA/tws86

<operating_system>

オペレーティング・システム。

<TWS_user>

Tivoli Workload Scheduler がインストールされたユーザーの名前 (インストールの際に指定した名前)


WebSphere Application Server インストール・ログ・ファイル

アプリケーション・サーバーのインストールにはログはありません。ただし、アプリケーション・サーバーを更新する場合、例えば Tivoli Workload Scheduler フィックスパックの適用の際には、更新についての情報が記載されたログが作成されます。ログはディレクトリー <TWS_home>/eWAS/logs/update にあり、このディレクトリーには、インストールされているフィックスパックを識別するディレクトリー(例えば、7.0.0-WS-WASEmbeded-AixPPC64-FP000027.install) があり、そこに/updatelog.txt というログ・ファイルが入っています。

アプリケーション・サーバーの開始ログは、次の場所にあります。

<TWS_home>/eWAS/profiles/TIPProfile/logs/<SERVERNAME>/startServer.log

ここで <SERVERNAME> は以下を表します。

v Tivoli Workload Automation の最初のインスタンスの場合は server1

v Tivoli Workload Automation のそれ以降のインスタンスの場合は server2, server3...

注: アップグレードの場合、<SERVERNAME> は前のサーバーの名前です (例えばserver1)。

DB2 インストール・ログ・ファイル

DB2 インストール・ログ・ファイルについては、DB2 資料を参照してください。

Tivoli Workload Scheduler ユーザー

UNIX および Linux のオペレーティング・システムでは、選択したインストール方法には関係なく、インストールを実行する前に Tivoli Workload Scheduler ユーザーを手動で作成する必要があります。適切な UNIX および Linux オペレーティング・システム・コマンドを使用して、このユーザーを作成してください。

注: 一部のオペレーティング・システムでは、パスワードのあるユーザーは、最初のログイン時にパスワードを変更する必要があります。このような場合、インストールが正常に実行されるためには、ユーザーとしてログインし、最初にパスワードを変更する必要があります。

Windows ユーザーのドメインの権限および構造

Windows オペレーティング・システム上にインストールする場合は、以下の制約を考慮してください。

1 人はローカル・システム、もう 1 人は同じ名前でドメインに定義されている同じユーザーを使用して、同じシステムに 2 つのエージェントをインストールしないでください。

インストールを実行する Windows ユーザーについて、次の要件があります。

v ローカル TWS ユーザーの場合、ローカル管理グループのメンバーでなければなりません。

v ドメイン TWS ユーザーの場合、ドメイン・コントローラーのドメイン管理グループのメンバーでなければなりません。


すべての Windows 2003 Tivoli Workload Scheduler ユーザーに以下のユーザー権限が必要です。これらは、ローカルで付与される場合があります。ドメイン・レベルのポリシーは常にローカル・ポリシーに優先するので、以下の権限をドメインから付与する必要がある場合があります。

v オペレーティングシステムの一部として機能

v ローカルでのログオンを許可

v 認証後のクライアントの偽名の使用

v 以下の形でログオン:

– バッチ・ジョブとして– サービスとして

v プロセス・レベル・トークンの置き換え

注: これらの権限はインストールの際に付与されますが、確認は手動で行えます。

Microsoft Active Directory を実行する Windows ドメイン・コントローラーに関する考慮事項

ジョブを実行するユーザーがドメイン・ユーザーであり、ドメイン・コントローラーが実行中の Microsoft Active Directory であるワークステーション上に Tivoli

Workload Scheduler フォールト・トレラント・エージェントをインストールする場合、jobmon プロセスが正しい情報を取得してユーザーにジョブを実行させることができるように、エージェントをインストールしドメインを構成する方法を決定する必要があります。

ジョブを実行する前に、jobmon は、ジョブを実行するユーザーに関する情報を検索する必要があります。ユーザーがドメイン・ユーザーであり、ドメイン・コントローラーが Microsoft Active Directory を実行している場合には、そのユーザーの情報を検索できるかどうかは、そのユーザーのアクセス・コントロール・リスト (ACL)

の情報に依存します。ジョブを実行するメインの jobmon プロセスは、ローカル・システム・アカウント (AUTHORITYSYSTEM) として開始されますが、直ちにフォールト・トレラント・エージェントを所有する <TWS_user> の名前を使用します。これは、jobmon が正常にジョブを起動するためには、<TWS_user> が、それが情報を検索しようとしているユーザーの ACL 内にアクセス・コントロール・エントリー (ACE) をもっている必要があることを意味します。

この問題を解決するには、以下のアクションのうちいずれか 1 つを実行してください。

ジョブを実行するユーザーのセットに <TWS_user> がアクセスできるようにします。ドメイン・サーバー上で、ワークステーションでジョブを実行するすべての

ユーザーの ACL を編集し、それぞれに対して <TWS_user> の ACE を追加します。この場合、指定されたユーザーのみが jobmon によって実行依頼されたジョブを実行することができます。

TWS_BYPASS_DC=TRUE システム変数を使用することによって、すべてのユーザーが jobmon によって実行依頼されたジョブを実行できるようにします。

非ヌルの値を使用して、TWS_BYPASS_DC=TRUE システム変数を作成し、ワークステーションをリブートします。この場合、jobmon は、ユーザーのACL 内の ACE に対してセキュリティー検査を実行せずに、ユーザー情報


を取得します。すべてのローカル・ユーザーおよびドメイン・ユーザーは、jobmon によって実行依頼されたジョブを実行することができます。

<TWS_user> をドメイン・ユーザーとして設定することによって、すべてのユーザーが jobmon によって実行依頼されたジョブを実行できるようにします。

<TWS_user> を Windows ドメイン・ユーザーとしてセットアップし、<TWS_user> を使用して Tivoli Workload Scheduler のインスタンスをインストールします。この場合、ドメイン・コントローラー上のすべての認証済みユーザーは、ドメイン・ユーザーのデフォルト ACL にアクセスすることができます。これによって、ジョブはローカル・ユーザーまたはドメイン・ユーザーによって起動できるようになります。すべてのローカル・ユーザーおよびドメイン・ユーザーは、jobmon によって実行依頼されたジョブを実行することができます。

ユーザーの ACL に対するセキュリティー検査からワークステーションを除外します。ドメイン・サーバー上で、フォールト・トレラント・エージェントがインス

トールされるワークステーションのホスト名を Pre-Windows

2000-Compatible Access Group に追加します。このようにして、セキュリティーの見地から、ドメイン・コントローラーは、Active Directory をサポートしない Windows ドメインにあるかのように、このワークステーションとの間で相互作用を行います。この場合、すべてのローカル・ユーザーおよびドメイン・ユーザーは、jobmon によって実行依頼されたジョブを実行することができます。加えて、任意のローカル・ユーザーまたはドメイン・ユーザーによる、Tivoli Workload Scheduler によって制御されていない他のプロセスの実行が、ドメイン・コントローラーによって妨げられることはありません。

Windows Vista ユーザーの環境設定の確認

Tivoli Workload Scheduler を Windows ドメインに属していない Windows Vista ワークステーションにインストールする前に、ワークステーション名とドメイン名の両方が Windows 環境設定に大文字で登録されていることを確認してください。ワークステーションが Windows ドメインにない場合でも COMPUTERNAME とUSERDOMAIN の値は同一ですが、Vista の場合は、COMPUTERNAME が大文字の場合でも、USERDOMAIN の値が小文字になる場合があります。

この問題を解決するには、以下のアクションを実行してください。

1. DOS コマンド・プロンプト・シェルを開きます。

2. set コマンドを実行して、Windows 環境設定を表示します。

3. USERDOMAIN の値が大文字かどうかを確認してください。大文字でない場合、以下の次善策に従って修正してください。

4. set コマンドを実行して、COMPUTERNAME の値を選択した一時ホスト名に変更します。

set /p COMPUTERNAME=MYTEMPHOST

5. システムを再始動します。

6. ステップ 4 の一時ホスト名を元の値に置き換えて、set コマンドを再度実行します。



8. USERDOMAIN の値が大文字になっていることを確認します。

Windows サービス

Windows オペレーティング・システムにインストールを行うと、以下のサービスがWindows Service Control Manager に登録されます。

v Tivoli Workload Scheduler (<TWS_user> 用)

v Tivoli Netman (<TWS_user> 用)

v Tivoli Token Service (<TWS_user> 用) - インフライト・トレース機能サービスを含む

v Tivoli Workload Scheduler SSM Agent (<TWS_user> 用)

v WebSphere Application Server (<TWS_user> 用)

v IBM Common Platform Agent: tws_cpa_agent_ (<TWS_user> 用)

注: 新規サービスと同じ名前の既存のサービスは、インストールの際に上書きされます。

Service Control Manager 独自のユーザー・パスワード・データベースを保守します。インストールの後で <TWS_user> パスワードが変更される場合は、「コントロールパネル」にある「サービス」アプレットを使用して Tivoli Token Service および Tivoli Workload Scheduler (<TWS_user> 用) に新規パスワードを割り当てる必要があります。詳しくは、「管理ガイド」にある TWS_User のパスワードの変更に関するセクションを参照してください。

インストールまたはアップグレード前の Tivoli Workload Scheduler データベース表の作成またはアップグレード

この手順は、製品のインストールに必須ではありません。製品をインストールするIT 管理者がデータベース管理者のユーザー ID とパスワードを知らない場合に限り、データベース管理者がこの手順を実行して製品のインストール前に製品データベース表を作成したりアップグレードしたりする必要があります。それ以外の場合は、IT 管理者がインストール中にデータベース管理者のユーザー ID とパスワードを指定します。そうすると、製品のインストール/アップグレード時に表が自動的に作成/アップグレードされます。

データベース管理者は、この手順を使用してデータベース表を作成したりアップグレードしたりします。その後で、データベース管理者ユーザーとは異なるユーザーを持つ IT 管理者が製品をインストールしたりアップグレードしたりします。この手順を使用すれば、データベースに関するすべての機密情報 (管理者のユーザー ID/

パスワードなど) を管理するのはデータベース管理者のみとなり、IT 管理者はデータベースの機密情報を知らなくても製品をインストールしたりアップグレードしたりできます。

この章では、以下を行う場合に従う手順を説明します。

v DB2 を使用している場合、製品をインストールまたはアップグレードする前にTivoli Workload Scheduler および Dynamic Workload Broker データベース表を作成およびアップグレードします。 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』を参照してください。


v Oracle を使用している場合、製品をインストールまたはアップグレードする前にTivoli Workload Scheduler および Dynamic Workload Broker データベース表を作成およびアップグレードします。 56ページの『Oracle を使用している場合のデータベース表の作成またはアップグレード』を参照してください。

IT 管理者は以下を実行できます。

v Tivoli Workload Scheduler データベースにアクセスするための権限を DB2 サーバーの管理者が与えるユーザーとしてデータベース管理者ユーザー名を指定したインストール。

v 製品をインストールしたユーザーと同じ許可を持つ別のユーザーを使用したアップグレード。

DB2 を使用している場合のデータベース表の作成またはアップグレード

DB2 を使用している場合に Tivoli Workload Scheduler および Dynamic Workload

Broker データベース表を作成またはアップグレードするには、以下の手順を実行します。

1. プロパティー・ファイルをカスタマイズします。『DB2 のプロパティー・ファイルのカスタマイズ』を参照してください。

2. SQL ファイルを生成します。 47ページの『DB2 用 SQL ファイルの生成』を参照してください。

3. SQL ファイルを実行して SQL テーブルを作成します。 48ページの『DB2 用SQL テーブルを作成またはアップグレードするための SQL ファイルの実行』を参照してください。

DB2 のプロパティー・ファイルのカスタマイズプロパティー・ファイルをカスタマイズするには、以下のステップを実行します。

1. インストール DVD から、またはマスター・ドメイン・マネージャーまたは動的ドメイン・マネージャーを含んでいる eImage から、以下のプロパティー・ファイルを開きます。

Windows オペレーティング・システムの場合:<images_dir>¥RESPONSEFILES¥customizeDB2SQL.properties

UNIX および Linux システムの場合:<images_dir>/RESPONSEFILES/customizeDB2SQL.properties

ここで、images_dir は、製品イメージを抽出するディレクトリーを指定します。

2. ユーザーの必要に応じた値を使用して、SQL プロパティーをカスタマイズします。

TWSTEMPDIRデータベース表を作成するための SQL スクリプトを格納するディレクトリー。デフォルト値は以下のとおりです。

Windows オペレーティング・システムの場合:C:¥DOCUME~1¥ADMINI~1¥LOCALS~1¥Temp¥TWA¥tws86

UNIX および Linux システムの場合:/tmp/TWA/tws86


DB_USER

製品をインストールする前に、データベース表を作成する場合は、以下を実行します。

DB2 サーバーの管理者によって Tivoli Workload Scheduler データベースにアクセスするための権限を付与されるユーザーを指定します。

IT 管理者は、製品のインストール時にこの値を「DB2 サーバー管理者ユーザー」フィールドに指定する必要があります。

Windows オペレーティング・システムの場合デフォルト値は db2admin です。

UNIX および Linux オペレーティング・システムの場合デフォルト値は db2inst1 です。

UNIX では、このユーザーに切り替えることができるか、およびDB2 環境を読み込むことができるかを検査します。

製品をアップグレードする前にデータベース表をアップグレードする場合は、以下を実行します。

アップグレードする製品のバージョンをインストールするときに使用したユーザーを指定します。後から製品をアップグレードするときに「DB_USER」フィールドに指定したユーザーとは異なるユーザーを指定できますが、そのユーザーはデータベース・アクセス許可を持っている必要があります。

TWS_USERTivoli Workload Scheduler のユーザー名を指定します。

これには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。国別文字を含めることはできません。ユーザー名の先頭文字は文字でなければなりません。

IT 管理者は、製品のインストール時にこの値を「User_name」フィールドに指定する必要があります。

TWS_DBDB2 データベースの名前。最大長は 5 文字です。デフォルト値は TWSです。以下に示すように、SQL テーブルを作成する対象に応じて操作します。

マスター・ドメイン・マネージャー動的ドメイン・マネージャーに使用されないデータベースの名前を入力します。

動的ドメイン・マネージャーマスター・ドメイン・マネージャーに使用されないデータベースの名前を入力します。

IT 管理者は、製品のインストール時にこの値を「データベース名」フィールドに指定する必要があります。

TWS_TS_NAMEDB2 インスタンスの表スペースの名前。この表スペースは、スケジューリング・オブジェクトおよびイベント・ルールの保管に使用されます。


DB2 表スペースに関する情報については、DB2 の資料を参照してください。デフォルトの表スペース名は TWS_DATA です。

IT 管理者は、製品のインストール時にこの値を「テーブル・スペース名」フィールドに指定する必要があります。

TWS_DATA_TS_PATHDB2 表スペースの相対パス。このパスは、相対パスでも完全修飾パスでもかまいません。表スペース・パスが完全修飾パスの場合、DB2 管理者ユーザーには、表スペースがインストールされているディレクトリーに対する完全なアクセス権限が必要です。デフォルトの表スペース・パス名は TWS_DATA です。UNIX および Linux オペレーティング・システムの場合は、DB2 管理者がテーブル・スペース・ディレクトリーの上のディレクトリーに対して書き込みアクセス権限を持つようにしてください。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。

IT 管理者は、製品のインストール時にこの値を「テーブル・スペース・パス」フィールドに指定する必要があります。

TWS_LOG_TS_NAMETivoli Workload Scheduler イベント・ログを保管する DB2 テーブル・スペースの名前を指定します。これらのログには、イベント・ルール・インスタンス、トリガーされるアクション、および Dynamic Workload

Console によって表示されるオペレーター・メッセージに関するデータが含まれます。ログのデータを使用して、レポートを作成できます。レポート・データは Dynamic Workload Console を使用して表示できます。デフォルト名は TWS_LOG です。

IT 管理者は、製品のインストール時にこの値を「レポート・テーブル・スペース名」フィールドに指定する必要があります。

TWS_LOG_TS_PATHTivoli Workload Scheduler イベント・ログを保管する DB2 テーブル・スペースのパスを指定します。デフォルトのパスは TWS_LOG です。このパスは、相対パスでも完全修飾パスでもかまいません。表スペースのパスが完全修飾パスの場合、DB2 管理者ユーザーには、表スペースがインストールされているディレクトリーに対する完全なアクセス権限が必要です。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。

注: レポート・テーブル・スペース・パスはテーブル・スペース・パスと同じものにすることはできません。

IT 管理者は、製品のインストール時にこの値を「レポート・テーブル・スペース・パス」フィールドに指定する必要があります。

COMPANY_NAME会社の名前。スペースを使用でき、最大フィールド長は 40 文字です。デフォルトは MYCOMPANY です。

IT 管理者は、製品のインストール時にこの値を「会社」フィールドに指定する必要があります。


EIF_PORTイベント管理処理プログラムがイベントを受信するために使用するポート。デフォルト値は 31131 です。有効範囲は、1 から 65535 です。

IT 管理者は、製品のインストール時にこの値を「イベント処理プログラム」フィールドに指定する必要があります。

HOST_NAME動的ドメイン・マネージャーが動的エージェントと通信するときに使用する完全修飾ホスト名または IP アドレス。

IT 管理者は、製品のインストール時にこの値を動的エージェント構成情報の「ホスト名または IP アドレス」フィールドに指定する必要があります。

WAS_SEC_PORTDynamic Workload Broker の HTTPS ポート。動的エージェントがDynamic Workload Broker に接続するときにこれを使用します。デフォルト値は 31116 です。フィールドをブランクのままにすると、デフォルトで 0 に設定されます。有効な範囲は 1 から 65535 です。

IT 管理者は、製品のインストール時にこの値を「Dynamic workloadbroker の HTTPS ポート番号」フィールドに指定する必要があります。

DB2 用 SQL ファイルの生成SQL ファイルを生成するには、customizeSQL スクリプトを使用します。これは、以下に配置されています。

Windows オペレーティング・システムの場合<images_dir>¥TWS¥<operating_system>¥tws_tools¥customizeSQL.bat

UNIX および Linux オペレーティング・システムの場合<images_dir>/TWS/<operating_system>/tws_tools/customizeSQL.sh

ここで、

images_dir

製品イメージを保管したディレクトリー。eImage を使用する場合は、マスター・ドメイン・マネージャーを含んでいるものをダウンロードします。

operating_system

作業しているオペレーティング・システム。

コマンドの使用法を表示するには、以下を実行します。

customizeSQL -usage

スクリプトの構文は以下のとおりです。

Windows オペレーティング・システムの場合customizeSQL -javaHome <javahome_dir> -propertyFile <property_file_path>

UNIX および Linux オペレーティング・システムの場合customizeSQL -imagesDir <images_dir> -javaHome <javahome_dir>

-propertyFile <property_file_path>


ここで、

images_dir

UNIX のみ。Tivoli Workload Scheduler setup.bin コマンドが配置されているディレクトリー。

javahome_dirJava ランタイム環境が配置されているディレクトリー。

property_file_pathプロパティー・ファイルが配置されているディレクトリー。

以下の例は、/opt/TWSImages/TWS/AIX ディレクトリーにイメージを保管し、/tmp/

ディレクトリーにプロパティー・ファイルを保管する場合の UNIX 用コマンドを示しています。

customizeSQL -imagesDir /opt/TWSImages/TWS/AIX -javaHome /usr -propertyFile/tmp/customizeDB2SQL.properties

SQL ファイルは、TWSTEMPDIR プロパティーで指定したディレクトリーに作成されます。

以下の例は、 C:¥Program Files¥Java¥jre6 に Java ランタイムを保管し、C:¥Temp¥

ディレクトリーにプロパティー・ファイルを保管する場合の Windows 用のコマンドを示しています。

customizeSQL -javaHome "C:¥Program Files¥Java¥jre6"-propertyFile "C:¥Temp¥customizeDb2Sql.properties"

SQL ファイルは、TWSTEMPDIR プロパティーで指定したディレクトリーに作成されます。

DB2 用 SQL テーブルを作成またはアップグレードするための SQLファイルの実行このセクションでは、SQL テーブルを作成またはアップグレードするために実行する必要があるコマンドについて説明します。実行する必要があるコマンドは、以下の場合に応じて異なります。

インストール前に SQL テーブルを作成する場合

v マスター・ドメイン・マネージャー。 49ページの『マスター・ドメイン・マネージャーのインストール前』を参照してください。

v 動的ドメイン・マネージャー。 51ページの『動的ドメイン・マネージャーのインストール前』を参照してください。

製品のアップグレード前に SQL テーブルをアップグレードする場合

v バージョン 8.3 からバージョン 8.5 まで。 51ページの『Tivoli Workload

Scheduler V8.3 以降から V8.5 へのアップグレード前』を参照してください。

v バージョン 8.5.1 からバージョン 8.5.1.1 まで。 54ページの『Tivoli

Workload Scheduler V8.5.1 から V8.5.1.1 へのアップグレードの前』を参照してください。


これらのスクリプトは、db2inst1 管理者ユーザーを使用して、またはデータベース管理者から Tivoli Workload Scheduler データベースにアクセスする権限を付与されたユーザーを使用して、データベース管理者によって実行される必要があります。

マスター・ドメイン・マネージャーのインストール前: マスター・ドメイン・マネージャーをインストールする前に SQL テーブルを作成する場合は、以下のステップを実行します。

1. 以下のコマンドを実行して、Tivoli Workload Scheduler データベースを作成します。

db2 -v -t -f <sql_directory>/sql/create_database.sql

ここで、

sql_directory は、 47ページの『DB2 用 SQL ファイルの生成』で作成したSQL の保管先のディレクトリーです。

2. 以下のコマンドを実行して、ユーザーを Tivoli Workload Scheduler データベースに接続します。

db2 connect to TWS_DB user ADMIN_USER ¥"ADMIN_PW¥"

ここで、

TWS_DB

TWS_DB プロパティーに指定した値です。

ADMIN_USER

DB2 データベース管理者です。

ADMIN_PW

DB2 データベース管理者のパスワードです。

3. 以下のコマンドを実行して、Tivoli Workload Scheduler テーブル・スペースを作成します。

db2 -v -t -f <sql_directory>/sql/create_tablespaces.sql

4. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール表を作成します。

db2 -v -t -f <sql_directory>/sql/create_rule_tables.sql

5. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ表を作成します。

db2 -v -t -f <sql_directory>/sql/create_log_tables.sql

6. 以下のコマンドを実行して、Tivoli Workload Scheduler 表を作成します。

db2 -v -t -f <sql_directory>/sql/create_tables.sql

7. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール制約を設定します。

db2 -v -t -f <sql_directory>/sql/create_rule_constraints.sql

8. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ制約を設定します。

db2 -v -t -f <sql_directory>/sql/create_log_constraints.sql

9. 以下のコマンドを実行して、Tivoli Workload Scheduler 制約を設定します。

db2 -v -t -f <sql_directory>/sql/create_constraints.sql


10. 以下のコマンドを実行して、Tivoli Workload Scheduler 表にデータを取り込みます。

db2 -v -t -f <sql_directory>/sql/populate_tables.sql

11. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール索引を作成します。

db2 -v -t -f <sql_directory>/sql/create_rule_indexes.sql

12. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ索引を作成します。

db2 -v -t -f <sql_directory>/sql/create_log_indexes.sql

13. 以下のコマンドを実行して、Tivoli Workload Scheduler 索引を作成します。

db2 -v -t -f <sql_directory>/sql/create_indexes.sql

14. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール・ビューを作成します。

db2 -v -t -f <sql_directory>/sql/create_rule_views.sql

15. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ・ビューを作成します。

db2 -v -t -f <sql_directory>/sql/create_log_views.sql

16. 以下のコマンドを実行して、Tivoli Workload Scheduler ビューを作成します。

db2 -v -t -f <sql_directory>/sql/create_views.sql

17. 以下のコマンドを実行して、Tivoli Workload Scheduler ユーザーに Tivoli

Workload Scheduler の表とビューにアクセスする許可を割り当てます。

db2 -v -t -f <sql_directory>/sql/grant_twsuser.sql

18. 以下のコマンドを実行して、データベース・ユーザーに許可を付与します。

db2 grant DBADM on database to user DB_USER

19. 以下のコマンドを実行して、ジョブ・リポジトリーを作成します。

db2 -v -t -f <sql_directory>/DWB/sql/create_job_repository.sql

20. 以下のコマンドを実行して、割り振りリポジトリーを作成します。

db2 -v -t -f <sql_directory>/DWB/sql/create_allocation_repository.sql

21. 以下のコマンドを実行して、リソース・リポジトリーを作成します。

db2 -v -t -f <sql_directory>/DWB/sql/create_resource_repository.sql

22. 以下のコマンドを実行して、サーバー表を作成します。

db2 -v -t -f <sql_directory>/DWB/sql/create_server.sql

23. 以下のコマンドを実行して、Tivoli Workload Scheduler ノードをカタログします。

db2 catalog local node TWS_DB_ND instance DB2_instance_name

24. 以下のコマンドを実行して、ローカル・ノードをカタログします。

db2 catalog tcpip node LBNODE remote 127.0.0.1 serverDB2_instance_port

25. 以下のコマンドを実行して、Tivoli Workload Scheduler データベースの別名をカタログします。

db2 catalog db TWS_DB as TWS_DB_DBat node LBNODE


|

|

動的ドメイン・マネージャーのインストール前: 動的ドメイン・マネージャーをインストールする前に SQL テーブルを作成する場合は、以下のステップを実行します。

1. 以下のコマンドを実行して、Tivoli Workload Scheduler データベースを作成します。

db2 -v -t -f <sql_directory>/sql/create_database.sql

ここで、

sql_directory は、 47ページの『DB2 用 SQL ファイルの生成』で作成したSQL の保管先のディレクトリーです。


db2 connect to TWS_DB user ADMIN_USER ¥"ADMIN_PW¥"

ここで、

TWS_DB


ADMIN_USER


ADMIN_PW


3. 以下のコマンドを実行して、Tivoli Workload Scheduler テーブル・スペースを作成します。

db2 -v -t -f <sql_directory>/sql/create_tablespaces.sql










db2 grant DBADM on database to user DB_USER

9. 以下のコマンドを実行して、Tivoli Workload Scheduler データベースの別名をカタログします。

db2 catalog db TWS_DB as TWS_DB_DBat node LBNODE

10. 以下のコマンドを実行して、ローカル・ノードをカタログします。

db2 catalog tcpip node LBNODE remote 127.0.0.1 server DB2_instance_port

Tivoli Workload Scheduler V8.3 以降から V8.5 へのアップグレード前: Tivoli

Workload Scheduler を V8.3 以降から V8.5 にアップグレードする前に SQL テーブルをアップグレードする場合は、以下のステップを実行します。



db2 connect to TWS_DB user ADMIN_USERusing ¥"ADMIN_PW¥"

ここで、

TWS_DB


ADMIN_USER


ADMIN_PW


2.


db2 grant DBADM on database to user DB_UPGRADE_USER

ここで、DB_UPGRADE_USER は、 IT 管理者が後から製品のアップグレード時に「DB2 サーバー管理者ユーザー」フィールドに指定するユーザーの名前です。SYSMON 権限を DB_UPGRADE_USER に割り当てる必要があります。

4. select コマンドを実行して、ご使用のデータベースのバージョンを検査します。

このコマンドは、DBADM 権限または少なくとも DATAACCESS 権限を持つユーザーによって実行される必要があります。

以下の構文を使用して、このコマンドを実行します。

select MPR_DESCRIPTION, MPR_VALUE from MDL.MPR_MODEL_PROPERTIESwhere MPR_NAME=’DATABASE_VERSION’

DATABASE_VERSION が以下の値のいずれかを戻したとします。8.3.0.00

バージョン 8.3 をインストール済みです。8.3.0.01

バージョン 8.3.0.1 をインストール済みです。8.4.0.00



バージョン 8.5 をインストール済みです。

以上の場合に、ステップ 5 (53ページ) で説明されている手順を実行します。

DATABASE_VERSION が以下の値のいずれかを戻したとします。

8.5.1.00バージョン 8.5.1 をインストール済みです。

8.5.1.01バージョン 8.5.1.1 をインストール済みです。


|

|

|

|

|

54ページの『Tivoli Workload Scheduler V8.5.1 から V8.5.1.1 へのアップグレードの前』で説明されている手順を実行します。

5. ユーザー固有の DATABASE_VERSION 値に対するコマンドから開始して、以下のコマンドを順番に実行します。

例えば、DATABASE_VERSION が以下と等しい場合を想定します。

8.3.0.00「Tivoli Workload Scheduler データベース表をアップグレードするには」にリストされているすべてのコマンドを実行します。

8.4.0.00以下のコマンドを実行します。a. 4c

b. 4d

c. 4e

d. 4f

e. 4g

f. 4h

8.5.0.00Tivoli Workload Scheduler データベース表をアップグレードするには、以下のコマンドを実行します。a. 4e

b. 4f

c. 4g

d. 4h

Dynamic Workload Broker データベース表をアップグレードするには、「動的ワークロード・ブローカー・データベース表をアップグレードするには」にリストされているすべてのコマンドを実行します。

Tivoli Workload Scheduler データベース表をアップグレードするには、以下を実行します。

a.

db2 -v -t -f <sql_directory>/sql/upgrade_83000_83001.sql

b.


c.


d.


e.


f.


g.


h.


db2 -x ’SELECT COUNT (*) FROM MDL.JSF_JS_INST_FORECAST’

v コマンドが以下のエラー・メッセージを戻したとします。

SQL0204N "MDL.JSF_JS_INST_FORECAST"name is an undefined name. SQLSTATE=42704

以下のコマンドを実行します。


Dynamic Workload Broker データベース表をアップグレードするには、以下を実行します。

a. 以下のコマンドを実行して、ジョブ・リポジトリーを作成します。


b. 以下のコマンドを実行して、割り振りリポジトリーを作成します。


c. 以下のコマンドを実行して、リソース・リポジトリーを作成します。


d. 以下のコマンドを実行して、サーバー表を作成します。


Tivoli Workload Scheduler V8.5.1 から V8.5.1.1 へのアップグレードの前: Tivoli

Workload Scheduler をバージョン 8.5.1 からバージョン 8.51.1 にアップグレードする前に SQL テーブルをアップグレードする場合は、以下のステップを実行します。


db2 connect to TWS_DB user ADMIN_USERusing ¥"ADMIN_PW¥"

ここで、

TWS_DB


ADMIN_USER


ADMIN_PW



db2 grant DBADM on database to user DB_UPGRADE_USER

ここで、DB_UPGRADE_USER は、 IT 管理者が後から製品のアップグレード時に「DB2 サーバー管理者ユーザー」フィールドに指定するユーザーの名前です。SYSMON 権限を DB_UPGRADE_USER に割り当てる必要があります。

3. select コマンドを実行して、ご使用のデータベースのバージョンを検査します。

このコマンドは、DBADM 権限または少なくとも DATAACCESS 権限を持つユーザーによって実行される必要があります。以下の構文を使用して、このコマンドを実行します。


|

|

|

|

|

select MPR_DESCRIPTION, MPR_VALUE from MDL.MPR_MODEL_PROPERTIESwhere MPR_NAME=’DATABASE_VERSION’







51ページの『Tivoli Workload Scheduler V8.3 以降から V8.5 へのアップグレード前』で説明されている手順を実行します。




以上の場合に、ステップ 4 で説明されている手順を実行します。

4. DATABASE_VERSION が 8.5.1.00 から 8.5.1.01 までの値を戻す場合、以下のコマンドを順序どおりに実行します。

Tivoli Workload Scheduler データベース表をアップグレードするには、以下を実行します。

a.


b.


c.

db2 -x ’SELECT COUNT (*) FROM MDL.JSF_JS_INST_FORECAST’

v コマンドが以下のエラー・メッセージを戻したとします。

SQL0204N "MDL.JSF_JS_INST_FORECAST"name is an undefined name. SQLSTATE=42704

以下のコマンドを実行します。



db2 -v -t -f <sql_directory>/DWB/sql/upgrade_85100_86000.sql


Oracle を使用している場合のデータベース表の作成またはアップグレード

Oracle を使用している場合に Tivoli Workload Scheduler および Dynamic Workload

Broker データベース表を作成またはアップグレードするには、以下の手順を実行します。

1. プロパティー・ファイルをカスタマイズします。『Oracle 用プロパティー・ファイルのカスタマイズ』を参照してください。

2. SQL ファイルを生成します。 58ページの『Oracle 用 SQL ファイルの生成』を参照してください。

3. SQL ファイルを実行して SQL テーブルを作成します。 58ページの『Oracle 用の SQL テーブルを作成およびアップグレードするための SQL ファイルの実行』を参照してください。

Oracle 用プロパティー・ファイルのカスタマイズプロパティー・ファイルをカスタマイズするには、以下のステップを実行します。

1. インストール DVD から、またはマスター・ドメイン・マネージャーまたは動的ドメイン・マネージャーを含んでいる eImage から、以下のプロパティー・ファイルを開きます。

Windows オペレーティング・システムの場合:<images_dir>¥RESPONSEFILES¥customizeORACLESQL.properties

UNIX および Linux システムの場合:<images_dir>/RESPONSEFILES/customizeORACLESQL.properties

ここで、<images_dir> は、製品イメージを抽出するディレクトリーを指定します。

2. ユーザーの必要に応じた値を使用して、SQL プロパティーをカスタマイズします。

TWSTEMPDIRデータベース表を作成するための SQL スクリプトを格納するディレクトリー。デフォルト値は以下のとおりです。

Windows オペレーティング・システムの場合:C:¥DOCUME~1¥ADMINI~1¥LOCALS~1¥Temp¥TWA¥tws86

UNIX および Linux システムの場合:/tmp/TWA/tws86

MDL_USERTivoli Workload Scheduler および Dynamic Workload Broker データベースにアクセスするデータベース管理者ユーザー名 (SYSTEM など)。これは、Oracle 上で作成されたユーザーである必要があります。これはオペレーティング¥システムのユーザーではありません。

IT 管理者は、製品のインストール時にこの値を「Oracle アドミニストレーター・ユーザー」フィールドに指定する必要があります。

TWS_PASSWORDMDL_USER のパスワード。


IT 管理者は、製品のインストール時にこの値を「Oracle アドミニストレーター・ユーザー・パスワード」フィールドに指定する必要があります。

TWS_USERTivoli Workload Scheduler のユーザー名を指定します。

これには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。国別文字を含めることはできません。ユーザー名の先頭文字は文字でなければなりません。

IT 管理者は、製品のインストール時にこの値を「User_name」フィールドに指定する必要があります。

TWS_TS_NAMETivoli Workload Scheduler データ表スペースを識別する名前。このフィールドのデフォルトは USERS です。

IT 管理者は、製品のインストール時にこの値を「Tivoli WorkloadScheduler データ・テーブル・スペース」フィールドに指定する必要があります。

TWS_LOG_TS_NAMEレポート・データが保管される Tivoli Workload Scheduler テーブル・スペースを識別する名前。レポート・データは Dynamic Workload Console

を使用して表示できます。このフィールドのデフォルト値は USERS です。

IT 管理者は、製品のインストール時にこの値を「Tivoli WorkloadScheduler レポート・テーブル・スペース」フィールドに指定する必要があります。

TWS_TS_TEMP_NAMETivoli Workload Scheduler 一時表スペースを識別する名前。このフィールドのデフォルト値は TEMP です。

IT 管理者は、製品のインストール時にこの値を「Tivoli WorkloadScheduler 一時テーブル・スペース」フィールドに指定する必要があります。

COMPANY_NAME会社の名前。スペースを使用でき、最大フィールド長は 40 文字です。デフォルトは MYCOMPANY です

IT 管理者は、製品のインストール時にこの値を「会社」フィールドに指定する必要があります。

EIF_PORTイベント管理処理プログラムがイベントを受信するために使用するポート。有効範囲は、1 から 65535 です。デフォルト値は 31131 です。

IT 管理者は、製品のインストール時にこの値を「イベント処理プログラム」フィールドに指定する必要があります。

HOST_NAME動的ドメイン・マネージャーが動的エージェントと通信するときに使用する完全修飾ホスト名または IP アドレス。


IT 管理者は、製品のインストール時にこの値を動的エージェント構成情報の「ホスト名または IP アドレス」フィールドに指定する必要があります。

WAS_SEC_PORTDynamic Workload Broker の HTTPS ポート。動的エージェントがDynamic Workload Broker に接続するときにこれを使用します。有効範囲は、1 から 65535 です。デフォルト値は 31116 です。このフィールドをブランクのままにすると、デフォルトの 0 になります。

IT 管理者は、製品のインストール時にこの値を「Dynamic workloadbroker の HTTPS ポート番号」フィールドに指定する必要があります。

Oracle 用 SQL ファイルの生成SQL テーブルを生成するには、 47ページの『DB2 用 SQL ファイルの生成』で説明されているように customizeSQL スクリプトを実行します。

Oracle 用の SQL テーブルを作成およびアップグレードするためのSQL ファイルの実行このセクションでは、SQL テーブルを作成またはアップグレードするために実行する必要があるコマンドについて説明します。実行する必要があるコマンドは、以下の場合に応じて異なります。

インストール前に SQL テーブルを作成する場合

v マスター・ドメイン・マネージャー。『マスター・ドメイン・マネージャーのインストール前』を参照してください。

v 動的ドメイン・マネージャー。 61ページの『動的ドメイン・マネージャーのインストール前』を参照してください。

製品のアップグレード前に SQL テーブルをアップグレードする場合

v バージョン 8.3 以降からバージョン 8.5。 62ページの『Tivoli Workload

Scheduler V8.3 以降から V8.5 へのアップグレード前』を参照してください。

v バージョン 8.5.1 からバージョン 8.5.1.1 まで。 67ページの『V8.5.1 から V8.5.1.1 へのアップグレードの前』を参照してください。

これらのスクリプトは、ユーザーが MDL_USER に指定した値、またはデータベース管理者が Tivoli Workload Scheduler データベースにアクセスするために権限を付与したユーザーを使用して、データベース管理者によって実行される必要があります。

マスター・ドメイン・マネージャーのインストール前: マスター・ドメイン・マネージャーをインストールする前に SQL テーブルを作成する場合は、以下のステップを実行します。

1. 以下のコマンドを実行して、Tivoli Workload Scheduler ユーザーを作成します。


sqlplus -L -S <ORACLE_ADMIN>/<ORACLE_ADMIN_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_users.sql

ここで、

ORACLE_ADMIN

Oracle データベース管理者です。

ORACLE_ADMIN_PW

ORACLE_ADMIN のパスワードです。

ネット・サービス名

クライアントが Oracle Net サーバーと、Oracle Net 接続用の特定のシステム ID またはデータベースを示すために使用する名前。ネット・サービス名は、ポート番号およびプロトコルにマップされます。それは、接続ストリング、データベース別名、ホスト・ストリング、またはサービス名とも呼ばれます。

Oracle データベースのインストール先に応じて、以下のようになります。

v マスター・ドメイン・マネージャーまたはバックアップ・マスターのインストール先と同じシステムにインストールされる場合、ネット・サービス名は Oracle データベースの名前となります。

v 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストール先と同じシステムにインストールされる場合、ネット・サービス名は Oracle データベースの名前となります。

v マスター・ドメイン・マネージャーまたはバックアップ・マスターのインストール先のシステムにインストールされていない場合、ネット・サービス名はリモート・データベースへの接続用に構成された別名となります。

v 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストール先のシステムにインストールされていない場合、ネット・サービス名はリモート・データベースへの接続用に構成された別名となります。

IT 管理者は、製品のインストール時にこの値を「ネット・サービス名」フィールドに指定する必要があります。

sql_directory

47ページの『DB2 用 SQL ファイルの生成』で作成した SQL の保管先のディレクトリー。

2. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール表を作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_rule_tables.sql

ここで、

TWS_MDL_USER

プロパティー・ファイルの「MDL_USER」フィールドに指定したユーザーです。


TWS_MDL_PWMDL_USER のパスワードです。

3. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ表を作成します。

ORACLE Partitioning フィーチャーを使用していなかった場合sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/create_log_tables.sql

ORACLE Partitioning フィーチャーを使用していた場合sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_log_tables.sql

4. 以下のコマンドを実行して、Tivoli Workload Scheduler 表を作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_tables.sql

5. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール制約を設定します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_rule_constraints.sql

6. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ制約を設定します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_log_constraints.sql

7. 以下のコマンドを実行して、Tivoli Workload Scheduler 制約を設定します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME><sql_directory>/sql/create_constraints.sql

8. 以下のコマンドを実行して、Tivoli Workload Scheduler 表にデータを取り込みます。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/populate_tables.sql

9. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール索引を作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_rule_indexes.sql

10. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ索引を作成します。

ORACLE Partitioning フィーチャーを使用していなかった場合sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/create_log_indexes.sql

ORACLE Partitioning フィーチャーを使用していた場合sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_log_indexes.sql

11. 以下のコマンドを実行して、Tivoli Workload Scheduler 索引を作成します。


sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_indexes.sql

12. 以下のコマンドを実行して、Tivoli Workload Scheduler イベント・ルール・ビューを作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_rule_views.sql

13. 以下のコマンドを実行して、Tivoli Workload Scheduler ログ・ビューを作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_log_views.sql

14. 以下のコマンドを実行して、Tivoli Workload Scheduler ビューを作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/create_views.sql


sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_job_repository.sql


sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_allocation_repository.sql


sqlplus -L -S <TWS_MDL_USER/<TWS_MDL_PW@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_resource_repository.sql


sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_server.sql

動的ドメイン・マネージャーのインストール前: 動的ドメイン・マネージャーをインストールする前に SQL テーブルを作成する場合は、以下のステップを実行します。

1. 以下のコマンドを実行して、Tivoli Workload Scheduler ユーザーを作成します。

sqlplus -L -S <ORACLE_ADMIN>/<ORACLE_ADMIN_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_users.sql

ここで、

ORACLE_NET_SERVICE_NAME



IT 管理者は、インストール時にこの値を「ネット・サービス名」フィールドに指定する必要があります。






sql_directory

47ページの『DB2 用 SQL ファイルの生成』で作成した SQL の保管先のディレクトリー。






sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_resource_repository.sql



Tivoli Workload Scheduler V8.3 以降から V8.5 へのアップグレード前: Tivoli

Workload Scheduler を V8.3 以降から V8.5 にアップグレードする前に SQL テーブルをアップグレードする場合は、以下のステップを実行します。

1. MDL_USER プロパティーに指定したユーザーを使用して、ORACLE データベースにログオンします。

2. 以下のコマンドを実行して、ご使用のデータベースのバージョンを検査します。

select * FROM <MDL_USER>.MPR_MODEL_PROPERTIESwhere MPR_NAME=’DATABASE_VERSION’



8.3.0.00バージョン 8.3 をインストール済みです。





以上の場合に、ステップ 3 にリストされているコマンドを実行します。




67ページの『V8.5.1 から V8.5.1.1 へのアップグレードの前』で説明されている手順を実行します。

3. ORACLE Partitioning フィーチャーを使用していたかどうかを考慮し、ユーザー固有のデータベース・バージョンに対するコマンドから開始して、以下のコマンドを順序どおりに実行します。

例えば、DATABASE_VERSION が 8.5.0.00 に等しい場合、以下を実行します。

ORACLE Partitioning フィーチャーを使用していなかった場合以下のコマンドを実行します。

a. 4d (64ページ)

b. 4e (64ページ)

c. 4f (64ページ)

d. 4g (64ページ)

ORACLE Partitioning フィーチャーを使用していた場合以下のコマンドを実行します。

a. 7d (66ページ)

b. 7e (66ページ)

c. 7f (66ページ)

d. 7g (66ページ)

ORACLE Partitioning フィーチャーを使用していなかった場合に、TivoliWorkload Scheduler データベース表をアップグレードする場合

以下のコマンドを実行します。a. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>

@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/upgrade_83001_84000.sql



クライアントが Oracle Net サーバーと、Oracle Net 接続用の特定のシステム ID またはデータベースを示すために使用する名前。ネット・サービス名は、ポート番号およびプロトコルにマップされます。それは、接続ストリング、データベース別名、ホスト・ストリング、またはサービス名とも呼ばれます。IT 管理者は、インストール時にこの値を「ネット・サービス名」フィールドに指定する必要があります。






sql_directory

47ページの『DB2 用 SQL ファイルの生成』で作成したSQL の保管先のディレクトリー。

b. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_84001_84001.sql

c. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/upgrade_84001_85000.sql

d. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85000_85100.sql

e. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85100_85101.sql

f. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/upgrade_85101_86000.sql

g. sqlplus -L -S <TWS_MDL_USER>/<TWS_USER_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/check_forecast.sql

v コマンドが 0 以外の値を戻す場合は、以下のコマンドを実行します。


sqlplus -L -S <TWS_MDL_USER>/<TWS_USER_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgreade_84001_84005.sql

ORACLE Partitioning フィーチャーを使用していた場合に、Tivoli WorkloadScheduler データベース表をアップグレードするには、以下を実行します。

以下のコマンドを実行します。a. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>

@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_83001_84000.sql









sql_directory



c. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_84001_85000.sql


d. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85000_85100.sql

e. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85100_85101.sql

f. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85101_86000.sql

g. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/check_forecast.sql

v コマンドが 0 以外の値を戻す場合は、以下のコマンドを実行します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_USER_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_84001_84001.sql


a. 以下のコマンドを実行して、ジョブ・リポジトリーを作成します。









v 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストール先のシステムにインス


トールされていない場合、ネット・サービス名はリモート・データベースへの接続用に構成された別名となります。

sql_directory


b. 以下のコマンドを実行して、割り振りリポジトリーを作成します。


c. 以下のコマンドを実行して、リソース・リポジトリーを作成します。

sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/create_resource_repository.sql

d. 以下のコマンドを実行して、サーバー表を作成します。


e. ORACLE データベースに SYSTEM としてログオンし、以下のコマンドを実行します。

grant create procedure to <MDL_USER>

V8.5.1 から V8.5.1.1 へのアップグレードの前: Tivoli Workload Scheduler をバージョン 8.5.1 からバージョン 8.5.1.1 にアップグレードする前に SQL テーブルをアップグレードする場合は、以下のステップを実行します。

1. MDL_USER プロパティーに指定したユーザーを使用して、ORACLE データベースにログオンします。

2. 以下のコマンドを実行して、ご使用のデータベースのバージョンを検査します。

select * FROM <MDL_USER>.MPR_MODEL_PROPERTIESwhere MPR_NAME=’DATABASE_VERSION’







62ページの『Tivoli Workload Scheduler V8.3 以降から V8.5 へのアップグレード前』で説明されている手順を実行します。





以上の場合に、ステップ 3 で説明されている手順を実行します。

3. ORACLE Partitioning フィーチャーを使用したかどうかに応じて、特定のデータベース・バージョンに対するコマンドから開始して、以下のコマンドを順序どおりに実行します。

ORACLE Partitioning フィーチャーを使用していなかった場合に、TivoliWorkload Scheduler データベース表をアップグレードする場合

a. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85100_85101.sql









sql_directory


b. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/stded/upgrade_85101_86000.sql


ORACLE Partitioning フィーチャーを使用していた場合に、Tivoli WorkloadScheduler データベース表をアップグレードするには、以下を実行します。

a. sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/sql/upgrade_85100_85101.sql









sql_directory




sqlplus -L -S <TWS_MDL_USER>/<TWS_MDL_PW>@<ORACLE_NET_SERVICE_NAME>@<sql_directory>/DWB/sql/upgrade_85100_86000.sql


インストール中

この章では、Tivoli Workload Scheduler の現行バージョンを初めてインストールする方法を説明します。この章には、以下のセクションが含まれています。

v 『ユーザー許可要件』

v 『DB2 のインストール』

v 71ページの『インストール・ウィザードの使用』

v 100ページの『サイレント・インストールの実行』

v 106ページの『twsinst を使ったエージェントのインストール』

v 115ページの『Software Distribution を使ったエージェントのインストール』

v 125ページの『Job Brokering Definition Console のインストール』

v 126ページの『Tivoli Workload Scheduler for Additional Plug-ins の使用による追加プラグインのインストール』

ユーザー許可要件

手順を開始する前に、許可の役割を確認します。

インストール、アップグレード、またはアンインストールのウィザードのいずれかまたはコマンドを実行するための許可要件は、同じです。

UNIX および Linux オペレーティング・システム:root アクセス

Windows オペレーティング・システムユーザーのログイン・アカウントは、「オペレーティング・システムの一部として機能」を持つ Windows Administrators グループのメンバーであるか、ドメイン管理者である必要があります。

ワークステーションに Windows ユーザー・アカウント制御 (UAC) を設定するには、インストールを管理者として実行する必要があります。このためには、インストールを実行する前に、次の手順を実行します。

1. プログラムを実行する場合に使用するアイコンを右クリックします。

ウィザードを使用する場合:SETUP.exe

サイレント・インストールまたは twsinst を使用する場合:コマンド・プロンプト

2. 「管理者として実行」を選択します。

さらに、Software Distribution を使用するには、ユーザーは Software Distribution 役割の admin、senior、または super を持つ必要があります。

DB2 のインストール

DB2 について詳しくは、 http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp

で DB2 の文書を参照してください。

DB2 をインストールするには、以下のオプションのいずれかを選択します。


|

|

|

|

|

|

|

|

|

|

|

|

|

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp

v ランチパッドを使用します。 36ページの『Launchpad』を参照してください。

v 製品 DVD 上の DB2 サーバー・インストールを、手動で起動します。 DB2 用のセットアップ・ファイルは、製品 DVD の以下の場所にあります。

表 4. DB2 セットアップ・ファイル

オペレーティング・システムセットアップ・ファイル

AIX®、HP-UX/IA64、SunOS/SPARC、SunOS/

SPARC64、すべての Linux オペレーティング・システム

DB2/server/db2setup

SunOS/AMD64 DB2/wse/db2setup

Windows/x86 および Windows/AMD64 DB2¥SERVER¥setup.exe

インストール・ウィザードの使用

このセクションでは、インストール・ウィザードを使用して Tivoli Workload

Scheduler コンポーネントをインストールする方法を説明します。インストール・ウィザードは、サポートされるすべてのオペレーティング・システム上で実行されます。サポートされているオペレーティング・システムの完全なリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27012175 を参照してください。

注: IBM i は例外です。このプラットフォームでは、twsinst コマンド行のみを使用して動的エージェントをインストールできます。

マスター・ドメイン・マネージャーまたはバックアップ・マスターのインストール

グラフィカル・インストールでは、インストール DVD から、または適切な eImage

から、 36ページの『Launchpad』の説明に従ってランチパッドを始動し、Tivoli

Workload Scheduler のインストールを選択します。または、インストールするオペレーティング・システムのセットアップを実行します。

Windows オペレーティング・システムの場合TWS¥operating_system¥SETUP.exe または TWS¥SETUP.cmd

UNIX および Linux オペレーティング・システムの場合TWS/operating_system/SETUP.bin または TWS/SETUP.sh

注: インストールを開始するときに、RDBMS が実行されている必要があります。

UNIX または Linux にインストールしており、Tivoli Workload Scheduler 前提条件チェックでエラーまたは警告が発生した場合にインストールを停止する場合は、setup コマンドの後にパラメーター -W checkPrerequisites.stopOnCheckPrereq=trueを指定します。前提条件チェックについて詳しくは、 28ページの『前提条件の検査(UNIX および Linux)』を参照してください。

マスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーをインストールするときに、以下のワークステーション・タイプがデータベース内に作成されます。



マスターマスター・ドメイン・マネージャー用

ブローカーブローカー・サーバー用

エージェント動的エージェント用

バックアップ・マスター・ドメイン・マネージャーをインストールする場合は、インストールの実行後に手動で構成を行う必要があります。 192ページの『バックアップ・マスター・ドメイン・マネージャーの構成』を参照してください。

マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインストール・プロセスのインストール・ステップは、以下のセクションで説明されています。

1. 『Tivoli Workload Scheduler インストール・オプション』

2. 75ページの『WebSphere Application Server インストール・オプション』

3. 77ページの『RDBMS インストール・オプション』

このセクションは、以下のサブセクションに分かれています。

v 77ページの『DB2 データベース・サーバー用のインストール』

v 79ページの『DB2 データベース・クライアント用のインストール』

v 82ページの『Oracle データベース用のインストール』

4. 85ページの『Dynamic workload broker 構成情報』

インストールが正常に実行された後に、インストールしたコンポーネントのタイプに応じて、以下の構成タスクのいずれかを実行してください。

v 191ページの『マスター・ドメイン・マネージャーの構成』

v 192ページの『バックアップ・マスター・ドメイン・マネージャーの構成』.

Tivoli Workload Scheduler インストール・オプション:

以下の Tivoli Workload Scheduler データ・フィールドにすべて入力します。

ユーザー名Tivoli Workload Scheduler のユーザー名を指定します。ユーザー名には、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。国別文字を含めることはできません。ユーザー名の先頭文字は文字でなければなりません。

Windows オペレーティング・システムの場合

v このユーザー・アカウントがまだ存在していない場合は、インストール・ウィザードによって自動的に作成されます。

v ドメイン内の Windows サーバー上にインストールする場合、ドメインとローカル ID を同じユーザー名で定義しないでください。

v ドメイン・ユーザーを指定する場合、その名前をdomain_name¥user_name として定義します。


v ローカル・ユーザーを指定する場合、その名前をsystem_name¥user_name として定義します。パスワードを入力し、確認します。

UNIX および Linux オペレーティング・システムの場合インストールを実行する前に、このユーザー・アカウントを手動で作成する必要があります。ホーム・ディレクトリーおよびグループを持つユーザーを作成します。デフォルトで、Tivoli Workload

Scheduler は TWA_home 上にインストールされます

注: Tivoli Workload Automation の新しいインスタンスにインストールする場合、 Tivoli Workload Scheduler のユーザー名およびパスワードがWebSphere Application Server 管理者のユーザー名およびパスワードとしても使用されます。

パスワードTivoli Workload Scheduler パスワードを指定します。パスワードは、ローカル・セキュリティー設定のパスワード・ポリシーに従っていなければなりません。スペースは許されません。

Windows オペレーティング・システムの場合ユーザーのパスワードには、英数字、ダッシュ (-)、および下線 (_)

文字、そして ()!?=^*/~ [] $`+;:.,@ を含めることができます。

UNIX および LINUX システムの場合ユーザーのパスワードには、任意の英数字、ダッシュ (-)、下線 (_)

文字、および ()!?=*~+. を含めることができます。

マスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーの構成情報

会社会社の名前。スペースが許可されており、最大フィールド長は 40

文字です。

このワークステーション名インスタンスをインストールするワークステーションの名前。デフォルトは、ワークステーションのホスト名です。

マスター・ドメイン・マネージャーをインストールするときに、ここで指定する名前は、データベース内で master として認識されるTivoli Workload Scheduler ワークステーションの名前です。

バックアップ・マスター・ドメイン・マネージャーをインストールするときに、ここで指定する名前は、データベース内で fta として認識される Tivoli Workload Scheduler ワークステーションの名前です。スペースは許可されず、最大フィールド長は 16 文字です。ホスト名が 16 文字を超える場合、インストールを正常に行うために、代替名を指定する必要があります。それには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。先頭文字は文字でなければなりません。

マスター・ドメイン・マネージャー名マスター・ドメイン・マネージャー・ワークステーションの名前。バックアップ・マネージャーをインストールする場合は、このフィールドは必須です。バックアップ・マネージャーをインストールし


ない場合は、このフィールドはグレーアウトされます。スペースは許可されず、最大フィールド長は 16 文字です。先頭文字は数字であってはなりません。

Tivoli Workload Scheduler Netman ポート分散スケジューリングを実行するために Netman プロセスが使用するポート。 Netman は、実稼働環境を制御するネットワーク・プロセスです。デフォルト値は 31111 です。有効範囲は、1 から 65535

です。

注: この値を変更すると、アプリケーション・サーバーのポート情報パネルのデフォルトのポート番号値すべてが、新しい範囲に合わせて変更されます。例えば、「TCP/IP ポート番号」に42111 を指定すると、HTTP トランスポートのデフォルトが42125 になり、 HTTPS のデフォルトが 42126 になるなどの変更が行われます。

動的エージェントの構成情報

ホスト名または IP アドレス動的エージェントの完全修飾ホスト名または IP アドレス。Dynamic

Workload Broker および Tivoli Workload Scheduler for z/OS コントローラーは、このアドレスを使用して動的エージェントに接続します。

エージェント表示名動的エージェント・ワークステーション定義の名前。

JobManager ポート番号動的エージェント・セキュア・ポート番号 (SECUREADDR)。Tivoli

Workload Scheduler for z/OS コントローラーおよび Dynamic

Workload Broker はこのポートを使用して Tivoli Workload

Scheduler 動的エージェントと通信します。デフォルト値は 31114です。有効範囲は、1 から 65535 です。

Dynamic workload broker ホスト名バックアップ・マスター・ドメイン・マネージャーのみに適用されます。完全修飾ホスト名 Dynamic Workload Broker。Tivoli

Workload Scheduler for z/OS コントローラーおよび動的エージェントは、このアドレスを使用して Dynamic Workload Broker と通信します。

Dynamic workload broker HTTPS ポート番号バックアップ・マスター・ドメイン・マネージャーのみに適用されます。Dynamic Workload Broker の HTTPS トランスポート・ポート。動的エージェントはこのポートを使用して Dynamic Workload

Broker に接続します。デフォルト値は 31116 ですが、このフィールドをブランクのままにすると、デフォルトの 0 になります。有効範囲は、1 から 65535 です。

「FINAL」ジョブ・ストリームをデータベースに追加して、実動サイクルを自動化しますこのオプションは、マスター・ドメイン・マネージャーをインストールする

場合にのみ使用可能です。 final ジョブ・ストリームをデータベースに追加


します。このオプションを使用すると、現在の実動計画の各処理の終了時に実動計画の自動拡張を可能にします。デフォルトでは、このボックスはチェック・マークを外したままにします。

注: インストールの際に、final ジョブ・ストリームを持つ既存の Tivoli

Workload Scheduler データベースを識別した場合、インストールはそれを上書きしません。

その他のすべての Tivoli Workload Scheduler ポートを自動的に生成するデフォルトでは、このボックスにチェック・マークが付いています。このボックスを選択されたままにすると、WebSphere Application Serverが必要とするすべてのポートが、デフォルト値を使用して自動的に生成され、アプリケーション・サーバーのポート情報パネルは表示されません。インストール手順では、指定されたポート範囲にあるポートが使用可能かどうかチェックされます。1 つ以上のポートをほかのアプリケーションが使用中である場合は、新しいポート番号を入力するように求めるプロンプトが出されます。ポートを自動的に生成するように要求していない場合、Tivoli Workload

Scheduler インスタンスに組み込まれた、アプリケーション・サーバーによって使用されるポートの値を指定します。デフォルト値が他のアプリケーションによって既に使用中であることを知っている場合を除いて、それらのデフォルト値を受け入れます。

インストール・ディレクトリー指定されたユーザー用に Tivoli Workload Scheduler インスタンスがインストールされるディレクトリーの名前を入力します。最大フィールド長は 46

文字で、名前に数字を含めることはできません。括弧 () は許可されません。国別文字を使用することはできません。

スペースを使用できます。ただし、ディレクトリー・パスにスペースが含まれている場合、バージョン 8.2.1 以前の Tivoli Workload Scheduler for

Applications は、現行バージョンの Tivoli Workload Scheduler にはインストールできません。

Windows オペレーティング・システムの場合:

v 名前は長さが 4 文字以上、2 番目の文字が :、3 番目の文字が ¥

でなければなりません。

v デフォルトのディレクトリーは、%ProgramFiles%¥IBM¥TWA です。

UNIX および Linux システムの場合:

v 名前は、長さが 2 文字以上、先頭文字が / でなければなりません。

v デフォルトのディレクトリーは /opt/IBM/TWA ディレクトリーです。

v オプションで、「シンボリック・リンクの作成」にチェック・マークを付けると、/usr/bin ディレクトリーにリンクが作成されます。既存の Tivoli Workload Scheduler シンボリック・リンクは上書きされます。

WebSphere Application Server インストール・オプション:


以下のフィールドは、WebSphere Application Server データ用に提供されています。入力するフィールドは、Tivoli Workload Automation の新しいインスタンスまたは既存のインスタンスのどちらにインストールするかに応じて異なります。インストール手順では、指定されたポート範囲にあるポートが使用可能かどうかチェックされます。1 つ以上のポートをほかのアプリケーションが使用中である場合は、新しいポート番号を入力するように求めるプロンプトが出されます。

新しいインスタンスTivoli Workload Automation の新しいインスタンスにインストールする場合、以下の情報を提供します。

HTTP トランスポートHTTP トランスポート用のポート。これは、このプロトコルが選択されるときに、composer コマンド行インターフェースによって使用されます。デフォルト値は 31115 です。有効範囲は、1 から65535 です。

HTTPS トランスポートセキュア HTTP トランスポート用のポート。これは、このプロトコルが選択されるときに、composer コマンド行インターフェースによって使用されます。デフォルト値は 31116 です。有効範囲は、1

から 65535 です。

ブートストラップブートストラップまたは RMI 用のポート。これは、グラフィカル・ユーザー・インターフェースによって使用されます。デフォルト値は 31117 です。有効範囲は、1 から 65535 です。

SOAP コネクターアプリケーション・サーバー・プロトコル SOAP コネクター用のポート。デフォルト値は 31118 です。有効範囲は、1 から 65535 です。

SAS サーバー認証リスナーSecure Association Services (SAS) がインバウンド認証要求を listen

するために使用するポート。デフォルト値は 31119 です。有効範囲は、1 から 65535 です。

CSIv2 サーバー認証リスナーCommon Secure Interoperability Version 2 (CSIv2) サービスが、インバウンド・サーバー認証要求を listen するためのポート。デフォルト値は 31120 です。有効範囲は、1 から 65535 です。

CSIv2 クライアント認証リスナーCommon Secure Interoperability Version 2 (CSIv2) サービスが、インバウンド・クライアント認証要求を listen するためのポート。デフォルト値は 31121 です。有効範囲は、1 から 65535 です。

ORB リスナーIIOP 通信を介した RMI に使用するポート。デフォルト値は 31122です。有効範囲は、1 から 65535 です。


管理 HTTP トランスポート管理コンソール・ポート。デフォルト値は 31123 です。有効範囲は、1 から 65535 です。

管理 HTTPS トランスポート管理コンソール・セキュア・ポート。デフォルト値は 31124 です。有効範囲は、1 から 65535 です。

イベント処理プログラムイベント管理処理プログラムがイベントを受信するために使用するポート。デフォルト値は 31131 です。有効範囲は、1 から 65535

です。このパラメーターは、バックアップ・マスター・ドメイン・マネージャーをインストールする場合には要求されません。

既存のインスタンスTivoli Workload Automation の既存のインスタンスにインストールする場合、 WebSphere Application Server 管理者のユーザー名およびパスワードを入力することだけが要求されます。ポート・データは、既存の WebSphere

Application Server インスタンスから自動的に取得されます。ユーザー名が不明な場合は、適切なパネルで「検索」をクリックして、このフィールドに値を取り込むことができます。ただし、その場合でもパスワードは入力しなければなりません。「検索」をクリックした場合は、フィールドにデータが取り込まれるまで待つ必要がある可能性があります。

RDBMS インストール・オプション:

このセクションは、複数のサブセクションに分かれています。使用する RDBMS に対応するセクションを参照してください。

v 『DB2 データベース・サーバー用のインストール』



DB2 データベース・サーバー用のインストール:

既存のデータベース用にインストールする場合、 72ページの『Tivoli Workload

Scheduler インストール・オプション』で説明されている手順を実行してください。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。

DB2 検索パス既存の DB2 インスタンスがインストールされているディレクトリーを入力するか、「参照」します。Windows の場合、デフォルトは%ProgramFiles%¥IBM¥sqllib です。複数の DB2 インスタンスがインストールされている場合、必要な DB2 インスタンスの完全修飾パスを指定したことを確認してください。このパスは、db2level.exe ファイルが入っているDB2 構造内のツリーを示している必要があります。

インスタンス名DB2 サーバー・インスタンスの名前。

インスタンス・ポートDB2 インスタンスとの通信に使用する TCP/IP ポート番号。デフォルトは50000 です。


DB2 サーバー管理者ユーザーDB2 サーバー・インスタンスの管理者のユーザー名。このユーザーは、DB2 サーバー上で SYSADM または SYSCTRL 権限を持つ任意のユーザーとすることもできます。UNIX では、このユーザーに切り替えて、DB2 環境を読み込めることを検査します。

DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表を作成していた場合、ユーザー名は DB2 管理者が customizeDB2SQL.properties ファイルの DB_USER プロパティーに指定したものになります。



DB2 サーバー管理者パスワードDB2 サーバー管理者ユーザーのパスワードか、SYSADM または SYSCTRL

権限を持つユーザーのパスワード。パスワードを確認するよう求められます。

データベース名DB2 データベースの名前。最大長は 5 文字です。その名前が 5 文字を超えない場合、既存の DB2 データベース・インスタンスを使用できます。インストールする対象に応じて、以下を実行します。


バックアップ・マスター・ドメイン・マネージャーマスター・ドメイン・マネージャー・データベースの名前を入力します。


バックアップ動的ドメイン・マネージャー動的ドメイン・マネージャー・データベースの名前を入力します。

DB2 データベース名に関する情報については、DB2 の資料を参照してください。

Tivoli Workload Scheduler データベースの拡張構成パラメーターを指定このオプションは、以下の拡張パラメーターを指定したい場合に選択します。

表スペース名DB2 インスタンスの表スペースの名前。この表スペースは、スケジューリング・オブジェクトおよびイベント・ルールの保管に使用されます。DB2 表スペースに関する情報については、DB2 の資料を参照してください。


表スペース・パスDB2 表スペースの相対パス。このパスは、相対パスでも完全修飾パスでもかまいません。表スペース・パスが完全修飾パスの場合、DB2 の管理者ユーザーは、表スペースがインストールされているディレクトリーに対して完全なアクセス権限を持っている必要があります。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。

デフォルトの表スペース・パス名は TWS_DATA です。デフォルトの表スペース一時ディレクトリーは TWS_TEMP です。UNIX および Linux オペレーティング・システムの場合は、DB2 管理者が表スペース・ディレクトリーの上のディレクトリーに対して書き込みアクセス権限を持つようにしてください。

イベント・ログの保管に使用される表スペースTivoli Workload Scheduler イベント・ログを保管する DB2 表スペースの名前とパスを指定します。これらのログには、イベント・ルール・インスタンス、トリガーされるアクション、および Dynamic Workload Console によって表示されるオペレーター・メッセージに関するデータが含まれます。ログのデータを使用して、レポートを作成できます。レポート・データはDynamic Workload Console を使用して表示できます。

レポート・テーブル・スペース名レポート・データを保管する表スペースの名前。デフォルト名はTWS_LOG です。

レポート・テーブル・スペース・パスレポート・データを保管する表スペースのパス。デフォルトのパスは TWS_LOG です。このパスは、相対パスでも完全修飾パスでもかまいません。表スペース・パスが完全修飾パスの場合、DB2 の管理ユーザーは、表スペースがインストールされているディレクトリーに対して完全なアクセス権限を持っている必要があります。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。レポート表スペース・パスは表スペース・パスと同じにできないことに注意してください。

DB2 データベース・クライアント用のインストール:

バックアップ・マスター・ドメイン・マネージャーのインストール時に、Tivoli

Workload Scheduler データベースが含まれている DB2 サーバーに接続する DB2 クライアントをインストールします。このデータベースは、マスター・ドメイン・マネージャーのインストール時に作成されたものです。これが DB2 データベース・サーバーである場合、データベースは、マスター・ドメイン・マネージャーのワークステーション上にあります。これが DB2 データベース・クライアントの場合、データベースは、別のワークステーション上にあります。

バックアップ動的ドメイン・マネージャーのインストール時に、Tivoli Workload

Scheduler データベースが含まれている DB2 サーバーに接続する DB2 クライアントをインストールします。このデータベースは、動的ドメイン・マネージャーのインストール時に作成されたものです。これが DB2 データベース・サーバーである


場合、データベースは、動的ドメイン・マネージャーのワークステーション上にあります。これが DB2 データベース・クライアントの場合、データベースは、別のワークステーション上にあります。

既存のデータベースを使用してインストールする場合、 72ページの『Tivoli

Workload Scheduler インストール・オプション』で説明されている手順を実行してください。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。

DB2 検索パス既存の DB2 インスタンスがインストールされているディレクトリーを入力するか、「参照」します。複数の DB2 インスタンスがインストールされている場合、必要な DB2 インスタンスの完全修飾パスを指定したことを確認してください。このパスは、db2level.exe ファイルが入っている DB2 構造内のツリーを示している必要があります。

リモート・データベース・サーバーDB2 サーバーがインストールされているワークステーションの IP アドレスまたはホスト名。

リモート・データベース・ポートリモートの DB2 サーバー・インスタンスが通信に使用する TCP/IP ポート番号。

DB2 管理タスクのインストールに使用されるリモート DB2 サーバーのユーザーを確認してください

以下のデータを提供します。


DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表を作成していた場合、ユーザー名は DB2 管理者がcustomizeDB2SQL.properties ファイルの DB_USER プロパティーに指定したものになります。



DB2 サーバー管理者パスワードDB2 サーバー管理者ユーザーのパスワードか、SYSADM またはSYSCTRL 権限を持つユーザーのパスワード。パスワードを確認するよう求められます。

DB2 管理タスクのインストールに使用される DB2 クライアントのユーザーを確認してください。

DB2 管理タスク用のインストールによって使用される DB2 クライアント上のユーザーを指定します。以下のデータを提供します。


DB2 クライアント管理者ユーザーDB2 クライアント・インスタンスの DB2 管理者のユーザー名。ユーザー ID には、以下のログイン・プロパティーが含まれている必要があります。

-login=’true’

-rlogin=’true’

DB2 クライアント管理者パスワードDB2 クライアント・インスタンスの DB2 管理者のパスワード。

注: パスワードは、ローカル・セキュリティー設定のパスワード・ポリシーに従っていなければなりません。従っていなければ、インストールは失敗します。

Tivoli Workload Scheduler がデータベースへのアクセスに使用する DB2 サーバーのユーザーを識別します (DB2 サーバー管理ユーザーと異なる場合)。

Tivoli Workload Scheduler にアクセスするために使用されるDB2 サーバー・ユーザーが、DB2 サーバー管理ユーザーと異なる場合、このオプションを選択します。以下のデータを提供します。

Tivoli Workload Scheduler DB2 ユーザーTivoli Workload Scheduler DB2 ユーザーのユーザー名。

Tivoli Workload Scheduler DB2 パスワードTivoli Workload Scheduler DB2 ユーザーのパスワード。

データベース名DB2 データベースの名前。最大長は 5 文字です。その名前が 5 文字を超えない場合、既存の DB2 データベース・インスタンスを使用できます。インストールする対象に応じて、以下を実行します。


バックアップ・マスターマスター・ドメイン・マネージャー・データベースの名前を入力します。


バックアップ動的ドメイン・マネージャー動的ドメイン・マネージャー・データベースの名前を入力します。

DB2 データベース名に関する情報については、DB2 の資料を参照してください。


Tivoli Workload Scheduler データベースの拡張構成パラメーターを指定このオプションは、以下の拡張パラメーターを指定したい場合に選択します。

表スペース名DB2 インスタンスの表スペースの名前。DB2 表スペースに関する情報については、DB2 の資料を参照してください。

表スペース・パスDB2 表スペースの相対パス。このパスは、相対パスでも完全修飾パスでもかまいません。表スペース・パスが完全修飾パスの場合、DB2 の管理者ユーザーは、表スペースがインストールされているディレクトリーに対して完全なアクセス権限を持っている必要があります。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。

デフォルトの表スペース・パス名は TWS_DATA です。デフォルトの表スペース一時ディレクトリーは TWS_TEMP です。UNIX および Linux オペレーティング・システムの場合は、DB2 管理者が表スペース・ディレクトリーの上のディレクトリーに対して書き込みアクセス権限を持つようにしてください。

イベント・ログの保管に使用される表スペースTivoli Workload Scheduler イベント・ログを保管する DB2 表スペースの名前とパスを指定します。これらのログを使用して、レポートを作成できます。レポート・データは Dynamic Workload Console

を使用して表示できます。

レポート・テーブル・スペース名レポート・データを保管する表スペースの名前。デフォルト名は TWS_LOG です。

レポート・テーブル・スペース・パスレポート・データを保管する表スペースのパス。デフォルトのパスは TWS_LOG です。このパスは、相対パスでも完全修飾パスでもかまいません。表スペース・パスが完全修飾パスの場合、DB2 の管理者ユーザーは、表スペースがインストールされているディレクトリーに対して完全なアクセス権限を持っている必要があります。詳しくは、 360ページの『DB2 表スペースの相対パス』を参照してください。

Oracle データベース用のインストール:

サーバーとクライアントの両方の Oracle データベースにインストールする場合は、インストール・ウィザードのプロンプトに従ってください。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。

Oracle データーベース検索パスTivoli Workload Scheduler の前提条件を満たす Oracle のインストール済み環境のパスを指定します。この完全修飾パスは、sqlplus 実行可能ファイルが含まれている Oracle 構造内のツリーを示している必要があります。


ネット・サービス名







データベース管理者に問い合わせて、正しいネット・サービス名を取得してください。

Oracle アドミニストレーター・ユーザーOracle データベースに対する認証に必要なデータベース管理者ユーザー名(SYSTEM など)。このアカウントは既に存在していなければなりません。

ORACLE 管理者が既に 56ページの『Oracle を使用している場合のデータベース表の作成またはアップグレード』を使用してデータベース表を作成していた場合、ユーザー名は ORACLE 管理者がcustomizeORACLESQL.properties ファイルの MDL_USER プロパティーに指定したものになります。

Oracle アドミニストレーター・ユーザー・パスワードOracle データベースに対する認証に必要なデータベース管理者ユーザーのパスワード。

Tivoli Workload Scheduler Oracle ユーザーTivoli Workload Scheduler スキーマの所有者。

ORACLE 管理者が既に 56ページの『Oracle を使用している場合のデータベース表の作成またはアップグレード』を使用してデータベース表を作成していた場合、ユーザー名は ORACLE 管理者がcustomizeORACLESQL.properties ファイルの MDL_USER プロパティーに指定したものになります。この名前は、Oracle の命名規則に従っている必要があります。

インストールする対象に応じて、以下を実行します。


マスター・ドメイン・マネージャーこのフィールドをブランクのままにすると、この名前はデフォルトの <TWS_user> に設定されます。

バックアップ・マスターマスター・ドメイン・マネージャーで使用したものと同じ名前を入力します。

動的ドメイン・マネージャーこのフィールドをブランクのままにすると、この名前はデフォルトの <TWS_user> に設定されます。マスター・ドメイン・マネージャーをインストールするときに使用したものと違う名前を入力します。

バックアップ動的ドメイン・マネージャー動的ドメイン・マネージャーで使用したものと同じ名前を入力します。

フレッシュ・インストールの場合:

マスター・ドメイン・マネージャーこのユーザーはデータベース内に存在しません。ユーザーが存在する場合、このユーザー名と同じデータベースを指すマスター・ドメイン・マネージャーまたはバックアップ・マスター・インスタンスが既に存在することを意味します。既に存在する Tivoli Workload

Scheduler インスタンスがバージョン 8.3 以降である場合、インストール・プロセスにより、現在のデータベース・スキーマが新しいスキーマにアップグレードされます。

動的ドメイン・マネージャーこのユーザーはデータベース内に存在しません。これに該当しない場合、このユーザー名と同じデータベースを指す動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーが既に存在することを意味します。既に存在する Tivoli Workload

Scheduler インスタンスがバージョン 8.3 以降である場合、インストール・プロセスにより、現在のデータベース・スキーマが新しいスキーマにアップグレードされます。

既に存在するインスタンスが現行のバージョンである場合は、インストール・プロセスにより、スキーマが正しいレベルにあると見なされて、Tivoli

Workload Scheduler 用のデータベース・オブジェクト (表、ビュー、クラスター、プロシージャー、索引など) は作成されません。

既存の Oracle ユーザーを Tivoli Workload Scheduler Oracle ユーザーとして識別する場合、インストール・プロセスは構成が完了していると見なし、Tivoli Workload Scheduler のデータベース・オブジェクトを作成しません。この場合、インストールは正常に完了しますが、データベースを使用することはできません。

Tivoli Workload Scheduler Oracle ユーザー・パスワードTivoli Workload Scheduler Oracle ユーザーのパスワード。これは、Oracle

の命名規則に従っている必要があります。


Oracle Partitioning オプションを使用した Tivoli Workload Scheduler スキーマの作成 Oracle Enterprise Edition にインストールする場合、Oracle Partitioning オプ

ションのインプリメントを選択して、イベント・ドリブン・ワークロード自動化のパフォーマンスを改善できます。イベント・ドリブン・ワークロード自動化については、「概要」を参照してください。

Tivoli Workload Scheduler データ・テーブル・スペースTivoli Workload Scheduler データ・テーブル・スペースを識別する名前。この表スペースは、以前にデータベース管理者によって作成済みでなければなりません。このフィールドのデフォルトは USERS です。

Tivoli Workload Scheduler レポート・テーブル・スペースレポート・データを保管する Tivoli Workload Scheduler の表スペースを示す名前。レポート・データは Dynamic Workload Console を使用して表示できます。

この表スペースは、以前にデータベース管理者によって作成済みでなければなりません。このフィールドのデフォルト値は USERS です。

Tivoli Workload Scheduler 一時テーブル・スペースTivoli Workload Scheduler 一時テーブル・スペースを識別する名前。この表スペースは、以前にデータベース管理者によって作成済みでなければなりません。このフィールドのデフォルト値は TEMP です。

Dynamic workload broker 構成情報:

マスター・ドメイン・マネージャーのインストールのみに適用されます。

Dynamic workload broker ワークステーション名Tivoli Workload Scheduler データベースに作成された Dynamic Workload

Broker ワークステーションの定義。このタイプは broker です。スペースは許可されず、最大フィールド長は 16 文字です。それには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。先頭文字は文字でなければなりません。

Dynamic workload broker Netman ポートワークロード・ブローカー・ワークステーション上のポート。Tivoli

Workload Scheduler マスターまたはバックアップ・マスターはこのポートを使用して Dynamic Workload Broker と通信します。デフォルト値は 41114です。有効範囲は、1 から 65535 です。

動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストール

分散環境とエンドツーエンド環境の両方で静的および動的ワークロードをスケジュールおよびコントロールする場合は、このコンポーネントをインストールします。例えば、さまざまな支店があり、動的スケジュールを各支店で独立して実行して、エージェントのスケーラビリティーを向上させる必要がある場合が該当します。さらに、これらのコンポーネントをインストールすると、マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーが使用できない場合でも、動的スケジュールを実行します。


動的ドメイン・マネージャーをインストールすることによって、以下を実行できます。

v フォールト・トレラント・エージェントおよび動的エージェントのスケーラビリティーが向上します。これは、ドメイン内のエージェントのワークロードが、それらが直接接続されている動的ドメイン・マネージャーによって直接制御されるためです。

v マスター・ドメイン・マネージャーへのエージェント接続が使用できない場合でも、静的処理および動的処理を続行できます。

動的ドメイン・マネージャーへの接続が使用できない場合でもワークロードが実行されるようにする場合は、バックアップ動的ドメイン・マネージャーをインストールします。

動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーは以下のもので構成されています。v フォールト・トレラント・エージェントv ブローカー・サーバーv 動的エージェントv 計画コネクター

動的ドメイン・マネージャーをインストールすると、以下のワークステーション・タイプがデータベース内に作成されます。

ブローカーブローカー・サーバー用

エージェント動的エージェント用

マネージャーフォールト・トレラント・エージェント用

ドメインドメイン用。このドメインは、マスター・ドメイン・マネージャー・ドメインの子です。

これらのワークステーションは、デフォルトのマスター・ドメイン・マネージャー・ドメインの下に作成されます。必要に応じて、インストール後に変更することも可能です。

インストールの実行後に、フォールト・トレラント・エージェントを手動で構成する必要があります。

動的ドメイン・マネージャーをインストールする場合:それを manager として構成します。 195ページの『動的ドメイン・マネージャーの構成』を参照してください。

バックアップ動的ドメイン・マネージャーをインストールする場合:それを fta として構成します。 195ページの『バックアップ・動的ドメイン・マネージャーの構成』を参照してください。




Workload Scheduler のインストールを選択します。または、インストールするオペレーティング・システムのセットアップを実行します。



注: インストールを開始するときに、RDBMS が実行されている必要があります。


動的ドメイン・マネージャーのインストール・ステップ、またはバックアップ動的ドメイン・マネージャーのインストール・プロセスは、以下のセクションで説明されています。

1. 『Tivoli Workload Scheduler インストール・オプション』

2. 75ページの『WebSphere Application Server インストール・オプション』

3. 77ページの『RDBMS インストール・オプション』

このセクションは、以下のサブセクションに分かれています。




4. 92ページの『Dynamic workload broker 構成情報』

インストールが正常に実行された後に、インストールしたコンポーネントのタイプに応じて、以下の構成タスクのいずれかを実行してください。

v 195ページの『動的ドメイン・マネージャーの構成』

v 195ページの『バックアップ・動的ドメイン・マネージャーの構成』.

Tivoli Workload Scheduler インストール・オプション:

以下の Tivoli Workload Scheduler インストール・オプションに入力します。

ユーザー名Tivoli Workload Scheduler のユーザー名を指定します。ユーザー名には、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。国別文字を含めることはできません。ユーザー名の先頭文字は文字でなければなりません。

Windows オペレーティング・システムの場合このユーザー・アカウントがまだ存在していない場合は、インストール・ウィザードによって自動的に作成されます。ドメイン内のWindows サーバー上にインストールする場合、ドメインとローカルID を同じユーザー名で定義しないでください。ドメイン・ユーザーを指定する場合、その名前を domain_name¥user_name として定義し


ます。ローカル・ユーザーを指定する場合、その名前をsystem_name¥user_name として定義します。パスワードを入力し、確認します。

UNIX および Linux オペレーティング・システムの場合インストールを実行する前に、このユーザー・アカウントを手動で作成する必要があります。ホーム・ディレクトリーおよびグループを持つユーザーを作成します。デフォルトで、Tivoli Workload

Scheduler は TWA_home 上にインストールされます。

注: Tivoli Workload Automation の新しいインスタンスにインストールする場合、 Tivoli Workload Scheduler のユーザー名およびパスワードがWebSphere Application Server 管理者のユーザー名およびパスワードとしても使用されます。




その他のプラットフォームの場合ユーザーのパスワードには、任意の英数字、ダッシュ (-)、下線 (_)


動的ドメイン・マネージャーおよびバックアップ動的ドメイン・マネージャーの構成情報

ドメイン名動的ドメイン・マネージャーのみに適用されます。動的ドメイン・マネージャーによって管理される Tivoli Workload Scheduler ドメイン名を指定します。デフォルト値は DYNAMICDM です。

このワークステーション名インスタンスをインストールするワークステーションの名前。デフォルトは、ワークステーションのホスト名です。インストールする対象に応じて、以下を実行します。

v 動的ドメイン・マネージャーをインストールするときに、ここで指定する名前は、データベース内で fta として認識される Tivoli

Workload Scheduler ワークステーションの名前です。 195ページの『動的ドメイン・マネージャーの構成』で説明されている手順を実行して、それを manager として構成します。

v バックアップ動的ドメイン・マネージャーをインストールするときに、ここで指定する名前は、データベース内で fta として認識される Tivoli Workload Scheduler ワークステーションの名前です。 195ページの『バックアップ・動的ドメイン・マネージャーの構成』で説明されている手順を実行して、それを fta として構成します。


スペースは許可されず、最大フィールド長は 16 文字です。ホスト名が 16 文字を超える場合、インストールを正常に行うために、代替名を指定する必要があります。それには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。先頭文字は文字でなければなりません。ワークステーション名とマスター・ドメイン・マネージャー名を同じにすることはできません。

マスター・ドメイン・マネージャー名マスター・ドメイン・マネージャー・ワークステーションの名前。スペースは許可されず、最大フィールド長は 16 文字です。先頭文字は数字であってはなりません。ワークステーション名とマスター・ドメイン・マネージャー名を同じにすることはできません。

接続先が Tivoli Workload Scheduler for z/OS コントローラーだけになる動的ドメイン・マネージャーをインストールする場合は、このフィールドで指定しなければならない値が、実際には使用されません。z/OS の軽量エンドツーエンド構成では、フォールト・トレラント・エージェントは必要ないからです。

Tivoli Workload Scheduler Netman ポート分散スケジューリングを実行するために Netman プロセスが使用するポート。 Netman は、実稼働環境を制御するネットワーク・プロセスです。デフォルト値は 31111 です。有効範囲は、1 から 65535

です。

接続先が Tivoli Workload Scheduler for z/OS コントローラーだけになる動的ドメイン・マネージャーをインストールする場合は、このフィールドで指定しなければならない値が、実際には使用されません。z/OS の軽量エンドツーエンド構成では、フォールト・トレラント・エージェントは必要ないからです。

注: この値を変更すると、アプリケーション・サーバーのポート情報パネルのデフォルトのポート番号値すべてが、新しい範囲に合わせて変更されます。例えば、「TCP/IP ポート番号」に42111 を指定すると、HTTP トランスポートのデフォルトが42125 になり、 HTTPS のデフォルトが 42126 になるなどの変更が行われます。


ホスト名または IP アドレス動的エージェントのローカル完全修飾ホストまたは IP アドレス。Dynamic Workload Broker および Tivoli Workload Scheduler for

z/OS コントローラーは、このアドレスを使用して動的エージェントに接続します。

エージェント表示名動的エージェント・ワークステーション定義の名前。

JobManager ポート番号動的エージェント・セキュア・ポート番号 (SECUREADDR)。Tivoli

Workload Scheduler for z/OS コントローラーおよびDynamic

Workload Brokerは、このポートを使用して Tivoli Workload


Scheduler 動的エージェントに接続します。デフォルト値は 31114です。有効範囲は、1 から 65535 です。

JobManager ポートで HTTPS 通信を有効にするこのオプションによって、ローカルの動的ワークロード・ブローカーと動的エージェントの間の HTTPS 通信が可能になります。セキュア接続にするには、HTTPS を使用することをお勧めします。HTTP 通信を使用するには、このチェック・ボックスをクリアします。

Dynamic workload broker ホスト名バックアップ動的ドメイン・マネージャーのみに適用されます。Dynamic Workload Broker の完全修飾ホスト名。Tivoli Workload

Scheduler for z/OS コントローラーおよび動的エージェントは、このアドレスを使用してDynamic Workload Brokerと通信します。

Dynamic Workload Broker の HTTPS ポート番号バックアップ動的ドメイン・マネージャーのみに適用されます。Dynamic Workload Broker の HTTPS ポート。動的ドメイン・マネージャーのインストール時にこれを指定しました。動的エージェントが Dynamic Workload Broker に接続するときにこれを使用します。デフォルト値は 31116 です。このフィールドをブランクのままにすると、デフォルトの 0 になります。有効範囲は、1 から 65535

です。

その他のすべての Tivoli Workload Scheduler ポートを自動的に生成するこのボックスにチェック・マークを付けると、WebSphere Application Server

が必要とするすべてのポートが、デフォルト値を使用して自動的に生成され、アプリケーション・サーバーのポート情報パネルは表示されません。インストール手順では、指定されたポート範囲にあるポートが使用可能かどうかチェックされます。1 つ以上のポートをほかのアプリケーションが使用中である場合は、新しいポート番号を入力するように求めるプロンプトが出されます。デフォルトでは、このボックスにチェック・マークが付いています。ポートを自動的に生成するように要求していない場合、Tivoli Workload

Scheduler インスタンスに組み込まれた、アプリケーション・サーバーによって使用されるポートの値を指定します。デフォルト値が他のアプリケーションによって既に使用中であることを知っている場合を除いて、それらのデフォルト値を受け入れます。

インストール・ディレクトリー指定されたユーザーに対して動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャー・インスタンスがインストールされているディレクトリーの名前を入力します。最大フィールド長は 46 文字で、名前に数字を含めることはできません。括弧 () は許可されません。国別文字を使用することはできません。

スペースを使用できます。ただし、ディレクトリー・パスにスペースが含まれている場合、バージョン 8.2.1 以前の Tivoli Workload Scheduler for







UNIX および Linux オペレーティング・システムの場合




WebSphere Application Server インストール・オプション:

以下のインストール・オプションは、WebSphere Application Server データ用に提供されています。入力するインストール・オプションは、Tivoli Workload Automation

の新しいインスタンスまたは既存のインスタンスのどちらにインストールするかに応じて異なります。

インストール手順では、指定されたポート範囲にあるポートが使用可能かどうかチェックされます。1 つ以上のポートをほかのアプリケーションが使用中である場合は、新しいポート番号を入力するように求めるプロンプトが出されます。

新しいインスタンスTivoli Workload Automation の新しいインスタンスにインストールする場合、以下の情報を提供します。

HTTP トランスポートHTTP トランスポート用のポート。これは、このプロトコルが選択されるときに、composer コマンド行インターフェースによって使用されます。デフォルト値は 31115 です。有効範囲は、1 から 65535

です。

HTTPS トランスポートセキュア HTTP トランスポート用のポート。これは、このプロトコルが選択されるときに、composer コマンド行インターフェースによって使用されます。デフォルト値は 31116 です。有効範囲は、1 から 65535 です。

ブートストラップブートストラップまたは RMI 用のポート。これは、グラフィカル・ユーザー・インターフェースによって使用されます。デフォルト値は 31117 です。有効範囲は、1 から 65535 です。



SAS サーバー認証リスナーSecure Association Services (SAS) がインバウンド認証要求を listen

するために使用するポート。デフォルト値は 31119 です。有効範囲は、1 から 65535 です。

CSIv2 サーバー認証リスナーCommon Secure Interoperability Version 2 (CSIv2) サービスが、インバウンド・サーバー認証要求を listen するためのポート。デフォルト値は 31120 です。有効範囲は、1 から 65535 です。


ORB リスナーIIOP 通信を介した RMI に使用するポート。デフォルト値は 31122です。有効範囲は、1 から 65535 です。

管理 HTTP トランスポート管理コンソール・ポート。デフォルト値は 31123 です。有効範囲は、1 から 65535 です。


既存のインスタンスTivoli Workload Automation の既存のインスタンスにインストールする場合、 WebSphere Application Server 管理者のユーザー名およびパスワードを入力することだけが要求されます。ポート・データは、既存の WebSphere

Application Server インスタンスから自動的に取得されます。ユーザー名が不明な場合は、適切なパネルで「検索」をクリックして、このフィールドにデータを取り込みます。ただし、その場合でもパスワードは入力しなければなりません。「検索」をクリックした場合は、フィールドにデータが取り込まれるまで待つ必要がある可能性があります。

RDBMS のステップ:

このセクションは、複数のサブセクションに分かれています。使用する RDBMS に対応するセクションを参照してください。




注: データベース名を入力するときは、必ずマスター・ドメイン・マネージャーによって使用されていないデータベースの名前を入力します。

Dynamic workload broker 構成情報:

動的ドメイン・マネージャーのインストールのみに適用されます。



Broker ワークステーションの定義。スペースは許可されず、最大フィールド長は 16 文字です。それには、英数字、ダッシュ (-)、および下線 (_) 文字を含めることができます。先頭文字は文字でなければなりません。

Dynamic Workload Broker ワークステーションは、マスター・ドメイン・マネージャーと Dynamic Workload Broker コンポーネント間における通信ブリッジとしての役割を果たします。ジョブまたはジョブ・ストリーム定義において、ジョブが実行されるワークステーションです。このように、このワークステーションを介して Dynamic Workload Broker コンポーネントに対してワークロードを送信します。

Dynamic workload broker Netman ポートTivoli Workload Scheduler 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーによって Dynamic Workload Broker と通信するために使用される Workload Broker ワークステーション上のポート。デフォルト値は 41114 です。有効範囲は、1 から 65535 です。

動的ドメイン・マネージャーの接続先を z/OS コントローラーのみにする動的ドメイン・マネージャーの接続先を z/OS コントローラーだけにする場合は、このチェック・ボックスを選択します。動的ドメイン・マネージャーを以下の項目に接続する場合は、このチェック・ボックスをクリアしたままにしておきます。

v マスター・ドメイン・マネージャー

v マスター・ドメイン・マネージャーと z/OS コントローラーの両方

動的ドメイン・マネージャーの接続先を z/OS コントローラーだけにするのは、分散システムの Tivoli Workload Scheduler for z/OS からワークロードを制御したり、ワークロードのスケジュールを設定したりする軽量のエンドツーエンド・スケジューリング環境を作成する場合です。この環境を作成するには、Tivoli Workload Scheduler for z/OS エージェントをインストールする必要があります。Tivoli Workload Scheduler for z/OS エージェントをインストールする方法について詳しくは、「Tivoli Workload Scheduler for z/OS:

計画およびインストール」を参照してください。このチェック・ボックスを選択すると、「マスター・ドメイン・マネージャーのホスト名」フィールドと「マスター・ドメイン・マネージャーの HTTPS ポート」フィールドは無効になります。

マスター・ドメイン・マネージャーのホスト名動的ドメイン・マネージャーがマスター・ドメイン・マネージャーと通信するときに使用される完全修飾ホスト名。

マスター・ドメイン・マネージャーの HTTPS ポートセキュア HTTP トランスポート用のポート。動的ドメイン・マネージャーがマスター・ドメイン・マネージャーと通信するときに使用します。デフォルト値は 31116 です。有効範囲は、1 から 65535 です。

エージェントのインストール

このセクションでは、Tivoli Workload Scheduler フォールト・トレラント・エージェントおよび動的エージェントを分散ネットワークまたはエンドツーエンド・ネッ


トワークにインストールする方法を説明します。動的エージェントのインストールの際に、Java ランタイム環境を追加して、拡張オプション付きジョブ・タイプ (製品と共に提供されているジョブ・タイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行できます。Tivoli Workload Scheduler for z/OS コネクターをインストールするには、「Tivoli Workload Scheduler for z/OS: 計画およびインストール」を参照してください。

注: IBM i® は例外です。このプラットフォームでは、twsinst コマンド行のみを使用して動的エージェントをインストールできます。

DVD または eImage からインストールするには、以下のように、インストールを行うオペレーティング・システムのセットアップを実行します。

Windows オペレーティング・システムの場合:TWS¥operating_system¥SETUP.exe または TWS¥SETUP.cmd

UNIX および Linux オペレーティング・システムの場合:TWS/operating_system/SETUP.bin または TWS/SETUP.sh

注: SETUP.sh は、イメージ全体を一時ディレクトリーにコピーします。使用可能なスペースが十分にあることを確認します。




Workload Scheduler のインストールを選択します。

Windows オペレーティング・システム

v ローカル・ユーザーをインストールするには、コンピューター管理者でなければなりません。

v ドメイン・ユーザーに対してインストールするには、ドメイン管理者でなければなりません。

UNIX または Linux オペレーティング・システムUNIX または Linux にインストールするには、root としてログインする必要があります。

Tivoli Workload Scheduler のフルインストールの際に、またはエージェントのみのスタンドアロン・インストールで、エージェントをインストールできます。オプションで、フォールト・トレラント・エージェント、動的エージェント、および Java

ランタイム環境を同時にインストールできます。

フォールト・トレラント・エージェントのインストールフォールト・トレラント・エージェントのみをインストールするには、インストール・ウィザードの際に、インストールするコンポーネントとしてエージェントを選択し、エージェントのタイプとしてフォールト・トレラントを選択します。動的エージェントを同時にインストールしない場合は、必ずそ


のタイプのエージェントを選択解除します。インストールの実行後、手動でそれを構成します。 196ページの『フォールト・トレラント・エージェントの構成』を参照してください。

動的エージェントのインストールおよび Java ランタイムの追加動的エージェントのみをインストールするには、インストール・ウィザードの際に、インストールするコンポーネントとしてエージェントを選択します。動的エージェントに対するチェック・ボックスはデフォルトで既に選択されています。拡張オプション付きジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方)

を実行するためにランタイム環境をインストールする場合は、Java ランタイムを選択します。インストールの実行後に、 197ページの『動的エージェントの構成』で概要が説明されているステップを実行します。

フォールト・トレラント・エージェントと動的エージェントの両方を同時にインストールフォールト・トレラント・エージェントと動的エージェントの両方をインス

トールするには、インストール・ウィザードの際に、インストールするコンポーネントとしてエージェントを選択してから、フォールト・トレラント・エージェントと動的エージェントの両方を選択します (動的エージェントに対するチェック・ボックスはデフォルトで既に選択されています)。拡張オプション付きジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行するためにランタイム環境をインストールする場合は、Java ランタイムを選択します。197ページの『動的エージェントの構成』および 196ページの『フォールト・トレラント・エージェントの構成』で概要が説明されているステップを実行します。

インストール・パラメーターとオプションの説明については、『インストール・オプション』を参照してください。

インストール・オプション:

このセクションでは、インストール構成パラメーターおよびオプションについて説明します。

ユーザー名Tivoli Workload Scheduler ユーザー名を指定します。スペースは許されません。


v このユーザー・アカウントがまだ存在していない場合は、インストール・ウィザードによって自動的に作成されます。

v ドメイン・ユーザーを指定する場合、その名前をdomain_name¥user_name として指定します。

v ドメイン・コントローラーでインストールを行う場合、ユーザー名は常に domain_name¥user_name でなければなりません。

v ドメイン・ユーザーと同じ名前をローカル・ユーザー名に指定する場合、まず管理者が手動でこのローカル・ユーザーを作成し、次に system_name¥user_name として指定する必要があります。


UNIX および Linux オペレーティング・システムの場合インストールを実行する前に、このユーザー・アカウントを手動で作成する必要があります。ホーム・ディレクトリーを持つユーザーを作成します。デフォルトでは、Tivoli Workload Scheduler は選択したユーザーの HOME ディレクトリーの下にインストールされます。

注: Dynamic Workload Console が既にインストールされた Tivoli Workload

Automation のインスタンスにエージェントをインストールする場合に、後からそのエージェントにコネクター・フィーチャーを追加する予定であれば、 Dynamic Workload Console をインストールしたときにWebSphere Application Server 管理ユーザーとして使用したものと同じユーザーをエージェントの TWS_user として使用するように強くお勧めします。これらの名前が同じ場合は、WebSphere Application Server 管理が単純化されます (WebSphere Application Server を使用する Tivoli

Workload Scheduler コンポーネントを Dynamic Workload Console よりも前にインストールする場合は、これがデフォルトの状態です)。




その他のプラットフォームの場合ユーザーのパスワードには、任意の英数字、ダッシュ (-)、下線 (_)


フォールト・トレラント・エージェントの構成情報

会社会社の名前。スペースが許可されており、最大フィールド長は 40

文字です。

このワークステーション名インスタンスをインストールするワークステーションの名前。デフォルトは、ワークステーションのホスト名です。ここで指定する名前は、データベース内で認識される Tivoli Workload Scheduler ワークステーションの名前です。名前の先頭文字は英字でなければなりません。名前には英数字、ダッシュ、および下線を使用できます。名前には 16 文字まで含めることができます。ホスト名が 16 文字を超える場合、代替名を指定する必要があります。

マスター・ドメイン・マネージャー名ワークステーションが所属するマスター・ドメイン・マネージャーの名前。

Tivoli Workload Scheduler Netman ポートマスターからの通信を listen するために Netman プロセスが使用するポート。デフォルト値は 31111 です。有効範囲は、1 から 65535

です。



ホスト名または IP アドレス動的エージェントの完全修飾ホスト名または IP アドレス。Dynamic

Workload Broker は、このアドレスを使用して動的エージェントに接続します。

エージェント表示名動的エージェント・ワークステーション定義の名前

JobManager ポート番号動的エージェントの動的エージェント・ポート (SECUREADDR または TCPADDR)。Dynamic workload broker はこのポートを使用して Dynamic Workload Broker に接続します。これは、JobManager

によって、ダイナミック・ワークロードの実行、および分散環境でz/OS 環境から来るワークロードの実行に使用されます。JobManager

は、動的スケジューリング環境および z-セントリック環境を制御するネットワーク・プロセスです。インストール・デフォルト値は31114 です。有効範囲は、1 から 65535 です。

JobManager ポートで HTTPS 通信を有効にするこのオプションを使用すると、Tivoli Workload Scheduler マスター・ドメイン・マネージャーまたは Tivoli Workload Scheduler for

z/OS Controller とエージェントの間での HTTPS 通信が有効になります。このデフォルトを受け入れる場合、z/OS コントローラーのHTTPS 通信も必ず構成します。セキュア接続にするには、HTTPS

を使用することをお勧めします。HTTP 通信を使用するには、このチェック・ボックスをクリアします。ただし、Tivoli Workload

Scheduler for z/OS Controller とエージェントの間の通信のパフォーマンスを向上させるには、HTTP を使用するように選択します。

Dynamic workload broker ホスト名Dynamic Workload Broker の完全修飾ホスト名。Tivoli Workload

Scheduler 動的エージェントは、これを使用して Dynamic Workload

Broker に接続します。

Dynamic workload broker HTTPS ポート番号Dynamic Workload Broker の HTTPS トランスポート・ポート。マスターまたはバックアップ・マスターのインストール時にこれを指定しました。動的エージェントはこのポートを使用して Dynamic

Workload Broker に接続します。インストール・デフォルト値は31116 ですが、フィールドをブランクのままにすると、デフォルトの 0 になります。有効な範囲は 1 から 65535 です。

インストール・ディレクトリーTivoli Workload Scheduler インスタンスが、指定されたユーザー用にインストールされるディレクトリーの名前を入力します。最大フィールド長は 46

文字で、名前に数字、括弧 ()、または国別文字を含めることはできません。

スペースは許可されますが、ディレクトリー・パスにスペースが含まれている場合、バージョン 8.2.1 以前の Tivoli Workload Scheduler for







UNIX および Linux システムの場合




コマンド行クライアントのインストール

コマンド行クライアントは、マスター・ドメイン・マネージャー上で使用される多数のコマンドをインプリメントする Tivoli Workload Scheduler のコンポーネントです。コマンド行クライアントは、ほかの Tivoli Workload Scheduler コンポーネントがインストールされていないワークステーションを含め、前提条件を満たしている任意のワークステーション上にインストールすることができます。マスター・ドメイン・マネージャーの一部であるコマンド行サーバーと TCP/IP を使用して通信する。インストール・ウィザードを使用するか、サイレント・モードで、コマンド行クライアントをインストールします。他の Tivoli Workload Scheduler コンポーネントをインストールした際に使用したのと同じパスで、コマンド行クライアントをインストールしないでください。

マスター・ドメイン・マネージャーと接続するために必要な情報を、ローカル・オプション・ファイル内で定義するか、パラメーターとしてコマンドに指定する必要があります。

使用できるコマンドを以下に示します。

v Composer

v Optman

v Planman showinfo および unlock (その他の planman コマンドは、マスター・ドメイン・マネージャー上でローカルに実行する必要があります。)

v sendevent

注: コマンド行クライアントは、ローカル Symphony™ ファイルおよびローカル・ジョブの管理のために、エージェント上でローカルに conman を使用する機能とは異なり、この機能から独立して動作します。マスターとの接続を構成することにより、ローカルの conman はデータベースから計画にオブジェクトをサブミットできます。

インストール・ウィザードの実行:

コマンド行クライアントを既存のインストール済み環境にインストールするには、以下の手順を実行してください。


1. グラフィカル・インストールでは、インストール DVD から、または適切なeImage から、 36ページの『Launchpad』の説明に従ってランチパッドを始動し、Tivoli Workload Scheduler のインストールを選択します。または、インストールするオペレーティング・システムのセットアップを実行します。

DVD の TWS ディレクトリーから、以下を実行します。

v Windows の場合: WINDOWS¥SETUP.exe または SETUP.cmd

v UNIX および Linux の場合: SETUP.sh または operating_system/SETUP.bin


2. インストール・ウィザード画面に従ってインストールを完了します。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。

リモート・ホストTivoli Workload Scheduler エンジンがインストールされているワークステーションの TCP/IP アドレスまたはホスト名。

リモート・ポートマスター・ドメイン・マネージャーがインストールされているワークステーションへの接続に使用される HTTP または HTTPS ポート番号。このポート番号は、マスター・ドメイン・マネージャーに定義された値と一致している必要があります。

注: マスターとの接続を確立するためにコマンド行クライアントが使用するデフォルト・プロトコルは、HTTPS です。 HTTP ポートが「リモート・ポート」フィールドに指定される場合、コマンドを実行する前に、https の代わりに http を挿入することにより、localopts ファイルの PROTOCOL プロパティーを変更する必要があります。

ユーザー名マスター・ドメイン・マネージャーがインストールされているワークステーションへの接続に使用されるユーザー名。このユーザーは、マスター・ドメイン・マネージャー上のセキュリティー・ファイルにリストされている有効なユーザーである必要があります。

パスワードマスター・ドメイン・マネージャーがインストールされているワークステーションへの接続に使用されるパスワード。

機能の追加

製品のコンポーネントの一部に対して、機能を追加できます。

エージェントへのコネクターの追加エージェントまたはドメイン・マネージャー・ワークステーション上で使用可能な計画にアクセスする場合は、それと Dynamic Workload Console の間の通信を可能にするコネクター機能を追加します。 199ページの『コネクターの追加』を参照してください。


コマンド行クライアントへの言語パックの追加英語以外のサポートされている言語、またはコンピューターをインストールしたロケールの言語以外の言語でコマンド行クライアントを使用する場合は、言語パックを追加します。 200ページの『コマンド行クライアントへの言語パックの追加』を参照してください。

エージェントへの Java ランタイムの追加エージェントのインストールの際に、拡張オプション付きジョブ・タイプの実行をサポートする Java ランタイムを追加しないように選択した可能性があります。後からこの機能が必要であると判断する場合は、個別に Java ランタイムだけを追加できます。 121ページの『Java ランタイムの追加』を参照してください。

環境をセットアップ済みで、動的スケジューリング機能を有効にする場合は、 201

ページの『インストール後の動的スケジューリングの使用可能化』を参照してください。

サイレント・インストールの実行

サイレント・インストールは、応答ファイルに設定されたパラメーターに従って実行されます。応答ファイルには、ユーザー介入なしでインストールを実行するために必要なすべてのインストール情報が含まれています。

インストール要件を満たすように応答ファイルをカスタマイズするには、次の 2 つの方法があります。

v インストール DVD で提供される既存の応答ファイル・テンプレートを編集します。 105ページの『応答ファイル・テンプレートを使用するサイレント・インストール』を参照してください。

v インストール・ウィザードを実行してカスタマイズされた応答ファイルを自動的に作成します。 105ページの『自動的に生成された応答ファイルを使用するサイレント・インストール』を参照してください。

表 5 は、応答ファイルおよびそれぞれが実行するインストールのタイプをプラットフォームごとにリストしています。

表 5. 応答ファイル

インストールのタイプ使用する応答ファイル

UNIX 上でのインストール

コマンド行クライアントと言語パック

TWS86_CLI_LP_UNIX.txt

コマンド行クライアント (言語パックはインストールされない)

TWS86_CLI_UNIX.txt

既存の Tivoli Workload Automation

インスタンス上にあるフレッシュ・フォールト・トレラント・エージェント、またはフォールト・トレラント・エージェントと動的エージェントの両方

TWS86_FRESH_Agent_existTWA_UNIX.txt


表 5. 応答ファイル (続き)


新しい Tivoli Workload Automation


TWS86_FRESH_Agent_newTWA_UNIX.txt


インスタンス上のフレッシュ・バックアップ動的ドメイン・マネージャー

TWS86_FRESH_BACKUP_DDM_existTWA_UNIX.txt



TWS86_FRESH_BACKUP_DDM_newTWA_UNIX.txt


インスタンス上のフレッシュ・バックアップ・マスター・ドメイン・マネージャー

TWS86_FRESH_BACKUP_MDM_existTWA_UNIX.txt



TWS86_FRESH_BACKUP_MDM_newTWA_UNIX.txt

Dynamic Workload Console がインストールされていないフレッシュ・コネクター

TWS86_FRESH_Conn_NEITHER_TDWC_NOR_ZCONN_UNIX.txt

Dynamic Workload Console 上のフレッシュ・コネクター

TWS86_FRESH_Conn_ON_TDWC_OR_ZCONN_UNIX.txt

フレッシュ動的エージェント TWS86_FRESH_DYNAMIC_Agent_UNIX.txt

Tivoli Workload Scheduler for z/OS

の軽量エンドツーエンド・スケジューリング環境のための既存の Tivoli

Workload Automation インスタンス上のフレッシュ動的ドメイン・マネージャー

TWS86_FRESH_DDM_for_ZOS_existTWA_UNIX.txt


インスタンス上のフレッシュ動的ドメイン・マネージャー

TWS86_FRESH_DDM_existTWA_UNIX.txt

フレッシュ動的エージェント TWS86_FRESH_DYNAMIC_Agent_UNIX.txt


の軽量エンドツーエンド・スケジューリング環境のための新しい Tivoli


TWS86_FRESH_DDM_for_ZOS_newTWA_UNIX.txt






TWS86_FRESH_DDM_newTWA_UNIX.txt


インスタンス上のフレッシュ・マスター・ドメイン・マネージャー

TWS86_FRESH_MDM_existTWA_UNIX.txt



TWS86_FRESH_MDM_newTWA_UNIX.txt

エージェントのアンインストール TWS86_UNINSTALL_Agent.txt

エージェントのアップグレード TWS86_UPGRADE_Agent_UNIX.txt

バックアップ・マスター・ドメイン・マネージャーのバージョン 8.3

以降からのアップグレード

TWS86_UPGRADE_BACKUP_MDM_83plus_UNIX.txt

コマンド行クライアントのアップグレード

TWS86_UPGRADE_CLI_UNIX.txt

エンドツーエンド・フォールト・トレラント・エージェント上のコネクターのアップグレード

TWS86_UPGRADE_Connector_and_FTA_UNIX.txt

マスター・ドメイン・マネージャーのバージョン 8.3 以降からのアップグレード

TWS86_UPGRADE_MDM_83plus_UNIX.txt

Windows 上でのインストール

コマンド行クライアントと言語パック

TWS86_CLI_LP_WIN.txt

コマンド行クライアント (言語パックはインストールされない)

TWS86_CLI_WIN.txt



TWS86_FRESH_Agent_existTWA_WIN.txt



TWS86_FRESH_Agent_newTWA_WIN.txt



TWS86_FRESH_BACKUP_MDM_existTWA_WIN.txt






TWS86_FRESH_BACKUP_DDM_newTWA_WIN.txt



TWS86_FRESH_BACKUP_DDM_existTWA_WIN.txt

Dynamic Workload Console がインストールされていないフレッシュ・コネクター

TWS86_FRESH_Conn_NEITHER_TDWC_NOR_ZCONN_WIN.txt

Dynamic Workload Console 上のフレッシュ・コネクター

TWS86_FRESH_Conn_ON_TDWC_OR_ZCONN_WIN.txt

フレッシュ動的エージェント TWS86_FRESH_DYNAMIC_Agent_WIN.txt


の軽量エンドツーエンド・スケジューリング環境のための既存の Tivoli


TWS86_FRESH_DDM_existTWA_WIN.txt



TWS86_FRESH_DDM_for_ZOS_existTWA_WIN.txt


の軽量エンドツーエンド・スケジューリング環境のための新しい Tivoli


TWS86_FRESH_DDM_for_ZOS_newTWA_WIN.txt



TWS86_FRESH_DDM_newTWA_WIN.txt



TWS86_FRESH_MDM_existTWA_WIN.txt



TWS86_FRESH_MDM_newTWA_WIN.txt

エージェントのアンインストール TWS86_UNINSTALL_Agent.txt

エージェントのアップグレード TWS86_UPGRADE_Agent_WIN.txt


TWS86_UPGRADE_CLI_WIN.txt

バックアップ・マスター・ドメイン・マネージャーのバージョン 8.3

以降からのアップグレード

TWS86_UPGRADE_BACKUP_MDM_83plus_WIN.txt





TWS86_UPGRADE_CLI_WIN.txt

コネクターのアップグレード TWS86_UPGRADE_Connector_WIN.txt

エンドツーエンド・フォールト・トレラント・エージェント上のコネクターのアップグレード

TWS86_UPGRADE_Connector_and_FTA_WIN.txt

マスター・ドメイン・マネージャーのバージョン 8.3 以降からのアップグレード

TWS86_UPGRADE_MDM_83plus_WIN.txt

注: UNIX zSeries® システムでサイレント・インストールを実行する場合は、最初に応答ファイルを UTF 8 形式で保管する必要があります。

応答ファイル・テンプレートを使用してサイレント・インストールを実行するには、以下の手順を実行してください。

1. 対応する応答ファイルをローカル・ディレクトリーにコピーし、それをユーザーの環境の必要を満たすように編集します。

注: インストール・メディアに含まれる使用条件の情報を必ず確認してください。使用条件を受諾するには、使用する応答ファイルで licenseAccepted パラメーターを true に設定します。この値は、サイレント・インストールを正常に完了するために必要です。

2. 変更したファイルを保管します。

3. 次のコマンドを入力します。

Windows オペレーティング・システムSETUP.exe -options <local_dir>¥response_file.txt -silent

ここで、response_file.txt は、インストールで使用される応答ファイルの名前です。 SETUP.exe ファイルは、WINDOWS ディレクトリーにあります。 31ページの『インストール・メディア』を参照してください。

UNIX および Linux オペレーティング・システム./SETUP.bin -options <local_dir>/response_file.txt -silent

ここで、response_file.txt は、インストールで使用される応答ファイルの名前です。 SETUP.sh ファイルは、関係するインストール DVD のルート・ディレクトリーにあります。 31ページの『インストール・メディア』を参照してください。

4. summary.log ファイルに入っているインストール・メッセージを調べて、インストールが正常に実行されたかどうかを確認します。

5. インストールが正常に実行された場合は、最後に、インストールしたエージェントのタイプに応じて以下の構成タスクのいずれかを実行してください。

v 191ページの『マスター・ドメイン・マネージャーの構成』.

v 196ページの『フォールト・トレラント・エージェントの構成』.

v 197ページの『動的エージェントの構成』.


注: Dynamic Workload Console が既にインストールされた Tivoli Workload

Automation のインスタンスにエージェントをインストールする場合に、後からそのエージェントにコネクター・フィーチャーを追加する予定であれば、Dynamic Workload Console をインストールしたときに WebSphere Application

Server 管理ユーザーとして使用したものと同じユーザーをエージェントの<TWS_user> として使用するように強くお勧めします。これらの名前が同じ場合は、WebSphere Application Server 管理の実行が容易になります (WebSphere

Application Server を使用する Tivoli Workload Scheduler コンポーネントをDynamic Workload Console より前にインストールする場合、これがデフォルトの状態です)。

応答ファイル・テンプレートを使用するサイレント・インストール

インストール DVD の ¥TWS¥RESPONSEFILES¥ ディレクトリーにある応答ファイル・テンプレートを編集します。ファイルをカスタマイズするための指示は、ファイル内にコメント・テキストとして組み込まれています。応答ファイルのプロパティーについて詳しくは、 336ページの『Tivoli Workload Scheduler 応答ファイルのプロパティー』を参照してください。

自動的に生成された応答ファイルを使用するサイレント・インストール

Tivoli Workload Scheduler の現行バージョンを初期インストールする際に、初期インストールのパラメーターに従って応答ファイルを作成できます。この応答ファイルを使用して、後続のインストールを同じパラメーターで実行できます。自動生成による応答ファイルの作成は、すべての入力がプログラムによって自動的に妥当性検査されるので推奨されています。

自動生成の応答ファイルを使用してサイレント・インストールを実行するには、以下の手順を実行してください。

1. 以下のコマンドを使用して、初期インストールを実行します。


SETUP.exe -options-record <local_dir>¥response_file.txt

ここで、 response_file.txt は作成する応答ファイルの名前です。SETUP.exe ファイルは、WINDOWS ディレクトリーにあります。 31ページの『インストール・メディア』を参照してください。

UNIX オペレーティング・システムおよび Linux オペレーティング・システム

./SETUP.bin -options-record <local_dir>/response_file.txt

ここで、 response_file.txt は作成する応答ファイルの名前です。SETUP.sh ファイルは、関係するインストール DVD のルート・ディレクトリーにあります。 31ページの『インストール・メディア』を参照してください。

2. すべての後続のインストールで、以下のコマンドを入力します。

Windows SETUP.exe -options <local_dir>¥response_file.txt -silent


UNIX およびLinux

./SETUP.bin -options <local_dir>/response_file.txt -silent

3. 各サイレント・インストールの後に、summary.log ファイルに入っているインストール・メッセージを調べて、インストールが正常に実行されたかどうかを確認します。

4. インストールが正常に実行された場合は、最後に、インストールしたエージェントのタイプに応じて以下の構成タスクのいずれかを実行してください。




twsinst を使ったエージェントのインストール

このセクションでは、twsinst スクリプトを使用して、Tivoli Workload Scheduler

フォールト・トレラント・エージェントまたは動的エージェントを分散ネットワークまたはエンドツーエンド・ネットワークにインストールする方法を説明します。twsinst スクリプトは、サイレント・インストール・ウィザード ( 100ページの『サイレント・インストールの実行』を参照) に代わるものです。さらに、動的エージェントをインストールする場合は、twsinst スクリプトを使用して、拡張オプション付きジョブ・タイプを実行するために必要な Java ランタイムをエージェントに追加できます。twsinst を使用してインストールしたエージェントは、twsinst を使用してのみアンインストールできます。

注:

1. IBM i® では、twsinst コマンド行のみを使用して動的エージェントをインストールできます。

2. Java 仮想マシン (JVM) を実行している場合は、twsinst スクリプトを使用して Tivoli Workload Scheduler エージェントをインストールできません。

インストール・プロセス中に、インストール手順ごとに、twsinst によって以下のディレクトリーにファイルが作成されます。

UNIX オペレーティング・システムの場合/user's_home/TWS

Windows オペレーティング・システムの場合%ProgramFiles%¥IBM¥TWA¥TWS

エージェントのインストール

Tivoli Workload Scheduler のフルインストールの際に、またはエージェントだけのスタンドアロン・インストールで、フォールト・トレラント・エージェントまたは動的エージェントをインストールできます。

インストール・パラメーターとオプションの説明については、 110ページの『エージェントのインストール・パラメーター』を参照してください。

Tivoli Workload Scheduler エージェントをインストールするには、以下の手順を実行してください。


UNIX および Linux オペレーティング・システムの場合:

1. ご使用のオペレーティング・システム用の DVD を挿入するか、エージェント eImage をダウンロードします (詳しくは、 31ページの『インストール・メディア』または http://www.ibm.com/support/

docview.wss?rs=672&uid=swg24027501 にあるダウンロード文書を参照)。

2. Tivoli Workload Scheduler ユーザーを作成します。ソフトウェアは、デフォルトでは /installation_dir/TWS というユーザーのホーム・ディレクトリーにインストールされます。

ユーザー:TWS_user

ホーム:/installation_dir/TWS (例: /home/user1/TWS、ここで user1 はTivoli Workload Scheduler ユーザーの名前です。)

3. 製品のインストール先とするワークステーションで root としてログインします。

4. DVD_root/TWS/operating_system ディレクトリーから、以下に説明する構文を使用して twsinst を実行します。構文パラメーターの説明については、 110ページの『エージェントのインストール・パラメーター』を参照してください。


1. ご使用のオペレーティング・システム用の DVD を挿入するか、エージェント eImage をダウンロードします (詳しくは、 31ページの『インストール・メディア』または http://www.ibm.com/support/

docview.wss?rs=672&uid=swg24027501 にあるダウンロード文書を参照)。

2. 製品のインストール先とするワークステーションで administrator としてログインします。

3. DVD_root/TWS/operating_system ディレクトリーから、以下に説明する構文を使用して twsinst を実行します。構文パラメーターの説明については、 110ページの『エージェントのインストール・パラメーター』を参照してください。

注: Windows 用 twsinst は、CScript および WScript モードで実行できる Visual Basic Script (VBS) です。

Tivoli Workload Scheduler ユーザーは自動的に作成されます。ソフトウェアは、デフォルトで Tivoli Workload Scheduler インストール・ディレクトリーにインストールされます。デフォルト値は、%ProgramFiles%¥IBM¥TWA です。

IBM i オペレーティング・システムの場合、動的エージェントのみ

1. IBM i ワークステーションで、QSECOFR ユーザーとしてサインオンします。

2. Tivoli Workload Scheduler 動的エージェントをインストールするためのIBM i ユーザー・プロファイルを作成します。このユーザー・プロファイルを、QSECOFR としてログオンしてインストールを実行するユーザーと混同しないでください。むしろこのユーザーは、twsinst スクリプトを実行するときに -uname username パラメーターで指定するユーザーで


|

|

|

|

|

|

|





す。構文パラメーターの説明については、 110ページの『エージェントのインストール・パラメーター』を参照してください。既存の IBM i システム・ユーザー・プロファイル、アプリケーション提供のユーザー・プロファイル、以下の予約済みの IBM i ユーザー・プロファイルを使用することはできません。

QDBSHR, QDFTOWN, QDOC, QLPAUTO, QLPINSTALL,QRJE, QSECOFR, QSPL, QSYS, QTSTRQS

重要:

v ユーザー・プロファイルがグループのメンバーであると、インストールは失敗します。ユーザー・プロファイルに関連付けられているグループ・プロファイルを *NONE に設定してください。

v username が 8 文字を超える場合、インストール後に、エージェント (および JobManager コンポーネント) は QSECOFR ユーザーの下で実行されますが、インストール・ユーザーの権限の下で実行されるべきです。これを回避するには、IBM i でPASE_USRGRP_LIMITED 環境変数を N に設定します。

3. IBM i システムで、動的エージェント・ユーザーのために指定したユーザー・プロファイルと同じ名前のライブラリーが存在しないことを確認します。

4. IBM i システムに対応した DVD を挿入するか、パスポート・アドバンテージのオンライン Web サイトからエージェントの eImage をダウンロードします (詳しくは、 31ページの『インストール・メディア』、または http://www.ibm.com/support/docview.wss?rs=672&uid=swg24027501 にあるダウンロード文書を参照してください)。

5. eImage をダウンロードした場合に、パッケージを untar するには、PASE シェルまたは AIXterm を使用できます。

PASE シェルを使用する場合:

a. PASE シェルを開きます。

b. コマンド "CALL QP2TERM" を実行します。

c. eImage のダウンロード先のフォルダーを見つけて、次のコマンドを実行します。

"tar xvf TWS86_IBM_I.tar"

d. PASE シェルを終了します。

AIXterm を使用する場合:

a. デスクトップで Xserver を開始します。

b. iSeries マシンで、QSH シェルを開き、表示をエクスポートします。

c. QSH シェルで、ディレクトリー /QopenSys に移動し、コマンド "aixterm -sb" を実行します。

d. デスクトップにポップアップ・ウィンドウが表示されます。このポップアップ・ウィンドウを使用して、ファイルTWS86_IBM_I.tar を untar します。


|

|

|

|

|

||

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|


6. QSH シェルを開き、twsinst スクリプトを実行します。インストール時に、本製品によって、手順 2 (107ページ) で作成したユーザー・プロファイルと同じ名前で IBM i ライブラリーとジョブ記述が作成されます。インストール手順によって、このライブラリーが動的エージェントのユーザー・プロファイルのユーザー・プロファイル・ライブラリー・リストに追加され、このジョブ記述が動的エージェントのユーザー・プロファイルのジョブ記述として設定されます。ソフトウェアのデフォルトのインストール先は、ユーザーのホーム・ディレクトリーになります。

注: twsinst スクリプトを QSH シェルから実行しないと、インストールは失敗します。

インストールが失敗した場合は、戻りコード RC = 1 が発行されます。インストールが失敗した場合については、「Tivoli Workload Automation: メッセージおよびコード」を参照してください。

インストールが正常に実行された場合は、最後に、インストールしたエージェントのタイプに応じて以下の構成タスクのいずれかを実行してください。



UNIX、Linux、および IBM i オペレーティング・システムの場合:

コマンドの使用法とバージョンの表示

twsinst -u | -v

新規インスタンスのインストール

twsinst -new -uname username[-addjruntime true|false][-agent dynamic|fta|both][-company company_name][-create_link][-displayname agentname][-hostname hostname][-inst_dir install_dir][-jmport port_number][-jmportssl true|false][-lang lang_id][-master master_cpu_name][-port port_number][-reset_perm][-skip_usercheck][-stoponcheckprereq][-tdwbport tdwbport_number][-tdwbhostname host_name][-thiscpu workstation]


コマンドの使用法とバージョンの表示

twsinst -u | -v

新規インスタンスのインストール

twsinst -new -uname username-password user_password[-addjruntime true|false][-agent dynamic|fta|both][-company company_name]


|

|

|

|

|

|

|

|

|

|

|

[-displayname agentname][-domain user_domain][-hostname host_name][-inst_dir install_dir][-jmport port_number][-jmportssl true|false][-lang lang_id][-master master_cpu_name][-port port_number][-skip_usercheck][-tdwbport tdwbport_number][-tdwbhostname host_name][-thiscpu workstation]

エージェントのインストール・パラメーター

このセクションでは、twsinst スクリプトを使用してフォールト・トレラント・エージェントまたは動的エージェントをインストールする場合に使用されるパラメーターをリストおよび説明します。

-addjruntime true|false

Java ランタイムを追加して、拡張オプション付きジョブ・タイプ (製品と共に提供されたタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行します。有効な値は true および false です。フレッシュ・インストールのデフォルトは true です。

-agent dynamic|fta|both

インストールするエージェントのタイプ。有効な値は次のとおりです。

dynamicTivoli Workload Scheduler の動的エージェントをインストールします。この値と一緒に、-tdwbhostname host_name パラメーターと-tdwbport tdwbport_number パラメーターを使用します。

fta Tivoli Workload Scheduler のフォールト・トレラント・エージェントをインストールします。

both -tdwbhostname host_name パラメーターと -tdwbporttdwbport_number パラメーターを使用する動的エージェントと、フォールト・トレラント・エージェントの両方をインストールします。

デフォルトは dynamic です。

-company company_name

会社の名前。会社名にブランク文字を入れることはできません。この名前は、プログラム・ヘッダーおよびレポートに現れます。指定しなければ、デフォルト値は COMPANY です。

-create_linkUNIX のみ。/usr/bin/at と <install_dir>/TWS/bin/at との間に symlinkを作成します。詳しくは、 31ページの表 1 を参照してください。

-displayname動的エージェントに割り当てる名前。デフォルトは、このコンピューターのホスト名です。


-domain user_domain

Windows のみ。Tivoli Workload Scheduler ユーザーのドメイン名。デフォルトは、製品のインストール先となるワークステーションの名前です。

-hostname host_name

Dynamic Workload Broker がエージェントと通信するときに使用する完全修飾ホスト名または IP アドレス。デフォルトは、このコンピューターのホスト名です。

-inst_dir installation_dir

Tivoli Workload Scheduler インストールのディレクトリー。

UNIX および Linux オペレーティング・システムの場合:パスにブランクを含めることはできません。手動でパスを指定しない場合は、パスはデフォルトのホーム・ディレクトリー(%ProgramFiles%¥IBM¥TWA) に設定されます。

Windows オペレーティング・システムの場合:ブランクを含むパスを指定する場合は、それを二重引用符で囲みます。手動でパスを指定しない場合は、パスはデフォルトのホーム・ディレクトリー (user_name ホーム・ディレクトリー) に設定されます。

IBM i オペレーティング・システムの場合:パスにブランクを含めることはできません。手動でパスを指定しない場合は、パスはデフォルトのホーム・ディレクトリー (user_

home¥user_name ディレクトリー) に設定されます。

-jmport port_number

Tivoli Workload Scheduler 動的エージェントに接続するために Dynamic

Workload Broker によって使用される JobManager ポート番号。デフォルト値は 31114 です。有効範囲は、1 から 65535 です。

-jmportssl true|false

Tivoli Workload Scheduler 動的エージェントに接続するために Dynamic

Workload Broker が使用する JobManager ポート。この番号は ita.ini ファイルに登録されます。このファイルは、Windows では ITA¥cpa¥ita にあり、UNIX、Linux、および IBM i では ITA/cpa/ita にあります。

SSL または HTTPS を使用した通信の場合jmportssl = true を設定します。 Dynamic Workload Broker と通信するには、この値を true に設定することをお勧めします。この場合、jmport で指定されるポートが HTTPS で通信します。

SSL を使用しない HTTP 通信の場合jmportssl = false を設定します。この場合、jmport で指定されるポートが HTTP で通信します。

-lang lang_id

twsinst メッセージが表示される言語。指定しなければ、システム LANG

が使用されます。関連するカタログがない場合、デフォルトの C 言語カタログが使用されます。


注: これは、インストール・ログの記録に使用される言語であり、インストールされるエンジン・インスタンスの言語ではありません。 twsinstは、デフォルトとしてすべての言語をインストールします。

-master workstation

マスター・ドメイン・マネージャーのワークステーション名。この名前は16 文字を超えてはなりません。また、スペースを含めることはできませんし、thiscpu パラメーターに入力したワークステーション名と同じにすることはできません。指定しなければ、デフォルト値は MASTER です。

-new エージェントのフレッシュ・インストール。エージェントおよびすべてのサポートされている言語パックをインストールします。

-password user_password

Windows のみ。Tivoli Workload Scheduler をインストールする対象となるユーザーのパスワード。

-port port_number

マスターからの通信を listen するために Netman プロセスが使用するTCP/IP ポート番号。デフォルト値は 31111 です。有効範囲は、1 から65535 です。このポート番号は localopts ファイルに登録されます。

-reset_permUNIX および IBM i のみ。 /usr/Tivoli ディレクトリー内のライブラリーの許可をリセットします。

-skip_usercheck社内での認証プロセスが標準的なものではない場合には、このオプションを使用可能にして、それによってデフォルトの認証オプションを使用不可にします。 UNIX では、/etc/password ファイル内のユーザー、または su コマンドを使用しているユーザーの検査をスキップします。Windows では、-uname username パラメーターに指定したユーザーを作成しません。このパラメーターを指定する場合は、スクリプトを実行する前にユーザーを手動で作成する必要があります。

-stoponcheckprereq前提条件チェックの際に問題が発生するたびにインストールを停止します。前提条件チェックについて詳しくは、 28ページの『前提条件の検査 (UNIX

および Linux)』を参照してください。

-tdwbhostname host_name

Dynamic Workload Broker の完全修飾ホスト名。これは、-agentdynamic|both and the -tdwbport tdwbport_number パラメーターと共に使用されます。動的エージェントのインストールが必要です。このパラメーターを指定しなければ、ワークロードを動的に実行することはできません。このパラメーターのデフォルト値は、localhost です。この値は、JobManager.ini

ファイルの ResourceAdvisorUrl プロパティーに登録されます。

-tdwbport tdwbport_number

Dynamic Workload Broker HTTP または HTTPS トランスポート・ポート番号。これは、-agent dynamic|both and the -tdwbhostname host_name パラメーターと共に使用されます。動的エージェントのインストールが必要です。この番号は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。デフォルト値は 31116 です。有効範囲は、0 から


65535 です。 0 を指定した場合、またはこのパラメーターを指定しない場合は、ワークロードを動的に実行できません。-agent の値が dynamic または both の場合は、0 を指定しないでください。

-thiscpu workstation

このインストールの Tivoli Workload Scheduler ワークステーションの名前。この名前は 16 文字を超えてはなりません。また、スペースを含めることはできませんし、マスター・ドメイン・マネージャーのワークステーション名と同じにすることはできません。この名前は localopts ファイルに登録されます。指定しなければ、デフォルト値はワークステーションのホスト名です。

-u コマンド使用法情報を表示して、終了します。

-uname username

Tivoli Workload Scheduler がインストールされるユーザーの名前。このユーザー名を、UNIX と Linux では root として、Windows では管理者として、IBM i では QSECOFR としてログオンしてインストールを実行するユーザーと混同しないでください。

UNIX および Linux では、新規インストールの場合、インストールの実行前にこのユーザー・アカウントを手動で作成する必要があります。ホーム・ディレクトリーを持つユーザーを作成します。 Tivoli Workload Scheduler

は、デフォルトでは指定したユーザーのホーム・ディレクトリーの下にインストールされます。

IBM i では、username が 8 文字を超える場合、インストール後に、エージェント (および JobManager コンポーネント) は QSECOFR ユーザーの下で実行されますが、インストール・ユーザーの権限の下で実行されるべきです。これを回避するには、PASE_USRGRP_LIMITED 環境変数を N に設定します。

-v コマンドのバージョンを表示して、終了します。

インストールの例

次に示すのは、twsinst を使用してフォールト・トレラント・エージェントの新しいインスタンスをインストールする場合に使用される構文の例です。

UNIX および Linux の場合:

./twsinst -new-uname TWS_user-addjruntime true-agent both-company IBM-create_link-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-reset_perm-stoponcheckprereq-thiscpu mainworkstation



|

|

|

|

|

twsinst -new-uname TWS_user-password user_password-agent fta-company IBM-displayname thishostcomputername-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-thiscpu mainworkstation

次に示すのは、twsinst を使用して動的エージェントの新しいインスタンスをインストールし、拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加する場合に使用される構文の例です。

Unix および Linux オペレーティング¥システムの場合:

./twsinst -new-uname TWS_user-addjruntime true-agent dynamic-company IBM-create_link-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-reset_perm-stoponcheckprereq-tdwbport 31116-tdwbhostname mainbroker.mycompany.com-thiscpu mainworkstation


-twsinst -new-uname TWS_user-password user_password-addjruntime true-agent dynamic-company IBM-displayname thishostcomputername-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-tdwbport 31116-tdwbhostname mainbroker.mycompany.com-thiscpu mainworkstation

次に示すのは、twsinst を使用してフォールト・トレラント・エージェントと動的エージェントの両方の新しいインスタンスをインストールし、拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加する場合に使用される構文の例です。

UNIX および Linux の場合:

./twsinst -new-uname TWS_user-addjruntime true-agent both-company IBM-create_link


-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-reset_perm-stoponcheckprereq-tdwbport 31116-tdwbhostname mainbroker.mycompany.com-thiscpu mainworkstation


-twsinst -new-uname TWS_user-password user_password-addjruntime true-agent both-company IBM-displayname thishostcomputername-hostname thishostname.mycompany.com-inst_dir "c:¥Program Files¥IBM¥TWA"-jmport 31114-master TWSmdm-port 37124-tdwbport 31116-tdwbhostname mainbroker.mycompany.com-thiscpu mainworkstation

Software Distribution を使ったエージェントのインストール

このセクションでは、Software Distribution のソフトウェア・パッケージ・ブロックを使用して Tivoli Workload Scheduler エージェントをインストールする方法を説明します。インストールの際、以下を追加できます。

v 標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能

v 動的エージェント

v 拡張オプション付きジョブ・タイプ (製品と共に提供されるジョブ・タイプとカスタム・プラグインを通して実装される追加タイプの両方) を実行するためのJava ランタイム

Software Distribution ソフトウェア・パッケージ・ブロックを使用してインストールされたエージェントには、以下の特性があります。

v 同じシステム上にインストールされている他の Tivoli Workload Automation 製品またはコンポーネントからは独立して、独自のパス上にインストールされます。

v Tivoli Workload Automation ネットワークのコンポーネントは共有できません。

v コネクターを追加することはできないので、Dynamic Workload Console に直接接続することはできません。

Java 仮想マシンをワークステーション上で実行しない場合にのみ、Software

Distribution ソフトウェア・パッケージ・ブロックを使用して、Tivoli Workload

Scheduler エージェントをインストールします。これに該当しない事例では、代わりにサイレント・インストールの実行を選択することができます。 100ページの『サイレント・インストールの実行』を参照してください。


注: Software Distribution ソフトウェア・パッケージ・ブロックを使用してインストールされたエージェントは、Software Distribution を使用してのみアンインストールできます。

ソフトウェア・パッケージおよびパラメーター

Tivoli Workload Scheduler エージェントは、Tivoli Configuration Manager バージョン 4.1、4.2、4.2.1、4.2.2、または 4.2.3 の Software Distribution コンポーネントを使用して、ソフトウェア・パッケージ・ブロック (SPB) を配布してインストールできます。コマンド行インターフェースを使用するか、または Tivoli デスクトップからのいずれかで、SPB を配布できます。

注: 製品と一緒に提供される SPB は変更しないでください。

サポートされているオペレーティング・システムごとに SPB が存在し、それぞれはインストール・ディスク上の各オペレーティング・システムのディレクトリーの下に置かれています。SPB には、どのオペレーティング・システム用かに応じて、Tivoli_TWS_<operating_system>.SPB という名前が付けられます。パッケージを配布するには、それらをソフトウェア・パッケージ・プロファイルにインポートする必要があります。ソフトウェア・パッケージ・プロファイルには、どのオペレーティング・システム用で、どのユーザーのものであるかに応じて、FP_TWS_<operating_system>_<TWS_user>.8.6.00 のように名前を付ける必要があります。オペレーティング・システムの値として可能な値は次のとおりです。v AIX

v HP

v SOLARIS

v WINDOWS

v LINUX_I386

v LINUX_PPC

v LINUX_S390

v SOLARIS_I386

v HPIA64

v LINUX_X86_64

v WINDOWS_X86_64

SPB はまた、言語パックをインストールするためにも存在します(Tivoli_TWS_LP.SPB)。ソフトウェア・パッケージ・プロファイルには、ユーザーに応じて Tivoli_TWS_LP_<TWS_user>.8.6.00 のように名前を付ける必要があります。言語パックのソフトウェア・パッケージ・ブロックは、インストール DVD のルート・ディレクトリーの下にあります。

Tivoli Workload Scheduler インストール・パラメーターは、ソフトウェア・パッケージにデフォルト変数として定義されます。以下は、インストール・パラメーターのリストです。

backup オプションです。バックアップを示します。フレッシュ・インストールの場合、false を指定します。デフォルト値は false です。

company

オプションです。会社名。この名前は、プログラム・ヘッダーおよびレポートに現れます。デフォルト値は COMPANY です。


display_name必須です。動的エージェントに割り当てる名前。デフォルトは、このコンピューターのホスト名です。

domain ユーザーがドメイン・ユーザーでなければ、オプションです。 Windows オペレーティング・システムについてのみ使用されます。ユーザーのドメイン名。デフォルト値は、<computer_name> です。

fresh_install

必須です。最初のインストールであるかどうかを示します。フレッシュ・インストールを実行するには、false を指定します。アップグレードを実行するには、true を指定します。デフォルト値は true です。

from_release

upgrade を指定した場合には、必須です。 upgrade=”true” を指定する場合は、from_release も指定して、既存インスタンスのリリースを指示する必要があります。 8.x という形式です。

group オプションです。オペレーティング・システム・ユーザーのグループの名前。

host_nameオプションです。 Tivoli Dynamic Workload Broker がエージェントと通信するときに使用する完全修飾ホスト名または IP アドレス。

installer

オプションです。 Windows オペレーティング・システムについてのみ使用されます。 Tivoli Workload Scheduler をインストールするユーザーのユーザー ID です。デフォルト値は Administrator です。

install_dir

必須です。 Tivoli Workload Scheduler インストールのディレクトリーへの完全修飾パス。このパスは完全修飾パスでなければならず、ブランクを含めることはできません。Windows ワークステーションでは、このパスは、まだ存在しない場合、作成されます。UNIX および Linux のオペレーティング・システムでは、このパスはユーザーのホーム・ディレクトリーと同じです。デフォルト値は次のとおりです。

v Windows: $(system_drive)¥win32app1TWS¥<TWS_user>

v UNIX および Linux: user_home

jm_port

Tivoli Workload Scheduler サーバーと Tivoli Workload Scheduler 動的エージェントとの間の通信に使用される HTTP ポートの値を指定します。

HTTP で通信するには、パラメーター -D jm_port=nnnn も設定する必要があります。ここで、nnnn はポート番号であり、-D jm_sec_port=0 です。jm_port のデフォルト番号は 31114 です。

jm_sec_port

Tivoli Workload Scheduler サーバーと Tivoli Workload Scheduler 動的エージェントとの間の通信に使用される HTTPS ポートの値を指定します。

HTTPS で通信するには、パラメーター -D jm_port=0 -D jm_sec_port=nnnn

も設定する必要があります。ここで、nnnn はポート番号です。jm_sec_port

のデフォルト番号は 31114 です。


master_cpu

オプションです。マスター・ドメイン・マネージャーの名前。この名前は、16 文字を超えてはなりません。また、スペースを含めることはできません。デフォルトは MASTER です。

pwd (Windows の場合のみ)Windows オペレーティング・システムでは、最初のインストール時に必須です。<TWS_user> ユーザー名に関連するパスワード。 SPB password 変数が pwd 変数に渡されます。

tcp_port

必須です。分散スケジューリングの実行に使用される Netman ポートです。Netman は、実稼働環境を制御するネットワーク・プロセスです。同一のワークステーションに複数のインスタンスをインストールするときは、各インスタンスごとに異なるポート番号を使用してください。この番号は 1 から65535 の範囲内の割り当てられていない 16 ビットの値でなければなりません。デフォルト値は 31111 です。

tdwb_hostname

オプションです。 Dynamic Workload Broker の完全修飾ホスト名。-tdwbport <tdwbport_number> パラメーターと共に使用されます。Tivoli

Workload Scheduler にワークロードを動的に実行する機能を追加します。このパラメーターを指定しなければ、ワークロードを動的に実行することはできません。このパラメーターのデフォルト値は、localhost です。この値は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。

tdwb_port

オプションです。 Dynamic Workload Broker HTTP または HTTPS ポート番号。-tdwbhostname host_name パラメーターと共に使用されます。 Tivoli

Workload Scheduler にワークロードを動的に実行する機能を追加します。この番号は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。デフォルト値は 31116 です。有効範囲は、1 から 65535 です。

this_cpu

必須です。インストールを実行するワークステーションの名前です。この名前は、16 文字を超えてはなりません。また、スペースを含めることはできません。デフォルト値は THIS_CPU です。

tws_user

必須です。 Tivoli Workload Scheduler インスタンスがインストールされる対象のユーザー名。 Windows システムで、このユーザー・アカウントがまだ存在していない場合には、自動的に作成されます。ドメイン・ユーザーまたはドメイン・コントローラーを指定する場合、そのドメインを domain 変数に指定する必要があります。ドメイン・ユーザーと同じ名前をローカル・ユーザー名に指定する場合、まず管理者が手動でこのローカル・ユーザーを作成し、次に <system_name>¥<user_name> として示す必要があります。

UNIX および Linux のオペレーティング・システムでは、インストールを実行する前にこのユーザー・アカウントを手動で作成する必要があります。


upgrade

必須です。インストールがアップグレードであるかどうかを示します。アップグレードを実行するには、true を指定します。フレッシュ・インストールを実行するには、false を指定します。デフォルト値は false です。

注:

1. fresh_install と upgrade は同時に指定することはできません。

2. ここに記載されていない変数は、デバッグ専用の変数です。「管理ガイド」を参照してください。

インストール手順

インストール手順によって、Tivoli Workload Scheduler エンジンをインストールするのに十分なスペースがあるかどうかが検査されます。ただし、インストール手順は、swdis.ini ファイルで指定されている Configuration Manager バックアップ・ディレクトリーに十分なスペースがあるかどうかは検査しません。これらのスペース所要量については、Tivoli Configuration Manager の資料を参照してください。

インストールを実行するには、以下の手順を完了します。

1. ソフトウェア・パッケージ・プロファイルFP_TWS_<operating_system>_<TWS_user>.8.6.00 を作成します。ここで、operating_system は、インストール先のオペレーティング・システムで、<TWS_user> は、インストール済み環境のユーザーです。

2. wimpspo コマンドを使用してソフトウェア・パッケージ・ブロックをインポートします。ソフトウェア・パッケージ・ブロックをインポートする際には、wimpspo にプロファイル名を渡して、Configuration Manager エンドポイントがその名前を正しくカタログするようにする必要があります。

3. wdinstsp コマンドを使用してソフトウェア・パッケージ・ブロックをインストールします。

注: 提供されているソフトウェア・パッケージを COMMITTED としてインストールする必要があります。UNDO アクションで製品のレジストリー項目がロールバックされないため、パッケージを UNDOABLE としてインストールすることはできません。

4. インストールするエージェントのタイプに応じて、 196ページの『フォールト・トレラント・エージェントの構成』および 197ページの『動的エージェントの構成』のステップを実行します。

注: これらのタスクの実行の指示の詳細については、「IBM Tivoli Configuration

Manager Software Distribution リファレンス・マニュアル」の wimpspo とwdinstsp、および「IBM Tivoli Configuration Manager Software Distribution ユーザーズ・ガイド」を参照してください。

前提条件: Common Inventory Technology (CIT) のインストール:

CIT のインストールは、エージェントのインストールおよび以下の機能の追加の前に行う必要があります。



v 動的スケジューリング機能

v Java 環境ジョブのランタイムを追加するオプション

以下に示すのは、Windows およびUNIX ワークステーションで CIT をインストールするために実行するコマンドの例です。パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。

Windows オペレーティング・システム:1. wdinstsp -D CIT_ExploiterID=TWA D:¥TWS_86¥WINDOWS¥CIT_Preinstall.spb

2. wdinstsp D:¥TWS_86¥WINDOWS¥CIT.spb

UNIX および Linux オペレーティング・システム:1. wdinstsp -D CIT_ExploiterID=TWA /TWS_86/UNIX/CIT_Preinstall.spb

2. wdinstsp /TWS_86/UNIX/CIT.spb

Tivoli Workload Scheduler 動的エージェントのインストール:

このセクションでは、wdinstsp コマンドを使用して、Tivoli Workload Scheduler 動的エージェントをインストールする方法について説明します。さらに、Java ランタイムをエージェントに追加して、拡張オプション付きジョブ・タイプ (製品と共に提供されているジョブ・タイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行できます。 121ページの『Java ランタイムの追加』を参照してください。

Tivoli Workload Scheduler 動的エージェントをインストールするには、以下の手順を実行してください。

1. 70ページの『ユーザー許可要件』のセクションにある手順を実行するために必要な権限を確認します。

2. 116ページの『ソフトウェア・パッケージおよびパラメーター』のセクションにある手順で .spb の場所を見つけます。

3. TWA/TWS/_uninstall/CLI ディレクトリーにある以下のコマンドを起動して、ソフトウェア配布環境を設定します。

Windows オペレーティング・システム:swd_env.bat

UNIX および Linux オペレーティング・システム:swd_env.sh

4. 以下の例のようにして、TWA/TWS/_uninstall/CLI にある wdinstsp コマンドを実行します。

Windows オペレーティング・システム次の Windows の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_WINDOWS を使用したインストールについて説明しています。この例では、ドメイン・コントローラーまたは Windows ノード・エージェントにインストールしています。-D domain="domain_name" が指定されているためです。

wdinstsp-f-uy-D install_dir="C:¥ibm¥TWS¥twsuser¥TWS"-D tws_user="twsuser"-D password="twspasswd"


-D domain="domain_name"-D group="group_name"-D installer="Administrator"-D jm_port="0"-D jm_sec_port="31114"-D host_name="IT041924-T61.rot.ibm.com"-D display_name="IT041924-T61_1"-D tdwb_port="31116"-D "tdwb_hostname=slt.romelab.it.ibm.com"-D fresh_install="true"-D upgrade="false"-D execActionTools="true"-D startAgent="true"-n "TWS_LWA_twsuser.8.6.0.00"

"C:¥Output¥TWS_VLAST¥WINDOWS¥Tivoli_LWA_WINDOWS.SPB"

UNIX および Linux オペレーティング・システム次の UNIX の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_LINUX_I386 を使用したインストールについて説明しています。

wdinstsp-f-uy-D install_dir="/home/twsuser/TWS"-D tws_user="twsuser"-D domain="null"-D group="group_name"-D installer="root"-D jm_port="0"-D jm_sec_port="31114"-D host_name="IT041924-T61.rot.ibm.com"-D display_name="IT041924-T61_1"-D tdwb_port="31116"-D "tdwb_hostname=slt.romelab.it.ibm.com"-D fresh_install="true"-D upgrade="false"-D execActionTools="true"-D startAgent="true"-n "TWS_LWA_twsuser.8.6.0.00"

/mnt/gsa/home/s/l/user1/web/public/SPB_INSTALL/LINUX_I386/Tivoli_LWA_LINUX_I386.SPB

以下に示すのは、Windows および UNIX ワークステーションでエージェントのフレッシュ・インストールを実行するのに必要な設定値の例です。パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。

Java ランタイムの追加:

Java ランタイムを追加して、以下の機能をエージェントに追加します。

v 拡張オプション付きジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行する機能。


Java ランタイムを追加するには、以下の手順を実行してください。








パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。

Windows オペレーティング・システム:wdinstsp

-f-uy-D install_dir="C:¥ibm¥TWS¥twsuser¥TWS"-D tws_user="twsuser"-D group="group_name"-D installer="Administrator"-n "TWS_Eclipse_twsuser.8.6.0.00"

"C:¥Output¥TWS_VLAST¥WINDOWS¥Tivoli_Eclipse_WINDOWS.SPB"

UNIX および Linux オペレーティング・システム:次の UNIX の例は、ユーザー <TWS_user> を使用したインストールについて説明しています。

wdinstsp-f-uy-D install_dir="/home/twsuser/TWS"-D tws_user="twsuser"-D group="group_name"-D installer="root"-n "TWS_Eclipse_twsuser.8.6.0.00"

/mnt/gsa/home/s/l/user1/web/public/SPB_INSTALL/LINUX_I386/Tivoli_Eclipse_LINUX_I386.SPB

標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能の追加:

Windows および UNIX ワークステーションで Tivoli Workload Scheduler エージェントに標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を追加するには、以下の手順を実行してください。









Windows オペレーティング・システム:以下の例では、ドメイン・コントローラーまたは Windows ノード・エージェントにインストールしています。-D domain="domain_name" パラメーターが指定されていたためです。ユーザー <TWS_user> とエンドポイント Tivoli_TWS_WINDOWS でインストールを実行します。

wdinstsp-n "FP_TWS_WINDOWS_twsuser.8.6.0.00"-D install_dir="C:¥ibm¥TWS¥twsuser¥TWS"-D tws_user="twsuser"-D password="twspasswd"-f-uy-D company="company_name"-D this_cpu="IT041924-T61"-D master_cpu="MTMDM"-D tcp_port="33311" jm_port=0-D jm_sec_port=31114-D domain="domain_name"

"C:¥Output¥TWS_VLAST¥WINDOWS¥Tivoli_TWS_WINDOWS.SPB"

UNIX および Linux オペレーティング・システム:次の UNIX の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_LINUX_I386 を使用したインストールについて説明しています。

wdinstsp-n FP_TWS_WINDOWS_twsuser.8.6.0.00-f-uy-D install_dir="/home/twsuser/TWS"-D tws_user="twsuser"-D company="company_name"-D this_cpu="IT041924-T61"-D master_cpu="MTMDM" jm_port=0-D jm_sec_port=31114-D tcp_port="33311"-D serverName="server1"

/mnt/gsa/home/s/l/user1/web/public/SPB_INSTALL/LINUX_I386/Tivoli_TWS_LINUX_I386.SPB

言語パックのインストール

Software Distribution を使用して言語パックをインストールできます。 DVD のルート・ディレクトリーにある Tivoli_TWS_LP.SPB ソフトウェア・パッケージ・ブロックを見つけて、インストールする前に以下のパラメーターをカスタマイズします。


表 6. 言語パックをインストールするためのパラメーターのリスト

デフォルトの変数説明必須デフォルト値

zh_CN

it

ko

es

zh_TW

ja

pt_BR

de

fr

ALL_LANG

中国語 (簡体字)

イタリア語

韓国語

スペイン語

中国語 (繁体字)

日本語

ブラジル・ポルトガル語

ドイツ語

フランス語

上記言語のすべて

インストールする言語に true を指定します。他のすべての言語のデフォルト値はfalse です。

偽

tws_user 指定した言語パックがインストールされる対象のユーザー名。

はい $(user_name)

install_dir 指定した言語パックのインストール先の完全修飾パス。

はい $(program_files)






4. 以下の例のようにして、TWA/TWS/_uninstall/CLI にある wdinstsp コマンドを実行します。次に示すのは、すべての言語をインストールするために必要な構文です。

wdinstsp-D install_dir="Installation Path"-D tws_user="UserName"[-D zh_C =true ...-D de=true | ALL_LANG=true]Tivoli_TWS_LP.SPB [subscribers...]

次に示すものは、イタリア語およびドイツ語の言語パックをインストールするために必要な構文です。


wdinstsp-D install_dir="Installation Path"-D tws_user="UserName"[-D it =true | -D de=true]Tivoli_TWS_LP.SPB [subscribers...]

Job Brokering Definition Console のインストール

このセクションでは、Job Brokering Definition Console をインストールする方法を説明します。以下のトピックに分かれています。

v 『インストール・ウィザードの使用による Job Brokering Definition Console のインストール』

v 126ページの『Job Brokering Definition Console のサイレント・インストールの実行』

Job Brokering Definition Console は構造化された編集ツールで、Job Submission

Description Language (JSDL) ファイルの作成および変更に使用します。これらのファイルは、ジョブ定義としてジョブ・リポジトリーに保存され、実行依頼の際に使用できるようになります。 JSDL ファイルは、JSDL スキーマで定義される XML

の構文およびセマンティクスに従います。 Job Brokering Definition Console について詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」(SC88-9680) を参照してください。

Job Brokering Definition Console は、Windows 32 ビットおよび Linux 32 ビットでのみサポートされます。 Job Brokering Definition Console のインスタンスは、それぞれのワークステーションで、単一ユーザーにつき 1 つインストールできます。これは、同じユーザーによってインストールされる 2 つのインスタンスが同じワークスペースを共有するためです。同じワークステーションに Job Brokering Definition

Console のインスタンスを 2 つインストールすることが必要な場合は、各インスタンスをそれぞれ異なるユーザーを使用してインストールし、各インスタンスがその独自のワークスペースにアクセスできるようにしてください。

インストール・ウィザードの使用による Job Brokering DefinitionConsole のインストール

グラフィカル・インストールでは、インストール DVD から 36ページの『Launchpad』の説明に従ってランチパッドを開始し、Job Brokering Definition

Console のインストールを選択します。または、インストールするオペレーティング・システムのセットアップを実行します。

DVD の root ディレクトリーから以下を実行します。

v Windows オペレーティング¥システムの場合:

JBDC¥WORKBENCH¥setupwin32.exe

v Linux オペレーティング・システムの場合: JBDC/WORKBENCH/setuplinux.bin

インストール・ウィザード画面に従って、インストール・ディレクトリー名を指定し、インストールを完了します。


Job Brokering Definition Console のサイレント・インストールの実行

サイレント・インストールでは、以下のファイルをローカル・ディレクトリーにコピーします。

<images_path>/JBDC/WORKBENCH/ResponseFiles/TDWB_Workbench_installation.rsp

このファイルでは、以下のパラメーターを編集します。

-V licenseAccepted=true-P installLocation="<installation_path>"

応答ファイル・テンプレートを使用してサイレント・インストールを実行するには、以下のコマンドを入力してください。

-options "<path-to-ResponseFile>/TDWB_Workbench_installation.rsp" -silent

応答ファイルおよびサイレント・インストールについては、 100ページの『サイレント・インストールの実行』を参照してください。

Tivoli Workload Scheduler for Additional Plug-ins の使用による追加プラグインのインストール

このセクションでは、Tivoli Workload Scheduler for Additional Plug-ins を使用して1 つ以上の追加プラグインをインストールする方法について説明します。以下のトピックに分かれています。

v 『インストール前』

v 127ページの『インストール方法の選択』

v 128ページの『インストール・ウィザードの使用によるインストール』

v 129ページの『サイレント・インストールを使用したインストール』

Tivoli Workload Scheduler for Additional Plug-ins は、特定のニーズを解決するために開発した追加プラグインをインストールする場合に使用できるインストール・プロセスです。このインストーラーは、Tivoli Workload Scheduler フィックスパック1 の DVD または eImage に含まれています。

インストール前追加プラグインのインストールを実行する前に、次の条件を満たしていることを確認します。

v プラグイン・ファイル <plug-in_namespace>.<plug-in id>_<plug-

in_version>.zip の構造が、 127ページの『追加プラグインの構造』で説明されているとおりであること。

v インストールを実行するための次の権限があること。Windows オペレーティング・システム:

管理者UNIX および Linux オペレーティング・システム:

root


v インストール・プロセスがワークステーション上でまだ実行されていないこと。これは、セットアップ・プロセスが実行されていないことを調べることで確認できます。

追加プラグインの構造このセクションでは、プラグインの構造について説明します。

v プラグインの zip 名は次の形式である必要があります。

<plug-in_namespace>.<plug-in_id>_<plug-in_version>.zip

v プラグイン・ファイル <plug-in_namespace>.<plug-in id>_<plug-

in_version>.zip の構造は、次のようになっている必要があります。

/files/license/files/plugin.xml/files/<plug-in_name>.properties/files/<plug-in_name>_<plugin_version>.jar

ここで、各項目は以下のとおりです。

– /files/license ディレクトリーには、使用許諾契約書ファイルが入っています。このディレクトリーはオプションです。

– オプション・ファイル <plug-in_name>.properties には、プラグインのプロパティーが入っています。

– 必須ファイル /files/plugin.xml の構造は次のようになっている必要があります。

<plugin><pluginInfo version="<plugin_version>" name="<plug-in_name>"

id="<plug-in_ID>" /><vendor name="<company_name>" id="<company_id>" /><pluginIstaller minVersionSupported="<plugin_min_version>" />

<twsInstances><twsInstance version="8.6.0.00" /></twsInstances>

<licenses dir="files/license" />

<deploy><jarFiles><file name="files/com.ibm.scheduling.agent.<plug-in_name>_

<plug-in_version>.jar"overWriteIfExists="yes" mod="755" uninstall="yes" />

</jarFiles><propertiesFiles><file name="files/<plug-in_name>.properties" /></propertiesFiles></deploy>

</plugin>

インストール方法の選択追加プラグインは、このセクションで説明する方法のいずれかを使用してインストールできます。追加プラグインをインストールするには、次のいずれかの手順を使用してください。別のプラグインをインストールする場合は、インストール手順を再度開始してください。

インストール・ウィザードサポートされているオペレーティング・システムごとに個々のセットアップ・ファイルを実行して、既存のインストール済み環境に追加プラグインを


インストールします。詳しくは、『インストール・ウィザードの使用によるインストール』を参照してください。

サイレント・インストールインストールの際に使用されるすべての構成設定を追加して、応答ファイルをカスタマイズします。その後、コマンド行から setup コマンドを実行します。この手順により、無人のインストールをバックグラウンドで実行することができます。詳しくは、 129ページの『サイレント・インストールを使用したインストール』を参照してください。

インストール・プロセスを開始する前に、 126ページの『インストール前』に説明されているように、ファイル <plug-in_namespace>.<plug-in id>_<plug-

in_version>.zip が作成されていることを確認します。

注: インストールされたプラグインを正しく使用するには、まず WebSphere

Application Server、Tivoli Workload Scheduler エージェント、またはその両方を再始動する必要があります。

インストール・ウィザードの使用によるインストール

追加プラグインをインストールするには、次の手順を実行します。

1. Tivoli Workload Scheduler フィックスパック 1 の DVD または eImage から、インストールを行うオペレーティング・システムの setup インストール・コマンドを実行します。これは /PLUGIN_INSTALLER ディレクトリーにあります。インストールが開始します。

2. ウィザードに表示する言語を選択して「OK」をクリックします。「Welcome」パネルが表示されます。

3. このパネルに記載されている情報を確認し、「次へ」をクリックします。「操作」パネルが表示されます。

4. 「インストール」ラジオ・ボタンを選択します。「次へ」をクリックします。zip ファイルのロケーション・パネルが表示されます。

5. zip ファイル <plug-in_namespace>.<plug-in id>_<plug-in_version>.zip があるワークステーション上のパスを選択します。

インストール・プログラムが、この指定したパスで zip ファイルを検出しないと、アクションを実行することはできません。

6. 「次へ」をクリックします。プラグインの詳細パネルが表示されます。

7. プラグインの詳細を確認し、「次へ」をクリックします。プラグインのソフトウェア使用許諾契約書パネルが表示されます。

8. プラグインのソフトウェア使用許諾契約書の内容を確認し、ラジオ・ボタンを選択して契約内容に同意します。「次へ」をクリックします。要約情報のパネルが表示されます。

9. zip ファイル <plug-in_namespace>.<plug-in id>_<plug-in_version>.zip のインストール先のワークステーションで Tivoli Workload Scheduler を選択します。

インストール・プログラムが Tivoli Workload Scheduler のインスタンスを検出しないと、アクションを実行することはできません。


10. 要約の詳細を確認して、「インストール」をクリックします。インストール・プロセスが開始します。進行状況パネルが表示され、状況が示されます。

エラー・メッセージが表示された場合は、表 132ページの表 8 に示されているインストール・ログ・ファイルを分析します。

サイレント・インストールを使用したインストール

サイレント・インストールは、応答ファイルに設定されたパラメーターに従って実行されます。応答ファイルには、ユーザー介入なしでインストールを実行するために必要なすべてのインストール情報が含まれています。

サイレント・インストールで追加プラグインをインストールするために、次の応答ファイルが製品 DVD の PLUGIN_INSTALLER/RESPONSE_FILE に用意されています。

TWS_Plug-ins_RespFile_<operatingsystem>.txt

ここで、<operatingsystem> には unix または windows を指定できます。

これはテンプレート・ファイルなので、インストールする追加プラグインを反映するようにカスタマイズできます。

注: サイレント・インストールでは、プラグインを 1 つずつインストールできます。

サイレント・モードでインストールを実行する場合、メッセージは表示されません。メッセージは、 131ページの『インストールのアクションとログ・ファイル』にリストされているサイレント・インストール・ログ・ファイルに書き込まれます。サイレント・インストールが失敗した場合は、セクション、 228ページの『Tivoli Workload Scheduler for Additional Plug-ins サイレント・インストールの戻りコードの分析』にあるログ・ファイルを調べることによって、それらに書き込まれたメッセージを確認できます。

サイレント・インストールを実行するには、以下の手順を実行します。

1. 応答ファイルを作成するか、インストールを完了するために必要なオプションを含めるように応答ファイルをカスタマイズします。

TWS_Plug-ins_RespFile_<operatingsystem>.txt

これらのオプションのリストについては、 130ページの表 7 を参照してください。

応答ファイルには、インストールを実行するワークステーションからアクセスできることが必要です。応答ファイル内の項目の書式は、option=value です。各項目は別々の行に作成する必要があります。

2. ご使用のオペレーティング・システム用の製品 DVD を挿入し、setup コマンドを実行します。このコマンドは、PLUGIN_INSTALLER/ ディレクトリーにあります。

UNIX および Linux オペレーティング･システムの場合:

./setup.sh -i silent -f response_file



setup.bat -i silent -f response_file

各部の意味は、次のとおりです。

-i silentインストールが応答ファイルによって無人で実行されることを指定します。

-f response_file

インストール・オプションを含む応答ファイルの完全修飾パスを指定します。response_file はテキスト・ファイルで、名前および拡張子を自由に選択できます。

インストールで実行されるアクションについては、 131ページの『インストールのアクションとログ・ファイル』を参照してください。

表 7 に、インストールを実行するために指定できるオプションを示します。

表 7. サイレント・インストールを実行するオプション

オプション必須説明値

USER_INSTALL_DIR=<path> はい追加プラグインのインストール先のTivoli Workload

Scheduler インストール・パスを指定します。

完全修飾パス。例えば、c:¥program Files¥IBM¥TWA86

下に製品をインストールするには、次のように指定します。

USER_INSTALL_DIR="c:¥program Files¥IBM¥TWA86"

製品ファイルは、次の場所にインストールされます。

c:¥program Files¥IBM¥TWA86¥methods


デフォルトのパスは"c:¥¥Program

Files¥¥IBM¥¥TWA"

です。


デフォルトのパスは/opt/IBM/TWA です。


表 7. サイレント・インストールを実行するオプション (続き)


TWSAPPS_PLUGIN_FILE_NAME=<zip-filename> はいインストールする追加プラグインを含むzip ファイルの完全修飾パスを指定します。

完全修飾パス。例えば、C:¥Documents and

Settings ¥Administrator¥

Desktop¥PLUGINS¥

にある追加プラグイン<test_plug-in>.zip をインストールするには、次のように指定します。

TWSAPPS_PLUGIN_FILE_NAME=C:¥Documents and Settings¥Administrator¥Desktop¥PLUGINS¥<test_plug-in>.zip

LICENSE_ACCEPTED=<value> はいブール値を指定して、追加プラグインの使用許諾契約書に同意します。

値には、true または false を指定できます。ただし、値をtrue に設定してもプラグインのインストールは続行します。

ACTION_TYPE=<value> はいインストール・プロセスがプラグインに対して実行するアクションを指定します。この場合、値はDEPLOY に設定する必要があります。

値は DEPLOY に設定する必要があります。

次に、応答ファイル TWSPlug-ins_RespFile_UNIX.txt を使用して、UNIX ワークステーションでサイレント・インストールを実行するために実行するコマンドの例を示します。

./setup.sh -i silent -f /tmp/TWSPlug-ins_RespFile_unix.txt

次に、Windows ワークステーションに zip ファイル <plug-in>.zip に含まれている追加プラグインをインストールする応答ファイルの例を示します。

USER_INSTALL_DIR="c:¥¥Program Files¥¥IBM¥¥TWA"TWSAPPS_PLUGIN_FILE_NAME=C:¥Documents and Settings¥Administrator¥Desktop¥PLUGINS¥<plug-in>.zip

インストールのアクションとログ・ファイルこのセクションでは、追加プラグインのインストール・プロセスのアクションとインストールのログ・ファイルについて説明します。

追加プラグインのインストールは、次の Tivoli Workload Scheduler インスタンスで実行できます。


v バックアップ・マスター・ドメイン・マネージャー

v 動的ドメイン・マネージャー

v バックアップ動的ドメイン・マネージャー

v エージェント


v Java 拡張がインストールされているフォールト・トレラント・エージェント

zip ファイルの構造については、 127ページの『追加プラグインの構造』を参照してください。

インストールでは、すべての Tivoli Workload Scheduler ワークステーション・タイプ用の zip ファイル <plug-in_namespace>.<plug-in id>_<plug-in_version>.zip

の内容に対して次のアクションが実行されます。

v ファイル plugin.xml を plugin_<plugin_name>.xml として、選択されているTivoli Workload Scheduler インスタンスのディレクトリー <TWA_HOME>/

installDataPlugins にコピーします。

v ファイル /files/<plug-in_name>.properties を、選択されている Tivoli

Workload Scheduler インスタンスのディレクトリー <TWA_HOME>/TWS/JavaExt/

eclipse/configuration にコピーします。

v ファイル /files/<plugin_namespace>.<plug-in_id>_<plugin_version>.jar を、選択されている Tivoli Workload Scheduler インスタンスのディレクトリー<TWA_HOME>/TWS/JavaExt/eclipse/configuration にコピーします。

v /files/licenses ディレクトリー内のすべてのファイルを、選択されているTivoli Workload Scheduler インスタンスのディレクトリー <TWA_HOME>/license/

<plug-in_id> にコピーします。

インストールでは、特定のワークステーション・タイプ用の zip ファイル<plug-in_namespace>.<plug-in id>_<plug-in_version>.zip の内容に対して次のアクションも実行されます。

v マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、動的ドメイン・マネージャー、およびバックアップ動的ドメイン・マネージャーでは、ファイル files/<plugin_namespace>.<plug-

in_id>_<plugin_version>.jar も、選択されている Tivoli Workload Scheduler インスタンスのディレクトリー <TWA_HOME>/TWS/applicationJobPlugins にコピーします。

v Tivoli Workload Scheduler for z/OS コネクターでは、ファイルfiles/<plugin_namespace>.<plug-in_id>_<plugin_version>.jar も、選択されている Tivoli Workload Scheduler インスタンスのディレクトリー<TWA_HOME>/TWSZOS/applicationJobPlugins にコピーします。

エラー・メッセージが表示された場合は、表 8 に示されているインストール・ログ・ファイルを分析します。


ログ・ファイル名内容ディレクトリー

tws4plugins_ia_install.log InstallAnywhere エラーの追加プラグイン・ログ・ファイル。

Tivoli Workload

Scheduler_installation_dir¥logs


表 8. インストール・ログ・ファイル (続き)


tws4plugins_install.log 追加プラグイン・インストール・ログ・ファイル。

インストール・プロセスの開始時に、このログ・ファイルは次のディレクトリーに作成されます。


%TEMP%¥twa¥tws4apps


$tmp¥twa¥tws4apps

その後、インストール・プロセスの終了時にディレクトリー Tivoli

Workload

Scheduler_installation_dir¥logs にコピーされます。

tws4plugins_status.log 追加プラグインのインストール状況ログ・ファイルは、サイレント・インストールの場合にのみ作成されます。インストールが正常に完了したか、エラーが発生したかを報告します。エラーの場合、エラーの原因が、誤ったフィールド値にあるのか、手順の失敗にあるのかを示します。

インストール・プロセスの開始時に、このログ・ファイルは次のディレクトリーに作成されます。


%TEMP%¥twa¥tws4apps


$tmp¥twa¥tws4apps

その後、インストール・プロセスの終了時にディレクトリー Tivoli

Workload


注: サイレント・モードでのインストールでログ・ファイルを表示する必要がある場合は、最初に tws4plugins_status.log ファイルでインストール・プロセス状況を確認してから、詳細について tws4plugins_install.log ファイルを調べてください。

アップグレード

この章では、Tivoli Workload Scheduler をバージョン 8.3 以上から現行バージョンにアップグレードする方法について説明します。この章は、以下のセクションに分かれています。

v 134ページの『エンジンの共存およびアップグレードに関する注意事項』

v 70ページの『ユーザー許可要件』

v 136ページの『前提条件の検査 (UNIX および Linux)』

v 136ページの『マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインスタンスのアップグレード』


v 168ページの『エージェントおよびドメイン・マネージャーのアップグレード』

v 186ページの『コマンド行クライアントのアップグレード』

v 187ページの『レジストリー・ファイルが破損している場合のアップグレード』

v 190ページの『機能の追加』

注: データベース管理者がデータベースに関するすべての機密情報 (データベース管理者のユーザー ID/パスワードなど) を管理していて、製品をアップグレードする IT 管理者はその機密情報を知らない場合に限り、 43ページの『インストールまたはアップグレード前の Tivoli Workload Scheduler データベース表の作成またはアップグレード』で説明されている手順を実行します。

エンジンの共存およびアップグレードに関する注意事項

このセクションでは、前のバージョンとの共存およびアップグレードの可能性について記載します。

前のバージョンとの共存

<TWS_user>、nm ポート、およびインストール・パスのすべてが前のバージョンと異なれば、Tivoli Workload Scheduler 分散エンジンの現行バージョンは、前のバージョンを含むワークステーションにインストールできます。

既存のバージョンのアップグレード

Tivoli Workload Scheduler ネットワークのアップグレードは、トップダウンまたはボトムアップで実行できます。これらの方法の利点と欠点については、 137ページの『ネットワークのマイグレーション方法の選択』で説明しています。

表 9 に、現行バージョンにアップグレード可能な Tivoli Workload Scheduler コンポーネントのバージョンを示します。

表 9. Tivoli Workload Scheduler コンポーネントのアップグレードの可用性

コンポーネントバージョン推奨される最小フィックスパック・レベル

マスター・ドメイン・マネージャーバックアップマスター・ドメイン・マネージャーフォールト・トレラント・エージェント

8.3 7 以降

8.4 GA 以降

8.5 GA 以降

8.5.1 GA 以降

コマンド行クライアント 8.5.1 GA 以降

コネクターバージョン 8.3 からのアップグレードが可能

v これより低いフィックスパック・レベルの Tivoli Workload Scheduler コンポーネントをご使用の場合は、指定されているレベル以上のフィックスパックをインストールしてください。

v 表 9 でサポートされていない以前のバージョンから Tivoli Workload Scheduler コンポーネントを使用する場合は、最新のコンポーネントのフレッシュ・インストールによってそれらを置換すること、またはそれらを以下のようにアップグレードすることを検討してください。


1. コンポーネントを、サポートされるいずれかのアップグレード・プラットフォームにアップグレードします。その際、該当するプラットフォーム用のアップグレード・プログラムを使用し、資料に記載された手順に従います。

2. 134ページの表 9 に示すように、必要なフィックスパックを適用します。

3. 現行バージョンにアップグレードします。

アップグレード時に変更されるファイルとフォルダー

アップグレード・プロセスでは、以下のフォルダーとファイルが変更されます。

UNIX および Linux オペレーティング・システムの場合:/etc/TWS/etc/TWA/.swdis (This is the default Software Distribution directory.

The product changes the directory specified inthe product_dir property inthe /etc/Tivoli/swdis.ini file.)

/usr/Tivoli/TWStws_home

Windows オペレーティング・システムの場合:%windir%¥TWA%windir%¥system32¥TWS*Registry.datC:¥swdis (This is the default Software Distribution directory.

The product changes the directory specified inthe product_dir property inthe %windir%¥swdis.ini file.)

tws_home












|

|

|

|

|

|

|

|

|

|

|

|

|


前提条件の検査 (UNIX および Linux)

UNIX と Linux のオペレーティング・システムでアップグレードの準備をする場合は、Tivoli Workload Scheduler が前提条件検査をシステムで自動的に実行します。Tivoli Workload Scheduler システム要件を満たす環境を持つことによって、遅延や混乱がなくアップグレードが成功するようになります。

注: 前提条件チェックは、ソフトウェア配布インストール方式を使用している場合は使用不可であり、UNIX および Linux オペレーティング・システム上のみで使用可能です。

前提条件チェックは以下を検証します。

v オペレーティング・システムが製品によってサポートされていること。

v 必要なエンジン・ソフトウェア・パッチ・レベルがインストールされていること。

v 必要なカーネル・パラメーターが正しく構成されていること。

注: 前提条件チェックは、環境が Tivoli Workload Scheduler の要件を満たしているかどうかのみを検査します。DB2 などのその他のコンポーネントのインストール要件は検査しません。

この検査の詳細な説明については、 28ページの『前提条件の検査 (UNIX およびLinux)』を参照してください。

マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインスタンスのアップグレード

このセクションでは、マスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーをアップグレードする方法を説明します。

このセクションは、次の項目に分かれています。

v 『アップグレードの概要』

v 145ページの『アップグレードの準備』

v 147ページの『新規ディレクトリー構造』

v 150ページの『直接アップグレードの実行』

v 163ページの『並列アップグレードの実行』

アップグレードの概要

このセクションでは、Tivoli Workload Scheduler V8.3 以降のインスタンスの既存のバージョンのアップグレードについて概説します。この章は、以下のセクションに分かれています。

v 137ページの『ネットワークのマイグレーション方法の選択』

v 137ページの『コンポーネントのアップグレード手順』


v 138ページの『並列アップグレードまたは直接アップグレード』

v 140ページの『認証の更新』

v 144ページの『セーフ・アップグレードの実行』

注: バージョン 8.5 からアップグレードする場合、Tivoli Workload Automation のインスタンス全体をアップグレードする必要があります。Tivoli Workload

Automation インスタンスについて詳しくは、 32ページの『Tivoli Workload

Automation のインスタンス』を参照してください。

Tivoli Workload Automation のインスタンスをアップグレードするには、そのインスタンスを構成しているすべてのコンポーネントをアップグレードする必要があり、最初に Tivoli Workload Scheduler のコンポーネントから開始します。例えば、ご使用のインスタンスにマスター・ドメイン・マネージャーが 1 つとDynamic Workload Console も含まれている場合、これら両方のコンポーネントをアップグレードする必要がありますが、最初にマスター・ドメイン・マネージャーをアップグレードしてから、次に Dynamic Workload Console をアップグレードする必要があります。

ネットワークのマイグレーション方法の選択:

Tivoli Workload Scheduler は後方互換性をサポートしているため、以下の方法のどちらかでネットワークをアップグレードすることを決定できます。

トップダウンマスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーをアップグレードしてから、エージェントをプログレッシブにアップグレードします。現行バージョンに導入された新機能の大半を各エージェントで利用できるのは、各エージェントをアップグレードしたときになります。欠点は、同じ機能がすべてのエージェントに対して同時には使用可能にならないことです。V8.5 より前のエージェントに新規セキュリティー・ファイルを配布する場合でも、アップグレードするまでは機能しません。 V8.5 より古いエージェントはすべてアップグレードする必要があります。

ボトムアップまずエージェントをアップグレードし、それからマスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーをアップグレードします。現行バージョンに導入された新機能は、ネットワーク全体をアップグレードするまでは使用できません。

コンポーネントのアップグレード手順:

138ページの図 11 は、Tivoli Workload Scheduler を現行バージョンにアップグレードするために実行できるステップのフローチャートです。直接アップグレードと並列アップグレードでは、異なるパスをたどることに注意してください。これらのオプションは、以下のチャートで詳細に説明します。

このフローチャートでは、以下の頭字語が使用されています。

MDM マスター・ドメイン・マネージャー

BKM バックアップマスター・ドメイン・マネージャー


並列アップグレードまたは直接アップグレード:

いいえ

はいはい

BKM?がFGするか

BKM?がFGするか

Kしいをインストールする

BKMKしいをインストールする

BKM

BKMをアップグレードする


OPQRをに

コピーするBKMOPQRを

にコピーする

BKM

OPQRをに

マイグレーションするBKMOPQRを

にマイグレーションする

BKM

スイッチ・マネージャーをU�する

スイッチ・マネージャーをU�する

VWサイクルでアップグレードをYZできるか?

VWサイクルでアップグレードをYZできるか?

Kしいをインストールする

BKMKしいをインストールする

BKM


BKMをアップグレードする \]のデータベースでKしい

を^_し、abによってはブローカーをghする

BKM\]のデータベースでKしいを^_し、abによってはブローカーをghする

BKM

ij

スケジューリング・プロセスをghする

スケジューリング・プロセスをghする

V8.3 V8.4またはV8.3 V8.4または

はいはい

いいえ

l�

はいはい

はいはい

MDM BKMとをアップグレードするMDM BKMとをアップグレードする

いいえ

U�nのからpqするMDMU�nのからpqするMDM

アップグレード・タイプ?


BKM?がFGするか

BKM?がFGするか

MDMSymphony

BKM

でVWをrsRして、ファイルを

にuvする

MDMSymphony

BKM

でVWをrsRして、ファイルを

にuvする

スイッチ・マネージャーをwxyする(*)

スイッチ・マネージャーをwxyする(*)

MDMをアップグレードするMDMをアップグレードする

スイッチ・マネージャーをU�して、

アップグレードzのにスイッチバックするMDM

スイッチ・マネージャーをU�して、

アップグレードzのにスイッチバックするMDM

2{|のスイッチ・マネージャーをwxyする

2{|のスイッチ・マネージャーをwxyする

}~のスイッチ・マネージャーをwxyしたか

(*)?

}~のスイッチ・マネージャーをwxyしたか

(*)?

どのバージョンをアップグレード

するか?

どのバージョンをアップグレード

するか?

V8.4 V8.5とのK��のセキュリティー・ファイルをアップグレードする

V8.4 V8.5とのK��のセキュリティー・ファイルをアップグレードする

スケジューリング・プロセスをrpする

スケジューリング・プロセスをrpする

��バージョンにアップグレードされた

とMDM BKM

��バージョンにアップグレードされた

とMDM BKM

V8.5\�V8.5\�

\]の�Gの

をアップグレードする

MDM( BKM)\]の�Gの

をアップグレードする

MDM( BKM)

いいえ

ij

l�



図 11. アップグレード手順のフローチャート


マスター・ドメイン・マネージャーおよびバックアップ・マスター・ドメイン・マネージャーをアップグレードする前に、考慮する要因がいくつかあります。このセクションでは、これらの要因を説明し、選択する必要がある使用可能なアップグレード・シナリオの概要を示します。

v 『直接アップグレードのシナリオ - アップグレード時間の最小化』

v 『並列アップグレードのシナリオ - スケジューリングへの影響の最小化』

さまざまな点を考慮し、IBM は、特に、V8.5 または V8.5.1 からアップグレードする場合、予期しない問題が発生した場合にバックアップ・マスター・ドメイン・マネージャーを使用できることを想定し、直接アップグレード・シナリオが望ましいオプションであると考えます。ただし、両方のシナリオが詳細に説明され、サポートされているので、ユーザーはご使用のスケジューリング環境における業務での個別の要因について考慮し、独自の選択を行う必要があります。

直接アップグレードのシナリオ - アップグレード時間の最小化:

直接アップグレードのシナリオを使用すれば、現在の環境を速やかにアップグレードでき、手操作による介入を減らすことができます。この手順では、提供した入力データを使用してネットワークおよびデータベースの情報を自動的にアップグレードします。インストール・ウィザードはプロセス全体をガイドするため、このタイプのアップグレードにアプローチする最もシンプルな方法です。

表 10. 直接アップグレードのシナリオ

ステップ利点欠点

1. 古いマスター・ドメイン・マネージャーをリンク解除した後、停止します。

2. マスター・ドメイン・マネージャーをアップグレードして、スケジューリングおよび構成データを前のバージョンから自動的にインポートします。

3. 新旧のセキュリティー設定をマージして、セキュリティー構成を完全なものにします。

4. バックアップ・マスター・ドメイン・マネージャーをアップグレードします。

v 並列アップグレードよりも高速かつシンプルです。

v マスター・ドメイン・マネージャーを含むアクティビティーについて、スケジューリングが遅延することがあります。

ただし、アップグレードが失敗し、マスター・ドメイン・マネージャーが使用可能な状態ではなくなった場合に、バックアップ・マスター・ドメイン・マネージャーをインストール済み、テスト済み、およびすぐに引き継ぎ可能な状態にしておくことを強くお勧めします。

並列アップグレードのシナリオ - スケジューリングへの影響の最小化:

並列アップグレードを使用すれば、新しい環境に確信を持つまで前のマスター・ドメイン・マネージャーの保全性を維持できます。アップグレードが段階的に行われることで、古い環境を共存させて作業することが可能です。

以下のセクションで説明する並列シナリオでは、既存のバックアップ・ドメイン・マネージャーをアップグレードするか、新規 Tivoli Workload Scheduler バックアッ


プ・ドメイン・マネージャーをインストールすることにより開始されます。新規またはアップグレードされたバックアップ・マスター・ドメイン・マネージャーは、次に旧マスター・ドメイン・マネージャーの役割を担います。その後、この新しい環境を永続させるかどうか選択できます。あるいは、旧マスター・ドメイン・マネージャーを元の役割にアップグレードおよび復元することができます。

この操作手順は、サービス休止時間を最小化し、データ保全性を確保するために設計されています。並列アップグレードにはいくつかの手動ステップが含まれていますが、現在の環境の保全性を維持するという利点があります。

表 11. 並列アップグレードのシナリオステップ利点欠点

1. バックアップ・マスター・ドメイン・マネージャーが既にあるかどうかに応じて、以下のいずれかを実行します。

v 既存のデータベースを参照している現行のバックアップ・マスター・ドメイン・マネージャーをアップグレードします。

v 既存のデータベースを指すフレッシュ・バックアップ・マスター・ドメイン・マネージャーをインストールします。ユーザー認証構成も新しいバックアップ・マスター・ドメイン・マネージャーにマイグレーションする必要があります。

2. マネージャーを新規バックアップ・マスター・ドメイン・マネージャーに切り替えます。

3. スイッチ・マネージャーを永続化します。

4. この時点で、ご使用のバックアップ・マスター・ドメイン・マネージャーは新しい環境のマスター・ドメイン・マネージャーになります。次のステップに進む前に、旧マスター・ドメイン・マネージャーをどう処理するかを決定してください。以下の 3 つから選択できます。

v 新規マネージャーを新規環境のマスター・ドメイン・マネージャーとして保持し、旧マスター・ドメイン・マネージャーをフル状況エージェントとして保持して、後でこれを新規バージョンにアップグレードします。新規バックアップ・マスター・ドメイン・マネージャーをインストールし、それを構成します。

v 新規マネージャーを新規環境のマスター・ドメイン・マネージャーとして保持し、古いマスターをアップグレードして新規バックアップ・マスター・ドメイン・マネージャーにします。

v 古いマスター・ドメイン・マネージャーをアップグレードして、元の構成を新しい環境に復元します(これは 138ページの図 11 に示した手順です)。

5. スイッチバックし、元のスイッチが永続化されていた場合、スイッチバックも同様に永続化する必要があります。

6. 新旧のセキュリティー設定をマージして、セキュリティー構成を完全なものにします。

v 古いマスターと新しい環境の共存を許可します。

v 新規のマスター・ドメイン・マネージャーのために、パフォーマンスの良好な新規プラットフォームの選択を許可します。

v この処理は元に戻すことができます。

v 新旧のバージョンについて完全に互換性のあるデータベース・スキーマを自動的に更新します。

v 高い度合いの柔軟性を許可します。古いマスター・ドメイン・マネージャーのアップグレードを行わないという選択も可能です。

v 並列アップグレードの実行と同時に、ハードウェアのアップグレードも簡単に行えます。

v 手動の構成ステップが含まれます。

認証の更新:


このセクションでは、構成された認証メカニズムがどのようにアップグレードされるかを説明します。

V8.6 より前のバージョンの Tivoli Workload Scheduler では、認証はスタンドアロン・ユーザー・レジストリーを使用して構成され、組み込み WebSphere Application

Server によって管理されていました。使用可能なオプションは以下のとおりでした。

v ローカル・オペレーティング・システム

v カスタム (PAM - プラグ可能認証モジュール経由)

v LDAP

v ファイル・レジストリー

LDAP を有効にした場合、以下のサーバーのいずれかを使用できました。

v IBM Tivoli Directory Server

v Sun ONE

v Microsoft Windows Active Directory

v IBM Tivoli Directory Server 上で構成された RACF®

Tivoli Workload Scheduler V8.6 以降のバージョンは、VMM (Virtual Member

Manager) モードで (組み込み WebSphere Application Server を通して) 認証のために構成されます。これによって、複数のユーザー・レジストリーの同時使用をサポートする、フェデレーテッド・ユーザー・レジストリーが作成されます。ユーザー・レジストリーの選択項目と LDAP サーバーのオプションは、V8.6 より前のバージョンの場合とほぼ同じです。

ただし、フェデレーテッド・ユーザー・レジストリーの実装には、現在使用しているスタンドアロン構成とは異なる構成が必要です。

アップグレードの際に、既存の構成はマイグレーションされるため、アップグレードが完了したときに、製品は以前と同じ認証メカニズムを使用するように構成されますが、それはフェデレーテッド・ユーザー・レジストリーの内部になります。手順は、アップグレードをどのように実行するかに応じてわずかに異なります。 138

ページの図 11 を参照すると、3 つの可能性があることがわかります。

既存のマスター・ドメイン・マネージャーの直接アップグレードこのシナリオでは、アップグレード・ウィザードまたはコマンドが、ご使用の認証メカニズムをフェデレーテッド・ユーザー・レジストリーに対して再構成しようとします。これを行うことに失敗しても、その他のすべての点においてアップグレードが正常に行われる場合、アップグレードされたマスター・ドメイン・マネージャーは、スタンドアロン・ユーザー・レジストリーを使用して構成されます。ただし、これは、マスター・ドメイン・マネージャーにアクセスできるようにするための一時的な手段で、問題を解決する必要があり、他のコンポーネントがアップグレードまたはインストールされる前に構成をフェデレーテッド・ユーザー・レジストリーにマイグレーションする必要があります。

新規バックアップ・マスター・ドメイン・マネージャーのインストールによる並列アップグレード

このシナリオでは、新規バックアップ・マスター・ドメイン・マネージャー


をインストールした後に、認証メカニズムを古いマスター・ドメイン・マネージャーから新しいバックアップ・マスター・ドメイン・マネージャーに手動でマイグレーションする必要があります。したがって、新規バックアップ・マスター・ドメイン・マネージャーが新規マスター・ドメイン・マネージャーになるように切り替えられると、それは現在選択済みの認証メカニズムに対して既に構成されています。マイグレーションでは、マスター・ドメイン・マネージャー上の認証構成をテキスト・ファイルにエクスポートし、それをバックアップ・マスター・ドメイン・マネージャーにインポートする必要があります。これは、WebSphere Application Server ツールを使用して行われます。

既存のバックアップ・マスター・ドメイン・マネージャーのアップグレードによる並列アップグレード

このシナリオでは、既存のバックアップ・マスター・ドメイン・マネージャーは、ご使用のマスター・ドメイン・マネージャーと同じユーザー認証を使用して既に構成されています。アップグレード・ウィザードまたはコマンドは、フェデレーテッド・ユーザー・レジストリーに対して認証メカニズムを再構成しようとします。これを行うことに失敗しても、その他のすべての点においてアップグレードが正常に行われる場合、アップグレードされたバックアップ・マスター・ドメイン・マネージャーは、スタンドアロン・ユーザー・レジストリーを使用して構成されます。ただし、これは、バックアップ・マスター・ドメイン・マネージャーにアクセスできるようにするための一時的な手段で、問題を解決する必要があり、他のコンポーネントがアップグレードまたはインストールされる前に構成をフェデレーテッド・ユーザー・レジストリーにマイグレーションする必要があります。

RACF の考慮事項:

Tivoli Workload Scheduler V8.6 より前のバージョンでは、RACF 認証は IBM

Tivoli Directory Server を使用して構成されており、これを行う方法の指示は文書で提供されていました。V8.6 にアップグレードすると、この構成もアップグレードされ、引き続き使用できるようになります。ただし、フェデレーテッド・ユーザー・レジストリーは、アップグレードが完了した後に構成できる z/OS Integrated

Security Services LDAP Server をサポートします。

スタンドアロン・リポジトリーとフェデレーテッド・リポジトリーのキーワード間のマッピング:

WebSphere Application Server を使用する既存のコンポーネントをアップグレードすることにより、またはスタンドアロン環境からフェデレーテッド環境にご使用の構成をエクスポートすることにより、ご使用のスタンドアロン・ユーザー・レジストリーをアップグレードすると、製品は既存の構成キーワードを新しい構造にマップします。これは、以下のルールに従って行われます。

v 古いキーワードのみが存在する場合、これらのキーワードは新しいキーワードを構成するために使用されます。

v 古いキーワードと新しいキーワードが両方とも存在する場合は、古いキーワードが破棄され、新しいキーワードだけが使用されます。

v セキュリティー構成をスタンドアロン・リポジトリーに基づいて抽出するためにshowSecurityProperties WebSphere Application Server ツールが使用される場


合、再インポートされると、ファイル内のそのデータがVMM セキュリティーを有効にするために使用され、スタンドアロン・リポジトリーは無効にされる旨ユーザーに通知する警告が出されます。

v フェデレーテッド・リポジトリーでは LDAPreuseConnection プロパティーはサポートされておらず、存在する場合は破棄されます。

v 古い LDAP ユーザー検索フィルターが指定されている場合は、以下のように新しいユーザー検索フィルターに変換されます。ここで説明する個々のプロパティーについて詳しくは、「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

LDAPUserFilter=(&(|(mail=%v)(cn=%v))(objectclass=ePerson))すべてのパラメーター (「mail=%」や「cn=%v」など) が検索フィルターから削除され、セミコロン「;」で区切られて「LDAPloginProperties」に追加されます (まだ存在しない場合)。これらの変数は、フェデレーテッド LDAP 検索フィルターでサポートされていないからです。この新しい構成では、VMM は「%v」などの置換パラメーターをサポートしていません。VMM では、メールを指定された値に置換するフィルターは、フェデレーテッド・リポジトリー内で構成されている LDAP レジストリーに対して指定されたログイン・プロパティーに応じて、アプリケーション・サーバーへのログインの際に VMM ランタイムによって適用されます。残りの値は LDAPUserSearchFilter に追加されます。すべての値(objectclass=ePerson、objectclass=...... など) は、セミコロン「;」で区切られ、キーワード「objectclass」のない状態で、LDAPUserObjectClasses に追加されます。

LDAPGroupFilter=(&(cn=%v)(ou=memberlist)(ou=ibmgroups)(o=ibm.com)(objectclass=groupOfUniqueNames))

すべてのパラメーター (「cn=%v」など) は検索フィルターから削除され、(まだ存在しない場合は) セミコロンで「;」で区切られて「LDAPloginProperties」に追加されます。これらの変数がフェデレーテッド LDAP 検索フィルターではサポートされていないためです。この新しい構成では、VMM は「%v」などの置換パラメーターをサポートしていません。VMM では、メールを指定された値に置換するフィルターは、フェデレーテッド・リポジトリー内で構成されている LDAP レジストリーに対して指定されたログイン・プロパティーに応じて、アプリケーション・サーバーへのログインの際に VMM ランタイムによって適用されます。残りの値は LDAPGroupSearchFilter に追加されます。すべての値(objectclass=groupOfUniqueNames、objectclass=...... など) は、セミコロン「;」で区切られ、キーワード「objectclass」のない状態で、LDAPGroupObjectClasses に追加されます。

LDAPUserIdMap=*:cnマッピングの最初の部分が「*」ではなく、この値が「LDAPloginProperties」に存在する場合、マッピングの 2 番目の部分(この場合「cn」) を使用して「LDAPloginProperties」に置換されます。

LDAPGroupIdMap=*:cnマッピングの最初の部分が「*」ではなく、この値が「LDAPloginProperties」に存在する場合、マッピングの 2 番目の部分(この場合「cn」) を使用して「LDAPloginProperties」に置換されます。


LDAPGroupMemberIdMap=groupOfNames:member;groupOfUniqueNames:uniqueMember

このセミコロン「;」で区切られた値のシーケンスは、解析され、値のペアの最初のエレメントが「LDAPGroupConfigMemberClasses」に追加され、同時に 2 番目のエレメントが「LDAPGroupConfigMemberNames」に追加されます。

– サーバー・タイプが IDS である場合、「LDAPGroupConfigMemberScopes」が「all」に設定され、「LDAPGroupConfigName」が「ibm-allGroups」に設定されます。

– サーバー・タイプが AD である場合、「LDAPGroupConfigMemberScopes」が「direct」に設定され、「LDAPGroupConfigName」が「memberOf」に設定されます。

例:

スタンドアロン構成:LDAPServerType=IBM_DIRECTORY_SERVERLDAPUserFilter=(&(|(mail=%v)(cn=%v))(objectclass=ePerson))LDAPGroupFilter=(&(cn=%v)

(ou=memberlist)(ou=ibmgroups)(o=ibm.com)(objectclass=groupOfUniqueNames))

LDAPUserIdMap=*:cnLDAPGroupIdMap=*:cnLDAPGroupMemberIdMap=groupOfNames:member;groupOfUniqueNames:uniqueMember

フェデレーテッド構成LDAPServerType=IDSLDAPloginProperties=mail;cnLDAPUserEntityType=PersonAccountLDAPUserObjectClasses=ePersonLDAPUserSearchFilter=(objectclass=ePerson)LDAPGroupEntityType=GroupLDAPGroupObjectClasses=groupOfUniqueNamesLDAPGroupSearchFilter=(&(ou=memberlist)

(ou=ibmgroups)(o=ibm.com)(objectclass=groupOfUniqueNames))

LDAPGroupConfigName=ibm-allGroupsLDAPGroupConfigScope=allLDAPGroupConfigMemberNames=member;uniqueMemberLDAPGroupConfigMemberClasses=groupOfNames;groupOfUniqueNamesLDAPGroupConfigMemberScopes=all;allLDAPGroupConfigMemberDummies=uid=dummy;

changeSecurityProperties の出力:

changeSecurityProperties スクリプトがアップグレードの一部としてアップグレード・ウィザードによって実行された場合でも、手動で実行された場合でも、そのスクリプトの出力には、多くの情報メッセージ、警告メッセージ、エラー・メッセージが含まれています。「Tivoli Workload Scheduler: 管理ガイド」にあるchangeSecurityProperties の出力に関するセクションを参照してください。

セーフ・アップグレードの実行:

並列モードでアップグレードしている場合は、すべての実行中のプロセスを中断しません。ただし、直接モードでアップグレードしている場合は、アップグレードを


実行している最中に、実行中のプロセスを中断します。この中断がこれらの実行中のプロセスの保全性にリスクを与えないようにするために、これはセーフ・モードで実行されます。セーフ・モードでは、アップグレードの開始前に以下を実行して、この点を確実にします。

v 現在実行中のコマンド行があるかどうかを検査します。

v ワークステーション上でジョブ・フェンスを go (101) 値に設定して、他のジョブが開始されないようにします。

v 実行中のジョブがあるかどうかを検査します。それがある場合には、60 秒間待機し、再度検査します。この間隔の間にすべてのジョブが完了しない場合、アップグレードは続行されず、エラー・メッセージが表示されます。この値を変更する場合は、セットアップまたはサイレント・インストールを実行するときに分数を指定します。

v 実行中のプロセスがあるかどうかを検査します。ある場合は、それらを停止し、停止処置の完了を待ちます。

これらのすべての検査がパス済みになると、Tivoli Workload Scheduler がアップグレードを始動します。

v Batchman プロセスが再始動した後にアップグレードが正常に完了する場合、Batchman メッセージ・キューとジョブ・フェンス値の Symphony ファイルとは同期しているので、ジョブ・フェンスは元の値に設定されます。ワークステーションでインストール・プロセスが Batchman プロセスを開始せず、元のジョブ・フェンスを設定するには、以下のコマンドを実行します。

conman "start"

v 検査がパスしない、またはエラーが発生するといういずれかの理由によって、アップグレードが正常に完了しない場合は、ジョブ・フェンスは元の値に設定されません。以下を実行する必要があります。

– ジョブ・フェンスを手動でその元の値に設定します。

– 処置を完了するステップを実行するか、エラーを修正してアップグレードを再開します。

注: セーフ・アップグレードは、Software Distribution を使用する場合を除き、すべてのアップグレード方式で使用可能です。

アップグレードの準備

アップグレード・プロセスを開始する前に、必要に応じて以下のタスクを完了します。

新機能のためのセキュリティー・ファイルの構成アップグレード手順を実行する際に、新機能に関してセキュリティー・ファイルを構成する必要があります。セキュリティー・ファイルを構成するには、以下を行う必要があります。

バージョン 8.3 および 8.4 からのアップグレード時におけるデフォルトの変数テーブルの設定

変数テーブルの設定は、バージョン 8.3 以降で必要です。バージョン 8.3 および 8.4 からアップグレードする場合、アップグレードされたセキュリティー・ファイルには、変数テーブル用の新規のデフ


|

|

|

|

|

|

ォルト・ステートメントが組み込まれています。変数テーブルは、複数の変数をグループ化するオブジェクトです。これらのオブジェクトは、前のバージョンではグローバル・パラメーターと呼ばれましたが、バージョン 8.5 以降では変数と呼ばれます。ローカル・パラメーターは以前と同じように管理され、以前のセキュリティー・ファイルにある古いパラメーター・ステートメントは引き続きそのセキュリティー面を管理します。前のデータベースで定義したグローバル・パラメーターは、デフォルトの変数テーブルのエレメントになっており、テーブルのセキュリティー・ステートメントがセキュリティー・ファイルに追加されています。このテーブルに対するユーザー許可をカスタマイズすることを選択できます (デフォルトでは、すべてのユーザーが全許可を持ちます)。

イベント・ドリブン・ワークロード自動化の構成

イベント・ドリブン・ワークロード自動化の構成は、バージョン8.3 にのみ必要です。セキュリティー・ファイルを変更して、イベント管理およびレポート機能についての新しいセキュリティー・ステートメントを組み込む必要があります。固有のセキュリティー設定を V8.3 環境に持つ場合、現行環境用の最終セキュリティー・ファイルを作成する前に、これらの設定を新しい設定と手動でマージする必要があります。手動で追加するステートメントは以下のセクションで説明されるように、セキュリティー設定と、並列アップグレード・シナリオを選択したか、または直接アップグレード・シナリオを選択したかによって異なる場合があります。

データベースのバックアップの実行アップグレード・プロセスを開始する前に、Oracle または DB2 の資料を参照して、現行の Tivoli Workload Scheduler データベースのバックアップを実行します。

データベースの 64 ビットへのアップグレードLinux Intel 32 および HP RISC 以外の任意の UNIX または Linux プラットフォームで直接アップグレードを実行している場合は、ローカル DB2 または Oracle インスタンスを 64 ビット・バージョンにアップグレードする必要があります。

Linux カーネルLD_ASSUME_KERNEL=2.4.1 環境変数を使用する Linux 環境でアップグレードを行う場合は、Tivoli Workload Scheduler の現行バージョンへのアップグレードはやはり LD_ASSUME_KERNEL=2.4.1 環境変数を使用するシェルで行ってください。

現在の Tivoli Workload Scheduler インストール済み環境が正しい状態であることの確認現在の環境をアップグレードしている場合、ソフトウェア・パッケージが

COMMIT 状態であることを確認します。 UNDOABLE 状態の場合、現行バージョンにアップグレードする前にこれを受け入れて、状態を COMMIT に変更する必要があります。状態を確認するには、以下を実行します。

1. <TWA_dir>/TWS/_uninstall/CLI から、必要に応じて swd_env.bat または. . /swd_env.sh コマンドを実行します。

2. コマンド wdlssp を実行します。


3. 以下の行を検索します。

DISSE0164I Name : TWS_LP_twsuserDISSE0165I Version : 8.4.0.00DISSE0166I State : IC---

----------------------------------------

DISSE0164I Name : FP_TWS_WINDOWS_twsuserDISSE0165I Version : 8.4.0.00DISSE0166I State : IC---

4. パッケージの状態が IC であることを確認します。

バックアップ・マスター・ドメイン・マネージャーのインストール状態と処理状態の確認バックアップ・マスター・ドメイン・マネージャーを使用しない場合は、ア

ップグレード・プロセス中にそれをインストールし使用することを強くお勧めします。「Tivoli Workload Scheduler: 管理ガイド」(SC88-5733) の説明に従って、バックアップ・マスター・ドメイン・マネージャーを構成し、鍵ファイルを定期的にそれにミラーリングするようにします。switchmgr を実行して、それに切り替えてから再度元に戻し、それが正常に処理していることをテストします。

絶対インストール・パスの確認composer を使用して、絶対インストール・パスを使用しているジョブ依存関係またはファイル依存関係がワークステーションにあるかどうかを確認します。依存関係がある場合、変数を使用してパスを変更してください。

新規ディレクトリー構造

このセクションが当てはまるのは、バージョン 8.3 または 8.4 からアップグレードしている場合です。バージョン 8.5 からアップグレードする場合は、このディレクトリー構造はすでに存在しています。このセクションでは、新しい製品ディレクトリー構造、およびバージョン 8.5 でインプリメントされた SSL ファイルの新しいディレクトリー構造について説明します。

製品ディレクトリー:

すべてのアップグレードの新規ディレクトリー構造 (ただしソフトウェア配布を使用して実行したアップグレードは除く)。

バージョン 8.3 または 8.4 から現行バージョンにアップグレードする際に、新規製品ディレクトリー構造が作成されます。アップグレード・プロセスの際、Tivoli

Workload Scheduler は古いディレクトリー構造から移動され、新規ディレクトリー構造に更新されます。新しい構造により、既存の TWShome は TWAhome に変更されます。これが新しい TWShome の親ディレクトリーになります。

UNIX および Linux オペレーティング・システム製品は、ユーザーのホーム・ディレクトリーにインストールされます。アップグレードのデフォルトのロケーションは以下のとおりです。

v Linux の場合: /opt/ibm/TWA/TWS/

v UNIX の場合: /opt/IBM/TWA/TWS/


Windows オペレーティング・システムアップグレードのデフォルトのロケーションは %ProgramFiles

%¥IBM¥TWA¥TWS¥ です。

注: インストール・ディレクトリー内にある WebSphere Application Server は、appserver から eWAS に名前変更されます。

注:

1. アップグレードの際に FINAL スケジュールがある場合、インストール時にそれがダウンロードされます。デフォルトの FINAL が再利用されます。スケジュールのバックアップ・コピーが SFinal.extract という名前で新規インストール・ディレクトリーに作成されます。

2. カスタム構成 (例えば、カスタム・スクリプトまたはバックアップ処理) がTivoli Workload Scheduler 構造内に存在する場合、それらを更新して、新規ディレクトリー構造で機能するようにしなければなりません。

3. UNIX オペレーティング・システム上では、スケジューリング環境が更新されるまで、古いインストール・ディレクトリーから ln -s コマンドを実行することにより、新規ディレクトリー構造へのシンボリック・リンクを作成できます。例:

ln -s bin TWS/binln -s config TWS/config

インストール・パスについて詳しくは、 32ページの『Tivoli Workload Automation

のインスタンス』を参照してください。

例:

UNIX および Linux オペレーティング・システム

最初に Tivoli Workload Scheduler を /export/home/twsuser にインストールした場合、ディレクトリー構造は次のようになります。

/export/home/twsuser/bin/export/home/twsuser/config/export/home/twsuser/_uninstall/export/home/twsuser/appserver/export/home/twsuser/wastools

Tivoli Workload Scheduler をアップグレードすると、新規ディレクトリー構造は次のようになります。

/export/home/twsuser/TWA/TWS/bin/export/home/twsuser/TWA/TWS/config/export/home/twsuser/TWA/TWS/_uninstall/export/home/twsuser/TWA/eWAS/export/home/twsuser/TWA/wastools/export/home/twsuser/TWA/TDWB

Windows オペレーティング・システム最初に Tivoli Workload Scheduler をディレクトリー c:¥Program

Files¥IBM¥TWS にインストールした場合、ディレクトリー構造は次のようになります。

c:¥Program Files¥IBM¥TWS¥binc:¥Program Files¥IBM¥TWS¥configc:¥Program Files¥IBM¥TWS¥uninstallc:¥Program Files¥IBM¥TWS¥appserverc:¥Program Files¥IBM¥TWS¥wastools


Tivoli Workload Scheduler をアップグレードすると、新規ディレクトリー構造は次のようになります。

c:¥Program Files¥IBM¥TWA¥TWS¥binc:¥Program Files¥IBM¥TWA¥TWS¥configc:¥Program Files¥IBM¥TWA¥TWS¥uninstallc:¥Program Files¥IBM¥TWA¥eWASc:¥Program Files¥IBM¥TWA¥wastoolsc:¥Program Files¥IBM¥TWA¥TDWB

ファイル・システムの構造:

アップグレードを実行すると、ファイル・システムのディレクトリー構造が以下のように変更されます。


バージョン 8.3 と 8.4 から<TWS_home_directory>/appserver/profiles/twsprofile/config/cells/DefaultNode/nodes/DefaultNode/servers/server1/

バージョン 8.5.1 から<TWS_home_directory>/eWAS/profiles/twaprofile/config/cells/DefaultNode/nodes/DefaultNode/servers/twaserver

バージョン 8.6 へ<TWS_home_directory>/eWAS/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1


バージョン 8.3 と 8.4 から<TWS_home_directory>¥appserver¥profiles¥twsprofile¥config¥cells¥DefaultNode¥nodes¥DefaultNode¥servers¥server1

バージョン 8.5.1 から<TWS_home_directory>¥eWAS¥profiles¥twaprofile¥config¥cells¥DefaultNode¥nodes¥DefaultNode¥servers¥twaserver

バージョン 8.6 へ<TWS_home_directory>¥eWAS¥profiles¥TIPProfile¥config¥cells¥TIPCell¥nodes¥TIPNode¥servers¥server1

<TWS_home_directory> は、製品を最初にインストールしたディレクトリーです。

SSL ファイルのディレクトリー:

バージョン 8.3 または 8.4 から現行バージョンにアップグレードする際に、SSL ファイルの新規ディレクトリーが作成されます。以下に、デフォルトのインストール・パスを選択した場合と、インストール・パスをカスタマイズした場合の、新旧のディレクトリー構造を記述します。

デフォルトのインストール・パスを使用する場合、TWSServerTrustFile.jks およびTWSServerKeyFile.jks ファイルは次のロケーションに置かれます。この場合、セキュリティー・プロパティー内の keyFileName および trustFileName の値が、既にデフォルトに設定されていることに注意してください。

旧ディレクトリー構造

v TWSInstallationPath¥AppServer¥profiles¥twsprofile¥etc

¥TWSServerTrustFile.jks


v TWSInstallationPath¥AppServer¥profiles¥twsprofile¥etc

¥TWSServerKeyFile.jks


v TWSInstallationPath¥eWAS¥profiles¥TIPProfile¥etc¥

TWSServerTrustFile.jks


TWSServerKeyFile.jks

カスタマイズされたインストール・パスを使用する場合、TWSServerTrustFile.jks および TWSServerKeyFile.jks ファイルは次のロケーションに置かれます。古いキーは元のディレクトリーに残されますが、新規ディレクトリーにもコピーされます。WebSphere Application Server のロケーション・パラメーターは、デフォルト・パス${USER_INSTALL_ROOT}/etc/KEYNAME に設定されます。セキュリティー・プロパティー内の keyFileName および trustFileName の値は、デフォルト・パス${USER_INSTALL_ROOT}/etc/TWSServerKeyFile.jks および ${USER_INSTALL_ROOT}/

etc/TWSServerTrustFile.jks に設定されることに注意してください。


v CustomzedInstallationPath¥TWSServerTrustFile.jks

v CustomizedInstallationPath¥TWSServerKeyFile.jks




v TWSnstallationPath¥eWAS¥profiles¥TIPProfile¥etc¥


直接アップグレードの実行

このセクションでは、直接シナリオを使用してご使用の環境をアップグレードする方法を説明します。概要については、 139ページの『直接アップグレードのシナリオ - アップグレード時間の最小化』を参照してください。これは以下の手順に分かれています。

v 151ページの『直接 1: マスター・ドメイン・マネージャーのネットワークからのリンク解除および停止』

v 152ページの『直接 2: マスター・ドメイン・マネージャーまたはバックアップ・マスターのアップグレード』

v 157ページの『直接 3: バックアップ・マスター・ドメイン・マネージャーでのDB2 プロパティーの再構成』

v 158ページの『直接 4: 認証アップグレードが正常に行われたかの検査』

v 158ページの『直接 5: オプションの最終ジョブ・ストリームのカスタマイズと実行依頼』

v 160ページの『直接 7: 新しい環境のためのセキュリティー構成の実行』

v 160ページの『直接 6: ご使用のバックアップ・マスター・ドメイン・マネージャーのアップグレード』

v 161ページの『直接 8: スケジューリング・プロセスを再開する』


アップグレード・プロセスでは、いくつかのファイルとフォルダーが変更されます。完全なリストについては、 135ページの『アップグレード時に変更されるファイルとフォルダー』を参照してください。

直接 1: マスター・ドメイン・マネージャーのネットワークからのリンク解除および停止:

アップグレードを開始する前に、すべてのワークステーションをマスター・ドメイン・マネージャーからリンク解除してこれを停止する必要があります。

以下のステップに従います。

1. <TWS_user> としてログインします。

2. ドメインのすべてのワークステーションをリンク解除します。

Dynamic Workload Console の場合「エンジンの選択」パネルから、すべてのワークステーションを選択し、「リンク解除」をクリックします。

マスター・ドメイン・マネージャーのコマンド行の場合以下のコマンドを発行します。

conman "unlink @;noask"

3. マスター・ドメイン・マネージャーを停止します。

Dynamic Workload Console の場合「エンジンの選択」パネルから、すべてのワークステーションを選択し、「停止」をクリックします。

マスター・ドメイン・マネージャーのコマンド行の場合以下のコマンドを発行します。

conman “stop;wait”

4. マスター・ドメイン・マネージャーのコマンド行で、以下のようにして netmanプロセスを停止します。

UNIX オペレーティング・システムおよび Linux オペレーティング・システム以下を実行します。

conman “shut" ; wait

注: UNIX kill コマンドは、Tivoli Workload Scheduler プロセスの停止には使用しないでください。

Windows オペレーティング・システムTivoli Workload Scheduler のホーム・ディレクトリーから shutdown.cmd

コマンドを実行します。

5. バージョン 8.4 以降からアップグレードする場合は、次のようにして SSM エージェントを停止します。

UNIX オペレーティング・システムおよび Linux オペレーティング・システムconman stopmon を実行してエージェントを停止します。

Windows オペレーティング・システムWindows サービス Tivoli Workload Scheduler SSM エージェント(<TWS_user> 用) を停止します。


6. 以下のようにして、すべてのサービスおよびプロセスが実行中でないことを検証します。

UNIX オペレーティング・システムおよび Linux オペレーティング・システム次のコマンドを実行します。

ps -u <TWS_user>

次のプロセスが実行中でないことを検証します。 netman、 mailman、batchman、 writer、 jobman、 JOBMAN、 stageman、 appserverman。組み込み WebSphere Application Server (これは稼働させておかなければならない) を除くすべてのプロセスを停止する必要があります。

Windows オペレーティング・システム以下を実行します。

<drive>¥unsupported¥listproc.exe

ここで、<drive> は Tivoli Workload Scheduler ホーム・ディレクトリーです。次のプロセスが実行中でないことを検証します。netman、mailman、 batchman、 writer、 jobman、 stageman、 JOBMON、tokensrv、 batchup。

また、どのシステム・プログラム (コマンド・プロンプトを含む) も、ディレクトリーまたはサブディレクトリーにアクセス中でないこと、および Windows Explorer で、「管理ツール」>「サービス」パネルが開いていないことを確認します。

直接 2: マスター・ドメイン・マネージャーまたはバックアップ・マスターのアップグレード:

このセクションでは、マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーをアップグレードする方法を説明します。

以下のインストール方法を使用して、マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーをアップグレードできます。

v 『インストール・ウィザードの使用によるアップグレード』

v 157ページの『サイレント・インストールを使用したアップグレード』

インストール・ウィザードの使用によるアップグレード:

Tivoli Workload Scheduler マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーをアップグレードするには、以下のステップを実行します。

1. 以下のいずれかを選択してください。

v インストール DVD を挿入し、ご使用のオペレーティング・システムのセットアップを実行します。




v または、以下のようにランチパッドを開始し、Tivoli Workload Scheduler のインストールを選択します。

UNIX および Linux オペレーティング・システムの場合DVD の root ディレクトリーから launchpad.sh を実行します。

Windows オペレーティング・システムの場合DVD の root ディレクトリーから launchpad.exe を実行します。


2. インストール・ウィザード画面に従ってインストールを完了します。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。ご使用の旧バージョンが 8.3 以降かによって、アップグレードが必要ないフィールドもあります。

以前の Tivoli Workload Scheduler インスタンスをバックアップする (Back upthe previous Tivoli Workload Scheduler instance)

以前のインスタンスをバックアップするかどうかを選択します。

バックアップ宛先ディレクトリー以前のインスタンスをバックアップするよう選択する場合には、バックアップが置かれるディレクトリーを指定します。

プロファイルのバックアップ宛先ディレクトリーアップグレード・プロシージャーが WebSphere® Application Server

(WAS) プロファイルのバックアップを実行します。現在の設定は新しいWebSphere Application Server に自動的に転送されます。デフォルトのバックアップ・パスが表示されます。プロファイルを別のパスに保存する場合、このフィールドに指定します。「次へ」をクリックします。

Tivoli Workload Scheduler ユーザー・パスワードインスタンスをアップグレードする Tivoli Workload Scheduler ユーザーのパスワードを入力します。

組み込み WebSphere Application Server (WAS) 管理者ユーザー名/パスワード(Embedded WebSphere Application Server (WAS) administrator user nameand password)

WebSphere Application Server (WAS) 管理者ユーザー名およびパスワードを以前のインストール済み環境から変更した場合、新しいユーザー名およびパスワードを入力します。これらの WebSphere Application Server

の値を現在のインストール済み環境で変更していない場合、これらのフィールドを空白のままにします。

SAS サーバー認証リスナーバージョン 8.3 にのみ必要です。 Secure Association Services (SAS) がインバウンド認証要求を listen するために使用するポート。デフォルト値は 31119 です。

CSIv2 サーバー認証リスナーバージョン 8.3 にのみ必要です。 Common Secure Interoperability


|

|

|

|

Version 2 (CSIv2) サービスが、インバウンド・サーバー認証要求をlisten するためのポート。デフォルト値は 31120 です。

CSIv2 クライアント認証リスナーバージョン 8.3 にのみ必要です。 Common Secure Interoperability

Version 2 (CSIv2) サービスが、インバウンド・クライアント認証要求をlisten するためのポート。デフォルト値は 31121 です。

ORB リスナーバージョン 8.3 にのみ必要です。 IIOP 通信を介した RMI に使用するポート。デフォルト値は 31122 です。

管理 HTTP トランスポートバージョン 8.3 にのみ必要です。管理コンソール・ポート。デフォルト値は 31123 です。

管理 HTTPS トランスポートバージョン 8.3 にのみ必要です。管理コンソール・セキュア・ポート。デフォルト値は 31124 です。

イベント処理プログラムバージョン 8.3 にのみ必要です。このポートはイベント管理機能によって使用されます。デフォルト値は 31131 です。このポートはバックアップ・マスター・ドメイン・マネージャーによって要求されません。

JobManager ポート番号Tivoli Workload Scheduler for z/OS サーバーまたは Dynamic Workload

Broker コンポーネントが Tivoli Workload Scheduler エージェントに接続するために使用するポート。これは、JobManager によって、ダイナミック・ワークロードの実行、および分散環境で z/OS 環境から来るワークロードの実行に使用されます。JobManager は、動的スケジューリング環境および z-セントリック環境を制御するネットワーク・プロセスです。デフォルト値は 31114 です。有効範囲は、1 から 65535 です。このポート番号が必要となるのは、マスター・ドメイン・マネージャーをアップグレードする場合だけです。

ホスト名または IP アドレスDynamic Workload Broker がエージェントと通信するときに使用する完全修飾ホスト名。

動的スケジューリング機能を有効にするこのオプションを選択すると、マスター・ドメイン・マネージャーの動的スケジューリング機能が Dynamic Workload Broker で使用できるようになります。マスター・ドメイン・マネージャーをアップグレードする場合は、Dynamic Workload Broker ワークステーション定義が作成されます。動的スケジューリング機能を有効にするには、ネットワーク内のすべてのバックアップ・マスター・ドメイン・マネージャーが Tivoli

Workload Scheduler バージョン 8.3 フィックスパック 8 以降、またはTivoli Workload Scheduler バージョン 8.4 フィックスパック 4 以降をインストールしている必要があります。

Dynamic Workload Broker がバックアップ・マスター・ドメイン・マネージャーにインストールされなくても、動的スケジューリングは有効であり、インストールまたはアップグレードのどちらの際にも、関連する


WebSphere Application Server 構成ツールがインストールされます。後から動的スケジューリング機能を有効にするように決定する場合は、 201

ページの『インストール後の動的スケジューリングの使用可能化』で説明されている手順を参照してください。


Broker ワークステーションの定義。スペースは許可されず、最大フィールド長は 16 文字です。それには、英数字、ダッシュ (-)、および下線(_) 文字を含めることができます。先頭文字は文字でなければなりません。

Dynamic Workload Broker ワークステーションは、マスター・ドメイン・マネージャーと Dynamic Workload Broker コンポーネント間における通信ブリッジとしての役割を果たします。ジョブまたはジョブ・ストリーム定義において、ジョブが実行されるワークステーションです。このように、このワークステーションを介して Dynamic Workload Broker

コンポーネントに対してワークロードを送信します。

Dynamic workload broker ホスト名バックアップ・マスター・ドメイン・マネージャーに適用されます。Dynamic Workload Broker の完全修飾ホスト名。ダイナミック・ワークロードを実行する機能を Tivoli Workload Scheduler エージェントに追加します。指定しなければ、デフォルト値は localhost です。この値は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。

Dynamic workload broker Netman ポートバックアップ・マスター・ドメイン・マネージャーに適用されます。分散環境またはエンドツーエンド環境に、動的スケジューリング機能を追加するための Dynamic Workload Broker Netman ポート番号です。この番号は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。デフォルト値は 31116 です。有効範囲は、0 から65535 です。 0 を指定した場合、ダイナミック・ワークロードを実行する機能をエージェントに追加しません。

RDBMS インストール・パス (RDBMS installation path)使用する RDBMS のタイプに応じて、以下の情報を指定します。

DB2 の場合:


DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表を作成していた場合、ユーザー名は DB2 管理者がcustomizeDB2SQL.properties ファイルの DB_USER プロパティーに指定したものになります。


DB2 サーバー管理者パスワードDB2 サーバー管理者ユーザーのパスワードか、SYSADM またはSYSCTRL 権限を持つユーザーのパスワード。パスワードを確認するよう求められます。

注: DB2 インストール・パスは、アップグレード手順により自動的に発見されます。

UNIX プラットフォームに DB2 Enterprise クライアントがインストールされている場合、DB2 ローカル・クライアントのユーザー名も指定します。

Oracle の場合:

インストール・パスTivoli Workload Scheduler の前提条件を満たす Oracle のインストール済み環境のパスを指定します。この完全修飾パスは、sqlplus 実行可能ファイルが含まれている Oracle 構造内のツリーを示している必要があります。

Oracle アドミニストレーター・ユーザーOracle 管理者ユーザーの名前。

ORACLE 管理者が既に 56ページの『Oracle を使用している場合のデータベース表の作成またはアップグレード』を使用してデータベース表を作成していた場合、ユーザー名は ORACLE 管理者が customizeORACLESQL.properties ファイルの MDL_USERプロパティーに指定したものになります。

Oracle アドミニストレーター・ユーザー・パスワードOracle 管理者ユーザーのパスワード。パスワードを確認するよう求められます。

Tivoli Workload Scheduler データベース情報バージョン 8.3 からのアップグレードにのみ必要です。 Tivoli Workload

Scheduler データベースの更新に必要な以下の情報を指定します。

DB2 の場合:

レポート・テーブル・スペース名イベント・ログの保管に使用するテーブル・スペースの名前。

レポート・テーブル・スペース・パスイベント・ログの保管に使用するテーブル・スペースのパス。

注: Tivoli Workload Scheduler バージョン 8.3 フィックスパック 1 以降からアップグレードしている場合、DB2 インストール・パスは、アップグレード手順により自動的に発見されます。

Oracle の場合:

インストール・パスTivoli Workload Scheduler の前提条件を満たす Oracle のインストール済み環境のパスを指定します。この完全修飾パスは、sqlplus 実行可能ファイルが含まれている Oracle 構造内のツリーを示している必要があります。


Tivoli Workload Scheduler Oracle ユーザー・パスワードTivoli Workload Scheduler Oracle ユーザーのパスワード。

Oracle Partitioning オプションを使用した Tivoli Workload Schedulerスキーマの作成

Oracle Enterprise Edition 上でバージョン 8.3 をアップグレードしており、Oracle Partitioning 機能をまだインプリメントしていない場合、ここでインプリメントを行うことができます。このフィーチャーをインプリメントすることで、イベント・ドリブン・ワークロード自動化のパフォーマンスが向上します。 Oracle

インスタンスにパーティショニング・オプションがインストール済みでなければなりません。イベント・ドリブン・ワークロード自動化については、「概要」を参照してください。

バージョン 8.4 以降をアップグレードしている場合、イベント・ドリブン・ワークロード自動化のデータベース・スキーマが既に存在しているので、このオプションは使用できません。Oracle Partitioning 機能をインプリメントするには、「管理ガイド」を参照してください。

Tivoli Workload Scheduler レポート・テーブル・スペースTivoli Workload Scheduler レポート用の Oracle テーブル・スペースのパス

サイレント・インストールを使用したアップグレード:

Tivoli Workload Scheduler マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーのインスタンスをアップグレードするには、以下の応答ファイルのいずれか 1 つを使用します。

v TWS86_UPGRADE_MDM_83plus_UNIX.txt

v TWS86_UPGRADE_BACKUP_MDM_83plus_UNIX.txt

v TWS86_UPGRADE_MDM_83plus_WIN.txt

v TWS86_UPGRADE_BACKUP_MDM_83plus_WIN.txt

100ページの『サイレント・インストールの実行』で説明されている手順に従います。

直接 3: バックアップ・マスター・ドメイン・マネージャーでの DB2 プロパティーの再構成:

バックアップ・マスター・ドメイン・マネージャーをアップグレードしており、DB2 クライアントまたはサーバーのいずれかを使用している場合、アップグレード手順が完了した後、以下のステップを実行する必要があります。

TWA_HOME¥TDWB¥config¥CLIConfig.properties ファイルを開きます。このファイルの、以下のプロパティーを編集します。

com.ibm.tdwb.dao.rdbms.jdbcPath=jdbc¥:db2¥://DB2_server_hostname¥:DB2_server_port/DB_name

ここで、

v DB2_server_hostname は、DB2 サーバーのホスト名です。


v DB2_server_port は、DB2 サーバーのポート番号です。

v DB_name は、データベースの名前です。このフィールドはアップグレードの際には既にカスタマイズ済みになっています。

直接 4: 認証アップグレードが正常に行われたかの検査:

アップグレードでは、ご使用の認証構成 (ローカル OS、LDAP、またはファイル・レジストリーなど) をフェデレーテッド・ユーザー・レジストリーの内部の新しいフォーマットにマイグレーションしようとします (新しい認証機能とアップグレードがどのように実行されるかについての概要は、 140ページの『認証の更新』を参照)。このマイグレーションが失敗することがあります。その場合、以下が発生します。

アップグレード状況他にアップグレードに関する問題がない場合は、この点が失敗したとしても、アップグレードは「正常」として完了します。

認証構成既存の認証構成が「スタンドアロン」として実装されます。これは、マスター・ドメイン・マネージャーと通信する必要がある他のコンポーネントのインストールまたはアップグレードを試行する前に修正する必要がある一時的な状態です。これを行うには、Integrated Solutions Console またはWebSphere Application Server ツールのいずれかを使用してフェデレーテッド・ユーザー・レジストリー内の認証を構成する方法についての「Tivoli

Workload Scheduler: 管理ガイド」での説明に従ってください。

Dynamic Workload Console のインストールマスター・ドメイン・マネージャーと同じ Tivoli Workload Automation のインスタンスに Dynamic Workload Console をインストールしようとすると、ユーザー・レジストリーがフェデレーテッドされていないため、失敗します。Dynamic Workload Console を一時的にインストールする必要がある場合は、Dynamic Workload Console の新規インスタンスにインストールします。ただし、これは Dynamic Workload Console を使用する方法としては最も効率的なものではないことに注意する必要があります。また、これは、フェデレーテッド・ユーザー・レジストリーが構成され、動作するようになったらすぐに削除し、マスター・ドメイン・マネージャーと同じ Tivoli

Workload Automation インスタンスに再インストールするように計画する必要があります。

認証構成のマイグレーションが失敗したかどうかを判断するには、アップグレード・ログ (ログのある場所については、 38ページの『インストール・ログ・ファイル』を参照) を調べる必要があります。

直接 5: オプションの最終ジョブ・ストリームのカスタマイズと実行依頼:

ユーザーの古い最終ジョブ・ストリームが FINAL という名前である場合は、そのバックアップ・コピーが Sfinal.extract に作成されており V8.5.1 にアップグレードされています。カスタマイズした場合は、対応するカスタマイズを新規 FINAL ジョブ・ストリームに加える必要があります。FINAL という名前でない場合は、古い最終ジョブ・ストリームの機能を新規の FINAL ジョブ・ストリームの構文にマージする必要があります。状況に応じて、以下のステップを実行します。


1. 必要に応じて、最終ジョブ・ストリームをカスタマイズします。

データベースに FINAL という名前のカスタマイズされたジョブ・ストリームがあった場合:

a. composer または Dynamic Workload Console を使用して新規 FINAL

ジョブ・ストリームを編集します。

b. テキスト・エディターで Sfinal.extract ファイルを編集します。

c. 新規 FINAL ジョブ・ストリームに対して相応のカスタマイズを行います。

d. 新規 FINAL ジョブ・ストリームを保存します。

データベースに FINAL という名前以外のカスタマイズされた最終ジョブ・ストリームがあった場合:

a. composer または Dynamic Workload Console を使用して新規 FINAL

ジョブ・ストリームを編集します。

b. composer または Dynamic Workload Console を使用して古い最終ジョブ・ストリームを編集します。

c. 2 つのジョブ・ストリームをマージして、新規の最終ジョブ・ストリームが以前と同じ名前とカスタマイズを保持しつつ (その名前を保持する場合)、新たに必要な属性を新規 FINAL ジョブ・ストリームから取得できるようにします。

d. 新規 FINAL ジョブ・ストリームを保存します。

e. 古い最終ジョブ・ストリームを削除します。

データベースに FINAL という名前以外の最終ジョブ・ストリームがあり、それがカスタマイズされていない場合:

a. composer または Dynamic Workload Console を使用して古い最終ジョブ・ストリームを削除します。

b. composer または Dynamic Workload Console で、新規 FINAL ジョブ・ストリームを、古い最終ジョブ・ストリームの名前に名前変更します。

データベースに FINAL という名前の最終ジョブ・ストリームがあり、それがカスタマイズされていない場合:

インストールまたはアップグレード手順によって FINAL ジョブ・ストリームは既に編集されているので、何も行う必要はありません。

2. conman を使用して古い最終ジョブ・ストリーム・インスタンスを削除し、新規のインスタンスを実行依頼して置換します。

アップグレードの際に、たとえユーザーがカスタマイズしていても、JnextPlan は上書きされます。既存の JnextPlan はバックアップされ、以下のように名前変更されます。

Windows オペレーティング・システムの場合:JnextPlan.cmd.bk

UNIX および Linux オペレーティング・システムの場合:JnextPlan.bk


注: 『直接 7: 新しい環境のためのセキュリティー構成の実行』で JnextPlan を実行します。

直接 6: ご使用のバックアップ・マスター・ドメイン・マネージャーのアップグレード:

バックアップ・マスター・ドメイン・マネージャーを使用する場合は、それをマスター・ドメイン・マネージャーと同じバージョンにアップグレードする必要があります。そうしないと、新機能はサポートされません。行うべき操作の多くは、マスター・ドメイン・マネージャーに対するものと同じです。次の説明に従ってください。

v 152ページの『直接 2: マスター・ドメイン・マネージャーまたはバックアップ・マスターのアップグレード』

v 157ページの『直接 3: バックアップ・マスター・ドメイン・マネージャーでのDB2 プロパティーの再構成』

v 158ページの『直接 4: 認証アップグレードが正常に行われたかの検査』. ご使用のバックアップ・マスター・ドメイン・マネージャーに対しては、ご使用のマスター・ドメイン・マネージャーと同じ認証を実装しているはずなので、認証アップグレードから同じ結果を得ることが予期されますが、マスター・ドメイン・マネージャー認証アップグレードが正常に完了した場合でも、バックアップ・マスター・ドメイン・マネージャーに対するアップグレード・ログを確認する必要があります。

v マスター・ドメイン・マネージャー上の FINAL ジョブ・ストリームはスイッチ・マネージャー・プロセスを実行するたびに使用されるため、FINAL ジョブ・ストリームに対しては、いかなる変更も行う必要はありません。

v バックアップ・マスター・ドメイン・マネージャー上のセキュリティー・ファイルの構成も変更する必要はありません。これは、スイッチ・マネージャーを使用するために準備ができている状態に環境を維持するための手順によって、セキュリティー・ファイルを変更するたびにバックアップ・マスター・ドメイン・マネージャーにそれをミラーリングする必要があるからです。

バックアップ・マスター・ドメイン・マネージャーを使用していない場合は、スケジューリング環境の高可用性を確保するために、それをインストールして使用することを強くお勧めします。

直接 7: 新しい環境のためのセキュリティー構成の実行:

バージョン 8.5 以上には、イベント管理と変数テーブルのための新しいセキュリティー・ステートメントが含まれています。固有のセキュリティー設定を V8.3 または V8.4 環境に持つ場合、新しい環境で使用される最終セキュリティー・ファイルを作成する前に、これらの設定を新しい設定と手動でマージする必要があります。手動での追加が必要な可能性があるステートメントは、固有のセキュリティー設定によって異なります。

次のように実行します。

1. アップグレードしたマスター・ドメイン・マネージャーに <TWS_user> としてログインし、Tivoli Workload Scheduler 環境を設定します。


2. 集中化セキュリティーを使用可能にしている場合には、以下の V8.5 以降のコマンドを使用して、新規マスター上に新規セキュリティー・ファイルを抽出します。

dumpsec > sec_file

ここで、sec_file は dumpsec コマンドによって作成されたテキスト・ファイルです。

3. sec_file を編集して、以下のステートメントを挿入します。

V8.3 からアップグレードする場合は、以下のステートメントを追加します。

REPORT NAME=@ ACCESS=DISPLAYEVENTRULE NAME=@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,LIST,UNLOCKACTION PROVIDER=@ ACCESS=DISPLAY,SUBMIT,USE,LISTEVENT PROVIDER=@ ACCESS=USE

V8.3 または V8.4 環境からアップグレードする場合、以下のステートメントを追加します。

VARTABLE NAME=@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,USE,LIST,UNLOCK

4. 新規ステートメントのユーザー許可が正しいかどうか確認します。

5. 変更を sec_file に保存します。

6. V8.5 以降の makesec コマンドを使用して、新規マスター・ドメイン・マネージャーのための最終セキュリティー・ファイルを作成します。

makesec sec_file

7. FIPS を使用している場合は、WebSphere Application Server の java.security

ファイルで FIPS を再び有効にする必要があります。FIPS の準拠について詳しくは、「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

8. 集中化セキュリティーを使用している場合、セキュリティー・ファイルを配布します。

9. JnextPlan -for 0000 を実行して、エージェントに Symphony ファイルを配布します。

注: optman cf オプションが all に設定されていることを確認します。この値に設定されていないと、未完了のジョブ・ストリームのみが繰り越されます。

10. 必要に応じて、optman cf オプションの以前の設定を復元します。

11. EDWA を使用する場合、optman を使用してそれを使用可能にします。

直接 8: スケジューリング・プロセスを再開する:

アップグレードが完了した後に、以下のようにスケジューリング・プロセスを再開します。


2. マスター・ドメイン・マネージャーを始動します。

Dynamic Workload Console の場合「エンジンの選択」パネルから、すべてのワークステーションを選択し、「開始」をクリックします。


マスター・ドメイン・マネージャーのコマンド行の場合以下のコマンドを実行します。

conman "startappserver";waitconman “start”

3. マスター・ドメイン・マネージャーのコマンド行で、以下のようにして netmanプロセスを開始します。

UNIX および Linux オペレーティング・システム以下を実行します。

StartUp.sh


StartUp

4. 以下を実行します。

conman start

5. ドメイン内のすべてのワークステーションをリンクします。

Dynamic Workload Console の場合「エンジンの選択」パネルから、すべてのワークステーションを選択し、「リンク」をクリックします。

マスター・ドメイン・マネージャーのコマンド行の場合以下のコマンドを実行します。

conman "link @;noask"

6. アップグレードした環境でイベント処理を実行する場合は、最初に、次を実行します。

conman startevtp

次に、以下を実行します。

Dynamic Workload Console の場合

a. 「Tivoli Workload Scheduler」>「スケジューリング環境」>「モニター」>「ワークステーションのモニター」をクリックします。

b. 「計画内のすべてのワークステーション」または別の事前定義タスク名を選択します。

c. エンジン名を選択するか、接続プロパティーを指定し、「OK」をクリックします。

d. ワークステーションを選択し、「その他のアクション」>「イベント・モニターの開始」をクリックします。

マスター・ドメイン・マネージャーのコマンド行の場合


conman startmon

Windows オペレーティング・システムWindows サービス Tivoli Workload Scheduler SSM エージェント (<TWS_user> 用) を開始します。


7. 以下のようにして、すべてのサービスおよびプロセスが実行中であることを検証します。


ps -u <TWS_user>

プロセス netman、 mailman、 batchman、 writer、 jobman、JOBMAN、 stageman、 appserverman が実行中であることを検証します。


<drive>¥unsupported¥listproc.exe

ここで、<drive> は Tivoli Workload Scheduler ホーム・ディレクトリーです。プロセス netman、 mailman、 batchman、 writer、 jobman、stageman、 JOBMON、 tokensrv、 batchup が実行中であることを検証します。

注: 自動トレースのメカニズムは、サポートされなくなりましたが、アップグレード・プロセスによってアップグレード後に TWA_home¥TWS¥trace ディレクトリーが削除されるわけではありません。他の Tivoli 製品でそのディレクトリーを使用する可能性があるからです。TWA_home¥TWS¥trace ディレクトリーを使用しないことが確実であれば、削除してもかまいません。

並列アップグレードの実行

このセクションでは、並列アップグレードのシナリオを使用してご使用の環境をアップグレードする方法を説明します。概要については、 139ページの『並列アップグレードのシナリオ - スケジューリングへの影響の最小化』を参照してください。

シナリオは、以下の手順から構成されます。

v 164ページの『並列 1: 既存のバックアップ・マスター・ドメイン・マネージャーのアップグレード、または新規のインストール』– 164ページの『並列 1a: 新規バックアップ・マスター・ドメイン・マネージャーのインストール』

または– 165ページの『並列 1b: 現行のバックアップ・マスター・ドメイン・マネージャーのアップグレード』

v 165ページの『並列 2: マスター・ドメイン・マネージャーから新規またはアップグレードされたバックアップ・マスターへの切り替え』

v 166ページの『並行 3: スイッチ・マネージャーの永続化』

v 167ページの『並列 5: 新規バックアップ・マスター・ドメイン・マネージャーのインストールまたは古いマスター・ドメイン・マネージャーのアップグレード』

v 168ページの『並列 6: 旧マスター・ドメイン・マネージャーへのスイッチバック (オプション)』

v 168ページの『並行 7: 新しい環境のためのセキュリティー構成の実行』



並列 1: 既存のバックアップ・マスター・ドメイン・マネージャーのアップグレード、または新規のインストール:

このステップは、ご使用の環境にバックアップ・マスター・ドメイン・マネージャーが存在するかどうか応じて、以下の 2 つの代替のサブステップに分けられます。

並列 1a: 新規バックアップ・マスター・ドメイン・マネージャーのインストール:

このステップの目的は、新規のバックアップ・マスター・ドメイン・マネージャーをインストールして、現行のネットワークに接続することです。

このバックアップ・マスター・ドメイン・マネージャーは既存の Tivoli Workload

Scheduler データベースを指し、新規のマスター・ドメイン・マネージャーになります。

並列 1a-1: 新規のバックアップ・マスター・ドメイン・マネージャーのインストール新規のバックアップ・マスター・ドメイン・マネージャーをインストールす

るには、 70ページの『インストール中』で説明されている手順を参照してください。特に、DB2 または Oracle データベースのどちらを使用しているかに応じて、 72ページの『Tivoli Workload Scheduler インストール・オプション』で説明されている手順と後続のセクションを参照してください。新規のバックアップ・マスター・ドメイン・マネージャーが、現在の Tivoli

Workload Scheduler データベース・インスタンスを指していることを確認してください。

並列 1a-2: 認証構成のマイグレーション以下を実行して、ご使用の認証メカニズムを新しくインストールしたバックアップ・マスター・ドメイン・マネージャーにマイグレーションします。

1. 既存のマスター・ドメイン・マネージャー上で、showSecurityProperties ツールを使用して、ご使用の認証構成をテキスト・ファイルにエクスポートします。

2. このファイルを新しいバックアップ・マスター・ドメイン・マネージャーにコピーします。

3. 新しいバックアップ・マスター・ドメイン・マネージャー上でchangeSecurityProperties ツールを実行して構成をインポートします。このツールは、入力ファイルが古いフォーマットであることを認識し、構成を新しいフォーマットにマイグレーションしようとします。

ご使用の認証メカニズムが、マイグレーションが処理できない形でカスタマイズされている場合は、1 つ以上のエラーが出され、認証メカニズムを手動で構成する必要があります。

4. マイグレーション済みの認証メカニズムによって、複数のユーザー ID

でログオンして composer を使用できるようになっていることをテストします。


並列 1a-3: データベースでの新規バックアップ・マスター・ドメイン・マネージャーの定義

composer コマンド・インターフェースを使用して、新規のバックアップ・マスター・ドメイン・マネージャーを、フル状況エージェントとして、ご使用のマスター・ドメイン・マネージャーのドメインに定義します。

並列 1a-4: 動的スケジューリング機能の使用可能化 (オプション)アップグレードによって、バックアップ・マスター・ドメイン・マネージャー上に Dynamic Workload Broker が使用不可な状態でインストールされます。ネットワーク内で動的スケジューリング機能が不要な場合には、この時点でアクションを実行する必要はありません。 201ページの『インストール後の動的スケジューリングの使用可能化』で説明されている手順に従って、後から動的スケジューリング機能を使用可能にすることができます。

並列 1a-5: マネージャーを切り替えるための旧セキュリティー・ファイルの準備

Tivoli Workload Scheduler を正しく切り替えるには、新規 TWS_user を旧セキュリティー・ファイルに追加する必要があります。新規 TWS_user は、新規バックアップ・マスター・ドメイン・マネージャーのインストール時に使用したものです。

次のステップを実行します。

1. 旧マスター・ドメイン・マネージャーで、旧 TWS_user としてログインし、Tivoli Workload Scheduler 環境を設定します。新規マスター・ドメイン・マネージャーの TWS_user を、旧セキュリティー・ファイルに追加します。

2. 集中化セキュリティーを使用している場合、セキュリティー・ファイルをすべてのエージェントに配布します。集中化セキュリティーを使用していない場合、コンパイルしたセキュリティー・ファイルを、インストールまたはアップグレードしたバックアップ・マスター・ドメイン・マネージャーにコピーして、そこにあるバージョンを上書きします。

この時点で、以下のように、これらの変更を有効にする必要があります。

1. optman cf オプションが all に設定されていることを確認します。

2. JnextPlan -for 0000 を実行するかまたは実動計画が終了するまで待ちます。これによって、Symphony ファイルが新しいバックアップ・マスター・ドメイン・マネージャーに配布されます。


並列 1b: 現行のバックアップ・マスター・ドメイン・マネージャーのアップグレード:

現行のバックアップ・マスター・ドメイン・マネージャーをアップグレードするには、使用可能なインストール方式を使用して 152ページの『直接 2: マスター・ドメイン・マネージャーまたはバックアップ・マスターのアップグレード』で説明されている手順に従います。

並列 2: マスター・ドメイン・マネージャーから新規またはアップグレードされたバックアップ・マスターへの切り替え:


古いマスター・ドメイン・マネージャーで以下のコマンドを発行して、現在マスター・ドメイン・マネージャーになっている新規のバックアップ・ドメイン・マネージャーに切り替えます。

conmanswitchmgr masterdm;new_mgr_cpu

ここで、new_mgr_cpu は新規またはアップグレードしたバックアップ・マスター・ドメイン・マネージャーのワークステーションの名前です。

V8.4 以降からアップグレードを行っており、イベント処理プログラムが古いマスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャー上でホストされている場合は、switchevtprocessor を実行してイベント処理プログラムを同じ方法で切り替える必要があります。

バックアップのマスター・ドメイン・マネージャー V8.6 を使用する環境で、エージェント、プール、動的プールのいずれかのワークステーションを定義した後に、マスター・ドメイン・マネージャー V8.4 のデータベースからそれらのデータベース定義を開くと、ワークステーション・タイプがブランクになります。

並行 3: スイッチ・マネージャーの永続化:

前のステップで、アップグレードしたバックアップ・マスター・ドメイン・マネージャーをマスター・ドメイン・マネージャーの役割にプロモートしました。

この構成を完全に作動可能および JnextPlan で永続するようにするには、以下のステップを実行する必要があります。

新規のマスター・ドメイン・マネージャーで、new_mgr_cpu として参照します。

1. localopts ファイルを編集して、以下に示す項目を変更します。

DEFAULTWS=new_mgr_cpu

ここで、new_mgr_cpu は新規のマスターのワークステーション名です。「Tivoli

Workload Scheduler: 管理ガイド」を参照してください。

2. composer を使用して、古いマスターのワークステーション定義を変更します。

modify cpu=old_mgr_cpu

および type=manager を type=fta で置換します。

3. 前のステップを繰り返しますが、今回は新規のマスターのワークステーション定義を変更して、type=fta を type=manager で置換します。

4. 新規マスターの計画日を確認します。

planman showinfo

planman showinfo の出力に情報が入っている場合のみ、次のコマンドを実行して実動前計画を削除します。

planman reset -scratch

planman reset -scratch について詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。


注: このコマンドでは実動前計画が削除されて Symphony ファイルは維持されるのに対し、ResetPlan -scratch コマンドでは両方とも削除されます。そのため、適切に使用することが大切です。

5. optman cf オプションが all に設定されていることを確認します。

6. 計画を再作成して、データベースへの変更を活動化します。

JnextPlan - from <start_date> -for 0000


8. ¥TWS¥mozart¥globalopts ファイルを編集して、master=old_mgr_cpu 項目を以下のように変更します。

master=new_mgr_cpu

ここで、new_mgr_cpu は新規のマスターのワークステーション名です。「Tivoli

Workload Scheduler: 管理ガイド」を参照してください。

JnextPlan の実行時に、このようにしてレポート (reptr - pre と reptr -post) を実行できます。

注: グローバル・オプション carryforward が all に設定されていることを確認します。all に設定されていないと、未完了のジョブ・ストリームのみが繰り越されます。

並列 4: オプションの最終ジョブ・ストリームのカスタマイズ:

158ページの『直接 5: オプションの最終ジョブ・ストリームのカスタマイズと実行依頼』で説明されている手順を実行します。

並列 5: 新規バックアップ・マスター・ドメイン・マネージャーのインストールまたは古いマスター・ドメイン・マネージャーのアップグレード:

これで、 71ページの『マスター・ドメイン・マネージャーまたはバックアップ・マスターのインストール』の説明に従って、新しいバックアップ・マスター・ドメイン・マネージャーをインストールするように選択できます。

あるいは、新しいバックアップ・マスター・ドメイン・マネージャーをインストールするのではなく、アップグレードするように決定することもできます。

アップグレードの際に、対象のコンピューター上で動的スケジューリング機能を活動化するためのプロンプトが出されます。動的スケジューリング機能を活動化する場合、ネットワーク上にあるすべてのバックアップ・ドメイン・マネージャーがサポート対象の最小限のバージョン・レベルにあることを確認しなければなりません。http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 の Tivoli

Workload Scheduler システム要件ドキュメントを参照してください。その後、動的スケジューリング機能の活動化を選択できます。

すべてのバックアップ・マスター・ドメイン・マネージャーがサポート対象の最小限のレベルにあるかどうか不明な場合には、このオプションを選択して動的スケジューリング機能を活動化しないでください。 201ページの『インストール後の動的スケジューリングの使用可能化』の手順を実行して、後からこの機能を追加することもできます。



この手順を実行する前に、手順 165ページの『並列 2: マスター・ドメイン・マネージャーから新規またはアップグレードされたバックアップ・マスターへの切り替え』で、エージェント、プール、動的プールのいずれかのワークステーションを作成していた場合は、それらのワークステーションを ignore に設定してください。ignore に設定しないと、マスター・ドメイン・マネージャーは、ワークステーション定義を計画に追加するときに、それらの定義を検出できず、IBMTWATWSpobox

ファイルに多数のメッセージを送信することになります。これらのファイルのサイズは、急激に大きくなります。

マスター・ドメイン・マネージャー (現時点のバックアップ・マスター・ドメイン・マネージャー) をアップグレードするには、以下のステップを実行します。

1. 新規のマスター・ドメイン・マネージャーで、古いマスター・ワークステーションをリンク解除します。

conman "unlink old_mdm_cpu"

2. 160ページの『直接 6: ご使用のバックアップ・マスター・ドメイン・マネージャーのアップグレード』で説明されている手順を使用して、旧マスター・ドメイン・マネージャーを現行バージョンにアップグレードします。

3. アップグレードしたマスター・ドメイン・マネージャーをネットワークにリンクします。

conman "link old_mdm_cpu"

並列 6: 旧マスター・ドメイン・マネージャーへのスイッチバック (オプション):

このステップはオプションです。アップグレードされた旧マスター・ドメイン・マネージャーにスイッチバックすることができます。これを行うには、以下のステップを実行します。

1. アップグレードされたマスター・ドメイン・マネージャーから、マスター・ドメイン・マネージャーを切り替えます。

conmanswitchmgr masterdm;old_mdm_cpu

2. アップグレードされたマスター・ドメイン・マネージャーをその役割に永続的に復元するには、今回はマスター・ワークステーションに対して、 166ページの『並行 3: スイッチ・マネージャーの永続化』に概要を示したステップを実行します。

並行 7: 新しい環境のためのセキュリティー構成の実行:

160ページの『直接 7: 新しい環境のためのセキュリティー構成の実行』で説明されている手順を実行します。

エージェントおよびドメイン・マネージャーのアップグレード

このセクションでは、分散環境、z/OS 環境、またはエンドツーエンド・ネットワークにおいて Tivoli Workload Scheduler エージェントとドメイン・マネージャーをアップグレードする方法について説明します。アップグレードの際に、動的スケジューリング機能または拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加できます。ランタイム環境は、以下の目的で使用されます。


v エージェント上で拡張オプション付きジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行するため。



8.5.1 より前のバージョンからアップグレードする場合は、アップグレード・プロセス中に、新しい機能を追加できます。

バージョン 8.5.1 からアップグレードしていて、インストールの際に動的機能や拡張オプション付きジョブ・タイプを実行する Java ランタイムなどの一部の機能をインストールしなかった場合、アップグレード・プロセス中にそれらを追加することはできません。それらを追加するには、以下のセクションで説明されている手順を実行します。


v 201ページの『インストール後の動的スケジューリングの使用可能化』

製品は、開始前に 144ページの『セーフ・アップグレードの実行』で詳しく説明されている検査をすべて実行することによって、セーフ・モードでアップグレードを実行します。アップグレードを停止することなく実行できることを確認するには、アップグレードの開始前に、 170ページの『エージェント・ワークステーションのアップグレード時の Tivoli Workload Scheduler のリンク解除および停止』で説明されているステップを手動で実行します。


アップグレード手順が正常に実行された場合は、前のバージョンへのロールバックを不可能です。新規ディレクトリー構造について、また様々なインストール方式を使用してエージェントをアップグレードする方法について以下に説明します。

v 170ページの『新規ディレクトリー構造』

v 170ページの『エージェント・ワークステーションのアップグレード時の Tivoli

Workload Scheduler のリンク解除および停止』

v 171ページの『インストール・ウィザードを使用したエージェントおよびドメイン・マネージャーのアップグレード』

v 174ページの『サイレント・インストールを使用したエージェントおよびドメイン・マネージャーのアップグレード』

v 174ページの『twsinst を使用したエージェントおよびドメイン・マネージャーのアップグレード』

v 180ページの『Software Distribution の使用によるエージェントのアップグレード』



新しい製品ディレクトリー構造、および SSL ファイルの新しいディレクトリー構造については、 147ページの『新規ディレクトリー構造』を参照してください。

エージェント・ワークステーションのアップグレード時の TivoliWorkload Scheduler のリンク解除および停止

製品は、開始前に 144ページの『セーフ・アップグレードの実行』で詳しく説明されている検査をすべて実行することによって、セーフ・モードでアップグレードを実行します。アップグレードを停止することなく実行できることを確認するには、アップグレードの開始前に、手順で説明されているステップを手動で実行します。

エージェント・ワークステーションでアップグレードを実行する前に、すべてのTivoli Workload Scheduler プロセスおよびサービスが停止していることを確認してください。現在実行中のジョブがある場合、関連するプロセスは手動で停止するか、またはジョブが完了するまで待つ必要があります。

注: UNIX kill コマンドは、Tivoli Workload Scheduler プロセスの停止には使用しないでください。

Tivoli Workload Scheduler プロセスおよびサービスを停止するには、以下のステップに従います。

1. ネットワーク中の他のワークステーションからターゲット・ワークステーションのリンクを解除します。または、マスター・ドメイン・マネージャーのコマンド行から次のコマンドを入力します。

conman "unlink workstationname;noask"

2. ターゲット・ワークステーションを停止します。または、マスター・ドメイン・マネージャーのコマンド行から TWS_user としてログインして、次のコマンドを入力します。

conman “stop workstationname;wait”

3. バージョン 8.4 以降からアップグレードする場合は、次のようにして SSM エージェントを停止します。

v Windows では、Windows サービス Tivoli Workload Scheduler SSM エージェント (TWS_user 用) を停止します。

v UNIX では、stopmon コマンドを実行してエージェントを停止します。

4. 次のように netman プロセスを停止します。

v Windows では、shutdown.cmd を Tivoli Workload Scheduler ホーム・ディレクトリーから実行します。

v UNIX では、次のコマンドを実行します。

conman “shut;wait workstationname"

5. エージェントを更新する場合、NTFS マウント済みディレクトリーがあれば、マスター・ドメイン・マネージャーから除去 (アンマウント) します。

まだ実行中のサービスおよびプロセスがあるかどうかを検証するには、以下のステップを実行します。

v Windows オペレーティング・システムでは、次のコマンドを入力します。

<drive>unsupported¥listproc.exe


次のプロセスが実行中でないことを検証します。netman、 mailman、 batchman、writer、 jobman、 stageman、 JOBMON、 tokensrv、 batchup。

また、どのシステム・プログラム (コマンド・プロンプトを含む) も、ディレクトリーまたはサブディレクトリーにアクセス中でないことを確認します。Windows

エクスプローラで、「管理ツール」→「サービス」パネルを閉じる必要があります。

注:

1. Windows 環境でアップグレードを行う場合は、Tivoli Token Server が稼働中である必要があります。

2. アップグレードを行う前に、conman コマンド行が実行中でないことを確認します。

v UNIX では、次のコマンドを入力します。

ps -u TWS_user

インストール・ウィザードを使用したエージェントおよびドメイン・マネージャーのアップグレード

エージェントをアップグレードし、以下の達成目標を満たす必要がある場合は、インストール・ウィザードを使用します。

安全な方法でのアップグレードの実行開始前に、実行中のすべてのプロセスを確認します。現在実行中のコマンド行がある場合は、アップグレードは実行されず、実行中のジョブがある可能性があることが通知されます。この場合、アップグレードを実行するまで待機するか、アップグレードを終了するかを決定できます。詳しくは、 144ページの『セーフ・アップグレードの実行』を参照してください。

同じアップグレード方式を使用したマスター、バックアップ・マスター、およびエージェントのアップグレード

ネットワークのすべてのワークステーション上で実行できます。

アップグレード全般にわたってユーザーをガイドするグラフィカル・インターフェースの使用

対話モードでは、ウィザードがアップグレード手順をガイドします。

UNIX と Windows の両方のオペレーティング・システムのワークステーションの管理 UNIX エージェントと Windows エージェントの両方で実行されます。

インストール・ウィザードを使用してエージェントをアップグレードするには、アップグレードするオペレーティング・システムのセットアップを実行します。

Windows オペレーティング・システムWINDOWS ディレクトリーから以下を実行します。

SETUP.exe

UNIX および Linuxoperating_system ディレクトリーから以下を実行します。

SETUP.bin


注: アップグレードを開始する前に、実行中のジョブが完了するまで製品が待機する分数は 60 です。この間隔の間にジョブが完了しない場合、アップグレードは続行されず、エラー・メッセージが表示されます。この値を変更する場合は、アップグレードを開始する前に以下のコマンドを実行します。

Windows オペレーティング・システムWINDOWS ディレクトリーから以下を実行します。

SETUP.exe -W checkJobsLoop.wait=value

UNIX および Linux オペレーティング・システムoperating_system ディレクトリーから以下を実行します。

SETUP.bin -W checkJobsLoop.wait=value

ここで、value は整数、または製品が無期限に待機する場合は -1 にします。

または、以下のようにランチパッドを開始し、Tivoli Workload Scheduler のインストールを選択します。

Windows オペレーティング・システムDVD の root ディレクトリーから launchpad.exe を実行します。

UNIX および Linux オペレーティング・システムDVD の root ディレクトリーから launchpad.sh を実行します。

インストール・ウィザードが起動したら、アップグレードするエージェントを選択し、プロンプトに従ってアップグレードを完了します。

アップグレードの際に必要なオプションの説明については、 95ページの『インストール・オプション』を参照してください。

インストール・ウィザードを使用したコネクターが存在するエージェントのアップグレード:

インストール・ウィザードを使用して、コネクターを持つ Tivoli Workload

Scheduler エージェントのバージョン 8.3 以降をアップグレードするには、アップグレードしているオペレーティング・システムのセットアップを以下のように実行します。








注: アップグレードの際に、WebSphere Application Server 管理ユーザーの名前とパスワードを求めるプロンプトが出されます。

インストール・ウィザード・パネルに従ってアップグレードを完了します。アップグレードの際に必要なエージェント・オプションの説明については、 95ページの『インストール・オプション』を参照してください。

以下のリストは、コネクターに対して入力する必要のあるフィールドについて説明しています。

プロファイルのバックアップ宛先ディレクトリーこの情報は、WebSphere Application Server (WAS) プロファイルのバックアップを実行するために必要です。現在の設定が自動的に WebSphere

Application Server に転送されます。

Tivoli Workload Scheduler ユーザー・パスワードエージェントとコネクター・インスタンスをアップグレードする際に使用する Tivoli Workload Scheduler ユーザーのパスワードを入力します。WebSphere Application Server 管理者ユーザー名およびパスワードを前のインストールから変更している場合は、ここでそのユーザー名およびパスワードを指定する必要があります。インストール済み環境内でこれらの値を変更していない場合は、これらのフィールドをブランクのままにしてください。

SAS サーバー認証リスナーバージョン 8.3 にのみ必要です。 Secure Association Services (SAS) がインバウンド認証要求を listen するために使用するポート。デフォルト値は31119 です。

CSIv2 サーバー認証リスナーバージョン 8.3 にのみ必要です。 Common Secure Interoperability Version 2

(CSIv2) サービスが、インバウンド・サーバー認証要求を listen するためのポート。デフォルト値は 31120 です。

CSIv2 クライアント認証リスナーバージョン 8.3 にのみ必要です。 Common Secure Interoperability Version 2

(CSIv2) サービスが、インバウンド・クライアント認証要求を listen するためのポート。デフォルト値は 31121 です。

ORB リスナーバージョン 8.3 にのみ必要です。 IIOP 通信を介した RMI に使用するポート。デフォルト値は 31122 です。

管理 HTTP トランスポートバージョン 8.3 にのみ必要です。管理コンソール・ポート。デフォルト値は 31123 です。

管理 HTTPS トランスポートバージョン 8.3 にのみ必要です。管理コンソール・セキュア・ポート。デフォルト値は 31124 です。


サイレント・インストールを使用したエージェントおよびドメイン・マネージャーのアップグレード

エージェントをアップグレードし、以下の達成目標を満たす必要がある場合は、サイレント・インストールを使用します。

安全な方法でのアップグレードの実行開始前に、実行中のすべてのプロセスを確認します。現在実行中のコマンド行がある場合は、アップグレードは実行されず、実行中のジョブがある可能性があることが通知されます。この場合、アップグレードを実行するまで待機するか、アップグレードを終了するかを決定できます。詳しくは、 144ページの『セーフ・アップグレードの実行』を参照してください。

同じインストール方式を使用したマスター、バックアップ・マスター、およびエージェントのアップグレード

ネットワークのすべてのワークステーション上で実行できます。

無人でバックグラウンドで実行される方式の使用インストールの際に使用されるすべての構成設定を追加することによってカスタマイズする応答ファイルが使用されます。その後、コマンド行からsetup コマンドを実行します。この方法で、無人インストールをバックグラウンドで実行することができます。


サイレント・インストールを使用して、バージョン 8.3 以降からエージェントをアップグレードするには、以下の該当する応答ファイルを使用して、 100ページの『サイレント・インストールの実行』に説明されている、手順に従ってください。

エージェントTWS86_UPGRADE_Agent_WIN.txtTWS86_UPGRADE_Agent_UNIX.txt

コネクターを持つエージェントTWS86_UPGRADE_Connector_and_FTA_WIN.txtTWS86_UPGRADE_Connector_and_FTA_UNIX.txt

注: アップグレードを開始する前に、実行中のジョブが完了するまで製品が待機する分数は 60 です。この間隔の間にジョブが完了しない場合、アップグレードは続行されず、エラー・メッセージが表示されます。この値を変更する場合は、応答ファイルで、説明に従って -w checkJobsLoop.wait=60 パラメーターをカスタマイズします。応答ファイルのプロパティーについて詳しくは、 336ページの『Tivoli Workload Scheduler 応答ファイルのプロパティー』を参照してください。

twsinst を使用したエージェントおよびドメイン・マネージャーのアップグレード

エージェントをアップグレードし、以下の達成目標を満たす必要がある場合は、twsinst を使用します。

安全な方法でのアップグレードの実行開始前に、実行中のすべてのプロセスを確認します。現在実行中のコマンド


行がある場合は、アップグレードは実行されず、実行中のジョブがある可能性があることが通知されます。この場合、アップグレードを実行するまで待機するか、アップグレードを終了するかを決定できます。詳しくは、 144ページの『セーフ・アップグレードの実行』を参照してください。

製品のアップグレード時の時間、ディスク・スペース、および RAM の節約アップグレード・ウィザードより 30% 少ない時間でエージェント・アップグレードを実行します。Java ベースではないため、ディスク・スペースとRAM が節約されます。

非常に単純なコマンドの使用単一の行コマンドで構成されています。


twsinst を使用して分散ネットワークまたはエンドツーエンド・ネットワーク内のTivoli Workload Scheduler エージェントをアップグレードし、動的スケジューリング機能または拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加します。ランタイム環境は、以下の目的で使用されます。

v 拡張オプション付きエージェント・ジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) 上で実行されます。

v サーバー上の Dynamic Workload Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にします。

パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。動的スケジューリング機能を追加する場合は、-tdwbport パラメーターと -tdwbhostname パラメーターを指定します (対応する説明を参照してください)。拡張オプション付きのジョブ・タイプを実行するための Java ランタイムをエージェントに追加する場合は、-addjruntime パラメーターを指定します (対応する説明を参照してください)。

twsinst を使用してインストールされたエージェントについて詳しくは、 106ページの『twsinst を使ったエージェントのインストール』を参照してください。サポートされるオペレーティング・システムおよび要件のリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27012175 を参照してください。

注: 前のバージョンがインストール・ウィザードを使用してインストールされたTivoli Workload Scheduler を、twsinst スクリプトを使用してバージョン 8.6

にアップグレードした後に、Tivoli Workload Scheduler のそのインスタンスを再度アップグレードするには、twsinst 方式しか使用できなくなります。ただし、ウィザードを使用してその Tivoli Workload Scheduler インスタンスをアンインストールすることはできます。

アップグレードの実行:

アップグレード・プロセス中に、インストール手順ごとに、twsinst によって以下のディレクトリーにファイルが作成されます。



UNIX および Linux オペレーティング・システムの場合/user's_home/TWS

Windows オペレーティング・システムの場合C:¥%Program Files%¥IBM¥TWA

インストールを停止して再開した場合は、インストール・プロセスは停止されたときのインストール・ステップから開始されます。

twsinst スクリプトを使用してエージェントをアップグレードするには、以下の手順を実行します。


1. 当該オペレーティング・システム用のインストール DVD を挿入します。 31ページの『インストール・メディア』を参照してください。

2. DVD_root/TWS/operating_system ディレクトリーから、以下に説明されている概要を使用して、twsinst スクリプトを実行します。


1. オペレーティング・システム用の DVD を挿入します。 31ページの『インストール・メディア』を参照してください。

2. 製品のアップグレードを行うワークステーションで administrator としてログインします。

3. DVD の DVD_root/TWS/operating_system ディレクトリーから、以下に説明されている概要を使用して、twsinst を実行します。

注: Windows 用 twsinst は、CScript および WScript モードで実行できる Visual Basic Script (VBS) です。

twsinst を使用したアップグレードが正常に実行された場合は、戻りコード RC = 0

が出されます。アップグレードが失敗した場合は、戻りコード RC = 1 が出されます。インストールが失敗した場合については、「Tivoli Workload Automation メッセージおよびコード」を参照してください。

概要:


コマンドの使用法とバージョンの表示./twsinst -u | -v

インスタンスのアップグレード./twsinst -update -uname user_name[-addjruntime boolean][-backup_dir backup_dir][-displayname agentname][-hostname host_name][-inst_dir install_dir][-jmport port_number][-jmportssl boolean][-lang lang-id][-nobackup][-reset_perm]


[-skip_usercheck][-tdwbhostname host_name][-tdwbport port_number][-wait minutes]


コマンドの使用法とバージョンの表示twsinst -u | -v

インスタンスのアップグレードtwsinst -update -uname user_name-password user_password[-addjruntime boolean][-backup_dir backup_dir][-displayname agentname][-domain user_domain][-hostname host_name][-inst_dir install_dir][-jmport port_number][-jmportssl boolean][-lang lang_id][-nobackup][-skip_usercheck][-tdwbhostname host_name][-tdwbport port_number][-wait minutes]

-addjruntime拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加します。ランタイム環境は、エージェント上でアプリケーション・ジョブ・プラグインを実行するため、およびサーバー上の Dynamic Workload Broker

リソース・コマンドを、エージェントからリモートで実行する機能を有効にするために使用されます。パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。有効な値は true

および false です。デフォルトは false です。

-backup_dir backup_dir

旧バージョンのバックアップ・コピーを格納するディレクトリー。手動で作成する必要があります。アップグレードが失敗した場合は、ここに格納したファイルを使用しても旧バージョンをリストアすることはできません。IBM ソフトウェア・サポートに連絡して、このパスを知らせる必要があります。

アップグレードを実行するときにこのオプションを指定しない場合、以下のデフォルト値が使用されます。

$BACKUP_DIR = $INST_DIR_backup_$TWS_USER

ここで、

v $INST_DIR は、インストール・パス (UNIX および Linux ではユーザー・ホーム・ディレクトリー) です。

v $TWS_USER は、ユーザー名。

例:

$INST_DIR=/opt/TWS/TWS84$TWS_USER=user84$BACKUP_DIR=/opt/TWS/TWS83_backup_user83$BACKUP_SUBDIR=/opt/TWS/TWS83_backup_user83/TWS84


-displayname動的エージェントに割り当てる名前。デフォルトは、このコンピューターのホスト名です。

-domain user_domain

Windows のみ。Tivoli Workload Scheduler ユーザーのドメイン名。デフォルトは、製品のアップグレードを行うワークステーションの名前です。

-hostnameDynamic Workload Broker がエージェントと通信するときに使用する完全修飾ホスト名。

-inst_dir install_dir

Tivoli Workload Scheduler をインストールしたディレクトリー。以下のような場合は、アップグレード時に、inst_dir が使用されます。

v アップグレード・プロセスがレジストリーから製品のインストール場所を取得できない場合。

v アップグレード前に Tivoli Workload Scheduler のレジストリーを作成し直す必要がある場合。詳しくは、 189ページの『twsinst を使用したレジストリー・ファイルの再作成』を参照してください。

inst_dir を指定しないと、Tivoli Workload Scheduler は、インストール・レジストリーからその値を取得できません。製品は、ユーザーのホーム・ディレクトリーにインストールされます。

UNIX および Linux オペレーティング・システムの場合:パスにブランクを含めることはできません。指定しなければ、パスはuser_name のホーム・ディレクトリーに設定されます。

Windows オペレーティング・システムの場合:ブランクを含むパスを指定する場合は、それを二重引用符で囲みます。指定しなければ、パスは %ProgramFiles%¥IBM¥TWA に設定されます。

-jmport

Tivoli Workload Scheduler for z/OS サーバーまたは Dynamic Workload Broker

が Tivoli Workload Scheduler エージェントに接続するために使用するポート。デフォルト値は 31114 です。有効範囲は、1 から 65535 です。

-jmportsslTivoli Workload Scheduler for z/OS Controller、または Dynamic Workload

Broker が Tivoli Workload Scheduler エージェントに接続するときに使用するポート。この番号は ita.ini ファイルに登録されます。このファイルは、Windows では ITA¥cpa¥ita にあり、UNIX では ITA/cpa/ita にあります。 SSL

を使用する通信の場合、jmportssl = true を設定します。Dynamic Workload

Broker と通信するには、この値を true に設定することをお勧めします。この場合、jmport で指定されるポートが HTTPS で通信します。 true を指定する場合、z/OS コントローラー上でも HTTPS 通信を構成していることを確認します。HTTP 通信の場合は false を指定します。この場合、jmport で指定されるポートが HTTP で通信します。デフォルト値は true です。 SSL を使用しないで通信する場合には、jmportssl = false を設定します。Tivoli Workload

Scheduler for z/OS サーバーのパフォーマンスを向上させるには、この値をfalse に設定することをお勧めします。


-langtwsinst メッセージが表示される言語。指定しなければ、システム LANG が使用されます。関連するカタログがない場合、デフォルトの C 言語カタログが使用されます。

注: -lang オプションは、サポートされる言語パックとは関連していません。デフォルトでは、twsinst スクリプトを使用してインストールするとき、サポートされるすべての言語パックがインストールされます。

-nobackupアップグレード・プロセスでは、アップグレードしているインスタンスはバックアップされません。

-password user_password

Windows のみ。Tivoli Workload Scheduler をアップグレードする対象となるユーザーのパスワード。

-reset_permUNIX のみ。libatrc ライブラリーに対する許可をリセットします。

-skip_usercheck社内での認証プロセスが標準的なものではない場合には、このオプションを使用可能にして、それによってデフォルトの認証オプションを使用不可にします。UNIX では、/etc/password ファイル内のユーザー、または su コマンドを使用しているユーザーの検査をスキップします。Windows では、-uname username

パラメーターに指定したユーザーを作成しません。このパラメーターを指定する場合は、スクリプトを実行する前にユーザーを手動で作成する必要があります。

-tdwbhostnameDynamic Workload Broker の完全修飾ホスト名。これは、-tdwbporttdwbport_number パラメーターと共に使用されます。ワークロードを動的に実行する機能が Tivoli Workload Scheduler に追加され、開始されます。このパラメーターを指定しなければ、ワークロードを動的に実行することはできません。このパラメーターのデフォルト値は、localhost です。この値は、JobManager.ini

ファイルの ResourceAdvisorUrl プロパティーに登録されます。

-tdwbport分散環境またはエンドツーエンド環境に、動的スケジューリング機能を追加するための Dynamic Workload Broker HTTP または HTTPS ポート番号です。これは、-tdwbhostname host_name パラメーターと共に使用されます。この番号は、JobManager.ini ファイルの ResourceAdvisorUrl プロパティーに登録されます。デフォルト値は 0 ですが、この値を 0 のままにしておくと、ワークロードを動的に実行できなくなります。動的機能を追加するにはゼロ以外の値を指定します。有効な値の範囲は、0 から 65535 までです。

-uname username

Tivoli Workload Scheduler が更新されるユーザーの名前。ソフトウェアは、このユーザーのホーム・ディレクトリーで更新されます。このユーザー名は、アップグレードを実行するユーザーと混同してはなりません。

-updatetwsinst を使用してインストールされた既存のエージェントをアップグレードします。


-wait minutes

アップグレードを開始する前に、実行中のジョブが完了するまで製品が待機する分数。この間隔の間にジョブが完了しない場合、アップグレードは続行されず、エラー・メッセージが表示されます。有効な値は、整数、または製品がいつまでも待機するように指定する -1 です。デフォルトは 60 です。

例:

このセクションには、エージェントのアップグレードに使用可能な twsinst スクリプトの例が含まれています。

ユーザーのホーム・ディレクトリー内インストールされた、動的スケジューリング機能を持たないエージェント、および拡張オプション付きジョブ・タイプを実行する Java ランタイムを持たないエージェントをアップグレードするには、以下を実行します。

./twsinst -update -uname twsuser

パス /opt/IBM/TWA にインストールされたバージョン 8.5 エージェントをアップグレードし、それに動的スケジューリング機能は付与するが、拡張オプション付きジョブ・タイプを実行する Java ランタイムは付与しない場合は、以下を実行します。

UNIX および Linux オペレーティング・システムの場合:./twsinst -update -uname twsuser -tdwbhostname mybroker.mycompany.com

-tdwbport 31116 -inst_dir /opt/IBM/TWA

Windows オペレーティング・システムの場合:twsinst -update -uname TWS_user -password qaz12qaz-tdwbhostname mybroker.mycompany.com -tdwbport 31116-inst_dir "c:¥Program Files¥IBM¥TWA"

バージョン 8.5 エージェントをアップグレードし、それに動的スケジューリング機能、および拡張オプション付きジョブ・タイプを実行する Java ランタイムを付与するには、以下を実行します。ランタイム環境は、エージェント上でアプリケーション・ジョブ・プラグインを実行するため、およびサーバー上の Dynamic Workload

Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にするために使用されます。

UNIX および Linux オペレーティング・システムの場合:./twsinst -update -uname twsuser -tdwbhostname mybroker.mycompany.com

-tdwbport 31116 -addjruntime true

Windows オペレーティング・システムの場合:twsinst -update -uname TWS_user -password qaz12qaz-tdwbhostname mybroker.mycompany.com -tdwbport 31116 -addjruntime true-inst_dir "c:¥Program Files¥IBM¥TWA"

Software Distribution の使用によるエージェントのアップグレード

このセクションでは、Software Distribution のソフトウェア・パッケージ・ブロックを使用して Tivoli Workload Scheduler エージェントのアップグレードを行う方法を説明します。Software Distribution ソフトウェア・パッケージ・ブロックを使用したアップグレード・プロセスは、アップグレードの開始前に実行中のコマンド行、プロセス、またはジョブがあるかどうかを検証しません。 170ページの『エージェン


ト・ワークステーションのアップグレード時の Tivoli Workload Scheduler のリンク解除および停止』で説明されている手順に従って、手動でそれらを停止する必要があります。

アップグレードの際、以下の機能を追加できます。



v 拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加するオプション。ランタイム環境は、エージェント上で拡張オプション付きジョブ・タイプを実行するため、およびサーバー上の Dynamic Workload

Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にするために使用されます。

ソフトウェア・パッケージ・ブロックの作成とインストール:

ソフトウェア・パッケージ・ブロック (SPB) を作成、インポート、およびインストールするには、以下のステップを完了してください。

1. 次の名前をもつソフトウェア・パッケージ・プロファイルを作成します。

FP_TWS_operating_system_<TWS_user>.8.6.00

ここで、operating_system は、インストールを行うオペレーティング・システムであり、<TWS_user> は、インストールのユーザーです。

ソフトウェア・パッケージ・ブロックをインポートする際には、wimpspo にプロファイル名を渡して、Configuration Manager エンドポイントがその名前を正しくカタログするようにする必要があります。

2. wimpspo コマンドを使用してソフトウェア・パッケージ・ブロックをインポートします。

3. wdinstsp コマンドを使用してソフトウェア・パッケージ・ブロックをインストールします。

注: wdinstsp コマンドを使用してアップグレードを行う場合には、必ずinstall_dir 変数を指定するようにしてください。前のバージョンをデフォルト以外のディレクトリーにインストールして、install_dir を指定しない場合には、Tivoli Workload Scheduler は、フレッシュ・インストールとしてインストールされます。

これらのタスクの実行の詳細な詳細については、「IBM Tivoli Configuration

Manager Software Distribution リファレンス・マニュアル」および「IBM Tivoli

Configuration Manager Software Distribution ユーザーズ・ガイド」を参照してください。

アップグレード手順の概要:

アップグレードするには、ソフトウェア・パッケージ・ブロックのインストール後に、以下の手順を実行してください。

1. Common Inventory Technology (CIT) をアップグレードします。 182ページの『Common Inventory Technology のアップグレード』を参照してください。


2. 動的機能付きのバージョン 8.5.1 フォールト・トレラント・エージェントをインストールした場合は、エージェントの動的機能をアップグレードします。 183ページの『Tivoli Workload Scheduler 動的エージェントのアップグレード』を参照してください。

3. フォールト・トレラント・エージェントをアップグレードします。このステップを実行し、標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を組み込みます。 184ページの『標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャーのアップグレード』を参照してください。

4. オプションです。拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加する場合は、 185ページの『拡張オプションを使用してジョブ・タイプを実行するための Java ランタイムのアップグレード』を参照してください。

ソフトウェア・パッケージ・ブロックは、いくつかの Tivoli Workload Scheduler パラメーターを使用してアップグレードを実行します。各変数に値を割り当てて、アップグレード対象のインストール済み環境を反映させることができます。ユーザーが値を割り当てなかった場合は、デフォルト値が割り当てられます。

Software Distribution を使用してエージェントをアップグレードする場合には、以下の変数が必要です。

v install_dir

v tws_user

v pwd (このパラメーターは UNIX でのアップグレードには必要ありません。)

v fresh_install

v upgrade

v from_release

Software Distribution パラメーターのリストについては、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。

Common Inventory Technology のアップグレード:

Common Inventory Technology (CIT) のアップグレードは、エージェントのアップグレードおよび以下の機能の追加の前に行う必要があります。



v 拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加するオプション。ランタイム環境は、以下の目的で使用されます。

– Java ランタイムを追加して、拡張オプション付きジョブ・タイプ (製品と共に提供されたタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行するため。

– サーバー上の Dynamic Workload Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にするため。


以下に示すのは、Windows およびUNIX ワークステーションで CIT をインストールするために実行するコマンドの例です。パラメーターの説明については、 116ページの『ソフトウェア・パッケージおよびパラメーター』を参照してください。

Windows オペレーティング・システム:1. wdinstsp -D CIT_ExploiterID=TWA D:¥TWS_86¥WINDOWS¥CIT_Preinstall.spb

2. wdinstsp D:¥TWS_86¥WINDOWS¥CIT.spb

UNIX および Linux オペレーティング・システム:1. wdinstsp -D CIT_ExploiterID=TWA /TWS_86/UNIX/CIT_Preinstall.spb

2. wdinstsp /TWS_86/UNIX/CIT.spb

Tivoli Workload Scheduler 動的エージェントのアップグレード:

Tivoli Workload Scheduler 動的エージェントによって、フォールト・トレラント・エージェントが V8.5.1 で使用可能な動的機能と置換されました。後者を twsinstを使用してアップグレードするには、新しい動的エージェントをインストールする必要があります。







Windows オペレーティング・システム:次の Windows の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_WINDOWS を使用したインストールについて説明しています。この例では、ドメイン・コントローラーまたは Windows ノード・エージェントにインストールしています。-D domain="domain_name" が指定されているためです。

wdinstsp-D ita_port="31112"-D host_name=IT041924-T61.rot.ibm.com-f-uy-D install_dir="C:¥ibm¥TWS¥twsuser¥TWS"-D tws_user="twsuser"-D password="twspasswd"-D startAgent="true"-D company="company_name"-D this_cpu="CPU_name"-D master_cpu="MTMDM"-D tcp_port="33311"-D domain="domain_name"-n "FP_TWS_LWA_WINDOWS_twsuser.8.6.0.00"

"C:¥Output¥TWS_VLAST¥WINDOWS¥Tivoli_LWA_WINDOWS.SPB"


UNIX および Linux オペレーティング・システム:次の UNIX の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_LINUX_I386 を使用したインストールについて説明しています。

wdinstsp-D ita_port="31112"-D host_name="IT041924-T61.rot.ibm.com"-f-uy-D install_dir="/home/twsuser/TWS"-D tws_user="twsuser"-D company="company_name"-D this_cpu="cpu_name"-D master_cpu="MTMDM"-D tcp_port="33311"-D serverName="server1"-n "FP_TWS_LWA_LINUX_I386_twsuser.8.6.0.00"

/mnt/gsa/home/s/l/user1/web/public/SPB_INSTALL/LINUX_I386/Tivoli_LWA_LINUX_I386.SPB

標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャーのアップグレード:

以下に示すのは、Windows および UNIX ワークステーションで、標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を与えて、Tivoli Workload Scheduler エージェントをアップグレードするために必要な設定値の例です。拡張オプション付きジョブ・タイプを実行する Java ランタイムをエージェントに追加することもできます。ランタイム環境は、エージェント上でアプリケーション・ジョブ・プラグインを実行するため、およびサーバー上のDynamic Workload Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にするために使用されます。詳しくは、 185ページの『拡張オプションを使用してジョブ・タイプを実行するための Java ランタイムのアップグレード』を参照してください。







Windows オペレーティング・システム:この例では、ドメイン・コントローラーまたは Windows ノード・エージェントでアップグレードを行っています。-D domain="domain_name"が指定されているためです。次の Windows の例は、ユーザー<TWS_user> およびエンドポイント Tivoli_TWS_WINDOWS を使用したバージョン 8.4 からのアップグレードについて説明しています。


wdinstsp-n "FP_TWS_WINDOWS_twsuser.8.6.0.00"-D install_dir="C:¥ibm¥TWS¥twsuser¥TWS"-D tws_user="twsuser"-D password="twspasswd"-f-uy-D company="company_name"-D this_cpu="IT041924-T61"-D master_cpu="MTMDM"-D fresh_install="false"-D upgrade="true"-D tcp_port="33311"-D domain="domain_name"-D from_release="8.4"

"C:¥Output¥TWS_VLAST¥WINDOWS¥Tivoli_TWS_WINDOWS.SPB"

UNIX および Linux オペレーティング・システム次の UNIX の例は、ユーザー <TWS_user> およびエンドポイントTivoli_TWS_LINUX_I386 を使用したバージョン 8.4 からのアップグレードについて説明しています。

wdinstsp-n FP_TWS_WINDOWS_twsuser.8.6.0.00-f-uy-D install_dir="/home/twsuser/TWS"-D tws_user="twsuser"-D company="company_name"-D this_cpu="IT041924-T61"-D master_cpu="MTMDM"-D fresh_install=false-D upgrade=true-D tcp_port="33311"-D serverName="server1"-D from_release=8.4

/mnt/gsa/home/s/l/user1/web/public/SPB_INSTALL/LINUX_I386/Tivoli_TWS_LINUX_I386.SPB

拡張オプションを使用してジョブ・タイプを実行するための Java ランタイムのアップグレード:

以下は、動的機能を持つフォールト・トレラント・エージェントのバージョン 8.5.1

と共に、拡張オプション付きジョブ・タイプをエージェントに対して実行する Java

ランタイムをインストールした場合に、その Java ランタイムをアップグレードするために必要な設定値の例です。ランタイム環境は、以下の目的で使用されます。

v エージェント上で、拡張オプション付きジョブ・タイプ (製品と共に提供されているタイプとカスタム・プラグインを通して実装された追加タイプの両方) を実行します。

v サーバー上の Dynamic Workload Broker リソース・コマンドを、エージェントからリモートで実行する機能を有効にします。









Windows オペレーティング・システム:次の Windows の例は、ユーザー <TWS_user> を使用したアップグレードについて説明しています。

wdinstsp-n "TWS_Eclipse_twsuser.8.6.0.00"-D tws_user="twsuser"-D from_release="8.4"-D install_dir="D:¥IBM¥TWA¥TWS"

D:¥output¥TWS_851¥WINDOWS¥Tivoli_Eclipse_WINDOWS.SPB

UNIX および Linux オペレーティング・システム:次の UNIX の例は、ユーザー <TWS_user>: を使用したアップグレードについて説明しています。

wdinstsp-n "TWS_Eclipse_twsuser.8.6.0.00"-D tws_user="twsuser"-D from_release=8.4-D install_dir="D:¥IBM¥TWA¥TWS"

/mnt/gsa/home/s/l/user1/web/Tivoli_Eclipse_LINUX_I386.SPB


このセクションでは、コマンド行クライアントをアップグレードする方法を説明します。

インストール・ウィザードを使用して Tivoli Workload Scheduler バージョン 8.3 以降のコマンド行クライアントをアップグレードするには、アップグレード場所のオペレーティング・システム用のセットアップを実行します。


UNIX および Linux オペレーティング・システムの場合:TWS/operating_system/SETUP.bin または TWS/SETUP.sh






インストール・ウィザードが起動した後、プロンプトに従ってアップグレードを完了します。

サイレント・インストールを使用してコマンド行クライアントをアップグレードするには、TWS86_UPGRADE_CLI.txt 応答ファイルを使用して、 100ページの『サイレント・インストールの実行』で説明されている手順に従います。

レジストリー・ファイルが破損している場合のアップグレード

スタンドアロンのフォールト・トレラント・エージェント (他のコンポーネントと共有されていないエージェント、またはコネクター機能を持たないエージェント)

をアップグレードしようとして、Tivoli Workload Scheduler のインスタンスが見つからないことを示すエラー・メッセージを受け取った場合、これは破損したレジストリー・ファイルによって引き起こされた可能性があります。製品を再インストールしないで、破損したレジストリー・ファイルを持つスタンドアロンのフォールト・トレラント・エージェントをアップグレードすることができます。Tivoli

Workload Scheduler には、必要なファイルを再作成するために実行できるリカバリー・オプションがあります。このオプションは、アップグレードを実行する対象のノードが使用できなかったり、不整合な状態になっていたりする場合に、クラスター内のノードをアップグレードするときにも使用できます。リカバリー・オプションは、製品全体を再インストールすることなく、レジストリー・ファイルおよびSoftware Distribution 情報を再作成します。

以下のアップグレード方式のいずれかを使用している場合に、リカバリー・オプションを実行できます。

v インストール・ウィザードの使用によるアップグレード

v エージェントのサイレント・アップグレードの実行

v twsinst スクリプトを使用したエージェントのアップグレード

インストール・ウィザードを使用したレジストリー・ファイルの再作成

インストール・ウィザードを使用してアップグレードを実行している間にレジストリー・ファイルを再作成する場合は、以下のステップを実行します。

1. ご使用のオペレーティング・システム用のインストール DVD を挿入します。

2. 次のいずれかのコマンドを実行します。

Windows オペレーティング・システム以下のいずれかを選択してください。

v TWS¥operating_system¥SETUP.exe -W

InstallationActions.TWA_INSTANCE_PATH=TWA_home -W

recovInstReg.run=true


v TWS¥SETUP.cmd -W InstallationActions.TWA_INSTANCE_PATH=TWA_home

-W recovInstReg.run=true

ここで、operating_system は Tivoli Workload Scheduler をアップグレードするオペレーティング・システムであり、TWA_home は Tivoli

Workload Scheduler がインストールされるディレクトリーです。

UNIX および Linux以下のいずれかを選択してください。

v TWS/operating_system/SETUP.bin -W



v TWS/SETUP.sh -W



ここで、operating_system は Tivoli Workload Scheduler をアップグレードするオペレーティング・システムであり、TWA_home は Tivoli

Workload Scheduler がインストールされるディレクトリーです。

サイレント・アップグレードを使用したレジストリー・ファイルの再作成

サイレント・アップグレード方式を使用してエージェントをアップグレードしている間にレジストリー・ファイルを再作成するには、以下のステップを実行します。

1. オペレーティング・システムに応じて、以下の応答ファイルのいずれかをローカル・ディレクトリーにコピーします。

v TWS86_UPGRADE_Agent_UNIX.txt

v TWS86_UPGRADE_Agent_WIN.txt

2. パラメーター -W recovInstReg.run=true を指定して応答ファイルを編集します。



Windows オペレーティング・システムSETUP.exe -options local_dir¥response_file.txt -silent

ここで、response_file.txt はアップグレードのために使用する応答ファイルの名前です。SETUP.exe ファイルは TWS¥operating_system にあります。

UNIX および Linux オペレーティング・システム./SETUP.bin -options local_dir/response_file.txt -silent

ここで、response_file.txt は、アップグレードのために使用する応答ファイルの名前です。SETUP.bin ファイルは、TWS/operating_system にあります。

5. summary.log ファイルに入っているインストール・メッセージを調べて、アップグレードが正常に実行されたかどうかを確認します。


twsinst を使用したレジストリー・ファイルの再作成

twsinst スクリプトを使用してエージェントをアップグレードしている間にレジストリー・ファイルを再作成するには、以下のステップを実行します。

UNIX および Linux の場合

1. 当該オペレーティング・システム用のインストール DVD を挿入します。

2. TWS/operating_system ディレクトリー (operating_system は Tivoli

Workload Scheduler をアップグレードするオペレーティング・システム)

から以下に説明されている概要を使用して、twsinst スクリプトを実行します。


1. オペレーティング・システム用の DVD を挿入します。

2. 製品のアップグレードを行うワークステーションで administrator としてログインします。

3. DVD の TWS/operating_system ディレクトリー (operating_system はTivoli Workload Scheduler をアップグレードするオペレーティング・システム) から、以下に説明されている概要を使用して twsinst を実行します。

概要:

UNIX および Linux の場合

コマンドの使用法とバージョンの表示./twsinst -u | -v

インスタンスのアップグレード./twsinst -update -uname user_name[-inst_dir install_dir[-recovInstReg true]]

例./twsinst -update -uname twsuser -inst_dir /opt/IBM/TWA-recovInstReg true


コマンドの使用法とバージョンの表示twsinst -u | -v

インスタンスのアップグレードtwsinst -update -uname user_name

-password user_password[-domain user_domain][-recovInstReg true][-inst_dir install_dir]

例twsinst -update -uname twsuser -password qaz12qaz-inst_dir "C:¥Program Files¥IBM¥TWA" -recovInstReg true

twsinst パラメーターについて詳しくは、 175ページの『アップグレードの実行』を参照してください。


機能の追加

アップグレードした製品のコンポーネントの一部に対して、機能を追加できます。


コマンド行クライアントへの言語パックの追加英語以外のサポートされている言語、またはコンピューターをインストールしたロケールの言語以外の言語でコマンド行クライアントを使用する場合は、言語パックを追加します。 200ページの『コマンド行クライアントへの言語パックの追加』を参照してください。


環境をインストール済みで、動的スケジューリング機能を有効にする場合は、 201

ページの『インストール後の動的スケジューリングの使用可能化』を参照してください。

構成

この章では、インストールの完了後に行う構成について説明します。この章は、以下のセクションに分かれています。

v 191ページの『環境変数の設定』


v 192ページの『バックアップ・マスター・ドメイン・マネージャーの構成』

v 194ページの『ドメイン・マネージャーの構成』

v 194ページの『バックアップ・ドメイン・マネージャーの構成』

v 195ページの『動的ドメイン・マネージャーの構成』

v 195ページの『バックアップ・動的ドメイン・マネージャーの構成』

v 196ページの『フォールト・トレラント・エージェントの構成』

v 197ページの『動的エージェントの構成』

v 198ページの『コマンド行クライアントの構成』

v 198ページの『WebSphere Application Server の構成』


v 201ページの『インストール後の動的スケジューリングの使用可能化』


環境変数の設定

Tivoli Workload Scheduler コンポーネントを構成する前に、環境変数を設定する必要があります。

Windows オペレーティング・システムでは、tws_env.cmd シェル・スクリプトを実行して、PATH 変数と TWS_TISDIR 変数の両方を設定します。例えば、Tivoli

Workload Scheduler が %ProgramFiles%¥IBM¥TWA¥TWS ディレクトリーにインストールされている場合は、PATH 変数を次のように設定します。

c:¥Program Files¥IBM¥TWA¥TWS;c:¥Program Files¥IBM¥TWA¥TWS¥bin

注: 複数のバージョンの Tivoli Workload Scheduler をコンピューターにインストールしている場合は、TWS_TISDIR が最新のバージョンを指していることを確認します。これは最新の文字セット変換テーブルが使用されるようにするためです。

UNIX および Linux のオペレーティング・システムでは、 tws_env シェル・スクリプトを提供して、PATH 変数と TWS_TISDIR 変数の両方を設定します。例えば、Tivoli Workload Scheduler がデフォルト・ディレクトリーの /opt/IBM/TWA/TWS

ディレクトリーにインストールされている場合は、 tws_env.sh がそれらの変数を次のように設定します。

PATH=/opt/IBM/TWA/TWS:/opt/IBM/TWA/TWS/bin:$PATHexport PATH

TWS_TISDIR=/opt//opt/IBM/TWA/TWSexport TWS_TISDIR

tws_env スクリプトには、以下の 2 つのバージョンがあります。

v tws_env.sh (Bourne および Korn シェル環境用)

v tws_env.csh (C シェル環境用)

マスター・ドメイン・マネージャーの構成

インストール時に最終ジョブ・ストリームの自動的な追加を選択しておらず、そうしたい場合には、マスター・ドメイン・マネージャーのインストール後に、このセクションのステップに従って最終ジョブ・ストリームをデータベースに追加し、JnextPlan を実行してください。このジョブ・ストリームは毎日の実動に組み込まれており、各日のジョブの開始に先立って JnextPlan が実行されます。インストールは、ワークステーションの /TWA/TWS ディレクトリーに、 final ジョブ・ストリーム定義が入っている FINAL ファイルを作成します。この FINAL を使用するか、または新規ファイルを作成してカスタマイズすることができます。最終ジョブ・ストリームのカスタマイズについて詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。

以下に示すのは、インストール後にマスター・ドメイン・マネージャーを構成する方法の例です。


2. 環境変数を設定します。『環境変数の設定』を参照してください。

3. composer コマンドを実行します。


4. 次のコマンドを実行することによって、final ジョブ・ストリーム定義をデータベースに追加します。

add FINAL

ここで、FINAL は Final ジョブ・ストリーム定義に含まれるファイルの名前です。

5. Composer コマンド行を終了します。

6. JnextPlan ジョブを実行します。

JnextPlan

このステップは、インストール後に自動化することができます。「Tivoli

Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。

7. JnextPlan が完了したら、Tivoli Workload Scheduler の状況を確認します。

conman status

Tivoli Workload Scheduler が正しく開始した場合、コマンドによって戻される状況は Batchman=LIVES になります。

8. ワークステーションの limit 値を引き上げて、ジョブが実行できるようにします。インストール後のデフォルト・ジョブ制限は 0 であるため、この時点ではジョブの実行は許可されません。ジョブ制限の値を大きくして、ジョブを実行できるようにします。例えば、ジョブを 10 まで実行できるようにする場合は、次のようにします。

conman "limit ;10"

limit コマンドにワークステーション名が指定されていない場合、デフォルト値は現在のログイン・ワークステーションになります。

注: ジョブの優先順位が HI (100) または GO (101) に等しい場合、fence>=priority でなければ、limit は無視されて limit=0 であっても実行されます。

さらに、以下の構成手順が必要となることがあります。これらの手順について詳しくは、「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

v グローバル、ローカル、およびユーザー・オプションのカスタマイズおよび構成

v アクションおよびオブジェクトに対するユーザー権限を許可するため、およびLDAP を構成するためのユーザー認証のカスタマイズおよび構成

v コンポーネント間通信の SSL または GSKit を使用可能にするための接続セキュリティーの設定

バックアップ・マスター・ドメイン・マネージャーの構成

バックアップ・マスター・ドメイン・マネージャーをインストールした後、以下の構成の手順を実行します。

1. マスター・ドメイン・マネージャーで <TWS_user> としてログインします。


2. バックアップ・マスターのユーザー名およびパスワードを useropts ファイルに追加します。「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。

3. tws_env を実行することによって、環境変数を設定します。

4. composer コマンド・インターフェースまたは Dynamic Workload Console を使用して、バックアップ・マスターを Tivoli Workload Scheduler データベース内でフル状況オートリンク・フォールト・トレラント・エージェントとして定義します。次の例では、composer を使用しています。

composernew

5. テキスト・エディターでワークステーション定義を入力します。以下に例を示します。

CPUNAME BDM1DESCRIPTION "Backup master domain mananger"OS UNIXNODE lab777TCPADDR 31111FOR MAESTRO

TYPE FTAAUTOLINK ONBEHINDFIREWALL OFFFULLSTATUS ON

end

ワークステーション定義について詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。

6. JnextPlan -for 0000 を実行して、バックアップ・マスター・ワークステーションを計画に組み込み、Symphony ファイルをそれに送信します。


7. ワークステーション制限を変更して、ジョブがワークステーションで実行できるようにします。例えば、ワークステーションで同時に実行するジョブの数を 10

に設定するには、次のようにします。

conman "limit DM1;10"

注: バックアップ・マスターにログインした場合、DM1 は必要ありません。






ドメイン・マネージャーの構成

ドメイン・マネージャーをインストールした後、以下の構成の手順を実行します。



3. composer コマンド・インターフェースまたは Dynamic Workload Console を使用して、ドメイン・マネージャーを Tivoli Workload Scheduler データベース内でフル状況オートリンク・フォールト・トレラント・エージェントとして定義します。次の例では、composer を使用し、以下を入力します。

composernew


CPUNAME DDM1DESCRIPTION "domain mananger"OS UNIXNODE lab0777TCPADDR 31111DOMAIN MDMFOR MAESTRO

TYPE MANAGERAUTOLINK ONBEHINDFIREWALL OFFFULLSTATUS ON

END


5. JnextPlan -for 0000 を実行して、ドメイン・マネージャー・ワークステーションを計画に組み込み、Symphony ファイルをそれに送信します。




conman "limit;10"

バックアップ・ドメイン・マネージャーの構成

バックアップ・ドメイン・マネージャーをインストールした後、以下の構成の手順を実行します。



3. composer コマンド・インターフェースまたは Dynamic Workload Console を使用して、バックアップ・ドメイン・マネージャーを Tivoli Workload Scheduler

データベース内でフル状況オートリンク・フォールト・トレラント・エージェントとして定義します。次の例では、composer を使用し、以下を入力します。


composernew


CPUNAME DDM1DESCRIPTION "backup domain mananger"OS UNIXNODE lab0777TCPADDR 31111DOMAIN MDMFOR MAESTRO


END


5. JnextPlan -for 0000 を実行して、バックアップ・ドメイン・マネージャー・ワークステーションを計画に組み込み、Symphony ファイルをそれに送信します。




conman "limit;10"

動的ドメイン・マネージャーの構成

動的ドメイン・マネージャーをインストールした後、以下の構成の手順を実行します。



3. JnextPlan -for 0000 を実行して、動的ドメイン・マネージャー・ワークステーションを計画に組み込み、Symphony ファイルをそれに送信します。




conman "limit;10"

バックアップ・動的ドメイン・マネージャーの構成

バックアップ・動的ドメイン・マネージャーをインストールした後、以下の構成の手順を実行します。




3. composer コマンド・インターフェースまたは Dynamic Workload Console を使用して、バックアップ動的ドメイン・マネージャーを Tivoli Workload Scheduler

データベース内でフル状況オートリンク・フォールト・トレラント・エージェントとして定義します。次の例では、composer を使用し、以下を入力します。

composernew


CPUNAME BDDM1DESCRIPTION "backup dynamic domain mananger"OS UNIXNODE lab00777TCPADDR 31111DOMAIN DYNAMICDMFOR MAESTRO


END


5. JnextPlan -for 0000 を実行して、バックアップ・動的ドメイン・マネージャー・ワークステーションを計画に組み込み、Symphony ファイルをそれに送信します。




conman "limit;10"

フォールト・トレラント・エージェントの構成

フォールト・トレラント・エージェントのインストール後には、データベース内のワークステーションを定義し、マスターからワークステーションをリンクします。Dynamic Workload Console、またはコマンド行インターフェースを使用してこのタスクを実行できます。詳しくは、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」を参照してください。次に示すのは、コマンド行インターフェースを使ってインストール後にフォールト・トレラント・エージェントを構成する方法の例です。

1. マスター・ドメイン・マネージャーに <TWS_user> としてログインします。

2. tws_env.sh を実行することによって、環境変数を設定します。

3. Tivoli Workload Scheduler データベース内にワークステーション定義を作成します。コマンド行ウィンドウを開き、以下のコマンドを入力します。


composernew

4. テキスト・エディターでワークステーション定義を入力します。例:

CPUNAME F235007_00DESCRIPTION "fault-tolerant agent"OS UNIXNODE lab235007TCPADDR 31111DOMAIN MASTERDMFOR MAESTRO

TYPE FTAAUTOLINK ONBEHINDFIREWALL OFFFULLSTATUS OFF

END

オプション -for 0000 を使用して JnextPlan を実行し、エージェント・ワークステーション定義を計画に追加し、Symphony ファイルをそれに送信します。ワークステーション定義については、「Tivoli Workload Scheduler リファレンス・ガイド」を参照してください。


5. オートリンク・パラメーターを OFF に設定する場合は、マスター・ドメイン・マネージャーから link コマンドを出して、エージェントをリンクしてそこにSymphony ファイルをダウンロードします。

conman “link workstation”



composer "limit F235007_00;10"





動的エージェントの構成

動的エージェントをインストールした後に、以下のステップを実行します。

1. オプション -for 0000 を使用して JnextPlan を実行し、動的エージェント・ワークステーション定義を計画に追加し、Symphony ファイルをそれに送信します。ワークステーション定義については、「Tivoli Workload Scheduler リファレンス・ガイド」を参照してください。





composer "limit F235007_00;10"





コマンド行クライアントの構成

コマンド行クライアントのために以下の構成手順が必要となることがあります。これらの手順について詳しくは、「Tivoli Workload Scheduler: 管理ガイド」を参照してください。

v グローバルおよびローカル・オプションのカスタマイズおよび構成



WebSphere Application Server の構成

インストール後に、いずれかの Tivoli Workload Automation 製品を管理する複数のWebSphere Application Server のインスタンスがある場合、それらの LTPA

token_key が同一であることを確認する必要があります。「Tivoli Workload

Scheduler: 管理ガイド」を参照してください。

機能の追加

このセクションでは、ネットワークのインストールまたはアップグレードの後に以下の機能のいずれかをご使用の環境に追加する方法について説明します。


コマンド行クライアントへの言語パックの追加英語以外のサポートされている言語、またはコンピューターをインストールしたロケールの言語以外の言語でコマンド行クライアントを使用する場合


は、言語パックを追加します。 200ページの『コマンド行クライアントへの言語パックの追加』を参照してください。


コネクターの追加

既存のインストール済み環境にコネクター・インスタンスを追加するには、以下の手順を実行してください。

1. グラフィカル・インストールでは、インストール DVD から 36ページの『Launchpad』の説明に従ってランチパッドを開始し、Tivoli Workload Scheduler

のインストールを選択します。または、インストールするオペレーティング・システムのセットアップを実行します。

DVD から以下を実行します。


UNIX および Linux オペレーティング・システムの場合:TWS/SETUP.sh または TWS/operating_system/SETUP.bin


2. インストール・ウィザード画面に従ってインストールを完了します。以下のリストは、インストールの際に完成させなければならない可能性のあるフィールドを説明しています。

新機能の追加コネクターを追加するエージェントを選択します。「コネクターの追加(Add connector)」が表示されます。

TWSuser パスワード<TWS_user> のパスワード。

注: コネクターを追加するエージェントの <TWS_user> が Dynamic

Workload Console をインストールするときに使用した WebSphere

Application Server 管理ユーザーとは異なる場合、 WebSphere

Application Server に対する管理アクティビティーを行う際に<TWS_user> の資格情報ではなく WebSphere Application Server 管理ユーザーの資格情報を常に使用するように特別の注意を払う必要があることを覚えておいてください。また、これらの状況により、コネクターをアンインストールする際に多少の問題が生じる可能性があることにも注意する必要があります ( 279ページの『コネクターのアンインストールが「組み込み WebSphere Application Server を開始 (Start the embedded WebSphere Application server)」ステップで失敗する』を参照してください)。


HTTP トランスポートHTTP トランスポート用のポート。デフォルト値は 31115 です。有効範囲は、1 から 65535 です。

HTTPS トランスポートセキュア HTTPS トランスポート用のポート。デフォルト値は 31116 です。有効範囲は、1 から 65535 です。

ブートストラップブートストラップまたは RMI 用のポート。デフォルト値は 31117 です。有効範囲は、1 から 65535 です。


SAS サーバー認証リスナーSecure Association Services (SAS) がインバウンド認証要求を listen するために使用するポート。デフォルト値は 31119 です。有効範囲は、1 から 65535 です。

CSIv2 サーバー認証リスナーCommon Secure Interoperability Version 2 (CSIv2) サービスが、インバウンド・サーバー認証要求を listen するためのポート。デフォルト値は31120 です。有効範囲は、1 から 65535 です。


ORB リスナーIIOP 通信を介した RMI に使用するポート。デフォルト値は 31122 です。有効範囲は、1 から 65535 です。

管理 HTTP トランスポート管理コンソール・ポート。デフォルト値は 31123 です。有効範囲は、1

から 65535 です。


注: インストール手順では、指定されたポート範囲にあるポートが使用可能かどうかチェックされます。1 つ以上のポートをほかのアプリケーションが使用中である場合は、新しいポート番号を入力するように求めるプロンプトが出されます。

コマンド行クライアントへの言語パックの追加

コマンド行クライアントに言語パックを追加するには、以下の手順を実行してください。

1. インストール DVD から、インストールするオペレーティング・システム用のセットアップを実行します。



UNIX および Linux オペレーティング・システムの場合:TWS/SETUP.sh または TWS/operating_system/SETUP.bin

2. インストール・ウィザードの言語を選択します。「OK」をクリックします。

3. 「ようこそ」情報を読みます。「次へ」をクリックします。

4. ご使用条件を読んで、条項に同意します。「次へ」をクリックします。

5. ドロップダウン・リストから、既存のコマンド行クライアントを選択します。既存のインストールは、インストール・パスによって識別されます。オプション「言語パックの追加 (Add langPack)」が自動的に選択されていることに注意してください。

6. インストールする追加の言語を選択します。「次へ」をクリックします。

7. インストール設定値を確認します。「次へ」をクリックします。

8. インストールが完了すると、パネルが正常なインストールを表示するかまたはインストールが失敗した場合にはログ・ファイルのディレクトリーを示します。「完了」をクリックします。

拡張オプションを使用してジョブ・タイプを実行するための Java ランタイムの追加

Java ランタイムを使用すると、製品と共に提供されているものとカスタム・プラグインを通して実装された追加タイプの両方の拡張オプションを持つジョブ・タイプを実行できます。

他の Tivoli Workload Scheduler コンポーネントをインストールするときに Java ランタイムをインストールしなかった場合は、wdinstsp コマンドを使用して Java ランタイム環境ソフトウェア・パッケージ・ブロックをインストールすることによって、いつでも追加できます。詳しくは、 121ページの『Java ランタイムの追加』を参照してください。

インストール後の動的スケジューリングの使用可能化

このセクションでは、動的スケジューリング機能を使用可能にしないでマスターとエージェントの両方の製品をアップグレードした場合に、動的スケジューリングを使用可能にするために従う必要がある手順について説明します。例えば、以下の方法で製品をアップグレードした場合を想定します。

インストール・ウィザードの使用以下のオプションのいずれかまたは両方を選択しなかった。

v マスターのアップグレード時に、「動的スケジューリング機能を有効にする」。

v エージェントのアップグレード時に、「動的エージェント」。

エージェントのアップグレード時に twsinst を使用-tdwbport tdwbport_number および -tdwbhostname host_name を指定しなかった。

動的スケジューリングを使用可能にするには、以下のステップを実行します。


1. tws_home/TDWB/config/BrokerWorkstation.properties ファイルで、アップグレード時に指定した値に従って次のプロパティーの値を変更します。

Broker.Workstation.Name= master_name_DWBBroker.Workstation.Port= port_numberMasterDomainManager.Name= host_nameBroker.AuthorizedCNs=server1; ... ;servern

ここで、

Broker.Workstation.Name= master_name_DWBこれは、マスター・ドメイン・マネージャー名の後に _DWB が続いたものです。この値は、_DWB サフィックスも含めて変更できます。

Broker.Workstation.Port= port_number

これは、動的ワークロード・ブローカーと通信するために Tivoli

Workload Scheduler マスター・ドメイン・マネージャーによって使用されるワークロード・ブローカー・ワークステーション上のポートです。任意の値を指定できます。Netman ポート番号が 31111 の場合、デフォルト値は 41114 です。有効範囲は、1 から 65535 です。 Netman ポート番号を変更した場合、Broker.Workstation.Port port_number は、以下のように計算されます。

netman_port_number+10003

MasterDomainManager.Name= host_name

これは、エージェントがマスター・ドメイン・マネージャーと通信するときに使用される完全修飾ホスト名です。

Broker.AuthorizedCNs=server1; ... ;servern

ブローカー・サーバーと通信する権限がある共通名マスター・ドメイン・マネージャー証明書のプレフィックスのリストです。サーバーに接続する権限を与える操作の詳細については、「Tivoli Workload Scheduler:

管理ガイド」にあるマスター・ドメイン・マネージャーと動的ドメイン・マネージャーに対する SSL 接続のカスタマイズに関するセクションを参照してください。

2. マスター・ドメイン・マネージャー上で、showHostProperties wastool の実行によって httpsPort の現行値を検証します。デフォルト値は 31116 です。出力例を以下に示します。

################################################################# Ports Configuration Panel################################################################bootPort=38317bootHost=nynewhost.romelab.ibm.it.comsoapPort=38318soapHost=mynewhost.romelab.it.ibm.comhttpEnabled=truehttpPort=21115httpHost=*httpsEnabled=truehttpsPort=31116............

3. マスター・ドメイン・マネージャー上、およびワークロード・ブローカー・サーバーに接続している各エージェント上で、以下のロケーションの下にあるJobManager.ini 構成ファイルを更新します。

v Windows オペレーティング・システムの場合:


tws_home¥TWS¥ITA¥cpa¥config¥JobManager.ini

v UNIX および Linux オペレーティング・システムの場合:

tws_home/TWS/ITA/cpa/config/JobManager.ini

ResourceAdvisorUrl プロパティーに含まれる tdwb_hostname およびtdwb_httpsport 変数に以下の値を割り当てることによって更新します。

tdwb_hostname

ワークロード・ブローカー・サーバーの完全修飾ホスト名を指定します。

tdwb_httpsport

showHostPorperties wastool によって表示されたマスター・ドメイン・マネージャー上での httpsPort の値を指定します。デフォルトは、動的ワークロード・ブローカー・ポート番号である 31116 です。インストール時に動的ワークロード・ブローカーを使用しないように指定したため、このポートは、現在ゼロに設定されています。

ResourceAdvisorUrl プロパティーの構文は以下のとおりです。

ResourceAdvisorUrl = https://<tdwb_hostname>:<tdwb_httpsport>/JobManagerRESTWeb/JobScheduler/resource

4. startBrokerApplication.sh wastool を以下のように実行して、Dynamic Workload

Broker コンポーネントを始動します。

/<TWS_home>/wastools/startBrokerApplication.sh -user user_name-password password

ここで、

user_name

WebSphere Application Server の名前を指定します。

password

WebSphere Application Server のパスワードを指定します。

5. マスター・ドメイン・マネージャー上、およびワークロード・ブローカー・サーバーに接続するネットワークの各エージェント上で、TWS_home ディレクトリーから以下のコマンドを実行することによって、Tivoli Workload Scheduler エージェントを始動します。v Windows オペレーティング・システムの場合:

StartUpLwa.cmd


StartUpLwa

アンインストール中

この章では、Tivoli Workload Scheduler をアンインストールする方法を説明します。この章は、以下のセクションに分かれています。

v 70ページの『ユーザー許可要件』

v 205ページの『動的ドメイン・マネージャーのアンインストール』

v 206ページの『ウィザードを使用したアンインストール』

v 206ページの『サイレント・アンインストールの実行』


v 207ページの『twsinst スクリプトの使用によるエージェントのアンインストール』

v 209ページの『Software Distribution CLI の使用によるアンインストール』

v 209ページの『コマンド行クライアントのアンインストール』

アンインストール・プログラムは、インストール手順の実行中に作成されます。製品をアンインストールする際には、可能な場合は常に、製品のインストール時に選択した方法と同じ方法を使用してください。例えば、インストール・ウィザードを使用して製品をインストールした場合は、後で製品を除去する際には uninstallerプログラムを使用してください。

製品のアンインストールを行っても、Tivoli Workload Scheduler のインストール後に作成したファイル、およびアンインストール時に開いていたファイルは除去されません。これらのファイルが不要な場合は、手動で除去する必要があります。再インストールする予定があり、したがってこれらのファイルを使用する必要がある場合は、インストール・プロセスを開始する前にバックアップを作成してください。アンインストールを実行しても、DB2 または Oracle データベースは除去されません。

注:

1. Tivoli Workload Scheduler エンジンは、Tivoli Workload Scheduler for

Applications およびコネクターといった、インストールできる他の製品または機能のための前提条件です。エンジンをアンインストールする前に、すべての追加機能をアンインストールしてください。

2. Tivoli Workload Scheduler の手動での削除については、「Tivoli Workload

Scheduler: 管理ガイド」を参照してください。










|

|

|

|

|

|

|

|

|

|




動的ドメイン・マネージャーのアンインストール

動的ドメイン・マネージャーを正しくアンインストールするには、以下の手順を実行してください。

1. この章で取り上げる手順のいずれかを使用して、アンインストールする動的ドメイン・マネージャーに接続している動的エージェントをアンインストールします。

2. データベースで、アンインストールする動的ドメイン・マネージャーに接続しているタイプ AGENT のワークステーションの定義を削除します。Dynamic

Workload Console ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws agent_workstation_name

3. アンインストールする動的ドメイン・マネージャーに接続しているタイプREM-ENG のワークステーションの定義を削除します。Dynamic Workload

Console ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws rem_eng_workstation_name

4. アンインストールする動的ドメイン・マネージャーに接続しているタイプ POOL

のワークステーションの定義を削除します。Dynamic Workload Console ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws pool_workstation_name

5. アンインストールする動的ドメイン・マネージャーに接続しているタイプD-POOL のワークステーションの定義を削除します。Dynamic Workload Console

ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws dpool_workstation_name

6. 206ページの『ウィザードを使用したアンインストール』または 206ページの『サイレント・アンインストールの実行』の手順を使用して、動的ドメイン・マネージャーをアンインストールします。

7. アンインストールする動的ドメイン・マネージャーがホストになっているタイプX-AGENT のワークステーションの定義を削除します。Dynamic Workload

Console ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws x-agent_workstation_name

8. アンインストールする動的ドメイン・マネージャーのタイプ BROKER のワークステーションの定義を削除します。Dynamic Workload Console ワークロード・デザイナーを使用するか、以下のコマンドを実行できます。

composer del ws broker_workstation_name


|

|

|

ウィザードを使用したアンインストール

uninstaller プログラムは、製品ファイル、レジストリー・キー、およびサービスを除去します。また、このプログラムは、インストールした Tivoli Workload

Scheduler エージェントに関連するバイナリー、分散コネクター、および言語パックも除去します。

Tivoli Workload Scheduler をアンインストールするには、以下のステップを実行してください。

1. すべての Tivoli Workload Scheduler プロセスおよびサービスが停止していること、およびアクティブ・ジョブまたは保留ジョブがないことを確認します。プロセスおよびサービスの停止について詳しくは、「管理ガイド」を参照してください。

2. twshome パスにナビゲートします。

3. 次のように、アンインストール・スクリプトを実行します。


uninstaller.exe


./uninstall.bin

4. アンインストールしたい Tivoli Workload Scheduler インスタンスを選択します。

v マスター・ドメイン・マネージャーをアンインストールする場合、ウィザードは、選択したインスタンスと、そのインスタンスにインストールされているすべての追加機能を除去します。統合された Tivoli Workload Automation からアンインストールを行っても、組み込み WebSphere Application Server は除去されません。 Tivoli Workload Scheduler アプリケーションだけが除去されます。

v エージェントをアンインストールする場合、コネクターのみをアンインストールするか、またはエージェントとコネクターを両方とも同時にアンインストールするかを選択できます。

サイレント・アンインストールの実行

マスター・ドメイン・マネージャー、バックアップマスター・ドメイン・マネージャー、動的ドメイン・マネージャー、またはバックアップ動的ドメイン・マネージャーをサイレント・アンインストールする場合は、以下のステップを実行してください。


2. /TWA/TWS/_uninstall パスにナビゲートします。



uninstaller.exe -silent



./uninstall.bin -silent

エージェント、コネクター、またはその両方をサイレント・アンインストールする場合は、以下のステップを実行してください。

1. すべての Tivoli Workload Scheduler プロセスおよびサービスが停止していること、およびアクティブ・ジョブまたは保留ジョブがないことを確認します。

2. インストール DVD の ¥TWS¥RESPONSEFILES¥ ディレクトリーにあるTWS86_UNINSTALL_Agent.txt 応答ファイルをローカル・ディレクトリーにコピーして、必要に応じて編集します。


4. /TWA/TWS/_uninstall パスにナビゲートします。



uninstaller.exe -options <local_dir>¥TWS86_UNINSTALL_Agent.txt -silent


./uninstall.bin -options <local_dir>/TWS86_UNINSTALL_Agent.txt -silent

注: サイレント・アンインストールを実行した後に再インストールを行う場合は、環境変数を正しくリセットするために、最初のシェルを閉じてから、再び開く必要があります。

twsinst スクリプトの使用によるエージェントのアンインストール

twsinst スクリプトを使用して Tivoli Workload Scheduler エージェントをアンインストールするには、以下のステップに従ってください。 twsinst を使用してインストールされたエージェントのみが twsinst を使用してアンインストールできます。オペレーティング・システムに応じて、以下のように続行します。

v UNIX、Linux、および IBM i オペレーティング・システムの場合:


2. root としてログオンし (IBM i オペレーティング・システム上では、QSECOFR としてログオンし)、ご使用のディレクトリーを/installation_dir/TWS に変更します (例えば、/home/user1/TWS で user1 はTivoli Workload Scheduler ユーザーの名前です)。

3. TWS ディレクトリーから、次のように twsinst スクリプトを実行します。

twsinst -uninst -uname username [-wait minutes][-lang lang_id]

アンインストールはインストール・フェーズで設定された言語ではなく、ロケールの言語で実行されます。コンピューターのロケール以外の言語でエージェントをアンインストールする場合は、以下のように、/installation_dir/TWS (例えば、/home/user1/TWS) から twsinst スクリプトを実行します。

./twsinst -uninst -uname user_name -lang language


ここで、language はアンインストール中に設定された言語です。



2. 製品をアンインストールするワークステーションで administrator としてログオンします。

3. installation_dir¥TWS (例えば、c:Program FilesIBMTWA) から、以下のようにtwsinst スクリプトを実行します。

twsinst -uninst -uname username [-wait minutes][-domain domain_name] [-lang lang_id]

注: Windows 用 twsinst は、CScript および WScript モードで実行できるVisual Basic Script (VBS) です。

アンインストールはインストール・フェーズで設定された言語ではなく、ロケールの言語で実行されます。コンピューターのロケール以外の言語でエージェントをアンインストールする場合は、以下のように、/installation_dir/TWS (例えば、/home/user1/TWS) から twsinst スクリプトを実行します。

twsinst -uninst -uname user_name -lang language

ここで、language はアンインストール中に設定された言語です。

-uninstTivoli Workload Scheduler をアンインストールします。

-uname username

Tivoli Workload Scheduler がアンインストールされるユーザーの名前。このユーザー名を、UNIX と Linux では root として、Windows では管理者として、IBM i では QSECOFR としてログオンしてインストールを実行するユーザーと混同しないでください

-wait minutes

アンインストールを開始する前に、実行中のジョブが完了するまで製品が待機する分数。この間隔の間にジョブが完了しない場合、アンインストールは停止し、エラー・メッセージが表示されます。有効な値は、整数、または製品がいつまでも待機するように指定する -1 です。デフォルトは 60 です。

-domain domain_name

Windows のみ。Tivoli Workload Scheduler ユーザーのドメイン名。デフォルトは、製品がアンインストールされるワークステーションの名前です。

-lang lang_id

twsinst メッセージが表示される言語。指定しなければ、システム LANG が使用されます。関連するカタログがない場合、デフォルトの C 言語カタログが使用されます。

注: -lang オプションを Tivoli Workload Scheduler のサポートされている言語パックと混同してはなりません。


以下は、最初に twsuser という名前のユーザーのためにインストールされた Tivoli

Workload Scheduler エージェントをアンインストールする twsinst スクリプトの例です。

UNIX、Linux、および IBM i オペレーティング・システムの場合:./twsinst -uninst -uname TWS_user

Windows オペレーティング・システムの場合:twsinst -uninst -uname TWS_user

Software Distribution CLI の使用によるアンインストール

Tivoli Workload Scheduler のアンインストールは、Software Distribution/Configuration

Manager コマンドを使用して行えます。切断されているターゲットからソフトウェア・パッケージをアンインストールするには、wdrmvsp コマンドを使用します。Tivoli Workload Scheduler は切断されたカタログを使用します。

すべての Tivoli Workload Scheduler プロセスおよびサービスが停止していること、およびアクティブ・ジョブまたは保留ジョブがないことを確認します。プロセスおよびサービスの停止について詳しくは、「管理ガイド」を参照してください。

例えば、UNIX 上でアンインストールするには、以下を実行します。

conman "stop;wait"conman "shut;wait"

すべての処理が停止していることを確認してください。

root として、以下を実行します。

cd <twshome>/_uninstall/CLI. ./swd_env

パッケージの名前とバージョンを表示するには、wdlssp を実行します。

wdrmvsp -f packagename.version

同じ手順を使用して、言語パック、拡張オプション付きジョブ・タイプを実行するJava ランタイム、動的エージェントをインストールするソフトウェア・パッケージ・ブロックを削除することもできます。Tivoli Workload Scheduler を手動で除去する方法については、 283ページの『Tivoli Workload Scheduler の手動によるアンインストール』を参照してください。

コマンド行クライアントのアンインストール

コマンド行クライアントは、アンインストール・ウィザードを使用するか、サイレント・アンインストールを実行することによって、アンインストールすることができます。コマンド行クライアントをアンインストールするには、以下のステップを実行してください。

1. CLI_home/_uninstall パス (CLI_home はご使用のコマンド行クライアントのインストール・パス) にナビゲートします。

2. ウィザードを使用してアンインストールするには、アンインストーラー・コマンドを実行します。



uninstaller.exe


./uninstall.bin

注: サイレント・インストールでは、-silent フラグを使用します。

Tivoli Workload Scheduler for Additional Plug-ins を使用した追加プラグインのアンインストール

ウィザードまたはサイレント方法のいずれかを使用して追加プラグインをアンインストールします。

追加プラグインをアンインストールする場合は、1 つ以上のプラグインを同時にアンインストールできます。

サイレント・インストールを使用して追加プラグインをインストールした場合は、アンインストールにも同じ手順を使用します。

追加プラグインをアンインストールするには、次のいずれかの手順を使用することができます。

ウィザード詳しくは、『ウィザードを使用したアンインストール』を参照してください。

サイレント詳しくは、 212ページの『サイレント・アンインストールを使用したアンインストール』を参照してください。

注: アンインストールできるのは、Tivoli Workload Scheduler for Additional Plug-ins

を使用してインストールした追加プラグインのみです。

ウィザードを使用したアンインストールウィザードを使用した追加プラグインのアンインストール。

ウィザードを使用して、一度に 1 つ以上のプラグインをアンインストールできます。

インストール・ウィザードを使用して製品をインストールした場合、それをアンインストール・ウィザードまたはサイレント・アンインストールのいずれかを使用してアンインストールできます。サイレント・インストールを使用して製品をインストールした場合、それをアンインストールするにはサイレント・アンインストールを使用する必要があります。

1 つ以上のプラグインをアンインストールするには、以下のステップを実行します。

1. インストール先のオペレーティング・システム用の Tivoli Workload Scheduler

for Applications DVD または eImages を挿入し、以下のように setup インストール・コマンドを実行します。


Windows オペレーティング・システムの場合:¥PLUGIN_INSTALLER ディレクトリーから以下を実行します。

setup.bat

UNIX および Linux オペレーティング･システムの場合:/PLUGIN_INSTALLER ディレクトリーから以下を実行します。

./setup.sh

アンインストール・プログラムが開始します。

2. ウィザードの言語を選択し、「OK」をクリックします。「ようこそ」パネルが表示されます。

3. 「ようこそ」の情報を読み、「次へ」をクリックします。「操作」パネルが表示されます。

4. 「アンインストール」ラジオ・ボタンを選択します。「次へ」をクリックします。「プラグイン・リスト (Plug-in list)」パネルが表示されます。

5. アンインストールする追加プラグインを選択し、「次へ」をクリックします。アンインストールするために選択したプラグインの要約が表示されます。

6. アンインストール・プロセスが開始します。アンインストールが完了すると、結果を示すパネルが表示されます。

7. 「完了」をクリックしてウィザードを終了します。

エラー・メッセージを受け取った場合は、表 12 にリストされているアンインストール・ログ・ファイルを分析します。

表 12. アンインストール・ログ・ファイル


tws4plugins_status.log 追加プラグインのアンインストール状況ログ・ファイルは、サイレント・アンインストールの場合にのみ作成されます。アンインストールが正常に完了したか、エラーが発生したかを報告します。エラーの場合、エラーの原因が、誤ったフィールド値にあるのか、手順の失敗にあるのかを示します。

アンインストール・プロセスの開始時に、このログ・ファイルは以下のディレクトリー内に作成されます。

Windows オペレーティング・システムの場合: %TEMP%¥twa¥tws4apps


$tmp¥twa¥tws4apps

アンインストール・プロセスの終了時に、ログ・ファイルはディレクトリーTivoli Workload


tws4plugins_ia_uninstall.log InstallAnywhere エラーの追加プラグイン・ログ・ファイル。

Tivoli Workload

Scheduler_installation_dir¥logs


表 12. アンインストール・ログ・ファイル (続き)


tws4plugins_uninstall.log 追加プラグインのアンインストール・ログ・ファイル。

アンインストール・プロセスの開始時に、このログ・ファイルは以下のディレクトリー内に作成されます。

Windows オペレーティング・システムの場合: %TEMP%¥twa¥tws4apps


$tmp¥twa¥tws4apps

アンインストール・プロセスの終了時に、ログ・ファイルはディレクトリーTivoli Workload


注: サイレント・モードでアンインストールして、ログ・ファイルを確認する必要がある場合は、まず tws4plugins_status.log ファイルを調べてインストール・プロセス状況を確認し、次いで詳細について tws4plugins_install.log ファイルを調べます。

サイレント・アンインストールを使用したアンインストール

ユーザー介入なしに追加プラグインをアンインストールするには、サイレント・アンインストール・プロセスを使用します。サイレント方式を使用した場合、すべてのインストール済みプラグインを同時にアンインストールしたり、一度に 1 つのプラグインをアンインストールしたりできます。

インストール・ウィザードを使用してプラグインをインストールした場合、それをアンインストール・ウィザードまたはサイレント・アンインストールのいずれかを使用してアンインストールできます。サイレント・インストールを使用してプラグインをインストールした場合、それをアンインストールするにはサイレント方式を使用する必要があります。

サイレント・モードでアンインストールを実行する場合、メッセージは表示されません。メッセージは、 211ページの表 12 にリストされているサイレント・インストール・ログ・ファイルに書き込まれます。サイレント・アンインストールが失敗した場合は、それらのログ・ファイルに書き込まれたメッセージを確認できます。

一度に 1 つ以上のプラグインをアンインストールするには、以下のコマンドを実行します。

Windows オペレーティング・システムの場合:DVD または eImages 製品の /PLUGIN_INSTALLER ディレクトリーから、以下のようにします。

setup.bat -i silent -f <response file>

ここで response file は、アンインストールするプラグインのリストを示すためにカスタマイズできるテンプレート・ファイルです。デフォルトの応答


ファイルは、TWSPlug-ins_RespFile_Uninst_windows.txt です。これはRESPONSE_FILE ディレクトリーにあります。

UNIX および Linux オペレーティング･システムの場合:DVD または eImages 製品の /PLUGIN_INSTALLER ディレクトリーから、以下のようにします。

./setup.sh -i silent -f <response file>

ここで response file は、アンインストールするプラグインのリストを示すためにカスタマイズできるテンプレート・ファイルです。デフォルトの応答ファイルは、TWSPlug-ins_RespFile_Uninst_unix.txt です。これはRESPONSE_FILE ディレクトリーにあります。

表 13 では、アンインストール時に指定できるオプションをリストしています。

表 13. サイレント・アンインストールを実行するオプション


USER_INSTALL_DIR="<path>" はい 1 つ以上の追加プラグインをアンインストールする IBM Tivoli

Workload Scheduler インストール・パスを指定します。

完全修飾パス。例えば、C:¥Program

Files¥IBM¥TWA86 にある追加プラグインをアンインストールするには、次のように指定します。

USER_INSTALL_DIR="C:¥Program Files¥IBM¥TWA86"

Windows オペレーティング・システムの場合: デフォルトのアンインストー

ル・パスは、"c:¥¥Program

Files¥¥IBM¥¥TWA" です。


デフォルトのアンインストール・パスは、/opt/IBM/TWA です。


表 13. サイレント・アンインストールを実行するオプション (続き)


PLUGINS_TO_UNDEPLOY=<plug-

in_1>,...., <plug-in_n>

はいアンインストールするプラグインに対応するプラグイン ID を、コンマで区切って指定します。

プラグイン ID を検出するには、次のアクションを実行します。

1. <TWA_HOME>¥InstallDataPlugins

¥plugin_<plug-in_name>.xml ファイルを開きます。

2. プラグインの ID 属性の値を、次のようにして識別します。

<pluginInfo version="<plug-in_version>" name="<plug-in_name>"id="<plug-in_id>" />

例えば、以下のプラグインをアンインストールするには、次のようにします。

<pluginInfo version="1.0.0.01"name="plug-in_test_diskspace"id="plug-in_test_ds" />

次の値を指定します。

PLUGINS_TO_UNDEPLOY=

plug-in_test_ds

ACTION_TYPE=<value> はいアンインストール・プロセスでプラグインに対して実行されるアクションを指定します。このケースでは、値をUNDEPLOY に設定する必要があります。

値は UNDEPLOY に設定する必要があります。

以下に示すのは、/PLUGIN_INSTALLER ディレクトリーから実行するコマンドの例です。これは応答ファイル TWSPlug-ins_RespFile_uninst_UNIX.txt を使用して、UNIX ワークステーション上でサイレント・インストールを実行します。

./setup.sh -i silent -f TWSPlug-ins_RespFile_uninst_UNIX.txt

以下の例は、Windows ワークステーションで plug-in_test_ds をアンインストールする応答ファイルを示しています。

USER_INSTALL_DIR=c:¥¥Program Files¥¥IBM¥¥TWA86FEATURE_UNINSTALL_LIST=plug-in_test_ds

インストール、マイグレーション、およびアンインストールのトラブルシューティング

この章では、Tivoli Workload Scheduler のインストール、除去、および構成とその前提条件について説明します。以下のトピックに分かれています。

v 215ページの『インストール・プロセスのログ・ファイル』


v 216ページの『失敗した対話式 InstallShield ウィザード・インストールのリカバリー』

v 227ページの『失敗したサイレント InstallShield ウィザード・インストールのリカバリー』

v 228ページの『失敗したアップグレードのリカバリー』

v 232ページの『問題のシナリオ: インストール、再インストール、アップグレード、マイグレーション、およびアンインストール』

v 281ページの『インストールのセキュリティーの影響』

v 282ページの『インストールの検証』

v 283ページの『Tivoli Workload Scheduler の手動によるアンインストール』

v 288ページの『Tivoli Workload Scheduler コネクターの手動によるアンインストール』

v 291ページの『Windows レジストリー・キーの除去』

DB2 インストールに関する問題について詳しくは、DB2 製品資料を参照してください。

インストール・プロセスのログ・ファイル

インストール・プロセスのログ・ファイルは、インストール方法に応じて、異なる命名規則を持ちます。各種のインストールに関連付けられた各種のログ・ファイルについて詳しくは、 299ページの『インストール・ログ・ファイル』を参照してください。

サポート用のログ・ファイルのパッケージ化

インストールに関して解決できない問題が発生した場合は、IBM ソフトウェア・サポートから、インストール・ログ・ファイルをすべて送信していただくようにお願いする場合があります。以下のものが含まれます。

v Tivoli Workload Scheduler の場合は、<tempDir>/TWA/tws86 ディレクトリーのすべてのファイルおよびサブディレクトリー。

v Dynamic Workload Console の場合は、<tempDir>/TWA/tdwc86 ディレクトリーのすべてのファイルおよびサブディレクトリー。

v ソフトウェア・パッケージ・ブロック・ログ・ファイル。

v DB2 インストール・ログ。

v 組み込み WebSphere Application Server のインストール・ログ。

v Software Developers Kit の場合、/tmp/TWA/sdk86 ディレクトリーのすべてのファイルとサブディレクトリー。

v Job Brokering Definition Console の場合、 /tmp/TWA/jbdc86 ディレクトリーのすべてのファイルとサブディレクトリー。

注: <tempDir>/TWA/tws86 ディレクトリーのファイルを除去、追加、または変更しないでください。これは、この動作によって、インストールが失敗するか、失敗したインストールのリカバリーが妨げられる場合があるからです。


失敗した対話式 InstallShield ウィザード・インストールのリカバリー

このセクションでは、失敗した対話式インストールのリカバリー方法について説明します。

操作がインストール中に失敗した場合は、ウィザードは次のパネルを開きます。

TVT 指示

このウィンドウおよびこのセクションの以下のウィンドウをキャプチャーするには、次の手順に従います。

1. DB2 がインストールされたコンピューターを選択します。

2. インストール・ウィザードを実行して、新規のマスター・ドメイン・マネージャーのインストールを選択します。

3. DB2 についてたずねられた場合は、既存のインスタンスの使用を選択します。

4. 要約パネルが表示された場合は、停止します。

5. DB2 を以下のように停止します。

a. DB2 ウィンドウを開きます。

b. 「db2 force application all (DB2 はアプリケーションをすべて強制)」と入力します。

c. 「db2stop」と入力します。

DB2 は停止します。

6. 「次へ」をクリックしてインストールを開始します。失敗した場合は、ガイドに記載された手順に従って、画面間をナビゲートし、画面をキャプチャーします。最良の結果を得るには、画面のサイズの調整が必要な場合があります。

注: 対話式ウィザードを使用している場合は、「閉じる」アイコン: をクリックしてウィザード・パネルを閉じないでください。閉じた場合は、ウィザードは

図 12. インストール失敗後のウィザード・パネル


再開に必要なトラブルシューティング情報を保存できません。代わりに、インストールを確実に終了する場合は、「インストールを終了 (Quit installation)」をクリックします。

ウィザードのデバッグ・モードを使用すれば、インストールのどのステップが失敗したかを確認できます。発生したエラーを訂正して、ウィザードを終了することなく、正常に完了しなかったこれらのインストール手順を再開できます。

障害が発生したら即時にこの作業を実行するか、ウィンドウを閉じて後から状態をリカバリーするかを選択できます。

手順を以下のセクションで説明します。

v 『「ステップ・リスト」ウィンドウ』

v 219ページの『ステップ・ウィンドウ』

v 222ページの『失敗したステップの訂正およびインストールの続行』

v 223ページの『ウィザードを途中から継続するか再実行するかを決定』

v 225ページの『即時に再開するか、または終了して後で再実行するかを決定する』

v 226ページの『対話式インストールの停止および再開』

v 226ページの『問題を解決するための手順の例』

「ステップ・リスト」ウィンドウ

「ステップ・リスト」ウィンドウは、インストールが失敗したか、以前停止されたインストールを再開中に ( 226ページの『対話式インストールの停止および再開』を参照) 表示されます。 218ページの図 13 は、インストール・ステップが失敗した際の「ステップ・リスト」ウィンドウの例を示しています。


ステップ・リスト・ウィンドウは、以下のように編成されています。

ステップ #インストール・シーケンス。

説明インストール・ステップの説明。Tivoli Workload Scheduler インストールのステップについては、 70ページの『インストール中』で説明されています。

ターゲットインストールが実行されているワークステーション。

状況ステップの状況。以下のいずれかになります。

作動可能ステップは、インストールする準備が整っています。

成功ステップは、正常に完了しました。

エラーステップは完了しましたが、エラーが検出されました。

保留他のステップを前提条件とするステップが失敗しました。この状態を設定しないでください。

次を実行リスト内で状況が「作動可能」に設定されている次ステップを開始します。

すべて実行リスト内で状況が「作動可能」に設定されたステップをすべて順番に開始します。

停止この状況を使用して、ステップを処理している間に処理中のステップを停止します。ステップは、「作動可能」状況に戻ります。

図 13. 障害が起きたステップを示しているステップ・リスト・ウィンドウ


エラーで停止選択されると、エラーの場合に、実行する任意のステップ (複数も可) の処理を停止します。

状況別検索表示したい状況を選択して、「検索」をクリックします。ステップ・リストには、選択した状況を持つ、ステップ・リストの最初のステップが表示されます。

状況

インストール処理エンジンの状況。以下のいずれかになります。

待機中ユーザー・アクションが必要です。

実行中ステップのインストールが進行中です。

停止現行ステップの後、エンジンは停止します。

検索中エンジンは、製品イメージを検索しています。

詳細それぞれの状況ごとに、その状況にあるステップの数を示します。同時にステップの総数も表示します。

個別のステップについて詳しくは、ステップをダブルクリックして、「ステップ」ウィンドウを開いてください。

ステップ・ウィンドウ

「ステップ・リスト」ウィンドウでステップをダブルクリックすると、「ステップ」ウィンドウが表示されます。これには 3 つのタブがあります。

「状況」タブ:

「状況」タブは、インストール手順の状況 (作動可能、成功、エラー、または保留)

を示しています。ステップの失敗の原因となった条件が除去された場合は、状況を「エラー」から「作動可能」に変更できます。以下にタブの例を示します。

「プロパティー」タブ:

図 14. ステップの「状況」タブ


「プロパティー」タブには、ステップが必要とするユーザー・パラメーターが表示されます。これらは、インストール・ウィザードで入力したパラメーター、または操作の論理に従ってウィザードが決定した値の場合があります。以下にタブの例を示します。

例えば、このタブでは、プロパティー「DB2 クライアント・フラグ」は、ウィザードによって決定された内部プロパティーです。

プロパティーは、次の 3 タイプです。

コマンド一部のステップには、コマンド・ストリングを含むプロパティーがあります。これは、決して編集してはなりません。コマンド・ストリングには、定位置パラメーターおよび生成されたパラメーターがあります。 1 文字でも変更すると、コマンドは失敗する場合があります。

編集可能なパラメーターこれらは、ステップによって使用されるパラメーターですが、ユーザーが編集することもできます。パラメーターの名前は、データを入力する際にウィザード・パネル上で使用される名前と同じです。

内部パラメーターこれらは、ウィザードによって生成されるパラメーターです。これらは、ウィザード・パネルで入力しなかったために認識可能です。例えば、上の例の画面の「DB2 クライアント・フラグ」は、DB2 サーバーまたは DB2 クライアントのどちらをインストールするかをステップに指示する内部フラグです。これらは、決して編集してはなりません。これらは、ユーザーには明らかでない方法で他のパラメーターにリンクされている場合があります。

「出力」タブ:

「出力」タブには、インストール手順のために発生した出力およびすべてのエラー、さらにはインストールによって実行されたコマンドも示されています。以下に

図 15. ステップの「プロパティー」タブ


タブの例を示します。

「出力」タブには、次の項目があります。

タイム・スタンプコマンドが実行された時刻。

戻りコード操作の戻りコード:

0 OK

図 16. ステップの「出力」タブ


1 - 9 エラー

DiagRecord固有の障害識別点。これは、支援を要求する必要がある場合に、IBM ソフトウェア・サポートに対して引用できます。

コマンド失敗したコマンド。

コマンド出力 (Command output)コマンドからの任意の出力 (戻りコードまたはエラー・メッセージ番号など)

エラー・ログ (Error log)ステップのインストール中に発生したエラーのリストを示します。

失敗したステップの訂正およびインストールの続行

失敗したステップを訂正し、インストールを続行するには、以下の手順を使用します。

1. 「出力」タブを使用して、発生した問題の内容を判別します。

2. インストールによって検出された問題の解決方法、または表示されたエラー・メッセージのヘルプを説明した本書のセクションを参照します。

3. 問題を解決するために、インストール・ウィザードで入力した値の 1 つを変更する必要がある場合は、 223ページの『ウィザードを途中から継続するか再実行するかを決定』を参照し、そこに記載されたガイドラインから、ウィザードを最初から再実行する必要があるか、または、値を訂正してウィザードを再開することが適切であるかを決定します。後者の場合は、次の手順に従います。

a. 「プロパティー」タブを選択し、必要な変更を加えます。「適用」をクリックします。

エラーの説明は、失敗したステップで編集する際に使用できないプロパティーを参照している場合があります。その場合は、次の作業を実行する必要があります。

1) 「ステップ」ウィンドウを閉じます。

2) 先行ステップをダブルクリックして、「プロパティー」タブに必要なプロパティーが含まれているかどうかを確認します。含まれていない場合は、「ステップ」ウィンドウを閉じて、次の先行ステップを試します。変更するプロパティーが見つかるまで、この作業を続行します。

プロパティーを検出した場合は、その値を変更して、失敗したステップからではなく、変更したステップから、この手順の残りのステップを続行します。

b. インストールの他のステップをステップごとに順番にダブルクリックして、そのステップの「プロパティー」タブをクリックします。上記で変更した値を持つプロパティーがステップに含まれている場合は、それに従ってプロパティーの値を変更し、「適用」をクリックします。これは、ステップ・プロパティーがインターリンクされていないために必要です。

c. 変更したステップごとに「状況」タブをクリックして、状況を「作動可能」に変更し、「適用」をクリックします。ステップ・リストが再表示されます。


4. 問題を解決するために、インストール・ウィザードで入力した値を変更する必要がない場合は、ウィザードの外部で問題を解決し、「状況」を「作動可能」に変更して、「適用」をクリックします。ステップ・リストが再表示されます。

5. どのステップが最も早く「作動可能」状況になったステップかを判別します。

6. 「作動可能」状況の最初のステップのみを実行する場合は、例えば、実行した変更が機能したことを確認するために、「次を実行 (Run next)」をクリックします。これによって、「作動可能」の状況を持つ、ステップ・リスト (ステップ番号順) の最初のステップが実行されます。ステップが正常に完了したら、同様にインストールの他のステップを順番に実行するか、「すべて実行 (Runall)」を使用します。

7. インストールを一度に再開するには、「すべて実行 (Run all)」をクリックします。ウィザードは、「作動可能」状況の最初のステップから開始して、未完了のステップをすべて完了しようとします。

ウィザードを途中から継続するか再実行するかを決定

ウィザードが問題を診断し、訂正して再開する機能を備えているということは、それを実行する必要があることを意味するものではありません。ウィザードを再実行するよりも早い場合、またはそうすることによって成功をより確信できる場合には、数多くのシナリオがあります。このセクションでは、取るべき最良のアクションを判別する際に役立ちます。

注: 失敗したインストールの診断および再開は、本書の後続のセクションの指示に従うことによって、または IBM ソフトウェア・サポートの指示に従うことによって、ガイドされる必要があるプロセスです。

失敗したインストールを診断、訂正、および再開する機能は非常に便利な場合もありますが、正しく実行されなければ、再実行するよりも労力を要する可能性があります。

次のセクションでは、各種のインストール・シナリオについて詳述し、続行すべき最良の方法を提案します。

エージェントまたはコマンド行クライアントのインストール:

エージェントまたはコマンド行クライアントをインストールしている場合は、失敗したインストールを再開するよりも、再実行する方が常に容易です。この理由は、ステップ数が少ないので、すべて再実行することができるためです。

マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、またはコネクターのインストール:

マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャー、またはコネクターをインストールする場合、次のガイドラインに従う必要があります。

失敗の理由:

失敗の理由、および問題の修正に必要な内容について考慮します。


外部の理由ウィザードが、訂正可能な外部の理由により失敗した場合、常に失敗したステップから再開できます。

例えば、マスター・ドメイン・マネージャーのインストールにおいて、ウィザードで選択したデータベース・サポートは、インストール時に実行されている必要があります。情報を提供して、RDBMS インスタンスを識別する場合、ウィザードは、このサポートが実行中であるかどうかを確認し、実行中でない場合は、エラーを戻します。ただし、RDBMS サポートが何らかの理由で実行を停止した場合、ウィザードがこのサポートが実行中であるかどうかを確認した後で、ウィザードが Tivoli Workload Scheduler データベースのインストールを開始する前に、ウィザードは停止します。この問題を解決するには、RDBMS サポートを再始動して、失敗したステップからインストールを再開します。

無効なインストール・データウィザードに提供されたデータが無効であるためにウィザードが失敗した場合、どのデータが無効であるかを検討する必要があります。

<TWS_user> ID またはパスワード<TWS_user> ID またはパスワードに何らかの問題がある場合は、インストールを終了し、再実行する必要があります。多くのステップがプロパティーとして <TWS_user> を指定しており、インストールの多くの重大な要因が <TWS_user> にリンクしているので、ID を変更して再開を試みてはなりません。

インストール・ディレクトリー<TWS_user> ID のように、これはインストールにとって重要です。提供された値に何らかの問題がある場合は、インストールを終了し、再実行する必要があります。

ポート組み込み WebSphere Application Server によって使用されるポートは、これらを入力する際にチェックされますが、ウィザードが組み込み WebSphere Application Server の構成を開始するまでに、これらの 1 つがビジーになった場合、インストールは停止します。この場合、ステップで使用しているポートの値を続行して変更し、インストールを再開できます。これは、このポートが 1 つのステップでのみ使用されるからです。

データベース・データRDBMS サポートの構成および Tivoli Workload Scheduler データベースのインストールに関連するデータは、任意またはすべてのデータベース関連のステップで使用されている場合があります。ステップの名前を確認して、使用されているかどうかを判別します。あるステップの値を変更した場合は、これらをすべて開き、この値が別のステップで使用されているかどうか確認します。

その他のデータ他のすべてのインストール・データの場合は、すべてのステップを確認して、データ項目が使用されている場所を判別します。

疑わしい場合は、インストールを再実行します。


問題の所在:

インストール中に問題が発生した場所に応じて、以下のガイドラインに従います。

初期のステップ一般に、問題が初期のステップの 1 つで発生した場合は、インストールの再実行は、ほぼ即時であり、データを訂正してインストールを再開するよりも一般的により信頼性があります。

データベースが正常にインストールされた後データベースが正常にインストールされた後で問題が発生したものの、インストールを再実行したい場合、またはデータベース構成ステップより前のある時点から再開したい場合は、データベースを除去またはアンカタログする必要はありません。これは、ウィザードが既存のデータベースを検出し、続行するからです。

再実行の前のクリーンアップ:

再実行を決定した場合は、何もクリーンアップする必要はありません。インストールされたデータ構造は、すべて上書きできます。

即時に再開するか、または終了して後で再実行するかを決定する

ウィザードの診断、訂正、および再開を決定した場合、即時にそれを実行するか、インストールを終了して、後で問題を解決するかを選択できます。

障害の診断障害を即時に診断することを選択した場合、「ステップ・リスト」ウィンドウが表示されます。詳しくは、 217ページの『「ステップ・リスト」ウィンドウ』を参照してください。

インストールの終了インストールの終了を選択した場合、インストールの進行の要約が表示され、InstallShield ウィザードは閉じられます。

インストール・ログ・ファイルを調べることによって失敗の理由を発見でき、問題を訂正し、後で再開オプションを使用してインストールを再始動できます。 226ページの『対話式インストールの停止および再開』を参照してください。

以下の考慮事項について注意してください。

v 「閉じる」アイコン: をクリックしてパネルを閉じないでください。閉じた場合は、ウィザードは再開に必要なトラブルシューティング情報を保存できません。代わりに、インストールを確実に終了する場合は、「インストールを終了(Quit installation)」をクリックします。

v インストールしていたコンポーネントに関係なく、各セットアップ試行の直近のインストールのみを再開できます。任意のコンポーネントのインストールを実行中に「要約」パネルで「次へ」をクリックするたびに、任意のコンポーネントの前のインストールに関するトラブルシューティング情報が上書きされます。同じコンピューター上で複数のインストールを再開できるようにしたい場合は、それぞれのインストールの試行が停止された後で <tempDir>/TWA/tws86 ディレクトリー全体をバックアップし、再開が必要なインストールごとに、このデータをバックアップから復元して、インストールを再開します。


対話式インストールの停止および再開

インストールはいつでも停止して途中から継続することができます。例:

v インストールは正常に実行されているが、これを一時停止して後で再開したい場合

v インストールが失敗し、コンピューターをリブートして問題を訂正したい場合

実行中の対話式インストールを停止するには、「停止」をクリックします。ウィザードは、現行ステップが完了した後でインストールを終了するかどうかをたずねます。「はい」と応答すると、インストールは実行中のステップを完了し、完了したアクティビティーの要約パネルを表示します。「完了」をクリックして終了します。

失敗したばかりのインストールを停止するには、「インストールを終了 (Quitinstallation)」を選択して、「次へ」をクリックし、選択内容を確認します。

「ステップ・リスト」ウィンドウにあるインストールを停止するには、「キャンセル」をクリックして、選択内容を確認します。

インストールを再開するには、以下のコマンドを入力します。

<setup_file_name> -resume

ここで、<setup_file_name> は、以下のいずれか 1 つです。

Windows オペレーティング・システムsetup.exe

UNIX および Linux オペレーティング・システムSETUP.bin

InstallShield ウィザードは、直前のインストールが完了していないことを認識し、「ステップ・リスト」ウィンドウが表示されます。このウィンドウを使用して、直前のインストールが停止した時点から続行できます。「ステップ・リスト」ウィンドウのステップにエラーがない場合は、インストールを再開できます。エラーがある場合は、インストール・ステップが失敗した原因となったエラーを訂正してから、これらのステップを再開する必要があります。詳しくは、 217ページの『「ステップ・リスト」ウィンドウ』を参照してください。

問題を解決するための手順の例

このセクションでは、問題を解決し、インストールを完了するための手順の例について説明します。

DB2 を使用して、Tivoli Workload Scheduler バージョン 8.3 の既存のインスタンスをアップグレードしていて、「Tivoli Workload Scheduler インスタンスの構成」ステップが失敗したと想定します。それには、いくつかの理由が考えられます。問題を解決する手順は、インストールが停止し、「障害の診断 (Diagnose Failure)」ウィンドウが表示された際に開始されます ( 216ページの図 12 を参照)。

1. 「障害の診断 (Diagnose Failure)」ウィンドウで「障害の診断 (Diagnosefailure)」を選択し、「次へ」をクリックします。「ステップ・リスト」ウィンドウが表示されます ( 218ページの図 13 を参照)。


2. 失敗したステップをダブルクリックします。この場合は、「Tivoli Workload

Scheduler インスタンスの構成」ステップです。

3. 「出力」タブ ( 221ページの図 16 を参照) をクリックし、問題の原因を判別します。

4. 問題を修正します。このシナリオでは、インストール・ウィザードに最初に指定したワークステーション名が無効であると想定されます。「プロパティー」タブをクリックして、ワークステーション名を有効な値に変更します。「適用」をクリックします。

5. 「状況」タブの「状況」( 219ページの図 14 を参照) を「作動可能」に変更し、「適用」をクリックします。ステップ・リスト・ウィンドウが再び開きます。今回は、実行したすべてステップの状況が「作動可能」に設定されます。

6. 他のステップを順番にダブルクリックして、それぞれの「プロパティー」タブをクリックします。「ワークステーション名」フィールドを検出した場合は、失敗した「Tivoli Workload Scheduler インスタンスの構成」ステップの場合と同様に値を変更します。「適用」をクリックします。

7. この場合は、変更したステップはまだ実行されていないので、変更した最も初期のステップも、失敗したステップです。このステップの状況は、すでに「作動可能」に設定されており、これ以上の作業は不要です。

8. 影響のあるステップのプロパティーを確認したら、「すべて実行」をクリックします。インストール・ウィザードは、インストールを再開し、完了します。

失敗したサイレント InstallShield ウィザード・インストールのリカバリー

サイレント・ウィザードが停止した場合は、次の手順に従います。

1. インストール・ログを開き、インストールがどのポイントで失敗したかを明らかにします。インストール・ログ・ファイルの場所は、 38ページの『インストール・ログ・ファイル』で説明されています。

インストールは、2 つの異なるフェーズで実行されます。

妥当性検査段階入力パラメーターは検証されますが、インストール・アクションは実行されません。ログ・ファイルでは、入力パラメーターの検証がアクション、validateFields によって示されます。

ステップ実行段階インストールは一連のステップで実行されます。ログでは、「ステップを実行中: (Running step:)」で始まるメッセージを表示して各ステップが開始されます。

2. 問題の内容、およびそれが開始されたフェーズが判明したら、その解決方法を決定します。パラメーターを訂正するか、インストール環境で何かを変更する必要がある場合があります (例えば、より多くのディスク・スペースを作成するなど)。


3. 問題を解決したら、ウィザードを再実行または再開できます。どちらを実行するかを判別するには、 223ページの『ウィザードを途中から継続するか再実行するかを決定』を参照してください。決定した後、どのように続行するかについては、以下の指示に従ってください。

ウィザードを再実行します。検証フェーズでエラーが検出された場合は、ウィザードを再実行する必要があります。

ウィザードが「ステップ実行フェーズ」にある場合は、常に再実行できますが、ウィザードは各ステップを再実行しようとすることを考慮する必要があります。したがって、失敗したインストールの後でインストール環境をクリーンアップしてから再実行する必要がある場合があります。

入力パラメーターを変更する必要がある場合は、応答ファイルを編集します。次にサイレント・ウィザード・コマンドを最初に発行したときのように単に再発行して、ウィザードを再実行します。

ウィザードの途中から継続ステップ実行フェーズでエラーが検出された場合は、ウィザードの再開のみが可能です。途中継続オプションは、対話式ウィザードを使用します。ウィザードをサイレントに再開することはできません。これは、失敗したステップの再開には、対話が必要だからです。

ウィザードを再開するには、以下を変更して、サイレント・ウィザード・コマンドを最初に発行したときのように再発行します。

v パラメーター -resume を追加します。

v 最初に実行した場合は、パラメーター -silent を除去します。このパラメーターを除去しないと、インストールを再開できません。

対話式ウィザードの「ステップ・リスト」ウィンドウが表示され、ここでオプションとしてデータ入力パラメーターの値を変更し、失敗したステップでインストールを再開できます。 217ページの『「ステップ・リスト」ウィンドウ』を参照して、そのセクションの指示に従ってください。

失敗したアップグレードのリカバリー

アップグレードが失敗した場合は、ログまたはエラー・メッセージを収集し、IBM

ソフトウェア・サポートにお問い合わせください。

Tivoli Workload Scheduler for Additional Plug-ins サイレント・インストールの戻りコードの分析

サイレント・インストール・プロセス中に Tivoli Workload Scheduler for Additional

Plug-ins から発行されたエラー・メッセージと警告メッセージを確認します。

このセクションでは、サイレント・インストール・プロセス中に InstallAnywhere から返されるエラーと警告のメッセージを示します。

エラーと警告は 2 つの表に分けて説明します。


v デフォルトの InstallAnywhere エラー・メッセージ (表 14)

v 追加プラグイン・インストール・エラー・メッセージ ( 231ページの表 15)

サイレント・モードでインストールを実行する場合、メッセージは表示されません。メッセージは、 132ページの表 8 に示されているサイレント・インストール・ログ・ファイルに書き込まれます。

コマンド行で指定した応答ファイルが存在しない場合、またはそのファイル名が正しくない場合は、サイレント・インストール・プロセスでログ・ファイルは作成されません。サイレント・インストール・プロセスの正しい戻りコードを得るには、次のコマンドを発行してください。

start /w <silent command>

<silent command> は、サイレント・インストールを実行するために発行するコマンドです。

サイレント・インストール・プロセスでインストール・ログ・ファイルに記録されたエラー・コードは、以下の 2 つの表で調べることができます。これらの表には、エラー・メッセージの具体的な説明が記載されています。表 14 は、サイレント・インストールの実行中にログ・ファイルに記録されるデフォルト InstallAnywhere エラー・メッセージを示したものです。

表 14. デフォルトの InstallAnywhere エラー・メッセージ

エラー・コード説明

0 成功: インストールは正常に完了し、警告またはエラーは出されませんでした。(Success: The installation completed successfully without any warnings or

errors.)

1 インストールは正常に完了しましたが、インストール・シーケンスからの1 つ以上のアクションにより、警告または致命的でないエラーが生じました。(The installation completed successfully, but one or more of the actions

from the installation sequence caused a warning or a non-fatal error.)

8 1 つ以上のインストール・ステップでエラーが発生したため、サイレント・インストールが失敗しました。

-1 インストール・シーケンスからの 1 つ以上のアクションにより、致命的エラーが生じました。(One or more of the actions from the installation

sequence caused a fatal error.)

1000 ユーザーによってインストールがキャンセルされました。

1001 インストールには無効なコマンド行オプションが含まれています。(The

installation includes an invalid command-line option.)

2000 未処理エラー。(Unhandled error.)

2001 インストールで許可検査を実行できませんでした。バージョンの有効期限が切れている可能性があります。

2002 インストールのルール検査に失敗しました。(The installation failed a rules

check.)インストーラーに配置されているルール自体に障害が起こりました。(A rule placed on the installer itself failed.)


表 14. デフォルトの InstallAnywhere エラー・メッセージ (続き)


2003 サイレント・モードの未解決の依存関係により、インストーラーが終了しました。(An unresolved dependency in silent mode caused the installer to

exit.)

2004 インストール・アクションの実行中に十分なディスク・スペースが見つからなかったために、インストールが失敗しました。

2005 Windows 64 ビット・システムにインストールしようとしましたが、インストールに Windows 64 ビット・システムのサポートが含まれていないため、インストールが失敗しました。

2006 このインストーラーではサポートされていない UI モードで起動したため、インストールが失敗しました。(The installation failed because it was

launched in a UI mode that is not supported by this installer.)

3000 ランチャー固有の未処理エラー。(Unhandled error specific to a launcher.)

3001 lax.main.class プロパティー固有のエラーが原因で、インストールが失敗しました。(The installation failed due to an error specific to the lax.main.class

property.)

3002 lax.main.method プロパティー固有のエラーが原因で、インストールが失敗しました。(The installation failed due to an error specific to the

lax.main.method property.)

3003 インストールで、lax.main.method プロパティーで指定されたメソッドにアクセスできませんでした。(The installation was unable to access the method

specified in the lax.main.method property.)

3004 lax.main.method プロパティーによって生じた例外エラーが原因で、インストールが失敗しました。(The installation failed due to an exception error

caused by the lax.main.method property.)

3005 値が lax.application.name プロパティーに割り当てられていなかったため、インストールが失敗しました。(The installation failed because no value was

assigned to the lax.application.name property.)

3006 インストールで、lax.nl.java.launcher.main.class プロパティーに割り当てられている値にアクセスできませんでした。(The installation was unable to

access the value assigned to the lax.nl.java.launcher.main.class property.)

3007 lax.nl.java.launcher.main.class プロパティー固有のエラーが原因で、インストールが失敗しました。(The installation failed due to an error specific to the

lax.nl.java.launcher.main.class property.)

3008 lax.nl.java.launcher.main.method プロパティー固有のエラーが原因で、インストールが失敗しました。(The installation failed due to an error specific to

the lax.nl.java.launcher.main.method property.)

3009 インストールで、lax.nl.launcher.java.main.method プロパティーで指定されたメソッドにアクセスできませんでした。(The installation was unable to

access the method specified in the lax.nl.launcher.java.main.method property.)

4000 java.home システム・プロパティーで指定されたディレクトリーで Java 実行可能ファイルを検出できませんでした。(A Java executable could not be

found at the directory specified by the java.home system property.)


表 14. デフォルトの InstallAnywhere エラー・メッセージ (続き)


4001 インストーラー jar のパスが正しくないためにリランチャーが正しく起動されませんでした。(An incorrect path to the installer jar caused the

relauncher to launch incorrectly.)

表 15 は、プラグインの Tivoli Workload Scheduler for Additional Plug-ins サイレント・インストール時に発行されるエラー・メッセージを示したものです。

表 15. 追加プラグインの InstallAnywhere エラー・メッセージ


11 必須パラメーターに値がありません。(The required parameter does not

contain a value.)

12 応答ファイルに指定されたファイルが存在しません。(The file specified in

response file does not exist.)

13 指定されたプラグインが zip ファイルではありません。(The plug-in file

specified is not a zip file.)

14 指定されたプラグインに plugin.xml ファイルがありません。(The plug-in

you specified does not contain the plugin.xml file.)

15 インストール・プロセスで、このシステム上に Tivoli Workload Automation

インスタンスが見つかりませんでした。(The installation process does not

find a Tivoli Workload Automation instance on this system.)

16 選択されたインスタンスで、指定されたアクションを実行できません。(You cannot perform the action you specified on the selected instance.)

17 インストールを実行しているワークステーションにディスク・スペースが不足しています。(You are performing the installation on a workstation that

does not have enough disk space.)

18 指定したパスに Tivoli Workload Scheduler の有効なインストール済み環境がありません。(The path you specified does not contain a valid installation

of Tivoli Workload Scheduler.)

19 インストールを実行しているオペレーティング・システムはサポートされていません。(The operating system, where you are performing installation, is

not supported.)

20 指定したプラグインの plugin.xml ファイルに構文エラーがあります。(The

plug-in you specified contains a plugin.xml file with syntax errors.)

21 指定した plugin.xml ファイルに、プラグインに含まれていないファイルがリストされています (The plugin.xml file you specified, lists some files that

are not contained in the plug-in.)

22 応答ファイルにプラグインを指定していません。(You do not specify a

plug-in in the response file.)

23 このインスタンスには、選択したプラグインの上位バージョンが既にインストールされています。(An higher version of the selected plug-in is already

installed on this instance.)


表 15. 追加プラグインの InstallAnywhere エラー・メッセージ (続き)


24 インストールしているプラグイン (zip ファイル) に必須の jar ファイルがない、または jar ファイルが正しいパスにありません。(The plug-in (zip

file) you are installing does not contain the required jar file or the jar file is

not located in the correct path.)

25 正しいプラグイン・インストール・バージョンを使用して、選択されたプラグインをインストールできません。(You cannot install the selected

plug-in using the current plug-in installer version.)

26 インストールしているプラグイン (zip ファイル) に必須ライセンスがない、またはライセンスが正しいパスにありません。(The plug-in (zip file)

you are installing does not contain the required licences or the licences are

not located in the correct path.)

27 応答ファイルに指定した ACTION_TYPE パラメーターの値は DEPLOY または UNDEPLOY である必要があります。(The ACTION_TYPE parameter

value specified in the response file, must be DEPLOY or UNDEPLOY.)

28 応答ファイルの使用許諾契約書に同意できません。(You cannot accepted

the license agreement in the response file.)

29 インストール・プロセスで、TWARegistry.dat ファイルの更新を保存できません。(The installation process cannot save the updates for TWARegistry.dat

file.)

30 インストール・プロセスで、config.ini ファイルを更新できません。(The

installation process is unable to update the config.ini file.)

31 インストール・プロセスで、ターゲット・システム上のプラグイン・ファイルをコピーできません。(The installation process is unable to copy plug-in

files on the target system.)

32 Java 拡張がインストールされていないため、Tivoli Workload Scheduler インスタンスに選択されたプラグインをインストールできません (Cannot

install the selected plug-in on the Tivoli Workload Scheduler instance because

the Java extension is not installed)

問題のシナリオ: インストール、再インストール、アップグレード、マイグレーション、およびアンインストール

このセクションには、Tivoli Workload Scheduler コンポーネントのインストール、再インストール、アップグレード、マイグレーション、およびアンインストールによって発生する可能性がある既知の問題のシナリオが含まれています。この章は、以下のトピックに分かれています。

v 233ページの『Windows オペレーティング・システムでのインストールの問題』

v 240ページの『UNIX でのインストールの問題』

v 241ページの『HP-UX でのインストールの問題』

v 242ページの『Oracle Solaris でのインストールの問題』

v 243ページの『Linux でのインストールの問題』

v 245ページの『サイレント・インストールに関する問題』


v 246ページの『twsinst スクリプトの使用によるインストールの問題』

v 246ページの『アプリケーション・サーバーのインストールでの問題』

v 247ページの『インストールに関するその他の問題』

v 262ページの『アップグレードの問題』

v 278ページの『アンインストールの問題』

v 280ページの『フィックスパックのインストールの問題』

v

Windows オペレーティング・システムでのインストールの問題

以下のセクションでは、Windows 上でインストールする際に発生する可能性のある問題と、その回避方法について説明しています。

v 『Windows でのインストールに失敗する』.

v 234ページの『ホスト名が切り捨てられたためにインストールが失敗する』

v 234ページの『InstallShield ウィザードによるインストールが、メッセージ「CMW3202E コマンドが失敗しました (CMW3202E Command failed)」を出して失敗する』.

v 235ページの『InstallShield ウィザードのコミット・ステップが AWSDEQ024E

エラーを出して Windows で失敗する』.

v 235ページの『Windows でのインストールが警告 AWSGAB005W を受け取る』.

v 236ページの『Windows 2003 ドメインでは、アプリケーション・サーバーのインストールは、一見、資格情報の問題で失敗したように見えるが、資格情報は正しい』

v 236ページの『ユーザー・アカウントが Windows 2000 上に作成されず、システム・エラー 56b が出される』

v 237ページの『ユーザー・アカウントが Windows 上に作成されない。手動で作成する』.

v 237ページの『Windows サービスが、インストール後に開始に失敗する』

v 237ページの『インストール後、Tivoli Workload Scheduler サービスが開始されない』

v 238ページの『「SQL1219N - 専用仮想メモリーの割り振りができないために、要求が失敗しました」というエラーでインストールが失敗する』

Windows でのインストールに失敗する:

Windows ワークステーション上で InstallShield ウィザードを使用して製品のインストールを試みましたが、インストールは失敗しました。

原因および解決方法

Windows での InstallShield ウィザード・インストールの失敗の原因としては、「コントロールパネル」の「管理ツール」の「サービス」ウィンドウが開いていたことが考えられます。これは、このウィンドウが開いていると、「サービス」レジストリーを更新できないからです。

「サービス」ウィンドウを閉じて、以下のいずれか 1 つを実行します。


v 失敗したステップを再実行することによって、失敗したインストールをリカバリーするようにウィザード・オプションを選択した場合は、そのステップの状況を「作動可能」に設定して、ステップを再開できるようになります ( 216ページの『失敗した対話式 InstallShield ウィザード・インストールのリカバリー』を参照)。

v 完全にインストールを停止した場合は、インストールを再開できます ( 226ページの『対話式インストールの停止および再開』を参照)。

ホスト名が切り捨てられたためにインストールが失敗する:

15 文字よりも長いホスト名を定義したシステムに InstallShield ウィザードを使用して、Tivoli Workload Scheduler コンポーネントをインストールしています。インストールは、ホスト名の不一致により失敗します。


この問題は、Windows が原因です。ホスト名を定義すると、Windows は、ホスト名の長さに制限を設けません。ただし、15 文字よりも長いホスト名を指定すると、Windows システムをリブートして、ホスト名をアクティブにした際に、Windows

は、ホスト名を 15 文字で切り捨て、メッセージをシステム・ログに記録します。このメッセージに気付かない場合は、名前が切り捨てられたことを知らずに、フル・バージョンのホスト名をインストール・パネル上で指定します。

残念ながら、指定された長いホスト名を使用する Windows Java クラスは、名前を切り捨てないため、レポートは一致しません。

この問題を解決するには、以下のいずれか 1 つを実行します。

v ホスト名を厳密に 15 文字以下に変更し、コンピューターをリブートしてインストールを再始動します。

v 切り捨てられた名前が受け入れ可能な場合は、ステップ再始動設備 ( 216ページの『失敗した対話式 InstallShield ウィザード・インストールのリカバリー』または、 227ページの『失敗したサイレント InstallShield ウィザード・インストールのリカバリー』を参照) を使用して、指定したホスト名を切り捨てられた形式に変更し、インストールを続行します。

InstallShield ウィザードによるインストールが、メッセージ「CMW3202E コマンドが失敗しました (CMW3202E Command failed)」を出して失敗する:

InstallShield ウィザード・インストールをWindows 上で実行していますが、ウィザードがステップ「Tivoli Workload Scheduler インスタンスの構成」で失敗し、以下のようなエラー・メッセージが出されました。

"atinstall.exe"CMW3202E Command failed.


この問題の原因としては、<drive_letter>¥program (例えば、D:program) という名前のファイル (ディレクトリーではない) がインストール・ドライブ上に存在することが考えられます。このファイルを削除するか名前を変更して、失敗したステップでインストールを再開します。


InstallShield ウィザードのコミット・ステップが AWSDEQ024E エラーを出してWindows で失敗する:

InstallShield ウィザード、対話式、またはサイレントにより、Windows で Tivoli

Workload Scheduler をインストールしています。コミット・ステップが失敗し、エラー・ログには、次のようなメッセージが含まれます。

AWSDEQ024E Error owner is not of type user in :."makesec failed with error code: 1"


問題は、TMP 環境変数の無効な設定が原因である可能性があります。例えば、上記のバージョンのメッセージ AWSDEQ024E のは、変数が C.¥tmp ではなく、C:¥tmp に設定された場合に発生します。

この問題を解決するには、インストール・ウィザードを終了し、Tivoli Workload

Scheduler をアンインストールしてから、インストール・ウィザードを再実行します。 TMP 変数のみを訂正して、インストールを再開することはできません。アンインストールの実行に問題がある場合は、 283ページの『Tivoli Workload Scheduler

の手動によるアンインストール』を参照してください。

Windows でのインストールが警告 AWSGAB005W を受け取る:

Windows でのインストールが、次のエラーを受け取ります。

AWSGAB005E The account cannot be verified automatically. >Check that the supplied login and password are valid and >satisfy the local security policy.


これは、Windows ワークステーションのセキュリティー設定に依存する Windows

の既知の制約です。 <TWS_user> に指定したパスワードは完全に有効かもしれませんが、インストール・ウィザードはこれを検証できません。

この問題は、インストールを妨害しません。対話式ウィザードを使用している場合は、インストールによってこのメッセージが表示されます。これによって、「次へ」をクリックして、続行するオプションが得られます。サイレント・オプションを使用している場合は、インストールは先に進みます。

この問題を解決するには、以下のステップを実行します。

1. インストールが完了した後、指定したパスワードが正しいかどうかを確認します。正しければ、それ以上何もする必要はありません。

2. パスワードが誤っている場合は、製品が作成した Windows サービスを開始しようとすると、サービスは失敗します。Windows 機能を使用して、これらのサービスによって使用されるパスワードを変更し、<TWS_user> のパスワードに一致するようにします。このためには、サービスごとに以下のステップを実行します。

a. 「Windows サービス」パネルから、誤ったパスワードを持つ Tivoli Workload

Scheduler サービスを検出します。


b. 例えば、サービスを右クリックして、「プロパティー」を選択することによって、このサービスのプロパティーにアクセスします。

c. 「ログオン」タブをクリックします。

d. パスワードの正しい値を入力し、確認します。

e. そのサービスを開始します。

Windows 2003 ドメインでは、アプリケーション・サーバーのインストールは、一見、資格情報の問題で失敗したように見えるが、資格情報は正しい:

アプリケーション・サーバーもインストールする任意の Tivoli Workload Scheduler

コンポーネントを Windows 2003 ドメインにインストールしていますが、インストールは、アプリケーション・サーバーをインストール中のステップで失敗します。戻されたエラー・メッセージは次のとおりです。

com.ibm.websphere.security.auth.WSLoginFailedException:Authentication failed for user mdm84 with the following error messageLogon failure: unknown user name or bad password.

資格情報をチェックすると、ユーザー ID とパスワードが正しいことがわかりました。


この問題の原因として、SP2 をWindows 2003 上にインストールしていないことが考えられます。SP2 がない場合は、Windows には、「認証後にクライアントの名前を使用する」権限を設定すると、ネットワーク接続のアイコンも削除され、インストールはアプリケーション・サーバーと通信できないという、既知のバグがあります。 SP2 は、インストールの前提条件です。

以下のようにしてください。

1. Windows 2003 SP2 をインストールします。

2. 「認証後にクライアントの名前を使用する」権限が <TWS_user> だけでなく、管理者グループ、およびサービス・システム・アカウントにも適用されることを確認します。

3. インストールを再実行します。

ユーザー・アカウントが Windows 2000 上に作成されず、システム・エラー 56bが出される:

Windows 2000 オペレーティング・システム上で、ドメイン・ユーザー(domain¥user) を <TWS_user> として指定して、InstallShield ウィザード・インストールを実行中です。インストールは、次のメッセージを出して、ユーザー・アカウント作成ステージで失敗します。

WARNING: USER DOES NOT EXIST #System error <56b>


実際には問題の原因は、Windows 2000 ドメイン・サーバーとクライアントとの間の同期エラーです。アカウントを適切なユーザー・グループに追加するアカウント作成プロセスが同期化されないため、アカウント作成が失敗したような印象を与えます。


通常は、エラーに気が付くまでにアカウント作成は完了しています。したがって、この問題を解決するには、単にインストールのユーザー・アカウント作成ステップを「作動可能」に設定して、インストールを続行するだけです。

ただし、プロセスが 2 度目に失敗した場合は、ユーザーを手動で作成し、失敗したステップを再開する必要があります。

ユーザー・アカウントが Windows 上に作成されない。手動で作成する:

Windows オペレーティング・システム上で、ユーザーがまだ存在しない場合は、インストールは適切な権限により、Tivoli Workload Scheduler ユーザーを自動的に作成します。ただし、インストール中にユーザーの作成に関する問題が発生した場合は、次のステップを実行できます。

1. インストールをバックアウトします。

2. Tivoli Workload Scheduler をインストールするワークステーション上で選択した名前を指定してローカル・ユーザー・アカウントを作成します。

注: 既存のユーザー・アカウントを使用することも可能です。ただし、このユーザーが Windows 管理者グループのメンバーであることを確認してください。

3. この <TWS_user> に、次の拡張ユーザー権限を付与します。

オペレーティングシステムの一部として機能クォータの増加バッチジョブとしてログオンサービスとしてログオンローカルログオンプロセス・レベル・トークンの置き換え

4. 必要に応じて、作成したアカウントの名前を引用してインストールを再実行します。

Windows サービスが、インストール後に開始に失敗する:

Tivoli Token サービスおよび <TWS_user> サービス用の Tivoli WorkloadScheduler が、インストール後に開始に失敗した場合、<TWS_user> パスワードに問題がある可能性があります。このシナリオは『インストール後、Tivoli Workload

Scheduler サービスが開始されない』に説明があります。

インストール後、Tivoli Workload Scheduler サービスが開始されない:

Windows 上では、Tivoli Token サービス、および <TWS_user> サービス (batchup)用の Tivoli Workload Scheduler は、両方とも、初めての開始に失敗します (正常なインストールの後)。


インストール中に <TWS_user> を作成するオプションを選択しましたが、指定したパスワードにエラーが検出されました (例えば、指定されたパスワードがワークステーション上のセキュリティー・ポリシーを満たさなかった可能性があります)。再始動機能 ( 216ページの『失敗した対話式 InstallShield ウィザード・インストールのリカバリー』を参照) を使用して、状態をリカバリーしました。リカバリー・パ


ネルで最初に入力した値とは異なる値をパスワードに対して入力しました。この値は有効だったため、プログラムは先に進み、インストールを完了しました。

ただし、インストールの完了時に、リカバリー・パネルで入力した新規パスワードを使用して <TWS_user> が作成され、その一方でサービスは元のパスワード値を使用して作成されました。

これは、インストール・ウィザードがインストール手順を開始した際に、インストール変数のすべての入力を受け入れた後で、ステップの実行に必要なプロパティー(変数) を指定して、それぞれのステップを作成しためです。ステップが失敗して、「ステップ・リスト」ウィンドウが開いた場合 ( 217ページの『「ステップ・リスト」ウィンドウ』を参照)、あるステップ用に表示されたプロパティーは、他のステップのプロパティーとは完全に別個です。したがって、あるステップ用にパスワードを変更した場合 (例えば、「<TWS_user> の作成 (Windows のみ)」ステップ)、それが使用された他のすべてのステップでも変更する必要があります (例えば、「Tivoli Workload Scheduler インスタンスの構成」ステップ。 222ページの『失敗したステップの訂正およびインストールの続行』を参照)。

インストールが完了した後でこの問題を解決するには、「Tivoli Workload Scheduler

管理ガイド」で説明した手順に従って、サービスのパスワードを、リカバリー・パネルで入力した値に変更する必要があります。

インストールが完了する前にこの問題に気付いた場合は、前の段落で説明したように、インストールを続行して、後でパスワードを変更するか、「Tivoli Workload

Scheduler 計画およびインストール」で説明した手順に従って、インストールを終了し、インストールした内容をすべてアンインストールして、インストールを再実行するかを選択できます。

「SQL1219N - 専用仮想メモリーの割り振りができないために、要求が失敗しました」というエラーでインストールが失敗する:

Windows 上の DB2 でマスター・ドメイン・マネージャーをインストールする際、「SQL1219N - 専用仮想メモリーの割り振りができないために、要求が失敗しました」というエラーでインストールが失敗します。


専用仮想メモリーの割り振りができないために、要求が失敗しました。これは、DB2 管理者が Administrators グループの一員でないために生じる可能性があります。DB2 管理者を Administrators グループに追加しなければなりません。以下の手順を実行してください。

1. インストール・ウィザードを取り消します。

2. DB2 管理者 (例えば db2admin) を Administrators グループに追加します。

3. ワークステーションを再始動します。

4. インストールを再開します。

AIX でのインストールの問題

AIX でインストールする際に次の問題が発生する可能性があります。

v 239ページの『AIX で ISMP インストールがハングする』


v 『AIX 6100-05 で ISMP インストールがハングする』

AIX で ISMP インストールがハングする:

ISMP ウィザードを対話モードで使用中にインストールがハングします。


これが発生した場合は、以下を行います。

1. 対話式インストールを取り消します。

2. すでに実行済みのインストール・アクションをすべてバックアウトするには、216ページの『失敗した対話式 InstallShield ウィザード・インストールのリカバリー』で説明されている指示に従います。

3. インストールをサイレント・モードで実行します。

サイレント ISMP インストールを実行する手順については、「Tivoli Workload

Scheduler 計画およびインストール」の第 3 章を参照してください。

AIX 6100-05 で ISMP インストールがハングする:

AIX 6100-05 へのインストール時に、認証情報 (ユーザー ID とパスワード) の検証に関する問題が発生したことを示すメッセージが生成されます。


次のエラーを受け取ります。

<2011.05.04 14:14:32 - Configure the Tivoli Workload Scheduler database (nc118226)>Installation completed with errors <<<---/tmp/TWA/tws86/scripts/createdb_root.shTWS86 TRUE TWS86_ND nc118227.romelab.it.ibm.com 50000 db2inst1******** DUMMY FALSE FALSE FALSE<OUT [AWSJIS038E An internal error has occurred.An unspecified internal error has occurred during the installation process.Checking nodeChecking for database existenceError in attaching to the node TWS86_ND.Check out the node TWS86_ND in the DB2 node catalogand the supplied authentication data (username/password)

CMW3202E Command failed. RC: 3]ERR [AWSJIS031E An internal error has occurred. An internal program has failed.]

認証情報 (ユーザー ID とパスワード) は正しい値になっています。問題を解決するには、以下のステップを実行します。

1. /tmp/TWA/tws86/scripts/createdb_root.sh スクリプトで、以下の行を変更します。

su - $DB2_ADMINISTRATOR -c "cd $TWS_TEMPDIR/scripts &&./dbsetup.sh $TWSDBNAME $TWSCLIENTFLAG $1 $2 $3 $4 ’$5’ $6 $7 $8 $9"

以下のように変更します。

su - $DB2_ADMINISTRATOR -c "source .profile && cd $TWS_TEMPDIR/scripts &&./dbsetup.sh $TWSDBNAME $TWSCLIENTFLAG $1 $2 $3 $4 ’$5’ $6 $7 $8 $9"

2. /tmp/TWA/tws86/DWB/scripts/createdb_root.sh スクリプトで、以下の行を変更します。


su - $LOCAL_DB2_USER -c "cd $SCRIPT_DIR &&./dbmigrate.sh $1 $2 ’$3’ $4 $5"

以下のように変更します。

su - $LOCAL_DB2_USER -c "source .profile && cd $SCRIPT_DIR &&./dbsetup.sh $1 $2 ’$3’ $4 $5"

3. 失敗したステップをもう一度実行します。

UNIX でのインストールの問題

以下の問題が発生する可能性があります。

v 『Java 仮想マシン (JVM) の検証に関する問題により、UNIX でのインストールが失敗する』

v 『UNIX の TWS_user に誤ったパスワードが指定された』

Java 仮想マシン (JVM) の検証に関する問題により、UNIX でのインストールが失敗する:

UNIX でのインストール中に、Java 仮想マシン (JVM) の検証に関する問題があることを示すメッセージを受け取りました。


これは、タイムアウトの問題が原因の可能性があります。InstallShield ウィザードは、インストールした JVM のバージョンを検証するために、その操作中、デフォルトの 5 秒のタイムアウトを使用します。さまざまな理由により、このタイムアウトでは不十分である可能性があります。

次のパラメーターを追加してインストール・ウィザード (対話式またはサイレント)

を再起動します。

-is:jvmtimer 10

これによってタイムアウトが 10 秒に拡張され、これが機能しない場合は、20 秒に拡張してみることができます。引き続き、JVM が正しく検証しない場合は、IBM

ソフトウェア・サポートに支援を依頼してください。

UNIX の TWS_user に誤ったパスワードが指定された:

UNIX の TWS_user に対して誤ったパスワードが指定されました。該当するエラー・メッセージが表示されますが、このメッセージは、パスワードの入力時ではなく、ステップごとのインストール中に表示されます。リカバリーの方法を決定する必要があります。


TWS_user パスワードは、技術的な理由から入力時に UNIX 上でチェックすることはできません。誤ったパスワードが指定されると、ウィザードがすでに Tivoli

Workload Scheduler データベースおよび組み込み WebSphere Application Server を正常にインストールした後で、製品のインストールを試みるまで、エラーは検出されません。

この状態からリカバリーするには、以下の作業を行ってください。


1. ウィザードを終了します。

2. アプリケーション・サーバー・ディレクトリー、$WAS_HOME/eWAS/ を削除します。ここで、$WAS_HOME は、組み込み WebSphere Application Server のインストール・パスを含む環境変数です。

3. ウィザードを再実行します。

4. 必要に応じて TWS_user に正しいパスワードを指定します。

HP-UX でのインストールの問題


v 『HP-UX 上で InstallShield ウィザードのインストールを開始できない』

v 『InstallShield ウィザードの HP-UX でのインストールが、バンドルされた JRE

のインストール・エラーにより失敗する』

v 『InstallShield ウィザードの HP-UX でのインストールが「実行エラー」により失敗する』

HP-UX 上で InstallShield ウィザードのインストールを開始できない:

InstallShield ウィザードを使用して、HP-UX に Tivoli Workload Scheduler をインストールしようとしています。ウィザードが開始されません。


これは、インストール・プログラムが使用できるスレッドが不十分なためである可能性があります。

max_thread_proc カーネル・パラメーターを最大の 128 に設定して、インストールが開始できるようにします。

HP-UX 上で Tivoli Workload Scheduler の実行に使用する典型的なカーネル・パラメーターの詳細については、 http://www.ibm.com/support/docview.wss?rs=672

&uid=swg27012175 を参照してください。

InstallShield ウィザードの HP-UX でのインストールが、バンドルされた JRE のインストール・エラーにより失敗する:

HP-UX でインストールしていますが、必要なレベルの JRE がインストールされていません。インストール・ウィザードは、バンドルされた JRE のインストールを試みますが、失敗します。以下のメッセージを受け取ります。

Bundled JRE is not binary compatible with host OS/Arch or it is corrupt.Testing bundled JRE failed.


この問題は、HP-UX 構成パラメーター MAXDSIZ が、低すぎる値に設定されたことが原因である可能性があります。 MAXDSIZ 構成パラメーターを最大の 128 MB に設定して、インストールを再試行します。

InstallShield ウィザードの HP-UX でのインストールが「実行エラー」により失敗する:




AIX または HP-UX オペレーティング・システム上で InstallShield ウィザードを使用して、Tivoli Workload Scheduler のインストールを試みています。インストールはスレッド「メイン」に次の例外を出して失敗します。

java.lang.NoClassDefFoundError: run error

この問題については、 252ページの『InstallShield ウィザードの AIX またはHP-UX でのインストールが「実行エラー」により失敗する』で説明されています。

Oracle Solaris でのインストールの問題


Oracle Solaris でのインストールがエラー「コマンド行パラメーター、-installRootは無効です (The command line parameter, -installRoot, is invalid)」を出して失敗する:

Oracle Solaris でのコンポーネントのインストールが失敗します。以下のエラー・メッセージが戻されます。

AWSJIS038E: An unspecified internal error has occurredduring the installation process.

ERROR: The command line parameter, -installRoot, is invalidUse -usage to see the available command line optionsERROR installing WAS Express, check system stderr/stdout


問題は、誤った PATH 環境変数が原因である可能性があります。この変数は、X/Open 仕様に関連する検索パス (例えば、XPG4) の順序が誤っています。

Oracle Solaris の資料および Web サイトのサポートを参照し、PATH 変数が正しく表現されていることを確認します。検出したエラーをすべて訂正して、インストールを再試行します。

Oracle Solaris でのインストールが「SQL0101N ステートメントが長すぎるか、または複雑すぎます。SQLSTATE=54001」というエラーで失敗する:

Oracle Solaris でのコンポーネントのインストールが失敗します。DB2

/export/home/db2admin/sqllib/db2dump/db2diag.log に以下のエラー・メッセージが示されます。

SQL0101N The statement is too long or too complex. SQLSTATE=54001


この問題は、Solaris におけるカーネル・パラメーターが間違っているために生じている可能性があります。

問題を解決するには、以下のステップを実行します。

1. 例えば、home_dir などの別のディレクトリーに /tmp/TWA/tws86 ディレクトリーのコンテンツを保存します。


2. db2osconf を実行してカーネル・パラメーター設定を確認し、このコマンドによって提案されている値を設定してください。Oracle Solaris におけるカーネル・パラメーターの変更方法について記載されている IBM DB2 資料を参照してください。

3. /tmp/TWA/tws86 ディレクトリーのコンテンツを /tmp/TWA/ ディレクトリー内で復元します。

4. setup -resume コマンドを実行して、インストールをリカバリーします。

Oracle Solaris でのインストールが「SQL1084C 共有メモリー・セグメントを割り当てられません。SQLSTATE=5701 (SQL1084C Shared memory segments cannotbe allocated. SQLSTATE=5701)」というエラーで失敗する:

Oracle Solaris でのコンポーネントのインストールが失敗します。DB2

/export/home/db2admin/sqllib/db2dump/db2diag.log に以下のエラー・メッセージが示されます。

SQL1084C Shared memory segments cannot be allocated. SQLSTATE=5701


この問題は、Solaris におけるカーネル・パラメーターが間違っているために生じている可能性があります。


1. 例えば、home_dir などの別のディレクトリーに /tmp/TWA/tws86 ディレクトリーのコンテンツを保存します。

2. db2osconf を実行してカーネル・パラメーター設定を確認し、このコマンドによって提案されている値を設定してください。Oracle Solaris におけるカーネル・パラメーターの変更方法について記載されている IBM DB2 資料を参照してください。

3. /tmp/TWA/tws86 ディレクトリーのコンテンツを /tmp/TWA/ ディレクトリー内で復元します。

4. setup -resume コマンドを実行して、インストールをリカバリーします。

Linux でのインストールの問題


v 『InstallShield ウィザードの Linux でのインストールが、バンドルされた JRE のインストール・エラーにより失敗する』

v 244ページの『Linux での英語以外のインストールが正しく完了したが、Tivoli

Workload Scheduler の開始により、1 つ以上のエラーが発生した』

v Red Hat Enterprise Linux (RHEL) バージョン 5 または Suse Linux システムのバージョン 11 に Dynamic Workload Console をインストールする際の Java 仮想マシン (JVM) の障害

v 245ページの『Red Hat Enterprise Linux 6.0 でインストールが失敗する』.

InstallShield ウィザードの Linux でのインストールが、バンドルされた JRE のインストール・エラーにより失敗する:


Linux にインストールしていますが、必要なレベルの JRE がインストールされていません。インストール・ウィザードは、バンドルされた JRE のインストールを試みますが、失敗します。以下のメッセージを受け取ります。

This application requires a Java Run Time Environment (JRE)to run. Searching for one on your computer was not successful.Please use the command line switch -is:javahome to specifya valid JRE. For more help use the option -is:help.

注: この InstallShield ウィザード・メッセージで示される解決策は、機能しない可能性があります。


可能性のある原因としては、bc ユーティリティーは InstallShield ウィザードの前提条件ですが、デフォルトでは、すべての Linux プラットフォーム上にインストールされていないことが考えられます (例えば、Red Hat Linux、バージョン 2.1 では、サービス・パック 2 のみに含まれています)。

ユーティリティーの有無を確認するには、rpm レジストリー上で次の照会を実行します。rpm-q bc

ユーティリティーが欠落している場合は、オペレーティング・システムのサポート・リソースを参照して、取得方法を決定してください。正常にインストールされたら、インストールを再実行します。

Linux での英語以外のインストールが正しく完了したが、Tivoli WorkloadScheduler の開始により、1 つ以上のエラーが発生した:

Tivoli Workload Scheduler の英語以外のバージョンを Linux にインストールしましたが、製品を開始した際にエラーが発生しました。


ワークステーションのコード・ページが問題を起こしている場合があります。英語以外の言語をサポートするには、Tivoli Workload Scheduler では、コード・ページを UTF8 にする必要があります。コード・ページをリセットして、製品を再始動すれば、この問題が再発することはありません。

Red Hat Enterprise Linux (RHEL) バージョン 5 または Suse Linux システムのバージョン 11 にインストールする際の Java 仮想マシン (JVM) の障害:

問題記述

Red Hat Enterprise Linux バージョン 5 または Suse Linux システム・バージョン11 で Tivoli Workload Scheduler を処理するときに、「VM が見つかりません - 打ち切り中 (Failed to find VM - aborting)」というエラーを受け取る可能性があります。


Linux システムには、「Security Enhanced Linux」(短縮系は SELinux) という名前の新しいセキュリティー・フィーチャーがあります。Red Hat Enterprise Linux バージョン 4 には SELinux の下位バージョンが含まれており、デフォルトでは使用不可


になっています。Red Hat Enterprise Linux および Suse Linux のこれらのバージョンでは、このセキュリティー・フィーチャーがデフォルトで有効になっています。SELinux は、ある種の悪意のある攻撃からホストを保護する上で役立ちます。しかし、そのデフォルト設定では Java が正常に実行できないというケースが多く報告されています。

この問題を解決するには、以下のオプションのいずれかを選択してください。

v SELinux を構成し、Tivoli Workload Scheduler Java 関連のプロセスの実行を許可します。

v コマンド行で setenforce 0 を入力することにより、SELinux のモードを「許容(Permissive)」に変更します。次回システムのリブート時またはコマンド行にsetenforce 1 を入力すると、SELinux は再び完全に使用可能になります。Dynamic Workload Console が機能するためには、setenforce 0 を設定する必要があります。setenforce について詳しくは、ご使用のオペレーティング・システムの資料を参照してください。

Red Hat Enterprise Linux 6.0 でインストールが失敗する:

Red Hat Enterprise Linux 6.0 でインストールを起動しましたが、インストールが失敗し、以下のエラー・メッセージが twsismp.log ファイルに書き込まれます。

AWSJIS138E The specified instance name "instance_name"does not exist on the DB2 server.


この問題が発生するのは、インストール・プログラムが db2idefs ファイルを検出できないからです。


1. db2idefs ファイルの配置場所のパス (/opt/ibm/db2/V9.7/instance など) をPATH 環境変数に追加します。

2. インストールを再起動します。

サイレント・インストールに関する問題

サイレント・インストールでは、以下の問題が発生する可能性があります。

v 『サイレント・インストールがログを書き込むことなく失敗する』

サイレント・インストールがログを書き込むことなく失敗する:

サイレント・インストールを起動しましたが、ログを書き込むことなく失敗します。


応答ファイルが壊れたか、構文が誤っています。

問題を確認するには、パラメーター -is:javaconsole を追加してセットアップを実行してください。使用中のバージョンを提供されたテンプレートと比較して、応答ファイルの構文を訂正するか、読み取ることができない場合は、テンプレートから再作成します。


twsinst スクリプトの使用によるインストールの問題


v 『twsinst によるインストールが、失敗の理由を示さない戻りコードを出して失敗する』

v 240ページの『UNIX の TWS_user に誤ったパスワードが指定された』

twsinst によるインストールが、失敗の理由を示さない戻りコードを出して失敗する:

twsinst スクリプトを利用する無人インストール・プロセス中にエラーが発生した場合、文書化されていない戻りコードを表示する可能性があります。


複数の twsinst エラー状態により、失敗を知らせるエラー・メッセージで使用される同じ戻りコードが戻されます。各種のエラー状態は文書化されていません。これは、ログの他のエラー・メッセージで、正確なエラーが説明されているからです。

ログの一連のインストール・メッセージに従い、そのコンテキストから問題の理由を判別します。問題を訂正し、インストールを再実行します。

アプリケーション・サーバーのインストールでの問題


v 『アプリケーション・サーバー・プロファイルの作成が失敗する』

v 247ページの『アプリケーション・サーバーのインストールは、Windows 2003

ドメイン上で、資格情報の問題で失敗したように見えるが、資格情報は正しい』

アプリケーション・サーバー・プロファイルの作成が失敗する:

インストールがステップ「Tivoli Workload Scheduler モデル化および計画サーバー・バージョン 8.5 をロールバック・インストール」で停止します。これは、アプリケーション・サーバー・プロファイルを作成できないためです。

次のアプリケーション・サーバー・トレース・ファイルをチェックすると

次の行が検出されます (ここでは、3 行に分割して表示されています)。

変数 $WAS_HOME は、アプリケーション・サーバーがインストールされるディレクトリーです。


このエラーは、フォルダー repository が組み込み WebSphere Application Server

のインストール中に欠落していることを示しています。これは、インストール・イ

$WAS_HOME/profiles/TIPProfile.deleted/logs/wsadmin.traceout

[1/17/06 17:16:46:886 CST] 0000000a WorkSpaceMast EWKSP0020E: Error getting meta data repository root$WAS_HOME/eWAS/profiles/TIPProfile/config/.repository


メージを配置したパスで次のフォルダーが欠落したか、損傷を受けたことを意味します。

変数 $PLATFORM_IMAGES_ROOT は、選択したプラットフォーム (例えば、Solaris) のイメージの場所です。

配布メディア上の対応するファイルと、インストール・イメージをコピーした場所とを比較します。

v ファイルが異なる場合は、配布メディアから、それらを使用する場所へのインストール・イメージのコピーが正しく完了しませんでした。十分なディスク・スペースがあることを確認します。十分なディスク・スペースがあることを確認します。ftp を使用している場合は、バイナリー・オプションを使用していることを確認します。ファイルを再コピーして Tivoli Workload Scheduler コンポーネントのコンポーネントを再実行するか、配布メディアから直接、インストールを再実行します。

v ファイルが (上記で示したものと) 同じ正しいパスにあり、同じであれば、内部エラーが発生した可能性があります。IBM ソフトウェア・サポートに支援を依頼してください。

アプリケーション・サーバーのインストールは、Windows 2003 ドメイン上で、資格情報の問題で失敗したように見えるが、資格情報は正しい:

アプリケーション・サーバーもインストールする任意の Tivoli Workload Scheduler

コンポーネントを Windows 2003 ドメインにインストールしていますが、インストールは、アプリケーション・サーバーをインストール中のステップで失敗します。戻されたエラー・メッセージは次のとおりです。

com.ibm.websphere.security.auth.WSLoginFailedException:Authentication failed for user mdm84 with the following error messageLogon failure: unknown user name or bad password.

資格情報をチェックすると、ユーザー ID とパスワードが正しいことがわかりました。


原因および解決策に関しては、 236ページの『Windows 2003 ドメインでは、アプリケーション・サーバーのインストールは、一見、資格情報の問題で失敗したように見えるが、資格情報は正しい』を参照してください。

インストールに関するその他の問題

以下の各種の問題が発生する可能性があります。

v 248ページの『UNC マップ・ドライブでのインストールが失敗する』

v 248ページの『メッセージ "Error writing file = " を受け取った』

v 249ページの『メッセージ "Error writing file = 28" を受け取った』

v 250ページの『UNIX でメッセージ AWSFAB037E を受け取る』

$PLATFORM_IMAGES_ROOT/EmbeddedExpress/profileTemplates/default/documents/config/.repository


v 250ページの『マスター・ドメイン・マネージャーのインストールがメッセージAWSJIS038E で失敗する』

v 251ページの『動的ドメイン・マネージャーのインストールがメッセージAWSJIS038E で失敗する』

v 251ページの『動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストールがデータベース構成後に失敗する』

v 252ページの『NFS マウント上のインストール・イメージに関する問題によりインストールが失敗する』

v 252ページの『InstallShield ウィザードの AIX または HP-UX でのインストールが「実行エラー」により失敗する』

v 253ページの『InstallShield ウィザード「フィーチャーの追加」インストールが失敗する』

v 254ページの『ソフトウェア・パッケージ・ブロックのインストールが、メッセージ: DISSE0324E を出して失敗する』

v 255ページの『ソフトウェア・パッケージ・ブロックのインストールが正常に完了しない』

v 257ページの『インストールが失敗し、エラー AWSFAB035E が出される』

v 258ページの『swd_env script を使用して環境変数を設定したシェルからエージェント・インストールを起動すると失敗する』

v 258ページの『インストールが失敗し、エラー AWSGAB566E が出される』

v 259ページの『コミット・ステップが失敗する』

v 259ページの『同じワークステーション上で同じ名前を持つ動的エージェントのアンインストールおよび再インストール』

v 259ページの『その他の失敗』

UNC マップ・ドライブでのインストールが失敗する:

汎用命名規則 (UNC) を使用してマップされたドライブで、インストール・イメージを使用して、インストールを実行しています。ウィザードは、最初のステップで失敗します。


Tivoli Workload Scheduler インストール・ウィザードの方法論は、UNC マップ・ドライブをサポートしていません。 UNC マップされていないドライブからインストールを再実行します。

メッセージ "Error writing file = " を受け取った:

任意のオペレーティング・システムで任意のタイプのインストールを実行する際、次のエラーを受け取る場合があります。

Error writing file = There may not be enough temporary disk space.Try using -is:tempdir to use a temporary directory on a partitionwith more disk space.


特にエラー・コードが欠落している点に注意してください。これは、このメッセージが、エラー・コード 28 を出す、非常に類似したメッセージと区別される点であり、root としてログオンしていないことを示します (『メッセージ "Error writingfile = 28" を受け取った』を参照)。


通常は、このエラーは文字通りの内容を意味します。解決策は次のとおりです。

最初に、インストール・コマンドに -is:tempdir .<temp_dir_path> 変数を追加することにより、インストールが別の一時ディレクトリーを使用するよう宛先変更します。

これで解決しない場合、以下の 2 つの方法のどちらかを使用して、swdis ディレクトリーのスペースを拡大します。

v 方法 1:

別のファイル・システムで新規バージョンを作成します。手順は、次のとおりです。

1. work および backup の両サブディレクトリーを削除または名前変更し、それより大きいスペースを持つディレクトリーをファイル・システム内に再作成します。

2. ln -s コマンドを使用して、新規ディレクトリーを .swdis ディレクトリーにリンクします。

v 方法 2:

より大きなスペースを持つファイル・システム内に新規バックアップ・ディレクトリーを作成し、それをポイントするように /etc/Tivoli/swdis.ini ファイルを変更します。

次のようにして、必ず swdis.ini ファイルの正しいセクションを変更します。

– 切断されたコマンド行 (wdinstsp) を使用する InstallShield ウィザードによるローカル・サイレント・インストールを行う場合、 [#MOBILE] セクションのbackup_dir キーの値を変更します。

– Tivoli Configuration Manager を使用したリモート・インストールを行う場合は、ターゲットとして選択したエンドポイントから見た相対的なセクション(たとえば、[lab133080_aix]) を識別し、そのセクション内で backup_dir キーを変更する必要があります。

メッセージ "Error writing file = 28" を受け取った:

任意のオペレーティング・システムで任意のタイプのインストールを実行する際、次のエラーを受け取る場合があります。

Error writing file = 28 There may not be enough temporary disk space.Try using -is:tempdir to use a temporary directory on a partitionwith more disk space.


特にエラー・コード 28 に注意してください。これは、このメッセージと、エラー・コード 28 を出さない、非常に類似したメッセージとを区別する点であり、ディスク・スペースの問題を示しています ( 248ページの『メッセージ "Error writingfile = " を受け取った』を参照)。


このエラーは、厳密には文面どおりのことを意味していません。UNIX のフィックスパックのサイレント・インストールを実行している場合、およびおそらく他の特定の環境で、このエラー・メッセージは、root としてログオンしていないことを意味する可能性があります。

ワークステーションに root としてログオンしていることを確認してから、サイレント・インストールを実行します。

/SETUP.bin -options <path_to_patchInstall.txt> -silent

UNIX でメッセージ AWSFAB037E を受け取る:

twsinst スクリプトの UNIX でのインストールが、次のエラー・メッセージを出して失敗しました。

AWSFAB037E The twsinst script is being run from the wrong directory.AWSFAB038I Mount the TWS installation CD and run the twsinst utilityplaced there.


インストール DVD から、インストール中に TWS_user として指名されたユーザーのホーム・ディレクトリーへコピーされた twsinst ユーティリティーを使用して、UNIX オペレーティング・システムに Tivoli Workload Scheduler をインストールしようと試みる際に、これらのエラー・メッセージを受け取りました。インストールが失敗し、ログ・ファイルは生成されません。

twsinst を以下の場所から実行することができます。

v Tivoli Workload Scheduler DVD

v DVD のディスク・イメージ

v インストール中に TWS_user として指名されるユーザーのホーム・ディレクトリー以外の任意のローカル・ディレクトリーに配置された twsinst ユーティリティーおよびその関連ファイルのコピー。

マスター・ドメイン・マネージャーのインストールがメッセージ AWSJIS038E で失敗する:

ドメイン・マネージャーをインストールしていますが、インストールは、次のエラー・メッセージが表示され、失敗します。

AWSJIS038E An internal error has occurred.An unspecified internal error has occurred during the installation process.


さらに、対話式インストールを実行している場合は、インストール・ステップの出力がリストされ、また、サイレント・インストールを実行している場合は、¥inst_logfile_dir¥ItemConfigure_TWS_DBOut.xml ファイルに以下の情報が報告されます。

Database DDMSM already presentChecking if DDMSM is a TWS databaseDDMSM is not a TWS database.

ここで、inst_logfile_dir は、すべてのインストール・ログ・ファイルが保存されるディレクトリーです。


マスター・ドメイン・マネージャーをインストールしており、動的ドメイン・マネージャーによって既に使用されているデータベースの名前を「データベース名」フィールドに指定したために、インストールが失敗します。データベースに別の名前を指定して、インストールを再度実行します。

動的ドメイン・マネージャーのインストールがメッセージ AWSJIS038E で失敗する:

動的ドメイン・マネージャーをインストールしていますが、インストールは、次のエラー・メッセージが表示され、失敗します。

AWSJIS038E An internal error has occurred.An unspecified internal error has occurred during the installation process.

さらに、対話式インストールを実行している場合は、インストール・ステップの出力がリストされ、また、サイレント・インストールを実行している場合は、¥inst_logfile_dir¥ItemConfigure_TWS_DBOut.xml ファイルに以下の情報が報告されます。

Database TWSBM already presentChecking if TWSBM is not a TWS databaseTWSBM is a TWS database. It must be a TDWB database.One or more errors has occurred during the database setup.

ここで、inst_logfile_dir は、すべてのインストール・ログ・ファイルが保存されるディレクトリーです。


動的ドメイン・マネージャーをインストールしており、マスター・ドメイン・マネージャーによって既に使用されているデータベースの名前を「データベース名」フィールドに指定したために、インストールが失敗します。データベースに別の名前を指定して、インストールを再度実行します。

動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーのインストールがデータベース構成後に失敗する:

動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーをインストールしようとしますが、データベース構成手順の後にインストールが失敗します。

解決方法


この場合は、以下の手順を実行して、動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャーを手動でアンインストールする必要があります。

1. TWS_home_directory/TDWB/bin ディレクトリーから以下のコマンドを実行します。

exportserverdata -dbUsr <username> -dbPwd <password> [exportFile <export_file>]

ここで、

username

Tivoli Workload Scheduler データベース・サーバーにアクセスするために必要なユーザーの名前を指定します。

password

Tivoli Workload Scheduler データベース・サーバーにアクセスするために必要なユーザーのパスワードを指定します。

export_file

作成するテキスト・ファイルの名前を指定します。デフォルトはserver.properties です。

2. 作成したファイルを開き、失敗したインストールに関連した項目を削除して、そのファイルを編集します。例:

http://9.168.117.211:31115/JobManagerRESTWeb/JobScheduler

3. 以下のコマンドを実行して、データベース定義を更新します。

importserverdata -dbUsr <username> -dbPwd <password> [importFile <import_file>]

ここで、<import_file> は、exportserverdata コマンドを使用して作成したファイルの名前です。デフォルトは server.properties です。

NFS マウント上のインストール・イメージに関する問題によりインストールが失敗する:

インストール・イメージが NFS マウントにあります。インストールが失敗し、ログには次のようなメッセージが表示されます。

cannot start <file_name>No such file or directory <file_name>"

ここで、<file_name> は、インストール・イメージのディレクトリー構造のファイルです。


NFS マウントが壊れています。unmount コマンドおよび mount コマンドを順に発行することによって、NFS マウントを最新表示します。失敗したステップ (あるいは、障害の内容およびインストールの時点によっては、インストール全体) を再試行します。

InstallShield ウィザードの AIX または HP-UX でのインストールが「実行エラー」により失敗する:

AIX または HP-UX オペレーティング・システム上で InstallShield ウィザードを使用して、Tivoli Workload Scheduler のインストールを試みています。インストールはスレッド「メイン」に次の例外を出して失敗します。


java.lang.NoClassDefFoundError: run error


これは、表示、Java、およびバイナリーの問題の組み合わせが原因です。

この問題を解決するには、以下のステップを実行します。

1. Quality Pack 10 以降がインストールされていることを確認します。

2. xhost + を実行し、表示を再エクスポートします。

3. DVD のルートに位置する SETUP.bin バイナリーを使用して、インストールを再試行します。

これによって、該当するメディアが /tmp にコピーされ、そこからインストールが実行されます。

注: /tmp に十分なスペースがない場合は、-is:tempdir .<temp_dir_path> 変数を指定して SETUP.bin コマンドを実行します。

InstallShield ウィザードインストールが開始せず、メッセージ「サポートされている JVM がありません (A supported JVM is missing)」が表示される:

UNIX または Linux でインストールしており、対話式またはサイレント・インストールが開始されません。メッセージ「サポートされている Java 仮想マシンがありません (A supported Java Virtual Machine is missing)」が表示されます。


非常に低速の環境では、このインストールの問題とエラー・メッセージが発生する可能性があります。ただし、この InstallShield メッセージは正しくありません。問題は、実行している低速環境のために、InstallShield Java Virtual Machine 検証ルーチンがタイムアウトになることです。

InstallShield には、インストール・ランチャーに以下のパラメーターがあります。

-is:jvmtime timeout in seconds

ここで、timeout in seconds はインストールがタイムアウトになるまでInstallShield が待つ時間の長さです。低速の環境の場合は、このパラメーターを高い値に設定して、Java 仮想マシンの認識ルーチンの十分な時間によって、タイムアウトになる前に値を取得できるようにします。最初に、timeout in seconds パラメーターを 60 に設定し、インストールが正常に起動されるまで、それを 60 ずつ増やしていきます。

InstallShield ウィザード「フィーチャーの追加」インストールが失敗する:

ウィザードで「フィーチャーの追加」オプションを使用して、フィーチャーを既存の Tivoli Workload Scheduler インストールに追加しようとしています。ウィザードを Tivoli Workload Scheduler DVD から開始しましたが、あらかじめ、フィーチャーの DVD イメージをハード・ディスクにコピーしていました。ウィザードから


フィーチャー・インストールへのパスを指定するように依頼されると、製品 DVD

を取り出して、ハード・ディスク・パス情報を指定します。インストールは失敗します。


これは、InstallShield ウィザードに関する既知の問題です。インストールが DVD から開始された場合、InstallShield ウィザードは、DVD が DVD ドライブにあるものと見なします。

この問題を訂正するには、製品 DVD または他の任意の DVD を DVD ドライブに戻します (InstallShield ウィザードには、DVD が必要ですが、どの DVD でも構いません)。

ソフトウェア・パッケージ・ブロックのインストールが、メッセージ: DISSE0324Eを出して失敗する:

IBM Tivoli Configuration Manager のソフトウェア配布コンポーネントのソフトウェア・パッケージ・ブロックを使用するフル製品、コンポーネント、またはフィックスパックのインストールを起動しました。インストールは失敗し、以下のメッセージが表示されます。

DISSE0282E Error compressing file <file_name> in the software Package block.DISSE0324E Cannot create backup packageDISSE0005E Operation unsuccessful


ソフトウェア・パッケージ・ブロックを使用するインストールは、実行するバックアップに対して十分なスペースがあることを確認できません。バックアップには、少なくとも 80 MB のディスク・スペースが必要です。バックアップに使用されるディレクトリーは、swdis.ini ファイルの [#MOBILE] セクションにあるパラメーター backup_dir によって決定されます。以下に示すのは、ファイルのこのセクションの例です。

[#MOBILE]product_dir=/root/.swdisworking_dir=/root/.swdis/workbackup_dir=/root/.swdis/backuptrace_level=0trace_size=1000000send_timeout=300autopack_dir=/root/.swdis/autopackstaging_dir=root/.swdis/serviceuser_file_variables=/root/.swdis/swdis.varimport_libraries=spd,libecimp

このディレクトリーのスペースが不十分な場合は、上記のエラー・メッセージが表示されます。

Tivoli Configuration Manager のインストールを開始できないので、復元スクリプトtwsRestore は使用できません。リカバリー手順は以下のとおりです。

1. フル製品インストールを実行している場合は、以下のファイルおよびディレクトリーを手動で削除します。


v twsRestore.sh または twsRestore.cmd (必要に応じて)

v twsRemove.sh または twsRemove.cmd (必要に応じて)

v _uninstall ディレクトリー

2. ファイル・スペースの問題を次のように解決します。

最初に、インストール・コマンドに -is:tempdir .<temp_dir_path> 変数を追加することにより、インストールが別の一時ディレクトリーを使用するよう宛先変更します。

これで解決しない場合、以下の 2 つの方法のどちらかを使用して、swdis ディレクトリーのスペースを拡大します。

v 方法 1:

別のファイル・システムで新規バージョンを作成します。手順は、次のとおりです。

a. work および backup の両サブディレクトリーを削除または名前変更し、それより大きいスペースを持つディレクトリーをファイル・システム内に再作成します。

b. ln -s コマンドを使用して、新規ディレクトリーを .swdis ディレクトリーにリンクします。

v 方法 2:

より大きなスペースを持つファイル・システム内に新規バックアップ・ディレクトリーを作成し、それをポイントするように /etc/Tivoli/swdis.ini ファイルを変更します。

次のようにして、必ず swdis.ini ファイルの正しいセクションを変更します。

– 切断されたコマンド行 (wdinstsp) を使用する InstallShield ウィザードによるローカル・サイレント・インストールを行う場合、 [#MOBILE] セクションの backup_dir キーの値を変更します。

– Tivoli Configuration Manager を使用したリモート・インストールを行う場合は、ターゲットとして選択したエンドポイントから見た相対的なセクション(たとえば、[lab133080_aix]) を識別し、そのセクション内で backup_dir

キーを変更する必要があります。

3. インストールを再度実行します。

ソフトウェア・パッケージ・ブロックのインストールが正常に完了しない:

IBM Tivoli Configuration Manager のソフトウェア配布コンポーネントのソフトウェア・パッケージ・ブロックを使用するインストールを起動しました。インストールは失敗します。


ソフトウェア・パッケージ・ブロックにより、リモート側でインストールする際の問題は、解決が困難な場合が少なくありません。これは、インストールを正常に実行できるように、リモート環境を正しく設定することがより困難な場合があるからです。このため、ソフトウェア・パッケージ・ブロックには、インストール・アク


ティビティーをオンまたはオフに切り替える一連のキーが指定されています。これらのアクション・キーは、インストールが正常に完了するように、デフォルトではtrue に設定されています。既知の理由で失敗した場合は、後で解決して、これらのキーの 1 つ以上をfalse に設定して再試行し、インストール・プロセスがこれらのステップの実行を試みないようにすることができます。

例えば、前のインストールのバックアップを試行中にインストールが失敗し、バックアップをせずに続行できることがわかっている場合は、アクション・キーを false

に設定することによって、このアクションをインストールから除去できます。インストールを再起動して、バックアップ・ステップは実行されませんが、それ以外は正常に完了します。

各ステップで実行される処理については、「Tivoli Workload Scheduler: 計画およびインストール」を参照してください。

注: インストール手順は、使用するインストール方式とは無関係に、常に同じです。

アクション・キーの詳細は、以下のとおりです (アクションを実行しないようにするには、アクション・キーをすべて false に設定します)。

execActionTools = "true"これは、他のすべてのキーを制御します。false に設定すると、他のアクションは実行されません (設定は無視されます)。

execTwsStopAction = "true"これは、インストールがターゲット・ワークステーション上の既存の Tivoli

Workload Scheduler プロセスを停止するかどうかを制御します。

execTwsCleanAction = "true"これは、インストールが既存のインストールをアップグレードする前にクリーンアップするかどうかを制御します。

execTwsUndoAction = "true"これは、取り消し可能なインストール・スクリプトが実行されるかどうかを制御します。

execTwsBackupAction = "$(backup)"これは、インストールを開始する前にインストールが既存のインストールのバックアップを取るかどうかを制御します。デフォルトでは、この値は、「false」に設定されています。

execTwsUserAction = "true"これは、インストールが <TWS_user> の詳細を作成または変更するかどうかを制御します。

execTwsConfigAction = "true"これは、インストール後にインストールが Tivoli Workload Scheduler を構成するかどうかを制御します。

execTwsStartUpAction = "true"これは、インストール後にインストールが Tivoli Workload Scheduler を開始するかどうかを制御します。


execTwsCommitAction = "true"これは、インストールがソフトウェア配布 commit アクションを発行して、インストールを完了するかどうかを制御します (詳細は Tivoli Configuration

Manager の資料を参照)。

問題を解決したら、ソフトウェア・パッケージ・ブロックを使用して他のすべてのインストールに対してこれらのキーを true にリセットします。

ソフトウェア・パッケージ・ブロックのパラメーターの値を変更する方法について詳しくは、Tivoli Configuration Manager の資料を参照してください。

インストールが失敗し、エラー AWSFAB035E が出される:

Tivoli Workload Scheduler またはそのフィックスパックの 1 つをインストールしようとしています。インストールは、次のエラーを出して失敗します。

AWSFAB035E The installation has failed. For more details seethe log file: /tmp/tws84/summary.log.

インストール・ログにソフトウェア配布エラー・メッセージ DISSE0006E が含まれています。

DIS:SENG:0006 Operation unsuccessful: Fatal failure.Explanation: The operation cannot be completed because ofan internal error (for example, a memory allocation failure)System Action: Operation failed.

さらに、ログには、実行した最新の内部コマンドの詳細も含まれています。

+ wdinstsp -f -D promote=false -D upgrade=false -D fresh_install=true


これは、Tivoli Workload Scheduler インストーラーと、IBM Tivoli Configuration

Manager の現行バージョンとの間の非互換性に関連する問題です。以下のステップに従います。

1. コマンド wlsinst -ah を使用して、インストールされる Tivoli Configuration

Manager のバージョンを確認します。パッチがインストールされているかどうかを確認してください。

2. Tivoli Configuration Manager バージョン 4.2 をフィックスパック4.2-SWDGW-F1P1 (または同じコンポーネントのそれ以降のフィックスパック)

とともに使用している場合は、互換性の問題があります。これは、Tivoli

Workload Scheduler バージョン 8.4 のインストールとそのフィックスパックが、Tivoli Configuration Manager SWDGW コンポーネントの GA バージョンとのみ互換性があるからです。

この場合は、Tivoli Configuration Manager を使用しない異なるインストール方式を選択するか、インストールが完了するまで、Tivoli Configuration Manager

4.2-SWDGW フィックスパックをアンインストールする必要があります。


3. Tivoli Workload Scheduler GA およびフィックスパック・インストールは、Tivoli Configuration Manager バージョン 4.2 の切断されたコマンド行を使用します。このコンポーネントに問題が見つかり、以下の作業を実行する必要があります。

a. ワークステーションに Tivoli Configuration Manager フィックスパック4.2-TCM-FP02 をインストールします。

b. wconvcat コマンド (4.2-TCM-FP02.README ファイルを参照) を実行して、切断されたコマンド行の機能を復元します。

c. 失敗したインストールを再試行します。

swd_env script を使用して環境変数を設定したシェルからエージェント・インストールを起動すると失敗する:

エージェントをインストールするときに以下のエラーが発生します。

AWSFAB035E The installation has failed.


swd_env.cmd または . . /swd_env.sh を使用して Software Distribution 環境変数を以前にセットアップしたシェル・スクリプトからインストールを実行している場合に、このエラーを受け取る可能性があります。

環境変数を設定したことがないシェル・スクリプトからインストールを再開し、インストールを完了します。

インストールが失敗し、エラー AWSGAB566E が出される:

Tivoli Workload Scheduler のインストールを試みていますが、インストールは、次のエラーを出して失敗します。

AWSGAB566E There is not enough disk space available in the followingsupplied directory to complete the installation: <directory_name>.The installation requires <required_space> megabytes,but only <available_space> megabytes are available.


このエラーの原因としては、製品がインストールされるファイル・セット、または一時インストール・ファイルが書き込まれるファイル・セットの大きさが不十分だということが考えられます。ディスク・スペースの要件について詳しくは、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 の Tivoli Workload

Scheduler システム要件ドキュメントを参照してください。

ただし、このエラーは、ハード・ディスク上の仮想メモリー・ファイル (ページ・ファイルまたはスワップ・スペースと呼ばれることもあります) の大きさが不十分な場合にも出されます。

したがって、十分なディスク・スペースがあると思われる場合には、ハード・ディスクに割り振った仮想メモリーもチェックしてください。どのオペレーティング・システムであっても、インストールには少なくとも 256 MB の仮想メモリーが必要です。



コミット・ステップが失敗する:

Tivoli Workload Scheduler のインストールを試みていますが、コミット・ステップが失敗します。


マップされた属性、LDAPUSERIdMap が、ログイン属性、LDAPUserFilter とは異なり、コミット・ステップは失敗します。セキュリティー・ファイルをダンプして、マップされた値を挿入する必要があります (エラー・メッセージを参照)。次に、失敗した composer コマンドを手動で実行します (エラー・メッセージを参照)。最後に、失敗したステップを正常完了として設定し、インストールを再開します。

同じワークステーション上で同じ名前を持つ動的エージェントのアンインストールおよび再インストール:

ワークステーションから動的エージェントをアンインストールし、同じワークステーション上に同じ名前を付けて再インストールする場合は、以下のステップを実行して、既存エージェント定義をオーバーライドします。

1. 計画内でワークステーション上でコマンド conman cpuinfo 動的エージェント_name を実行する動的エージェントの ID を取得します。

2. 以下の例に示すように、AgentID キーワードを使用して動的エージェントのID を jobmanager.ini ファイルに追加します。

[ResourceAdvisorAgent]FullyQualifiedHostname = geneva12.paralab.it.fsx.comResourceAdvisorUrl = https://localhost.localdomain:31116/JobManagerRESTWeb/JobScheduler/resourceCPUScannerPeriodSeconds = 10ScannerPeriodSeconds = 120NotifyToResourceAdvisorPeriodSeconds = 180ComputerSystemDisplayName = geneva12_1BackupResourceAdvisorUrls = "https://localhost.localdomain:31116/JobManagerRESTWeb/JobScheduler/resource","https://geneva12.paralab.it.fsx.com:31116/JobManagerRESTWeb/JobScheduler/resource"AgentID = 4A0B274AC61E11DF995053784667819B

その他の失敗:

インストールが失敗し、原因はログ・メッセージからは即時に明らかではありません。


失敗の原因は次のいずれかである可能性があります。

ファイルのノードへの FTP 転送がバイナリー・モードで実行されなかったFTP を使用して、インストール・ディレクトリーを DVD からローカル・ハード・ディスクにコピーしましたが、バイナリー・オプションを指定しませんでした。ディレクトリー全体が FTP によってバイナリー・モードで転送されることを確認します。


注: ローカル・ハード・ディスク上のディレクトリーには任意の名前を指定できますが、twsinst インストールのために、親ディレクトリーを使用可能にすることが重要です。これは、複数の一時ファイルをそこに配置する必要があるからです。

例:

/temp/HP-UX

または

/temp/TWS84/HP-UX

インストール用の十分なディスク・スペースが用意されていない選択したファイル・セットにインストール用に十分なディスク・スペースがあることを確認します。

インストールに必要なスペースの量について詳しくは、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 の Tivoli

Workload Scheduler システム要件ドキュメントを参照してください。

ファイル名が元の大文字小文字を保持しなかったUNIX 上で、ファイル名が大文字小文字を保持していることを確認します。例えば、ファイル "TWS_size.txt" を "tws_size.txt" とすることはできません。

1 つ以上の必須ファイルがインストール DVD のルートからコピーされなかったDVD からコピーされたファイル数が DVD 上のファイル数と同じであることを確認します。同じでない場合は、ファイルを再度コピーします。

最初のインストールが正常に完了する前に 2 番目のインストールを起動した。別のインストールがまだ実行中であるのにインストール (例えば、追加のコンポーネント) を起動すると、両方のインストールとも失敗するか、最初のインストールを途中で終了して、改めて続行するかのように、2 番目のインストールが最初のインストールを試行して再開する可能性があります。

最初のインストールが到達したステージによっては、2 番目のインストールを閉じて、最初のインストールを完了させることができる場合があります。ただし、一方または両方が失敗すると、アンインストールしてから再びインストールを開始する必要がある場合があります。

InstallShield ウィザードで Oracle にインストールを行うことができず、エラーAWSJIS145E が出力される:

InstallShield ウィザードを使用して Oracle にインストールを行おうとしています。ウィザードから次のエラー・メッセージが表示されます。

AWSJIS145E "The supplied credentials for user Tivoli Workload SchedulerOracle Database user are not correct"


インストール・ログ・ファイル twsismp.log を開けば、エラーを確認できます。

DBCfgInfo, dbg, validate_twsDBUserAuthInfo: result of the queryfor the existence of the TWS Oracle User is:ERROR:ORA-28002: the password will expire within 7 days 0

ORA-01017: invalid username/password; logon denied


|

|

|

|

||

|

|

|||

|


問題は、インストールで使用される Oracle system アカウントのパスワードの有効期限がまもなく切れることです。 Oracle system アカウントのパスワードを変更して、ウィザード・インストールを再び開始してください。

InstallShield ウィザードによってインストールされたバックアップ・マスター・ドメイン・マネージャーで localopts ファイルが正しく管理されない:

InstallShield ウィザードを使用してバックアップ・マスター・ドメイン・マネージャーをインストールしました。インストールは正常に完了していますが、localopts ファイルに以下のセクションが含まれていません。

#----------------------------------------------------------------------------# Attributes for CLI connections## Master hostname used when attempting a connection.HOST = 127.0.0.1# Protocol used to establish a connection with the Master.PROTOCOL = httpsPORT = 31116 # Protocol port#PROXY = proxy.userlocal#PROXYPORT = 3333TIMEOUT = 3600 # Timeout in seconds to wait a server response#CLISSLSERVERAUTH = yes#CLISSLCIPHER = MD5#CLISSLSERVERCERTIFICATE =#CLISSLTRUSTEDDIR =DEFAULTWS = NC112015USEROPTS = useropts_mdm86

#----------------------------------------------------------------------------# Event Management parameters#CAN BE EVENT PROCESSOR = yes # yes for MDM and BKM, no otherwise


ウィザード・パネルで next アクションや back アクションを何回か行った場合、インストール・プロセスでは localopts ファイルの「CLI connections」セクションと「Event Management parameters」セクションを作成できません。インストール後に、これらのセクションを手動でファイルに追加してください。

追加プラグインのインストール時に十分な一時スペースがない:

Tivoli Workload Scheduler for Additional Plug-ins を使用して追加プラグインをインストールできず、次のメッセージが出力されました。

WARNING:/tmp does not have enough disk space!Attempting to use / for install base and tmp dir


一時ディレクトリーに十分なスペースがない場合は、インストール・プロセスを別の一時ディレクトリーにリダイレクトします。 InstallAnywhere 変数 IATEMPDIR

を設定してください。


1. set IATEMPDIR=<new_temp_dir> を実行します。

2. インストールを開始します。


|

|

|

|

|

|

|

|

||||||||||||||||||||||

|

|

|

|

|

|

|

|

||

|

|

|

|

|

|

|

UNIX オペレーティング・システム

1. export IATEMPDIR=<new_temp_dir> を実行します。

2. インストールを開始します。

アップグレードの問題


v 『アップグレード後に変数が解決されない』

v 『アップグレード後にデフォルトの変数テーブルにアクセスできない』

v 277ページの『アップグレードの際にレジストリー・ファイル情報が見つからない』

v

アップグレード後に変数が解決されない:

バージョン 8.5 へのアップグレードの後、グローバル変数が解決されません。


バージョン 8.5 へのアップグレードの際、グローバル変数に関連するセキュリティー・ファイル・ステートメントは、すべて、インストール・ウィザードによって、新規のセキュリティー・ファイルのデフォルトの変数テーブルにコピーされました。グローバル変数は、バージョン 8.5 では使用不可であり、変数テーブルを通してのみ使用できます。その後、前の dumpsec からの出力を、新規の makesec への入力として使用して、セキュリティー・ファイルを再作成する場合は、デフォルトの変数テーブルに関連するセキュリティー・ステートメントを上書きしてしまうので、デフォルトの変数テーブルへのアクセス権限を持つユーザーはいなくなります。

makesec を実行する前のセキュリティー・ファイルのバックアップがある場合は、「Tivoli Workload Scheduler 計画およびインストール」のアップグレード手順で説明されているように、そこから dumpsec を実行し、古い dumpsec 出力ファイルを新しいものとマージします。

バックアップがない場合は、「Tivoli Workload Scheduler 管理ガイド」のセキュリティー・ファイルの構成に関する指示に従って、デフォルトの変数テーブル・セキュリティー・ステートメントを作成します。

アップグレード後にデフォルトの変数テーブルにアクセスできない:

バージョン 8.5 へアップグレードした後、デフォルトの変数テーブルがどのユーザーからもアクセスできません。


この問題の原因および解決策は、前項とまったく同じです。『アップグレード後に変数が解決されない』を参照してください。

インストール中:


|

|

|

この章では、Dynamic Workload Console をインストールする方法を説明します。この章は、以下のセクションに分かれています。

v 『Dynamic Workload Console のインストール』

v 270ページの『Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 との接続のためのポストインストール・ステップ』

v 272ページの『Lightweight Third-Party Authentication (LDAP) の使用法を構成するためのポストインストール・ステップ』

v 272ページの『Dynamic Workload Console へのアクセス』

v 276ページの『Dynamic Workload Console の始動および停止』

Dynamic Workload Console のインストール:

このセクションでは、使用可能なインストール方法を使って Dynamic Workload

Console をインストールする方法について説明します。以下のトピックに分かれています。

v 『ランチパッドの使用』

v 『インストール・ウィザードの使用』

v 268ページの『サイレント・インストールの実行』

v 270ページの『イメージから外部の WebSphere Application Server に Tivoli

Integrated Portal をインストールする操作』

ランチパッドの使用:

ランチパッドを使用して Dynamic Workload Console をインストールできます。ランチパッドからのインストールにあるランチパッドを起動および実行するための指示を使用して、ランチパッドで Dynamic Workload Console インストール・オプションを選択します。画面の指示に従います。ランチパッドによって、一部のオプションが事前に入力された状態でインストール・ウィザードが実行されます。『インストール・ウィザードの使用』の指示に従って、プロセスを完了します。

インストール・ウィザードの使用:

インストール・ウィザードを使用して Dynamic Workload Console をインストールするには、以下のステップに従ってください。

1. セットアップ・ディレクトリーを参照し、セットアップ・ファイルを実行してインストールを開始します。インストール・ウィザードは、まず Java 一時ディレクトリーに十分なフリー・スペースがあるかどうか確認します。スペースがない場合にはインストールが終了するので、http://www.ibm.com/support/

docview.wss?rs=672&uid=swg27019747 にある Tivoli Workload Scheduler システム要件ドキュメントで説明されているようにして、Java 一時ディレクトリーのサイズを増やしてからインストール・ウィザードを実行する必要があります。

2. Dynamic Workload Console のインストールの際、使用する言語を選択し、「OK」をクリックします。

3. 「ようこそ」パネルで「次へ」をクリックして、インストールを続行します。

4. ご使用条件を読んで、条項に同意します。「次へ」をクリックします。




5. Tivoli Integrated Portal インスタンスを選択します。以下のいずれかを選択します。

v Tivoli Integrated Portal の新規インスタンスへのインストール、または組み込み WebSphere Application Server を含まない Tivoli Workload Automation の既存のインスタンスへのインストールを選択する場合は、 265ページの『Tivoli

Integrated Portal の新規インスタンスのインストール』にあるステップを実行します。このインストールを実行するのは、Tivoli Integrated Portal をまだインストールしていない場合、または組み込み WebSphere Application Server をインストールしない Tivoli Workload Scheduler コンポーネント (例えば、フォールト・トレラント・エージェントなど) をインストール済みの場合です。

v 組み込み WebSphere Application Server を含む既存の Tivoli Workload

Automation インスタンス上へのインストールを選択する場合は、 266ページの『組み込み WebSphere Application Server の既存のインスタンスへのインストール』にあるステップを実行します。組み込み WebSphere Application

Server もインストールする Tivoli Workload Automation コンポーネント (例えばマスター・ドメイン・マネージャー) をインストール済みの場合は、このインストールを実行します。

v Tivoli Integrated Portal の既存インスタンス上へのインストールを選択する場合は、 267ページの『Tivoli Integrated Portal の既存インスタンスへのインストール』にあるステップを実行します。別の Tivoli 製品と共に Tivoli

Integrated Portal をインストール済みの場合に、このインストールを実行します。サポートされている Tivoli Integrated Portal のリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27019747 にある Tivoli

Workload Scheduler システム要件ドキュメントを参照してください。

v V8.6 以降、外部 WebSphere Application Server にインストールされているDynamic Workload Console はサポートされなくなりました。Tivoli Integrated

Portal をインストールしていない場合は、インストール DVD または該当するeImage を使用してインストールできます。 270ページの『イメージから外部の WebSphere Application Server に Tivoli Integrated Portal をインストールする操作』を参照してください。

6. インストール・ロケーションを選択します。「次へ」をクリックします。

7. Dynamic Workload Console 管理者として使用する Tivoli Integrated Portal ユーザーの名前とパスワードを指定します。

注: ユーザー名とパスワードは、オペレーティング・システムの資格情報である必要があります。Windows オペレーティング・システム上では、指定したユーザー名が存在しない場合、新しいオペレーティング・システム・ユーザーが作成されます。

ユーザー名は 3 から 60 文字の固有の名前でなければなりません。この名前に使用できる文字は、a から z、A から Z、0 から 9、ピリオド (.)、ハイフン(-)、下線 (_)、および 2 バイト文字セット (DBCS) のみです。

パスワード長は、5 から 16 文字でなければなりません。パスワードに使用できる文字は、a から z、A から Z、0 から 9、ピリオド (.)、ハイフン (-)、および下線 (_) のみです。



ユーザーは、Tivoli Workload Scheduler でフェデレーテッド・ユーザー・レジストリーを使用する場合のルールで説明されている方法で作成する必要があります。

パスワードを確認し、「次へ」をクリックします。

8. インストールを行う新規パスまたは既存の Tivoli Workload Automation インスタンスのパスを選択します。インストール先のパス (以降、twa_install_dir) を選択するか、デフォルト・パスを受け入れ、「次へ」をクリックします。

インストール・パスの長さは 32 文字以下とし、特殊文字が含まれていないことを確認します。

Tivoli Integrated Portal の新規インスタンスのインストール:

以下は、新規 Tivoli Workload Automation インスタンスをインストールする場合、または組み込み WebSphere Application Server がまだインストールされていない既存の Tivoli Workload Automation インスタンス上にインストールする場合に適用されます。このケースが該当するのは、Tivoli Integrated Portal をまだインストールしていない場合、または組み込み WebSphere Application Server をインストールしない Tivoli Workload Scheduler コンポーネント (例えば、フォールト・トレラント・エージェントなど) をインストール済みの場合です。この場合、Tivoli Workload

Scheduler は組み込み WebSphere Application Server および Tivoli Integrated Portal

をインストールします。

Tivoli Integrated Portal および Dynamic Workload Console のインストールを選択した場合は、以下のステップに従ってください。

インストールを選択するウィンドウで、以下のインストール・タイプのいずれかを選択します。

デフォルト・インストールTivoli Integrated Portal のデフォルト設定を使用する場合は、『デフォルト・インストール』の説明に従ってインストールを進めます。

拡張インストールTivoli Integrated Portal 設定をカスタマイズする場合は、『拡張インストール』の説明に従ってインストールを進めます。

デフォルト・インストール:

デフォルト・インストールを進めるには、以下のステップに従ってください。

1. インストールを開始するには、「インストール要約」ウィンドウに表示される値が正しいことを確認し、「インストール」をクリックします。

2. インストールが正常に完了すると、Tivoli Integrated Portal のユーザー・インターフェースへのリンクを示すウィンドウが表示されます。詳しくは、 272ページの『Dynamic Workload Console へのアクセス』を参照してください。インストールが失敗すると、インストールされなかった項目のリストとログ・ファイルのロケーションがウィンドウに表示されます。「完了」をクリックします。

拡張インストール:

拡張インストールを進めるには、以下のステップを実行します。


1. Tivoli Integrated Portal に以下のポート番号を指定するか、またはデフォルト値を受け入れます。これらは Tivoli Integrated Portal によって使用される組み込みWebSphere Application Server ポートです。

HTTP トランスポートポータルが HTTP トランスポートに使用するポートの番号。デフォルト値は 29080 です。

HTTPS トランスポートセキュアな HTTP トランスポート (HTTPS) 用にポータルが使用するポートの番号。デフォルト値は 29443 です。

ブートストラップブートストラップ機能用のポート番号。デフォルト値は 22809 です。

SOAP コネクターポータルの Simple Object Access Protocol (SOAP) コネクター用のポート番号。デフォルト値は 28880 です。

SAS サーバー認証リスナーポータルの SAS SSL サーバー認証リスナー・ポート番号。デフォルト値は 29401 です。

CSIv2 サーバー認証リスナーポータルの CSIv2 SSL ServerAuth リスナー・ポート番号。デフォルト値は 29403 です。

CSIv2 クライアント認証リスナーポータルの CSIv2 SSL ClientAuth リスナー・ポート番号。デフォルト値は 29402 です。

ORB リスナーポータルの ORB リスナー・ポート番号。デフォルト値は 29100 です。

管理コンソールポータルの HTTP 管理コンソール・ポート。デフォルト値は 29060 です。

管理コンソール・セキュアポータルの HTTP 管理コンソール・セキュア・ポート。デフォルト値は29043 です。

IPC Connectorポータルの IPC コネクター。デフォルト値は 29314 です。

REST 通知ポータルの REST 通知ポート。デフォルト値は 29324 です。

DCS ユニキャスト・ポート (DCS Unicast port)ポータルの DCS ユニキャスト・ポート。デフォルト値は 29353 です。

「次へ」をクリックします。

2. 265ページの『デフォルト・インストール』に説明されているステップに従ってインストールを完了します。

組み込み WebSphere Application Server の既存のインスタンスへのインストール:


組み込み WebSphere Application Server もインストールする Tivoli Workload

Automation コンポーネント (例えばマスター・ドメイン・マネージャー) をインストール済みの場合は、このインストールを実行します。以下のステップに従って、組み込み WebSphere Application Server の既存のインスタンスに Dynamic Workload

Console をインストールします。

1. 既存の Tivoli Workload Automation ディレクトリーを選択します。

2. 組み込み WebSphere Application Server の既存のインスタンスのユーザー名とパスワードを入力します。

注: WebSphere Application Server が既存の Tivoli Workload Automation インスタンスに既にインストールされているがユーザー名がわからない場合は、「検索」をクリックします。ユーザー名は検索されますが、パスワードは入力する必要があります。この操作に数分かかる場合があります。サイレント・インストールを実行している場合、これらの資格情報を見つけるために、インストールを実行する前に、showSecurityProperties を実行します。

3. 管理者が Tivoli Workload Scheduler コンソールまたは Dynamic Workload

Broker コンソールあるいはその両方にアクセスできるようにする場合は選択します。「次へ」をクリックします。

注: 使用可能な 2 つのユーザー・インターフェースのいずれか 1 つを選択した場合、インストール後に、インストール・プロセスによって作成される事前定義役割の 1 つを割り当てることで、もう一方のユーザー・インターフェースに対するアクセスをユーザーに許可することができます。詳しくは、「Tivoli Workload Scheduler 管理ガイド」にある Dynamic Workload Console

の構成に関する情報を参照してください。


Tivoli Integrated Portal に以下のポート番号を指定するか、またはデフォルト値を受け入れます。これらは、Tivoli Integrated Portal によって使用される組み込み WebSphere Application Server ポートです。





Tivoli Integrated Portal の既存インスタンスへのインストール:


別の Tivoli 製品と共に Tivoli Integrated Portal をインストール済みの場合に、このインストールを実行します。以下のステップに従って、既存の Tivoli Integrated

Portal インスタンス上に Dynamic Workload Console をインストールします。

1. どの既存の Tivoli Integrated Portal インスタンスに対して Dynamic Workload

Console をインストールするかをインストール・パスを指定して選択します。

2. Dynamic Workload Console 管理者として設定する既存の Tivoli Integrated Portal

ユーザーの ID とパスワードを指定します。

注: 使用可能な 2 つのユーザー・インターフェースのいずれか 1 つを選択した場合、インストール後に、インストール・プロセスによって作成される事前定義役割の 1 つを割り当てることで、もう一方のユーザー・インターフェースに対するアクセスをユーザーに許可することができます。詳しくは、「Tivoli Workload Scheduler 管理ガイド」にある Dynamic Workload Console

の構成に関する情報を参照してください。



サイレント・インストールの実行:

セットアップ・インストール・ファイルを実行するときに -silent パラメーターを追加することにより、コマンド行から無人モードでインストールを実行することができます。次のステップを実行します。

v root (UNIX オペレーティング・システムの場合) または Administrator (Windows

オペレーティング・システムの場合) としてインストールを実行します。

v インストール・ウィザードを使用してインストールを行う場合は、求められるすべての設定を指定します。

インストール設定は、応答ファイルを使用して提供されます。

インストール DVD の ¥tdwc¥responsefiles¥ ディレクトリーにある応答ファイル・テンプレートを編集します。ファイルをカスタマイズするための指示は、ファイル内にコメント・テキストとして組み込まれています。応答ファイルのプロパティーについて詳しくは、 349ページの『Dynamic Workload Console 応答ファイルのプロパティー』を参照してください。

表 16 は、応答ファイルおよびそれぞれが実行するインストールのタイプをオペレーティング・システム別でリストしています。

表 16. Dynamic Workload Console 応答ファイル

インストールのタイプ Unix で使用する応答ファイル Windows で使用する応答ファイル

既存の TWA インスタンスでの新規 Dynamic Workload

Console

TDWC86_FRESH_existTWA_UNIX.txt TDWC86_FRESH_existTWA_WIN.txt


表 16. Dynamic Workload Console 応答ファイル (続き)

インストールのタイプ Unix で使用する応答ファイル Windows で使用する応答ファイル

外部の Tivoli Integrated Portal

での新規 Dynamic Workload

Console

TDWC86_FRESH_extTIP_UNIX.txt TDWC86_FRESH_extTIP_WIN.txt

新規 TWA インスタンスでの新規 Dynamic Workload

Console

TDWC86_FRESH_newTWA_UNIX.txt TDWC86_FRESH_newTWA_WIN.txt

Dynamic Workload Console のアンインストール

TDWC86_UNINSTALL.txt TDWC86_UNINSTALL.txt

既存の Tivoli Workload

Automation インスタンスでのDynamic Workload Console のアップグレード (組み込みWebSphere Application Server)

TDWC86_UPGRADE_embeddedWAS_UNIX.txt TDWC86_UPGRADE_embeddedWAS_WIN.txt

注: アップグレード・シナリオでは、Dynamic Workload Console バージョン 8.4 以降をインストールしたときに最初に選択した組み込み版 IBM Websphere

Application Server を選択します。

サイレント・モードでインストールするには、Dynamic Workload Console のインストールを行うコンピューターで以下のステップを実行してください。

1. そのオペレーティング・システム用のサンプル応答ファイルをローカルの一時ディレクトリーにコピーします。

2. 要件や環境に合わせて、応答ファイルに含まれるオプションをカスタマイズします。使用可能なオプションについて詳しくは、 349ページの『Dynamic Workload

Console 応答ファイルのプロパティー』を参照してください。

3. 以下のコマンドを実行します。

Windows オペレーティング・システム:SETUP.exe -options response_file.txt -silent

UNIX および Linux オペレーティング・システム:./SETUP.bin -options response_file.txt -silent

ここで、response_file は、絶対パス名です。

4. 以下のように、サイレント・インストールの結果を確認します。

Windows オペレーティング・システム:インストール・コマンドは非同期です。つまりコマンドが発行されるとインストール手順が開始され、値やメッセージを戻さずに終了します。サイレント・インストールが正常に実行されたかどうかを確認するには、一時ディレクトリーに保管される tdwcinstall.log インストール・ログ・ファイルで報告されるインストール結果を参照します。

UNIX および Linux オペレーティング・システム:インストール・コマンドは同期であり、インストールが正常に実行された場合は 0 を戻し、インストールが失敗した場合はゼロでない値を戻します。


注: インストール結果について詳しくは、一時ディレクトリーに保管されるtdwcinstall.log インストール・ログ・ファイルを参照してください。

イメージから外部の WebSphere Application Server に Tivoli Integrated Portal をインストールする操作:

以下の手順が該当するのは、WebSphere Application Server はインストールされていても、Tivoli Integrated Portal がインストールされていない場合です。Tivoli

Integrated Portal をインストールするには、以下の手順を実行してください。

1. インストール DVD またはダウンロードした eImage から、sample_response.txt ファイルが入っているTDWC_<operating_system>¥TDWC¥WEBUI¥<operating_system>¥TIP¥ ディレクトリーに移動します。

2. sample_response.txt ファイルに記されている手順を実行して、インストールの実行に必要なプロパティーをカスタマイズします。


install.sh/bat <java_jre_16_home> sample_response.txt

java_jre_16_home は、Java V16 のインストール先のパスです。

Tivoli Integrated Portal のインストールで、WebSphere Application Server の既存のインスタンスに TIPProfile プロファイルが作成されます。Tivoli Integrated

Portal のインストールが完了したら、 263ページの『Dynamic Workload Console

のインストール』に記されている手順を実行して、この新しい Tivoli Integrated

Portal インスタンスに Dynamic Workload Console をインストールできます。

Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 との接続のためのポストインストール・ステップ:

Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 環境にアクセスするには、Tivoli Workload Scheduler と Dynamic Workload Console を協働可能にする必要があります。

注:

1. これらのステップは、V8.3 フィックスパック 3 より高いバージョンのTivoli Workload Scheduler 環境への接続には必要ありません。バージョン8.3 フィックスパック 3 の後にアップグレードが実行される場合は常に、この手順の際に行われる変更がすべて維持されます。

2. Dynamic Workload Console バージョン 8.4 以降から Tivoli Workload

Scheduler バージョン 8.3 フィックスパック 3 と通信することを計画している場合、APAR PK47309 が Tivoli Workload Scheduler エンジン上にインストールされていることを確認します。詳しくは、IBM ソフトウェア・サポートにお問い合わせください。

3. 先へ進む前に、backupConfig.sh または backupConfig.cmd スクリプトを実行して、Tivoli Workload Scheduler 構成をバックアップすることをお勧めします。これらのスクリプトを実行する方法について詳しくは、「Tivoli

Workload Scheduler 管理ガイド」を参照してください。


このタスクは、接続先となる Tivoli Workload Scheduler エンジンがインストールされているシステムで実行する必要があります。

Tivoli Workload Scheduler 分散環境


v Tivoli Workload Scheduler コネクターがインストールされている完全な状態のフォールト・トレラント・エージェント (FTA) ワークステーション

Tivoli Workload Scheduler z/OS 環境Tivoli Workload Scheduler z/OS Connector がインストールされている分散システム

次のステップを実行します。

1. WebSphere Application Server の組み込みまたは外部のバージョンが Tivoli

Workload Scheduler ワークステーション上で適切に始動されていることを確認してから、以下のスクリプトを実行します。

Windows オペレーティング・システムの場合:Administrator として TWS_home¥wastools ディレクトリーから次のように実行します。

webui -operation enable -user TWS_user -password TWS_user_pw-port TWS_port [-server TWS_server]

UNIX および Linux システムの場合root として TWS_home/wastools ディレクトリーから次のように実行します。

./webui.sh -operation enable -user TWS_user -password TWS_user_pw-port TWS_port [-server TWS_server]

ここで、

TWS_user

Tivoli Workload Scheduler 管理者ユーザー ID。

TWS_user_pw

Tivoli Workload Scheduler 管理者パスワード。

TWS_port

Tivoli Workload Scheduler がインストールされている WebSphere

Application Server の SOAP ポート。この設定は、enable フラグを使用する場合に必須です。分散環境のデフォルト値は 31118 で、z/OS 環境のデフォルト値は 31128 です。

TWS_server

Tivoli Workload Scheduler によって使用される WebSphere Application

Server プロファイルの中で指定されているサーバーの名前。デフォルトでは、このフィールドに割り当てられた値は、server1 です。

2. スクリプトを実行する Tivoli Workload Scheduler システム上の外部または組み込み WebSphere Application Server を停止および開始します。

これらのステップを完了すると、Tivoli Workload Scheduler ワークステーション用のエンジン接続を作成し、Tivoli Workload Scheduler 実稼働環境を管理する準備が整ったことになります。これらのタスクを完了する方法について詳しくは、オンラインの Dynamic Workload Console 一般ヘルプにアクセスしてください。


Lightweight Third-Party Authentication (LDAP) の使用法を構成するためのポストインストール・ステップ:

Dynamic Workload Console および Tivoli Workload Scheduler エンジンまたはTivoli Workload Scheduler z/OS Connector が同一の LDAP ユーザー・レジストリーで構成されている場合か、同じコンピューター上にインストールされている場合には、接続の障害が生じることがあります。この場合、すべてのサーバー、つまりDynamic Workload Console、Tivoli Workload Scheduler エンジン・サーバー、および Tivoli Workload Scheduler z/OS Connector サーバーで、同じ Lightweight

Third-Party Authentication (LTPA) キーを使用してください。

LTPA キーを合わせるには、「管理ガイド」の Lightweight Third-Party

Authentication の使用の構成に関するセクションを参照してください。

Dynamic Workload Console へのアクセス:

Dynamic Workload Console のインストールが正常に完了すると、Integrated Solutions

Console ポータルへのリンク付きのメッセージが表示されます。サイレント・インストールを使用した場合、この情報は、tdwcinstall.log インストール・ログ・ファイルに保管されます。インストール・ログの保管場所について詳しくは、 299ページの『対話式ウィザードを使用したインストールおよびアンインストールにおけるログ・ファイル』を参照してください。

サポートされているブラウザーから、インストール・プログラムによって提供される以下のリンクの 1 つにアクセスします。

http://dynamic_workload_console_system:http_port/ibm/console

https://dynamic_workload_console_system:https_port/ibm/console

ここで、

dynamic_workload_console_system

Dynamic Workload Console をインストールしたシステムのホスト名またはIP アドレスです。

http_port

HTTP 非セキュア接続を使用して Dynamic Workload Console にアクセスする際に使用されるポート番号。新規 Tivoli Workload Automation インスタンスに Dynamic Workload Console をインストールした場合、このポート番号のデフォルト値は 29080 です。Dynamic Workload Console を既存のTivoli Workload Automation インスタンスにインストールする場合、このポートの値は継承されます。既存の Tivoli Workload Automation インスタンスに、デフォルトのポートを使用する Tivoli Workload Scheduler の現行バージョンが含まれる場合、値は 31123 になります。

https_port

HTTPS セキュア接続を使用して Dynamic Workload Console にアクセスする際に使用されるポート番号。新規 Tivoli Workload Automation インスタンスに Dynamic Workload Console をインストールした場合、このポート番号のデフォルト値は 29443 です。Dynamic Workload Console を既存のTivoli Workload Automation インスタンスにインストールする場合、このポ


ートの値は継承されます。既存の Tivoli Workload Automation インスタンスに、デフォルトのポートを使用する Tivoli Workload Scheduler の現行バージョンが含まれる場合、値は 31124 になります。

HTTPS 接続を使用して Tivoli Integrated Portal に接続している時にセキュリティー・アラートを受け取った場合は、Dynamic Workload Console 処理セッションを続行します。 Tivoli Integrated Portal をナビゲートしている時にセキュリティー情報ウィンドウが表示された場合は、非セキュア項目の表示を選択し、続行します。 Internet Explorer を使用している場合、これらのウィンドウが表示されないようにするには、セキュリティー設定で「混在したコンテンツを表示する」を「有効にする」に設定します。

Tivoli Integrated Portal ログイン・ポートレットで、インストールの際に指定したユーザー ID およびパスワードを入力し、「ログイン」をクリックします。

左のナビゲーション・バーで、Tivoli Workload Scheduler 項目を展開し、Dynamic

Workload Console にアクセスした後、Tivoli Workload Scheduler コンポーネントにアクセスします。 Dynamic Workload Broker 項目を展開して Dynamic Workload

Broker 環境にアクセスします。

これら 2 つの製品の機能を効率的に使用するために、Tivoli Workload Scheduler エンジンおよび Dynamic Workload Broker サーバーへの接続を定義する必要があります。

エンジン接続を定義しない場合、以下の限られた操作のみ実行できます。

Tivoli Workload Scheduler の場合v 参照タスクの作成v レポート・タスクの作成v イベント管理タスクの作成v ユーザー設定の定義

Dynamic Workload Broker の場合ユーザー設定の定義

Dynamic Workload Console への接続に使用したユーザー ID にTWSWEBUIAdministrator および TDWBAdministrator とは異なる役割が割り当てられていた場合、使用可能なパネルのサブセットが表示されます。このサブセットは、ユーザー ID に関連付けられた役割に割り当てられている権限によって異なります。役割について詳しくは、「Tivoli Workload Scheduler 管理ガイド」にあるDynamic Workload Console の構成に関する情報を参照してください。

Dynamic Workload Console への接続に使用したユーザー ID に役割が割り当てられていない場合、Tivoli Workload Scheduler および Dynamic Workload Broker の項目は Tivoli Integrated Portal ポータル・ナビゲーション・ツリーに表示されません。

Tivoli Workload Scheduler エンジン接続定義のクイック・ステップ:

TWSWEBUIAdministrator または TWSWEBUIConfigurator 役割が割り当てられている管理者ユーザー ID または別のユーザー ID を使用して Dynamic Workload

Console にログインした後、以下のステップに従って、サポートされている Tivoli

Workload Scheduler エンジンの 1 つにエンジン接続を作成します。


注: 組み込み WebSphere Application Server が既にインストールされている Tivoli

Workload Automation インスタンスに Dynamic Workload Console をインストールした場合、Tivoli Workload Scheduler コンポーネント (例えば、マスター・ドメイン・マネージャー、バックアップ・マスター・ドメイン・マネージャーまたはコネクター) への接続は、空の資格情報で自動的に定義されます。接続はすべての Dynamic Workload Console ユーザーによって共用されます。そのコンポーネントにシングル・サインオンが自動的にインプリメントされるので、それ以上の資格情報は不要です。 Tivoli Workload Scheduler コンポーネントをDynamic Workload Console および組み込み WebSphere Application Server が既にインストールされている Tivoli Workload Automation インスタンスにインストールする場合も同じ状況が適用されます。

1. ツリーを展開するには、Dynamic Workload Console および Tivoli WorkloadScheduler をクリックします。

2. 「クイック・スタート」を選択します。

3. 「新規エンジン」をクリックします。

4. 「エンジン接続のプロパティー」ウィンドウでエンジン接続に名前を割り当て、以下を指定します。

エンジン・タイプz/OS または分散のいずれか。これは接続先の Tivoli Workload Scheduler

エンジンのタイプです。

ホスト名分散エンジンまたは z/OS Connector (z/OS エンジン・タイプの場合) が実行されるシステムのホスト名または IP アドレス。

ポート番号Tivoli Workload Scheduler エンジンのブートストラップ・ポート番号。分散エンジンのデフォルト値は 31117 で、z/OS コネクターのデフォルト値は 31217 です。

リモート・サーバー名この設定は、z/OS エンジンにのみ有効であり、必須です。この値は、z/OS コネクターでエンジンを作成したときに指定した値です。z/OS コネクターのエンジン名と正確に一致しなければなりません。大/小文字の区別があります。WASTOOLS の "createZosEngine" コマンドでエンジンを定義した場合は、-name パラメーターで指定した値になります。これは、エンジンのリモート・サーバーの名前で、z/OS Connector で指定されています。

ユーザー ID およびパスワードエンジンとの接続に使用されるユーザー ID およびパスワード。この設定により Dynamic Workload Console から Tivoli Workload Scheduler へのアクセスが許可されます。許可される操作は、Tivoli Workload

Scheduler セキュリティー・ファイルのユーザーに割り当てられる権限によって決まります。

Tivoli Workload Scheduler データベースとの接続をテストする場合は (これは報告機能とイベント管理機能の管理に必須)、「報告の有効化」を選択して、ユーザー資格情報を指定する必要があります。


5. 「接続のテスト」をクリックして、構成が成功したこと、また Dynamic

Workload Console が選択したエンジンと通信していることを確認します。接続のテストが失敗する場合は、「Tivoli Workload Scheduler トラブルシューティング・ガイド」(SC88-9681) を参照してください。

注: Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 エンジンまたは z/OS Connector に接続している場合は、エンジン接続のテストをする前に、 270ページの『Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 との接続のためのポストインストール・ステップ』を実行済みであることを確認してください。

Dynamic Workload Broker 接続定義のクイック・ステップ:

Dynamic Workload Console では、1 つの Dynamic Workload Broker エンジンにつき 1 つの接続がサポートされています。許可ユーザーであれば、いつでもこの接続を行えます。許可ユーザーに対してサポートされている接続はそれぞれ異なります。

管理者ユーザー ID を使用して、または TDWBAdministrator またはTDWBConfigurator 役割が割り当てられている別のユーザー ID を使用してDynamic Workload Console にログインした後、以下のステップに従って、サポートされている Dynamic Workload Broker エンジンとのエンジン接続を作成します。

1. Dynamic Workload Console で「Dynamic Workload Broker」をクリックしてツリーを展開します。

2. 「構成」を選択します。

3. 「サーバー接続」をクリックします。

4. 「サーバー接続」で、以下を指定します。

ホスト名接続先の Dynamic Workload Broker のホスト名。

非セキュア・ポート接続に使用される非セキュア・ポート。

セキュア・ポート接続に使用されるセキュア・ポート。

セキュア接続の使用セキュア接続を使用する必要があるかどうかを指定します。セキュリティーについて詳しくは、「Tivoli Workload Scheduler 管理ガイド」(SC88-5733) を参照してください。

ユーザー名オプションで、サーバー接続に対して固有のユーザーを指定します。指定したユーザーの資格情報を使用することにより、新規サーバーへの接続が可能になります。アクセス可能なサーバー接続は、各ユーザーにつき 1 つだけです。

パスワード接続が適用される認証ユーザーのパスワードを指定します。

5. 「OK」をクリックして、変更内容を保管します。指定したサーバー接続が使用可能になり、即時に有効になります。


Dynamic Workload Console の始動および停止:

Dynamic Workload Console またはエンジンを始動および停止するには、それがインストールされているアプリケーション・サーバー・インスタンスを開始および停止する必要があります。

Tivoli Workload Automation インスタンス内の Tivoli Integrated Portal 上の組み込み WebSphere Application Server

組み込み WebSphere Application Server に Dynamic Workload Console をインストールした場合、以下のようにしてサーバーを始動および停止します。

Windows オペレーティング・システム:停止するには、install_dir¥wastools¥stopWas.bat を使用します。

始動するには、install_dir¥wastools¥startWas.bat を使用します。

UNIX および Linux オペレーティング・システム:停止するには、install_dir/wastools/stopWas.sh を使用します。

始動するには、install_dir/wastools/startWas.sh を使用します。

Tivoli Workload Automation インスタンスの外部の Tivoli Integrated Portal 上のWebSphere Application Server

WebSphere Application Server の外部インスタンスを使用している場合は、以下の WebSphere Application Server スクリプトを使用してアプリケーション・サーバー・インスタンスを始動および停止します。

注: 組み込み WebSphere Application Server の始動および停止には、上記で説明した方法を使用することが提案されていますが、これらのスクリプトも使用できます。

Windows オペレーティング・システム:ewas_install_dir¥bin¥stopServer.bat app_server

-user user_id -password user_id_pw

ewas_install_dir¥bin¥startServer.bat app_server

UNIX および Linux オペレーティング・システム:ewas_install_dir/bin/stopServer.sh app_server

-user user_id -password user_id_pw

/ewas_install_dir/bin/startServer.sh app_server

ここで、

ewas_install_dirWebSphere Application Server がインストールされているディレクトリーです。

app_serverDynamic Workload Console またはエンジンに関連した Tivoli

Integrated Portal プロファイルで指定されているサーバー名です。デフォルトは server1 です。


user_idDynamic Workload Console またはエンジンのインストールを行う際に指定される管理者ユーザー ID。

user_id_pwDynamic Workload Console またはエンジンのインストールをする際に指定される管理者ユーザー ID パスワード。

アップグレードの際にレジストリー・ファイル情報が見つからない:

スタンドアロンのフォールト・トレラント・エージェント (他のコンポーネントと共有されず、コネクター機能を持たないエージェント) をアップグレードしようとしましたが、アップグレードが失敗します。twsinst スクリプトを使用してアップグレードをしていた場合は、以下のエラー・メッセージが表示された可能性があります。

AWSFAB025E You are performing an update or uninstall operation, but theinstallation script has failed to find a previous instance of TivoliWorkload Scheduler in the Tivoli Workload Scheduler registry file. Thescript expected to find an entry belonging to the following user:user_name.and in the following registry file: registry_file_name.

サイレント・インストールを実行していた場合は、以下のエラー・メッセージが表示された可能性があります。

AWSJIS165E No valid instance of Tivoli Workload Automation has been specified.有効なインスタンスを指定するか、またはコンポーネントを新規インスタンスにインストールしてください。


この問題は、以下の考えられる理由のために発生しました。

v 間違ったインストール・パスを定義したために、レジストリー・ファイルが見つからない。

v アップグレードしている Tivoli Workload Scheduler エージェントの特定のインスタンスに関連付けられていないユーザー名を使用した。

v 破損したレジストリー・ファイルを持つスタンドアロンのフォールト・トレラント・エージェントをアップグレードしている。

正しいインストール・パスとユーザー名を使用していることが確実な場合は、必要なファイルを再作成する Tivoli Workload Scheduler レジストリー・ファイルのリカバリー・オプションを使用して、製品を再インストールすることなく、このエージェントをアップグレードできます。アップグレード方法に応じたリカバリー・オプションの使用方法に関する手順については、 187ページの『レジストリー・ファイルが破損している場合のアップグレード』を参照してください。

並列マイグレーションの実行後に pobox ファイルのサイズが大きくなる:

環境のマイグレーション後に、pobox ファイルのサイズが大きくなります。



並列マイグレーションを実行したときにこの問題が発生するのは、以下の理由によります。

v 手順 165ページの『並列 2: マスター・ドメイン・マネージャーから新規またはアップグレードされたバックアップ・マスターへの切り替え』で、バックアップのマスター・ドメイン・マネージャー V8.6 を使用して、エージェント、プール、動的プールのいずれかのワークステーションを定義した。

v 手順 165ページの『並列 2: マスター・ドメイン・マネージャーから新規またはアップグレードされたバックアップ・マスターへの切り替え』で定義したエージェント、プール、動的プールのいずれかのワークステーションを、手順 167ページの『並列 5: 新規バックアップ・マスター・ドメイン・マネージャーのインストールまたは古いマスター・ドメイン・マネージャーのアップグレード』でignore に設定しなかった。


1. バックアップのマスター・ドメイン・マネージャー V8.6 から、ワークステーションを ignore に設定します。

2. 前のバージョンのマスター・ドメイン・マネージャーから以下を実行します。

JnextPlan -for 0000

アンインストールの問題

アンインストールの際には、以下の問題が発生する可能性があります。

v 『Windows でのアンインストールが失敗する』

v 『組み込み WebSphere Application Server が停止しなかったために、復元プロファイル・ステップ中にアンインストールが失敗する』

v 279ページの『コネクターのアンインストールが「組み込み WebSphere

Application Server を開始 (Start the embedded WebSphere Application server)」ステップで失敗する』

Windows でのアンインストールが失敗する:

Windows ワークステーション上で InstallShield ウィザードを使用して製品のアンインストールを試みましたが、アンインストールは失敗しました。


Windows での InstallShield ウィザードのアンインストールの失敗の原因としては、「コントロールパネル」の「管理ツール」の「サービス」ウィンドウが開いていたことが考えられます。

「サービス」ウィンドウを閉じてください。アンインストールを再実行します。問題が発生した場合は、手動でサービスをアンインストールします。

組み込み WebSphere Application Server が停止しなかったために、復元プロファイル・ステップ中にアンインストールが失敗する:

製品のアンインストールを試みましたが、アンインストールは復元プロファイル・ステップで失敗しました。エラーは、組み込み WebSphere Application Server が停


止していないことを示しています (この事実がログによって報告されていない場合は、アプリケーション・サーバーが停止したかどうかを確認し、停止していない場合は、同様に続行します。


問題は、アプリケーション・サーバーの稼働中にプロファイルを復元できず、アプリケーション・サーバーの停止が失敗したことにあります。 2 つの原因が考えられます。

v Windows サービス制御マネージャーは、タイムアウトが切れるまでに組み込みWebSphere Application Server サービスを停止できなかった。

v Windows サービス制御マネージャーは、サービスを停止しようとしている際にエラーを出した。

Windows システム・ログ・ファイルをチェックして、エラーが Windows サービス・マネージャーによって、報告されているかどうかを確認します。報告されている場合は、問題を解決してから続行する必要があります。

Windows サービス制御マネージャーからエラーが報告されていない場合は、タイムアウトの問題です。

問題を解決するには、以下を行います。

1. 「Windows サービス」パネルを開きます。

2. 組み込み WebSphere Application Server を実行するサービスをパネルから停止します。

3. 「Windows サービス」パネルを閉じます。

4. 復元プロファイル・ステップからインストールを再開します。

コネクターのアンインストールが「組み込み WebSphere Application Server を開始 (Start the embedded WebSphere Application server)」ステップで失敗する:

コネクターをアンインストールしていますが、アンインストールは、「組み込みWebSphere Application Server を開始 (Start the embedded WebSphere Application

server) 」ステップで次のメッセージを出して失敗します。

AWSJIS038E An internal error has occurred. An unspecified internal error

has occurred during the installation process.

----------- Error log ------------

Could not open service ’IBMWAS70Service - <TWS_user>’

Reason: The specified service does not exist as an installed service.

ADMU0116I: Tool information is being logged in file C:¥Program

Files¥IBM¥TWA¥eWAS¥profiles¥TIPProfile¥logs¥server1¥startServer.log

ADMU0128I: Starting tool with the TIPProfile profile

ADMU3100I: Reading configuration for server: server1


ADMU3028I: Conflict detected on port 28880. Likely causes: a) An instance

of the server server1 is already running b) some other process is using

port 28880

ADMU3027E: An instance of the server may already be running: server1

ADMU0111E: Program exiting with error:

com.ibm.websphere.management.exception.AdminException: ADMU3027E: An

instance of the server may already be running: server1

ADMU1211I: To obtain a full trace of the failure, use the -trace option.

ADMU0211I: Error details may be seen in the file: C:¥Program

Files¥IBM¥TWA¥eWAS¥profiles¥TIPProfile¥logs¥server1¥startServer.log

TWA_EXCEPTION

CMW3202E Command failed.


この問題は、WebSphere Application Server 管理ユーザー ID とコネクターがインストールされたエージェントの TWS_user が異なる場合に発生します。原因としては、エージェントの前に Dynamic Workload Console をインストールし、TWS_user

ID として WebSphere Application Server 管理ユーザー ID を使用してエージェントをインストールしなかったためである可能性があります。

この問題を解決するには、以下を実行してください。

1. 対話式ウィザードを使用している場合は、オプションを選択して、ステップ再始動機能を使用します。ステップがサイレント・インストールで失敗した場合は、-resume オプションを使用し、-silent オプションを省略して、サイレント・インストールを再実行し、対話式ウィザードのステップ再始動機能を使用できるようにします。

2. ステップ再始動機能で、失敗したステップを選択し、「正常終了」状態に置きます。

3. 「次を実行 (Run next)」または「すべて実行 (Run all)」をクリックしてウィザードを完了させます。

4. stopWas および startWas コマンドを使用してアプリケーション・サーバーを停止し、再始動するために、「Tivoli Workload Scheduler: 管理ガイド」の指示に従い、確実に WebSphere Application Server 管理ユーザーの資格情報を使用するようにします。

フィックスパックのインストールの問題

このセクションでは、フィックスパックのインストール中に発生する可能性のある問題、およびその解決策について説明します。


フィックスパックのインストール中に組み込み WebSphere Application Server の更新が失敗する:


フィックスパックを適用しようとしましたが、インストールは、ステップ「組み込み WebSphere Application Server の更新 (Update of the 組み込み WebSphere

Application Server)」で失敗しました。次のようなメッセージが summary.log に表示されます。

Updating bobcatERROR: The script ended abnormally. The reason is:possible error, 65, launching updateinstaller.The script exit code is 65

CMW3202E Command failed.


詳しい情報については、フィックスパック・インストール・ログに記載されています。詳しくは、 40ページの『WebSphere Application Server インストール・ログ・ファイル』を参照してください。

原因の 1 つとして、ディスク・スペースの問題が考えられます。フィックスパック・インストール・ログ・ファイルで次のメッセージを検出してください。

(Aug 30, 2006 12:01:00 PM), UpdateInstaller,com.ibm.ws.install.ni.ismp.actions.MaintenancePrereqCheckAction, err,CWUPI0025E: There is insufficient free disk space on the system:

/<TWS_home>/eWAS:

Required: 400 MBAvailable: 146 MB

/tmp/:

Required: 250 MBAvailable: 311 MB

必要なファイル・システムすべてに十分な空きディスク・スペースがあることを確認して、操作を再試行してください。

インストールのセキュリティーの影響

Tivoli Workload Scheduler のインストールに関係するセキュリティーの影響があります。これは、インストールによって使用される一部のファイルに暗号化されていないパスワードが含まれているからです。機密漏れのシナリオは、以下のとおりです。

インストールが正常に行われた場合正常なインストール中に一部の一時ファイルが暗号化されていないパスワードによって書き込まれました。それらは、最終ステップで削除されます。障害は、インストールの所要時間以内です。

失敗したものの、再開され、正常に完了したインストール。これは正常なインストールに類似していますが、問題の内容に無関係に、その修正に要する時間によって、障害の期間が長期化する点が異なります。

失敗したものの、完了できず、ここから手動でリカバリーする必要があるインストールこの場合、一時ファイルを削除する最終ステップが実行されないので、ファ

イルは残ります。


サイレント・インストール暗号化されていないパスワードを追加して、応答ファイルを編集します。正常なインストールの後でも応答ファイルは削除されません。ユーザーがファイルを削除しないかぎり、このパスワードが見られてしまう状態は永久に続きます。

暗号化されていないパスワードを検出できるファイルは以下のとおりです。必ずしもすべてのファイルが存在しているとは限りませんが、以下のすべてのファイルについて確認を行う必要があります。

Windows オペレーティング・システム<TWS_home>¥userdef_wnt

<TEMP_DIR>¥TWA/tws86¥DB2Response.rsp

<TEMP_DIR>¥TWA/tws86¥checkdb_root.sh

<TEMP_DIR>¥TWA/tws86¥checkdbclient.sh

UNIX および Linux オペレーティング・システム<TEMP_DIR>/TWA/tws86/DB2Response.rsp

<TEMP_DIR>/TWA/tws86/checkdb_root.sh

<TEMP_DIR>/TWA/tws86/checkdbclient.sh

さらに、すべてのプラットフォームで、サイレント・インストールを使用した場合は、Tivoli Workload Scheduler 応答ファイル (テンプレート応答ファイル名について詳しくは、「Tivoli Workload Scheduler 計画およびインストール」を参照してください)。

インストールの検証

製品をインストールした後、インストール・プロセスは、他の操作の中で、次の構成タスクを完了するために続行します。

v 主要なローカルおよびグローバルのデフォルト設定を作成する。

v セキュリティー・アクセスを構成する。

デフォルトの操作可能セキュリティー・ファイルが <TWS_home> ディレクトリーに作成されます。デフォルトでは、<TWS_user> および管理者または root ユーザーを許可します。これは、コネクターの完全な InstallShield ウィザード・インストールが実行された際にも更新されます。

v Tivoli Workload Scheduler マスター・ドメイン・マネージャーをインストールまたはプロモートするたびに、ワークステーションおよびユーザー定義を設定します。

インストール中にエラーが発生しなかったことを確認するために、インストール・ログ・ファイルをチェックします (ログ・ファイルの詳細、およびその場所について詳しくは、 38ページの『インストール・ログ・ファイル』を参照)。

インストール、および対応するリカバリー・アクションを検証するために実行できるチェックの例を以下に示します。

メイン・ローカルおよびグローバル・デフォルトの設定値をチェックします。ワークステーションを標準エージェントまたはフォールト・トレラント・エージェントの役割からマスター・ドメイン・マネージャーの役割へプロモー


トした場合は、マスター・グローバル・オプションが正しいワークステーション名に設定されていることを確認します。

誤っている場合は、手動でファイルを編集し、現行値を正しい値に置換する必要があります。

Security ファイルの確認「セキュリティー」という名のデフォルトの操作可能セキュリティー・ファイルが、<TWA_home>¥tws ディレクトリーに作成されたことを確認します。作成されなかった場合は、次のようにしてファイルを作成します。

1. スクリプト tws_env を実行することにより、Tivoli Workload Scheduler

環境を設定します。

2. 次のようにして、Security ファイルをカスタマイズします。

a. <TWS_home>/config/Security.conf ファイルを開きます。

b. 内容を編集し、使用する環境と要件が反映されるようにします。

c. ファイルを <TWS_home>/Security.conf として保管します。

3. 次のいずれかのコマンドを実行します。

Windows オペレーティング・システムmakesec Security.conf

UNIX および Linux オペレーティング・システムmakesec -l Security.conf

ワークステーションおよびユーザーの定義の確認必要なワークステーションおよびユーザー定義がマスター・ドメイン・マネージャーのデータベースの適切な場所にあることを確認します。欠落した定義をデータベースに追加するには、「Tivoli Workload Scheduler: ユーザーズ・ガイドおよびリファレンス」または Dynamic Workload Console のオンライン・ヘルプの指示を参照してください。

Tivoli Workload Scheduler の手動によるアンインストール

このセクションでは、完全にアンインストールされなかった Tivoli Workload

Automation のインスタンスを手動で除去する方法について説明します。

リカバリーするために必要な考えられるシナリオを以下に示します。

v 製品の前のインストールを除去しましたが、アンインストール手順が正しく機能せず、前のインストールのレコードがシステムに残されました。

v 何らかの理由で、アンインストールは、「Tivoli Workload Scheduler 計画およびインストール」で説明したようには機能しません。

v インストールが失敗し、インストールをリカバリーおよび完了できません。この場合、どのステップが正常に完了したかを判別し、アンインストール手順の適切なポイントから開始する必要があります。ステップの詳しい説明については、222ページの『失敗したステップの訂正およびインストールの続行』を参照してください。

以下のオペレーティング・システムの場合の手動によるアンインストールについて詳しくは、以下を参照してください。

v 284ページの『Windows オペレーティング・システムでの手動によるアンインストール』


v 286ページの『UNIX での手動によるアンインストール』

v 288ページの『手動のアンインストール中の問題』

Tivoli Workload Scheduler および Dynamic Workload Console の統合されたインストールを含む Tivoli Workload Automation のインスタンスを除去するには、 313ページの『統合 Dynamic Workload Console の手動でのアンインストール』で説明されているように、最初に Tivoli Workload Scheduler のアンインストールを実行します。その後、以下のステップを実行して Dynamic Workload Console を除去します。

v Windows オペレーティング・システムでは、6 (313ページ) および 7 (314ページ)

のステップを実行します。

v UNIX および Linux オペレーティング・システムでは、5 (314ページ) のステップを実行します。

Tivoli Workload Automation インスタンスを除去せずに Tivoli Workload Automation

のインスタンスから Tivoli Workload Scheduler を除去する場合は、IBM ソフトウェア・サポートにお問い合わせください。

Windows オペレーティング・システムでの手動によるアンインストール

「Windows コントロールパネル」の「プログラムの追加と削除」で Tivoli

Workload Scheduler のアンインストールに失敗した場合、以下のステップを実行します。

1. ワークステーションで現在実行中のジョブがある場合、それらが完了するまで待機します。完了していないジョブを判別するには、exec 状態のジョブをチェックします。この状態のジョブがなく、すべてのイベントをネットワークに分散させるための十分な時間を許可した場合は、残りの手順を続行できます。

2. Tivoli Workload Scheduler がインストールされているコンピューターに管理者グループのユーザーとしてログオンします。

3. TWS_home/bin ディレクトリーから以下のコマンドを実行します。

conman "unlink workstation;noask"conman "stop;wait"conman "stopmon;wait"conman "shut;wait"

4. 引き続きアクティブなプロセスを以下のように停止します。

a. 「Windows コントロールパネル」から「サービス」を開き、以下の Tivoli

Workload Scheduler サービスを停止します。

Tivoli Netman for TWS_userTivoli Token Service for TWS_userTivoli Workload Scheduler for TWS_userTivoli Workload Scheduler SSM Agent for TWS_userIBM Common Platform Agent for tws_cpa_agent_TWS_user

b. 「Windows タスクバー」から「Windows タスクマネージャ」を実行して、Tivoli Workload Scheduler サービスの停止後にすでに実行中のプロセスをすべて終了します。


「プロセスの終了」アクションが機能しない場合は、TWS_home/unsupported

ディレクトリーから以下のステップを実行します。

1) listproc.exe を実行する

2) 終了するプロセスに関連付けられた PID 番号を読み取ります。

3) killproc.exe <PID> を実行する

5. conman stopappserver コマンドを使用して、WebSphere Application Server を停止します (「Tivoli Workload Scheduler リファレンス・ガイド」を参照してください)。

6. wdrmvsp を使用して、Tivoli Workload Scheduler に関連するエントリーだけを除去してください。詳しくは、 209ページの『Software Distribution CLI の使用によるアンインストール』を参照してください。%WINDIR

%¥system32¥TWSRegistry.dat (Windows 32 ビットの場合) または%WINDIR%¥TWSRegistry.dat (Windows 64 ビットの場合) ファイルを開きます。TWS_user の名前を含む行をすべて削除します。例えば、ユーザー ID がTWS_user の場合、以下の例に示すように、twsuser を含む行を削除します。

/Tivoli/Workload_Scheduler/twsuser_DN_objectClass=OU/Tivoli/Workload_Scheduler/twsuser_DN_PackageName=TWS_WINDOWS_twsuser.8.5.0.00/Tivoli/Workload_Scheduler/twsuser_DN_MajorVersion=8/Tivoli/Workload_Scheduler/twsuser_DN_MinorVersion=5/Tivoli/Workload_Scheduler/twsuser_DN_PatchVersion=/Tivoli/Workload_Scheduler/twsuser_DN_ProductID=TWS_ENGINE/Tivoli/Workload_Scheduler/twsuser_DN_ou=twsuser/Tivoli/Workload_Scheduler/twsuser_DN_InstallationPath=C:¥TWS¥twsuser/Tivoli/Workload_Scheduler/twsuser_DN_UserOwner=twsuser/Tivoli/Workload_Scheduler/twsuser_DN_MaintenanceVersion=0/Tivoli/Workload_Scheduler/twsuser_DN_Agent=MDM/Tivoli/Workload_Scheduler/twsuser_DN_LPName=TWS_LP_twsuser.8.5.0.00/Tivoli/Workload_Scheduler/twsuser_DN_LPList=ALL_LANG

TWSRegistry.dat ファイルの詳細については、 335ページの『レジストリー・ファイル』を参照してください。

7. 以下のコマンドを発行することによって、Tivoli Workload Scheduler サービスを停止して除去します。

TWA_home¥eWAS¥bin¥WASService.exe -stop TWS_userTWA_home¥eWAS¥bin¥WASService.exe -remove TWS_user

これを行うときには、Windows の「サービス」パネルが閉じていることを確認してください。

8. install_dir にナビゲートし、.id ファイル twainstancexxx.id の名前をメモします。この情報は、後の手順で必要になります。

9. ファイル teb_tws_cpa_agent_tws_user.ini を削除します。これは%windir%¥teb ディレクトリーにあります。

10. インストール・ディレクトリーとその内容をすべて削除します。

注: これらのファイルの手動による削除が遅い場合、 288ページの『Windows

でのファイル削除が遅すぎる』を参照してください。

11. 失敗する前にインストールまたはアンインストール・プロセスが到達していたポイントによっては、Windows サービスを除去する必要がある場合がありま


す。regedit を実行してこれを行うには、 291ページの『Windows レジストリー・キーの除去』の指示を参照してください。

12. 以下のファイルを除去します。

%WINDIR%¥TWA¥twainstancexxx.propertiestwainstancexxxx.properties.ext

ここで、xxx は、ステップ 8 (285ページ) でメモを取ったファイルの名前です。

13. この手順を実行している理由が、完了できずに失敗したインストールをクリーンアップするためである場合、暗号化されていないパスワードを含むファイルもすべて削除する必要があります。


TEMP_DIR/tws86/checkdb_root.bat

TEMP_DIR/tws86/checkdbclient.bat

さらに、サイレント・インストールを使用した場合は、すべてのプラットフォームで、Tivoli Workload Scheduler 応答ファイルを削除します。

14. 失敗する前にインストールまたはアンインストール・プロセスが到達していたポイントによっては、「プログラムの追加と削除」キーを除去する必要がある場合があります。これを行うには、システムの機能を使用します。

a. Windows コントロールパネルから、「プログラムの追加と削除」オプション・ウィンドウを開きます。

b. Tivoli Workload Scheduler がメニュー上で使用可能な場合は、その上で「除去」をクリックします。

c. 前のステップでアンインストーラーを除去すると、「プログラムの追加と削除」キーを除去するかどうかをたずねるメッセージが表示されます。「はい」をクリックすると、キーが除去されます。

15. ワークステーションをリブートしてサービス、DLL、デーモン、およびその他の実行可能プログラムをメモリーからすべて除去します。

UNIX での手動によるアンインストール

手動でアンインストールするには、以下のステップを実行してください。

1. ワークステーションで現在実行中のジョブがある場合、それらが完了するまで待機します。完了していないジョブを判別するには、exec 状態のジョブをチェックします。この状態のジョブがなく、すべてのイベントをネットワークに分散させるための十分な時間を許可した場合は、残りの手順を続行できます。

2. Tivoli Workload Scheduler がインストールされているコンピューターに root としてログオンします。

3. <TWS_home>/bin ディレクトリーから以下のコマンドを実行します。

conman "unlink workstation;noask"conman "stop;wait"conman "stopmon;wait"conman "shut;wait"


4. シェル・スクリプトから以下のコマンドを実行します。

ps -ef grep <TWS_install_dir>/bin/jobman

これによって、以下のプロセスがアクティブでないことが確認されます。

agentJobManagertaskLauncherbatchmanjobmanJOBMANmailmanmonmannetmanssmagentstagemanwriter

5. 引き続きアクティブなプロセスを以下のように停止します。

kill -9 <pid>


7. wdrmvsp を使用して、Tivoli Workload Scheduler に関連するエントリーだけを除去してください。詳しくは、 209ページの『Software Distribution CLI の使用によるアンインストール』を参照してください。/etc/TWS/TWSRegistry.dat を開いて、TWS_user ユーザー ID を含む行をすべて削除します。例えば、ユーザー ID が TWS_user の場合、以下の例に示すように、<TWS_user> を含む行を削除します。

/Tivoli/Workload_Scheduler/twsuser_DN_objectClass=OU/Tivoli/Workload_Scheduler/twsuser_DN_PackageName=TWS_LINUX_twsuser.8.5.0.00/Tivoli/Workload_Scheduler/twsuser_DN_MajorVersion=8/Tivoli/Workload_Scheduler/twsuser_DN_MinorVersion=5/Tivoli/Workload_Scheduler/twsuser_DN_PatchVersion=/Tivoli/Workload_Scheduler/twsuser_DN_ProductID=TWS_ENGINE/Tivoli/Workload_Scheduler/twsuser_DN_ou=twsuser/Tivoli/Workload_Scheduler/twsuser_DN_InstallationPath=/home/twsuser/Tivoli/Workload_Scheduler/twsuser_DN_UserOwner=twsuser/Tivoli/Workload_Scheduler/twsuser_DN_MaintenanceVersion=0/Tivoli/Workload_Scheduler/twsuser_DN_Agent=MDM/Tivoli/Workload_Scheduler/twsuser_DN_LPName=TWS_LP_twsuser.8.5.0.00/Tivoli/Workload_Scheduler/twsuser_DN_LPList=ALL_LANG

TWSRegistry.dat ファイルの詳細については、 335ページの『レジストリー・ファイル』を参照してください。

8. install_dir にナビゲートし、.id ファイル twainstancexxx.id の名前をメモします。後の手順でこの情報が必要になります。

9. インストール・ディレクトリーを以下のように削除します。

rm -R <TWS_home>

10. ファイル /etc/teb/teb_tws_cpa_agent_tws_user.ini を削除します。

11. 以下のファイルを削除します。

etc/TWA/twainstancexxx.properties


ここで、xxx は、ステップ 8 (287ページ) でメモを取ったファイルの名前です。



TEMP_DIR/tws86/checkdb_root.sh

TEMP_DIR/tws86/checkdbclient.sh

さらに、サイレント・インストールを使用した場合は、すべてのプラットフォームで、Tivoli Workload Scheduler 応答ファイルを削除します。


手動のアンインストール中の問題

手動のアンインストール中に、以下の問題が発生する可能性があります。

v 『Windows でのファイル削除が遅すぎる』

Windows でのファイル削除が遅すぎる:

手動でのアンインストール中にファイルを手動で削除すると、パス$TWA_DIR¥TWS¥stdlist¥yyyy.mm.dd¥Onnnn.hhmm 内のファイルの削除が非常に遅くなります。

原因および解決方法:

これは、Windows オペレーティング・システムで既知の Microsoft の問題によって引き起こされます。これは、マスター・ドメイン・マネージャーをアンインストールした後に Windows システム上で、指示されたファイルを削除しようとすると発生します。この問題の発生を防ぐには、「削除」メニュー・オプションを使用したり、それらをごみ箱に移動したり、キーボードの Canc キーを使用したりする代わりに、Shift-Canc を使用して、これらのファイルを削除します。

Tivoli Workload Scheduler コネクターの手動によるアンインストール

このセクションでは、完全にアンインストールされなかった Tivoli Workload

Scheduler コネクターのインスタンスを手動で除去する方法について説明します。

リカバリーするために必要な考えられるシナリオを以下に示します。

v コネクターの前のインストールを除去した可能性がありますが、アンインストール手順が正しく機能せず、前のインストールのレコードがシステムに残されました。

v 何らかの理由で、アンインストールは、 70ページの『インストール中』で説明したようには機能しません。


v インストールが失敗し、インストールをリカバリーおよび完了できません。この場合、どのステップが正常に完了したかを判別し、アンインストール手順の適切なポイントから開始する必要があります。ステップの詳しい説明については、222ページの『失敗したステップの訂正およびインストールの続行』を参照してください。

以下のオペレーティング・システムの場合の手動によるアンインストールについて詳しくは、以下を参照してください。

v 『UNIX での手動によるコネクターのアンインストール』

v 290ページの『Windows オペレーティング・システムでの手動によるコネクターのアンインストール』

UNIX での手動によるコネクターのアンインストール

コネクターを手動でアンインストールする必要がある場合は、以下のステップを実行してください。

1. Tivoli Workload Scheduler がインストールされているコンピューターに root としてログオンします。

2. ディレクトリー <TWS_home>/wastools にアクセスします。


4. インストール・ディレクトリーを以下のように削除します。

rm -R <TWS_home>

このステップは必須ではなく、単にファイル・システムのスペースを節約することが目的です。他の Tivoli Workload Scheduler ファイルを削除するリスクが少しでも疑われる場合は、このステップを省略してください。

5. /etc/TWS/TWSZConnRegistry.dat を開いて、<TWS_user> ユーザー ID を含む行をすべて削除します。



<TEMP_DIR>/tws86/checkdb_root.sh

<TEMP_DIR>/tws86/checkdbclient.sh

さらに、サイレント・インストールを使用した場合は、すべてのプラットフォームで、Tivoli Workload Scheduler 応答ファイルを削除します (応答ファイル名について詳しくは、 100ページの表 5 を参照)。


<WINDOR>¥TWA¥twainstancexxx.propertiestwainstancexxxx.properties.ext


Windows オペレーティング・システムでの手動によるコネクターのアンインストール

「アプリケーションの追加と削除」を Windows の「コントロールパネル」から実行できない場合は、以下のステップを実行してください。

1. Tivoli Workload Scheduler がインストールされているコンピューターに管理者グループのユーザーとしてログオンします。

2. ディレクトリー <TWS_home>/wastools にアクセスします。


4. 以下のコマンドを発行することによって、Tivoli Workload Scheduler サービスを停止して除去します。

<TWS_home>¥eWAS¥bin¥WASService.exe -remove(<TWS_user>)<TWS_home>¥eWAS¥bin¥WASService.exe -remove TWSZCONNECTOR(<TWS_user>)

これを行うときには、Windows の「サービス」パネルが閉じていることを確認してください。

5. コネクターが分散用であるか、または z/OS 用であるかに応じて、%WINDIR%¥System32¥TWSConnRegistry.dat または %WINDIR

%¥System32¥TWSZConnRegistry.dat ファイルを開き、<TWS_user> の名前を含む行をすべて削除します。

6. インストール・ディレクトリーとその内容をすべて削除します。このステップは必須ではありませんが、ファイル・システムのスペースを節約します。他のTivoli Workload Scheduler ファイルを削除する疑いがある場合は、このステップを省略してください。

7. 失敗する前にインストールまたはアンインストール・プロセスが到達していたポイントによっては、「プログラムの追加と削除」キーを除去する必要がある場合があります。これを行うには、システムの機能を使用します。

a. Windows コントロールパネルから、「プログラムの追加と削除」オプション・ウィンドウを開きます。

b. Tivoli Workload Scheduler Connector または Tivoli Workload Scheduler for

z/OS Connector がメニュー上で使用可能な場合は、それを選択して、「除去」をクリックします。

c. 前のステップでアンインストーラーを除去すると、「プログラムの追加と削除」キーを除去するかどうかをたずねるメッセージが表示されます。「はい」をクリックすると、キーが除去されます。




<TWS_home>¥userdef_wnt

<TEMP_DIR>¥tws86/checkdb_root.sh

<TEMP_DIR>¥tws86¥checkdbclient.sh

さらに、サイレント・インストールを使用した場合は、すべてのプラットフォームで、Tivoli Workload Scheduler 応答ファイルを削除します (テンプレート応答ファイル名について詳しくは、 100ページの『サイレント・インストールの実行』を参照)。


Windows レジストリー・キーの除去

この製品の存続期間中に名前が変更され、多数のバージョンで発行されました。製品のインストールおよびアンインストールには、複数の方法があります。どの方法であっても、あるバージョンから別のバージョンへアップグレードする際に、1 つ以上のレジストリー・キーが何かの事情で Windows レジストリに残るリスクがあります。この手順は、ユーザーがこれらの不要なキーを除去するのに役立つことを目的としています。

注: Windows レジストリに変更を加えると、オペレーティング・システムが使用できなくなる可能性があります。開始前にレジストリーをバックアップすることを強くお勧めします。

同様の手順が 284ページの『Windows オペレーティング・システムでの手動によるアンインストール』で説明されています。同じ目標は、各種の技法を使用して達成されます。

この手順は、以下の項目のキーを識別し、除去するために設計されています。

v Maestro バージョン 6.0 および 6.1

v Tivoli Workload Scheduler、バージョン 7.0、8.1、8.2.n、8.3、および 8.4

Maestro または Tivoli Workload Scheduler のバージョン、およびオペレーティング・システムのバージョンによっては、この手順の一部のキーがすでに InstallShield

ウィザード・アンインストール・プログラムによって除去されている場合があります。その場合には、そのステップをスキップして、手順の次のステップに進んでください。キーの名前の一部は、Maestro または Tivoli Workload Scheduler のインストール時に実行した選択によって異なるため、キーを検出する際は、これらの元の選択項目を把握していることを確認してください。

手順は、次のとおりです。

1. Tivoli Workload Scheduler を完全に停止します。停止するための最も簡単な方法は以下のとおりです。

a. <TWS_home>¥unsupported ディレクトリーに変更します。このディレクトリーには、listproc.exe と killproc.exe の 2 つのファイルがあります。

b. これらのファイルの両方とも <TWS_home>¥bin ディレクトリーへコピーし、Windows の path コマンドを使用して、<TWS_home> および <TWS_home>¥bin

へのパスを設定します。


c. 次のコマンドを入力します。

listproc | more

次のようなページが表示されます。

PID Command # Handles # Threads567 agent 87 4687 JobManager 65 8443 taskLauncher 34 8624 netman 86 5332 tokensrv 62 81088 writer 60 25688 monman 89 35364 ssmagent 210 191052 mailman 85 2936 batchup 57 41020 batchman 92 21036 JOBMAN 91 21312 JOBMON 105 3

この表は、実行中のフォールト・トレラント・エージェントの全 TivoliWorkload Scheduler ツリーを示しています。

注: オペレーティング・システムに属するその他のプロセス、およびこれらのプロセスの間に挿入されたその他のアプリケーションがあります。

d. 任意の TWS プロセスのプロセス ID (pid) を書き込みます。

e. 実行するプロセスごとにコマンド killproc <pid> を発行して、プロセスを停止します。 Killproc は、対応する Microsoft ツールよりも信頼性が高いツールです。 Microsoft ツールは、必ずしも常時ランナウェイ・プロセスを停止するとは限りません。

2. InstallShield ウィザードのアンインストールを実行して、Tivoli Workload

Scheduler を除去します。

3. ワークステーションをリブートします。

4. 「スタート」>「ファイル名を指定して実行」を選択し、regedit と入力して、Enter キーを押します。

5. 「HKEY_LOCAL_MACHINE」>「Software」を選択します。

6. バージョン 8.3 より前の Tivoli Workload Scheduler のバージョンからキーを除去します。

a. 「Unison Software, Inc」キーを削除します。

b. 「Software」を閉じます。

c. 「システム」>「CurrentControlSet」>「サービス」を開きます。

d. 「maestro_<workstation>_<user_ID」>キーを削除します。

e. 「netman_<system_name>_<user_ID>」という名前のキーを削除します。「Netman」という名の他のキーは一切、削除してはなりません。このNetman は Windows の一部です。

f. 「tokensrv_<system_name>_<user_ID>」という名前のキーを削除します。このタイプのキーを検出できない場合は、「<process_name>_<user_ID>」という名のキーを検出し、削除します。

7. Tivoli Workload Scheduler バージョン 8.3 および 8.4 からキーを除去します。


a. 「システム」>「CurrentControlSet」>「サービス」を開きます。

b. 「tws_maestro_<user_ID>」キーを削除します。

c. 「tws_netman_<user_ID>」キーを削除します。「Netman」という名の他のキーは一切、削除してはなりません。この Netman は Windows の一部です。

d. 「tws_tokensrv_<user_ID>」キーを削除します。

e. 「tws_cpa_agent_<user_ID>」キーを削除します。

f. 「tws_ssm_agent_<user_ID>」キーを削除します。

8. regedit を終了します。

9. ワークステーションをリブートします。


第 3 部 Dynamic Workload Console

準備

この章では、Dynamic Workload Console のインストールの準備をするにあたって知っておく必要のある概要について説明します。この章は、以下のセクションから構成されています。

v 『Dynamic Workload Console の概要』

v 『インストールの概要』

v 296ページの『インストールの注意点』

Dynamic Workload Console の概要

Dynamic Workload Console は、次の製品群と共に使用する Web ベースのユーザー・インターフェースです。

v Tivoli Workload Scheduler

v Tivoli Workload Scheduler for z/OS

v Tivoli Workload Scheduler for Applications

v Dynamic workload broker

Tivoli Workload Scheduler および Dynamic Workload Broker 環境は、Dynamic

Workload Console に接続しているサポート・ブラウザーのいずれかを使用して、ネットワーク内の任意の場所からアクセスすることができます。 Dynamic Workload

Console は、Tivoli Workload Scheduler または Dynamic Workload Broker ノードのいずれかにネットワーク接続を使ってアクセスできるシステムにインストールされている必要があります。

インストールの概要

以下のステップを実行して、Dynamic Workload Console の準備、インストール、および構成を行います。

1. http://www.ibm.com/support/docview.wss?rs=672&uid=swg27020800 にあるインストール前提条件を調べて、ご使用のシステムが対応しているかどうか確認します。

2. インストールの際に必須フィールドに入力する必要のある情報を収集します。262ページの『インストール中』を参照してください。

3. インストール中の説明に従って、要件に最適なインストール方法を選択します。

4. 263ページの『Dynamic Workload Console のインストール』に示されている指示に従って、Dynamic Workload Console をインストールします。

5. Tivoli Workload Scheduler または Tivoli Workload Scheduler for z/OS Connector

のバージョン 8.3 フィックスパック 3 との通信を計画している場合は、 270ページの『Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 との接続のためのポストインストール・ステップ』に説明されているポストインストール・ステップを実行します。



6. 272ページの『Dynamic Workload Console へのアクセス』の説明に従ってDynamic Workload Console にログインします。

7. 左のナビゲーション・ツリーから、次のいずれかをクリックします。

Tivoli Workload SchedulerTivoli Workload Scheduler の使用可能な機能にアクセスする

Dynamic workload brokerDynamic Workload Broker の使用可能な機能にアクセスする

8. Dynamic Workload Console で使用可能な機能を効率的に管理するには、管理する Tivoli Workload Scheduler および Dynamic Workload Broker 環境とのエンジン接続を作成します。エンジン接続を定義しない場合、Dynamic Workload

Console 機能の一部のみを使用できます。詳しくは、「 273ページの『Tivoli

Workload Scheduler エンジン接続定義のクイック・ステップ』」および「 275ページの『Dynamic Workload Broker 接続定義のクイック・ステップ』」を参照してください。

インストールの注意点

インストールまたはアップグレードを開始する前に、ご使用の環境に当てはまる可能性のある以下の項目を確認してください。

v Dynamic Workload Console を 1 つだけコンピューターにインストールして、それを次の場所にインストールすることができます。

– 新規 Tivoli Workload Automation インスタンス内

– 組み込み WebSphere Application Server が既にインストールされているがDynamic Workload Console がインストールされていない既存の Tivoli

Workload Automation インスタンス内

– Tivoli Integrated Portal の既存の外部インスタンスを使用している Tivoli

Workload Automation インスタンスの外

Tivoli Workload Automation インスタンスについて詳しくは、Tivoli Workload

Automation のインスタンスを参照してください。

v 同じワークステーション上に、Dynamic Workload Console の現行バージョンのインスタンスを複数インストールすることはできません。アップグレード可能バージョンを既に持つワークステーション上に別の Dynamic Workload Console のインストールを試行する場合には、アップグレードのみ行えます。

v Dynamic Workload Console をアップグレードすると、自動的に Tivoli Workload

Automation バージョン 8.5.1 の新規インスタンスにアップグレードされます。

v 既にインストールされている Tivoli Integrated Portal 上に Dynamic Workload

Console をインストールすることを計画している場合、インストールを開始する前にインストール先のプロファイルに関連したサーバーがアクティブであることを確認します。説明のとおりに作成され、カスタマイズされていないプロファイルのみサポートされます。

v Internet Protocol バージョン 6 (IPv6) 対応のエンジンに接続することを計画している場合は、インストールの後すぐに Dynamic Workload Console を再始動する必要があります。


v Windows および Windows 64 に Dynamic Workload Console をインストールする前に、Windows のワークステーション・サービスを開始する必要があります。これは、Windows 2003 および Windows 2008 にも当てはまります。

インストール方法の選択

Dynamic Workload Console のインストールは、以下のいずれかの方法を使用して行うことができます。

Launchpadランチパッドを使用して、単一のインターフェースからの Dynamic

Workload Console および Tivoli Workload Scheduler コンポーネントのインストールを手引きします。ランチパッドを使用してインストールを行う方法については、ランチパッドからのインストールを参照してください。

インストール・ウィザードインストール・ウィザードにアクセスするには、適切な setup コマンドを実行し、ご使用のインストールのインストールおよび構成のための構成設定を入力します。この方法を使用すると、インストールの処理と結果を同期的にモニターすることができます。詳しくは、 263ページの『インストール・ウィザードの使用』を参照してください。

このインストール方法は、Java 仮想マシン (JVM) を使用します。したがって、固有のシステム要件があります。インストール要件について詳しくは、http://www.ibm.com/support/docview.wss?rs=672&uid=swg27020800 の Dynamic

Workload Console システム要件ドキュメントを参照してください。

サイレント・モードインストールの際に使用されるすべての構成設定を追加して、応答ファイルをカスタマイズします。その後、-silent キーワードを使用して、コマンド行から setup コマンドを起動します。この方法で、無人インストールをバックグラウンドで実行することができます。詳しくは、 268ページの『サイレント・インストールの実行』を参照してください。

Tivoli Workload Automation のインスタンス

Dynamic Workload Console のインストールの際に、Tivoli Workload Automation の既存のインスタンスにインストールするか、新規のインスタンスを作成するかを決定する必要があります。詳しくは、Tivoli Workload Automation のインスタンスを参照してください。

Tivoli Workload Automation の既存のインスタンスにインストールを行う場合、特定のコンポーネントをインストールできるかどうかは、そのインスタンスに現時点で存在するコンポーネントまたは製品によって決まります。表 17 は、各種シナリオで実行できるアクションについて説明しています。

表 17. Tivoli Workload Automation の既存のインスタンスへのインストール


Dynamic Workload Console バージョン8.4、8.5、または 8.5.1


第 3 部 Dynamic Workload Console 297


表 17. Tivoli Workload Automation の既存のインスタンスへのインストール (続き)


外部 WebSphere Application Server にインストールされた Dynamic Workload Console バージョン 8.4、8.5、または 8.5.1

Dynamic Workload Console をアンインストールし、再インストールします。この場合、Dynamic Workload Console をアップグレードすることはできません。

Dynamic Workload Console バージョン 8.6 なし。この場合、Dynamic Workload Console


Tivoli Workload Scheduler バージョン 8.5 または 8.5.1 マスター・ドメイン・マネージャーまたはバックアップ・ドメイン・マネージャー

なし。この場合、Dynamic Workload Console


Tivoli Workload Scheduler バージョン 8.6 マスター・ドメイン・マネージャーまたはバックアップ・ドメイン・マネージャー

共通の組み込み WebSphere Application

Server に Dynamic Workload Console をインストールします。

Tivoli Workload Scheduler バージョン 8.5 または 8.5.1 エージェント (コネクター付き)

なし。同じコンピューター上に Dynamic

Workload Console の 2 番目のインスタンスをインストールすることはできません。

Tivoli Workload Scheduler バージョン 8.6 エージェント (コネクター付き)



Tivoli Workload Scheduler for z/OS Connector

のバージョン 8.5 または 8.5.1

なし。同じコンピューター上に Dynamic

Workload Console の 2 番目のインスタンスをインストールすることはできません。

Tivoli Workload Scheduler for z/OS Connector

のバージョン 8.6



Tivoli Workload Scheduler バージョン 8.6 動的ドメイン・マネージャーまたはバックアップ動的ドメイン・マネージャー



コネクターのないエージェント、ドメイン・マネージャーまたはコマンド行クライアントなど、この表に示されていないコンポーネントは、Tivoli WorkloadAutomation インスタンスにはインストールされていないため、Dynamic WorkloadConsole のインストールに影響を与えません。

インストール・メディア

Dynamic Workload Console は、サポートされている各オペレーティング・システムにつき 1 枚ずつ、複数の DVD にパッケージされています。各 DVD には次のものが含まれます。v インストール可能イメージv setup ファイルv 応答ファイルのサンプルv ランチパッド


DVD およびサポートされるオペレーティング・システムの完全なリストについては、http://www.ibm.com/support/docview.wss?rs=672&uid=swg24029125 にあるDynamic Workload Console ダウンロード可能資料を参照してください。

注:

1. システム・ディレクトリーに DVD をコピーまたはマウントする場合、そのディレクトリーのパス名に、サポートされていない次の文字が含まれないようにしてください。 { } [ ] < > $ | ? ! # * + " / % ' または非 US-ASCII

文字。

2. マップされたリモート・ドライブから Windows システムにインストールすることを計画している場合は、必ずインストールを行うシステムでローカルにリモート・フォルダーをマップします。その後、ローカル・パスを使用してインストールを実行します。

3. Linux 上にインストールすることを計画している場合は、マウントされるイメージに含まれるファイルに実行許可があること、またブランクが含まれているパスに SETUP.bin ファイルが置かれていないことを確認してください。

インストール・ログ・ファイル

ご使用のシステム上にあるログ・ファイルのタイプは、実行したインストールのタイプによって異なります。このセクションでは、各種インストールに関連したログについて説明します。

ログ・ファイルについて詳しくは、「管理ガイド」を参照してください。

対話式ウィザードを使用したインストールおよびアンインストールにおけるログ・ファイル:

以下のログ・ファイルでインストールに関する情報を検査することができます。インストール・プロセスの詳細は、ローカル・コンピューター上の以下のディレクトリーにあるログ・ファイルに記録されます。

注: 以下の値は、TEMP システム変数のデフォルト値を変更していない場合にのみ有効です。


%Temp%¥TWA¥tdwc86

UNIX および Linux オペレーティング・システム

/tmp/TWA/tdwc86

300ページの表 18 に InstallShield ウィザードログ・ファイルがリストされています。




ログ・ファイル名内容

tdwcstatus.log Dynamic Workload Console インストール状況ログ・ファイル。インストールが正常に完了したか、エラーが発生したかを報告します。エラーの場合、エラーの原因が、誤ったフィールド値にあるのか、手順の失敗にあるのかを示します。

tdwcinstall.log Dynamic Workload Console インストール・ログ・ファイル

tdwcuninstall.log Dynamic Workload Console アンインストール・ログ・ファイル

securityConfignnnn.log インストールの際に実行される Tivoli Integrated Portal セキュリティー構成に関する詳細を含む Dynamic Workload

Console ログ・ファイル。数値 nnnn が自動的に割り当てられます。 tdwcinstall.log ファイルにアクセスして、securityConfignnnn.log ファイルの名前を確認します。

wsadmin.log インストール済み環境と WebSphere Application Server との対話に関する詳細を含む Dynamic Workload Console ログ・ファイル

TIPInstaller-00.log Tivoli Integrated Portal インストール・ログ・ファイル

同じワークステーション上に複数のインストールが実行された場合は、ログのヘッダーおよびフッターに、インストールが実行されたユーザー ID (TWS_user) が示されます。

注: サイレント・インストールを実行しており、使用している応答ファイルに正しい構文が含まれていない場合、インストールは失敗し、ログは生成されません。

組み込み WebSphere Application Server のインストール・ログ・ファイル:

アプリケーション・サーバーのインストールにはログはありません。ただし、アプリケーション・サーバーを更新する場合、例えば Tivoli Workload Scheduler フィックスパックの適用の際には、更新についての情報が記載されたログが作成されます。ログはディレクトリー TWS_home/eWAS/logs/update にあります。そこにはインストールされたフィックスパックを識別するディレクトリーがあります (例えば7.0.0-WS-WASEmbeded-AixPPC64-FP0000027.install)。ここに /updatelog.txt というログ・ファイルが入っています。

アプリケーション・サーバーの開始ログは、次の場所にあります。

TWS_home/eWAS/profiles/TIPProfile/logs/server1/startServer.log

構成

この章では、Dynamic Workload Console を構成する方法を説明します。インストール後に随時、以下のオプションの構成ステップを実行できます。

v Dynamic Workload Console へのアクセスのために新規ユーザーを構成する

v ユーザー・レジストリー使用のために Dynamic Workload Console を構成する


– LDAP - RACF を使用して Dynamic Workload Console を構成する (詳しくは、「z/OS ベースの Resource Access Control Facility (RACF) を使用してLightweight Directory Access Protocol (LDAP) ユーザー・レジストリーをセキュアにする構成」にある WebSphere の資料を参照)

v Dynamic Workload Console へのアクセスのために役割を構成する

v シングル・サインオンの使用のために Dynamic Workload Console を構成する

v Secure Socket Layer プロトコルを使用して通信を保護する

v コンテキスト起動するように Dynamic Workload Console を構成する

注: インストール後に、いずれかの Tivoli Workload Automation 製品を管理する複数の WebSphere Application Server のインスタンスがある場合、それらのLTPA token_key が同一であることを確認する必要があります。

構成について詳しくは、「Tivoli Workload Scheduler 管理ガイド」(SC88-5733) にある『Dynamic Workload Console の構成』を参照してください。

始めに

この章では、Dynamic Workload Console の使用を開始する方法を説明します。

Dynamic Workload Console に接続すると、左側にポートフォリオが表示されます。そこには、Tivoli Workload Scheduler など、Tivoli Integrated Portal の内部にインストールされている Tivoli 製品ごとに項目が配置されています

Dynamic Workload Console には、環境内の任意のコンピューターから、Web ブラウザーでセキュアな HTTPS プロトコルまたは HTTP プロトコルを使用してアクセスできます。

製品とそのフィーチャーの概要を対話的に表示するいくつかのデモ・シナリオが用意されています (英語のみ)。それらは、リンク https://www.ibm.com/developerworks/

wikis/display/tivolimediagallery/Tivoli+Workload+Scheduler の製品インフォメーション・センターに用意されています。

Dynamic Workload Console インターフェースは、以下のセクションで構成されます。

ポートフォリオ左側に置かれており、ツリー構造を持っていて、Dynamic Workload Console

機能を起動するためのすべての項目が含まれています。ポートフォリオを使用して、パネルにナビゲートします。

注: アップグレードでは、ポートフォリオ上でユーザーが実行したカスタマイズは報告されません。デフォルト設定がインストールされます。

ポートレット領域作業域です。ここには、ポートフォリオでの選択内容に対応するパネルが表示されます。それぞれのパネルから、各ポートレットの右上隅にある「?」記号をクリックして、オンライン・ヘルプにアクセスすることができます。

タスクバーポートフォリオから呼び出す各アクティブ機能を開くタブが含まれていま


http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/tsec_config_racf.html



https://www.ibm.com/developerworks/wikis/display/tivolimediagallery/Tivoli+Workload+Scheduler

https://www.ibm.com/developerworks/wikis/display/tivolimediagallery/Tivoli+Workload+Scheduler

す。ポートフォリオの項目をクリックするたびに、それに対応するパネルがポートレット領域に開かれます。新規のパネルを開くと、それ以前のパネルはタスクバー内のタブに最小化されるので、そのタブをクリックして、パネルを切り替えることができます。ブラウザーのタスクバーには、開いているタブが最大 5 つ含まれています。開いたタブが 5 つより多い場合、新しいブラウザー・ウィンドウが開くので、「アクションの選択」メニューを開けば、あるページから別のページに移動することができます。

ポートフォリオには、Tivoli Workload Scheduler および Dynamic Workload Broker

に対する個別のセクションがあります。

Tivoli Workload Scheduler ポートフォリオ

Tivoli Workload Scheduler ポートフォリオには、以下の項目が含まれています。

クイック・スタート特定の基本操作を実行するには、この項目を開きます。ここをクリックして、計画中のオブジェクトの照会の作成と管理および Dynamic Workload

Console エンジンへの接続の作成および変更を行います。

すべての構成済みタスク計画内のオブジェクトのモニターのために、保存済みのすべてのタスクのリストを表示するには、この項目を開きます。アプリケーションを初めて使用する場合に、その開始の際に役立つよう、事前定義のタスクのセットが用意されています。そのようなタスクは、分散または z/OS (またはこの両方) プラットフォームで実行するスケジューリング・オブジェクトに関する情報を検索するために起動する最も一般的な照会を対象とします。

すべての構成済みレポート保存済みのすべてのレポートのリストを表示するには、この項目を開きます。このビューから、新規レポートの作成および既存レポートのカスタマイズを行うことができます。

ダッシュボードこの項目を開き、接続を構成しダッシュボードへの組み込みを指定したエンジンの現在の計画の進行状況を示すグラフィカル・ビューを表示します。

ワークロードデータベース内のオブジェクトの設計、計画の処理、計画内のオブジェクトのモニターのためのジョブまたはジョブ・ストリームの実行依頼、またはレポートの生成を行うには、ワークロードを管理します。

設計この項目を開いて、公開されたデータベース上でオブジェクトおよびオブジェクト定義を作成し、リストし、そして編集します。例えば、ここをクリックして、ジョブ、ジョブ・ストリーム、およびイベント・ルールの作成および変更を行います。

予測試行計画および予測計画を作成および表示し、アーカイブした計画をリストするには、計画を処理するためのこの項目を開きます。

実行依頼この項目を開いて、要求された場合にジョブおよびジョブ・ストリームを実行依頼します。


モニター計画内のオブジェクトのモニターのために、タスクを作成、リスト、および編集するには、この項目を開きます。例えば、ここをクリックして、計画内のジョブまたはジョブ・ストリーム用の照会の作成および変更を行います。また、ここをクリックして、ワークロードの依存関係およびイベントに関する照会を処理します。

スケジューリング環境スケジューリング環境のトポロジー、つまりワークステーションとドメインを設計して制御します。

設計この項目を開いて、環境内のワークステーションおよびドメインを作成し、リストし、そして編集します。

モニター計画内のワークステーションおよびドメインのモニターのために、タスクを作成、リスト、および編集するには、この項目を開きます。

報告レポートを定義および実行します。

ヒストリカル・レポートの生成ヒストリカル・データを収集するレポートを作成するには、この項目を開きます。

計画レポートの生成計画についての詳細を示すレポートを作成するには、この項目を開きます。

カスタム SQL レポートの生成カスタマイズした SQL レポートを生成して実行するには、この項目を開きます。

設定 Tivoli Workload Scheduler に関する一般設定を構成および変更します。

エンジンの管理Tivoli Workload Scheduler エンジンへの接続を作成、リスト、および編集するには、この項目を開きます。

ユーザー・プリファレンスの管理Tivoli Workload Scheduler のテーブル・レイアウト、時間帯、およびダッシュボード・レイアウトに関する設定を構成および変更するには、この項目を開きます。

設定の管理ユーザー・プリファレンス、構成済みタスク、エンジン接続をインポートおよびエクスポートする場合、およびご使用の設定のリポジトリーを構成する場合は、この項目を開きます。

Dynamic workload broker ポートフォリオ

Dynamic Workload Broker ポートフォリオには、以下の項目が含まれています。

スケジューリング環境動的スケジューリング環境の論理リソースおよびリソース・グループを定義し、制御します。


新規論理リソースの定義ジョブを動的に実行するために必要な新規論理リソースを定義するには、この項目を開きます。

新規リソース・グループの定義グループ内にさまざまな論理リソースを集約するための新規グループ定義を作成するには、この項目を開きます。

論理リソース定義済み論理リソースをリストおよび編集するには、この項目を開きます。

リソース・グループ定義済みリソース・グループをリストおよび編集するには、この項目を開きます。

構成 Dynamic Workload Broker コンポーネントとの接続を定義します。

サーバー接続Dynamic Workload Broker コンポーネントへの接続を作成または編集するには、この項目を開きます。

定義ダイナミック・ワークロードを管理し、リストの作成およびジョブの実行依頼を行います。

新規ジョブの定義新規ダイナミック・ジョブ定義を作成するには、この項目を開きます。

ジョブダイナミック・ワークロード・オブジェクトをリスト、編集、および実行依頼するには、この項目を開きます。

トラッキングダイナミック・ワークフローおよび環境の状況をモニターします。

ジョブ・インスタンス実行依頼済みダイナミック・ジョブ・インスタンスのモニター、ジョブ出力の表示、およびジョブのキャンセルを行うには、この項目を開きます。

コンピューターダイナミック・ワークステーションの状況と詳細をモニターおよび編集するには、この項目を開きます。

プリファレンスDynamic Workload Broker の表示の設定をカスタマイズします。

ユーザー・プリファレンス各テーブルのページの行数のカスタマイズおよび表示される時間帯の設定を行うには、この項目を開きます。

最初に実行する操作

以下のセクションでは、Dynamic Workload Console に接続したときに実行する最初の主な操作について説明します。


Tivoli Workload Scheduler エンジンへの接続を作成するTivoli Workload Scheduler エンジンへのアクセスのための詳細 (IP アドレス、ユーザー名、パスワードなど) の入力や、オプションで、計画内に定義されているかまたはデータベースに格納されているオブジェクトの処理の際のデータベースへのアクセスのための詳細の入力を行います。 Dynamic

Workload Console からは、分散環境の場合は、現在の計画、試行計画、予測計画、またはアーカイブ計画にアクセスでき、z/OS® 環境の場合は、現在の計画にアクセスできます。データベースにアクセスして、そこに保管されているオブジェクトに対するアクションの実行や、ヒストリカル・データまたは統計データを示すレポートの生成を行うことができます。さらに、データベースと計画の両方の処理により、イベント・ルールを作成して実行することで、Tivoli Workload Scheduler ノードで発生するイベントに対する応答として実行するアクションを定義して起動することができます。

スケジューリング環境の定義Tivoli Workload Scheduler ネットワークを定義します。ワークロードの実行がスケジュールされている物理マシンまたはコンピューター・システムを表すワークステーション定義を、データベース上で作成します。 Tivoli

Workload Scheduler ネットワークは、ジョブとジョブ・ストリームが処理されるいくつかのワークステーションにより構成されます。ネットワークの設計時には、特定のビジネス要件にあった役割をそれぞれのワークステーションに割り当てます。複数のドメインを持ったネットワークを設計して、大規模ネットワークの制御を、より管理しやすい小さいグループに分割することができます。典型的な Tivoli Workload Scheduler ネットワークは、マスター・ドメイン・マネージャーとして機能するワークステーションと、少なくとも 1 つのドメインで構成されます。

データベース内のスケジューリング・オブジェクトの定義ジョブ・ストリーム内で連結されるジョブで構成されるワークロードを定義します。次に、どのジョブ・ストリームの実行が必要かに従ってカレンダーおよび実行サイクルを指定します。さらに、ワークロード処理の条件を定める指定可能な依存関係を定義します。これらの定義はすべて、Workload

Designer で行うことができます。

タスク Tivoli Workload Scheduler を作成して、計画内のオブジェクトを管理する特定のフィルター条件を指定し、指定したその条件を満たす属性を含むスケジューリング・オブジェクトのリストを照会します。このリストからは、オブジェクト間での切り替えや別のリストのオープン、他の計画や他の Tivoli

Workload Scheduler 環境へのアクセスなど、計画の内容についてナビゲートと変更を行うことができます。

Tivoli Dynamic Workload Broker スケジューリング環境への接続を作成するDynamic Workload Broker ワークステーションへのアクセスのための詳細(IP アドレス、ユーザー名、パスワード、ポートなど) の入力を行います。セキュア HTTPS または HTTP プロトコルを使用する場合、これを指定します。接続を作成した後、トラッキング・コンピューターを開いて、ブローカー・ワークステーションの状況と詳細を表示したり、リソースおよびダイナミック・ジョブを定義したりすることができます。動的スケジューリングについて詳しくは、「ワークロードの動的なスケジューリング」を参照してください。



この章では、Dynamic Workload Console を現行バージョンにアップグレードする方法について説明します。

注: 外部 WebSphere Application Server でのアップグレードはサポートされていません。別の製品と共に WebSphere Application Server をインストール済みの場合は、Dynamic Workload Console をアンインストールし、再度インストールする必要があります。

Tivoli Workload Automation のインスタンスをアップグレードするには、以下を実行します。

v インスタンスの一部であるすべてのコンポーネントをアップグレードする必要があります。例えば、ご使用のインスタンスに 1 つのマスター・ドメイン・マネージャーが含まれ、Dynamic Workload Console も含まれている場合、これらのコンポーネントの両方をアップグレードする必要があります。

v Dynamic Workload Console をアップグレードするためには、まずそのインスタンスに含まれるコンポーネントをすべてアップグレードする必要があります。

他の Tivoli Workload Automation コンポーネントと WebSphere Application Server

を共有している Dynamic Workload Console をインストールした場合、これらのコンポーネントをアップグレードすると、既存の Dynamic Workload Console は新しいバージョンにアップグレードされるまで機能しません。

組み込み WebSphere Application Server 上の Dynamic Workload Console をアップグレードすると、コンソールのディレクトリー構造が変更されます。このため、このセクションには以下のトピックが含まれています。

v 『認証の更新』

v 307ページの『組み込み WebSphere Application Server にインストールされたコンソールのアップグレード』

v 309ページの『アップグレードの実行』

認証の更新

このセクションでは、構成された認証メカニズムがどのようにアップグレードされるかを説明します。

V8.6 より前のバージョンの Tivoli Workload Scheduler では、認証はスタンドアロン・ユーザー・レジストリーを使用して構成され、組み込み WebSphere Application

Server によって管理されていました。使用可能なオプションは以下のとおりでした。

v ローカル・オペレーティング・システム

v カスタム (PAM - プラグ可能認証モジュール経由)

v LDAP

v ファイル・レジストリー

LDAP を有効にした場合、以下のサーバーのいずれかを使用できました。


v IBM Tivoli Directory Server

v Sun ONE

v Microsoft Windows Active Directory

v IBM Tivoli Directory Server 上で構成された RACF

Tivoli Workload Scheduler V8.6 以降のバージョンは、VMM (Virtual Member

Manager) モードで (組み込み WebSphere Application Server を通して) 認証のために構成されます。これによって、複数のユーザー・レジストリーの同時使用をサポートする、フェデレーテッド・ユーザー・レジストリーが作成されます。ユーザー・レジストリーの選択項目と LDAP サーバーのオプションは、V8.6 より前のバージョンの場合とほぼ同じです。

アップグレードの際に、既存の構成はマイグレーションされるため、アップグレードが完了したときに、製品は以前と同じ認証メカニズムを使用するように構成されますが、それはフェデレーテッド・ユーザー・レジストリーの内部になります。

詳しくは、「Tivoli Workload Scheduler 管理ガイド」を参照してください。

組み込み WebSphere Application Server にインストールされたコンソールのアップグレード

このセクションでは、組み込み WebSphere Application Server での Dynamic

Workload Console のアップグレードについての情報を提供します。

ディレクトリー構造

このセクションでは、プログラム・ディレクトリー構造、およびバージョン 8.5.1

で実装された SSL ファイルのディレクトリー構造について説明します。このセクションが当てはまるのは、バージョン 8.3 または 8.4 からアップグレードしている場合です。バージョン 8.5 または 8.5.1 からアップグレードする場合は、このディレクトリー構造はすでに存在しています。

プログラム・ディレクトリー:

Dynamic Workload Console を現行バージョンにアップグレードする際に、新規プログラム・ディレクトリー構造が作成されます。アップグレード・プロセスの際、Dynamic Workload Console のコンポーネントは古いディレクトリー構造から移動され、新規ディレクトリー構造に更新されます。 Dynamic Workload Console プログラム・ファイルは、元のインストール・ディレクトリーに残ります。

カスタム構成 (例えば、カスタム・スクリプトまたはバックアップ処理) がDynamic Workload Console 構造内に存在する場合、それらを更新して、新規ディレクトリー構造で機能するようにしなければなりません。

例えば、最初に Dynamic Workload Console をデフォルト・ディレクトリーc:¥Program Files¥IBM¥webui¥ にインストールした場合、ディレクトリー構造は次のようになります。


c:¥Program Files¥IBM¥TWA¥webui¥appserverc:¥Program Files¥IBM¥TWA¥webui¥wastoolsc:¥Program Files¥IBM¥TWA¥webui¥_webuiutilsc:¥Program Files¥IBM¥TWA¥webui¥_webuiuninstc:¥Program Files¥IBM¥TWA¥webui¥_jvm

Dynamic Workload Console をアップグレードすると、新規ディレクトリー構造は次のようになります。

c:¥Program Files¥IBM¥TWA¥eWASc:¥Program Files¥IBM¥TWA¥wastoolsc:¥Program Files¥IBM¥TWA¥TDWCc:¥Program Files¥IBM¥TWA¥TDWC¥_tdwcscriptsc:¥Program Files¥IBM¥TWA¥TDWC¥_tdwcuninstc:¥Program Files¥IBM¥TWA¥TDWC¥_tdwcutilsc:¥Program Files¥IBM¥TWA¥TDWC¥_jvm

新規ディレクトリー構造には、Tivoli Workload Scheduler に共通する新規組み込みWebSphere Application Server ツールが含まれています。

SSL ファイルのディレクトリー:

現行バージョンにアップグレードする際に、SSL ファイルの新規ディレクトリーが作成されます。以下は、新旧のディレクトリー構造について説明しています。

注: アップグレードの前に、カスタマイズした SSL キーをすべてバックアップし、デフォルトのインストール・パスにコピーする必要があります。

アップグレード後に、PCKS12 フォーマットで保管されている旧 SSL ファイルはJKS フォーマットで新規 SSL ファイルにインポートされます。

古い PCKS12 ファイルもバックアップとして新しいディレクトリーにコピーされます。key.p12 ファイルは、TWSServerKeyFile.jks になります。trust.p12 ファイルは、TWSServerTrustFile.jks になります。


v TWSInstallationPath¥appServer¥profiles¥webuiprofile¥config¥cells

¥CellName¥nodes¥NodeName¥key.p12

v TWSInstallationPath¥appServer¥profiles¥webuiprofile¥config¥cells

¥CellName¥nodes¥NodeName¥trust.p12


v TWSInstallationPath¥eWAS¥profiles¥TIPProfile¥config¥cells

¥TIPNode¥nodes¥TIPCell¥key.p12

v TWSInstallationPath¥eWAS¥profiles¥TIPProfile¥config¥cells

¥TIPNode¥nodes¥TIPCell¥trust.p12





注: key.p12 ファイルと trust.p12 ファイルは Dynamic Workload Console

によって使用されることはありませんが、バックアップされます。


アップグレードの実行

Dynamic Workload Console のアップグレードは、以下の方法を使用して行うことができます。

対話式ウィザード

対話式ウィザードを使用してアップグレードするには、インストールを行うオペレーティング・システムのセットアップを実行します。

Windows オペレーティング・システムの場合:WINDOWS¥SETUP.exe

開始する前に、以下のコマンドを実行して、appserverman プロセスを停止します。

Shutdown.cmd -appsrvStartWas.bat -direct

これらのコマンドを実行した後、組み込み WebSphere Application

Server を除くすべての Tivoli Workload Scheduler プロセスが停止されていることを確認してください。組み込み WebSphere Application

Server は稼働し続ける必要があります。

UNIX および Linux オペレーティング・システムの場合:SETUP.sh または operating_system/SETUP.bin


Launchpadランチパッドを始動し、Dynamic Workload Console アップグレードを選択します。コンソールのアップグレードのための一部のオプションが事前に選択された状態で、インストール・ウィザードが起動されます。

サイレント提供されているテンプレートから応答ファイルを作成し、-silent オプションを指定してインストール・ウィザードを実行することによって、アップグレードをサイレントにバックグラウンドで実行できます。サイレント・インストールまたはサイレント・アップグレードを実行する方法について詳しくは、 268ページの『サイレント・インストールの実行』を参照してください。応答ファイルに入力する必要があるアップグレード情報については、以下のセクションを参照してください。

インストール・パネルに従ってアップグレードを完了します。以下のリストは、アップグレードの際に入力する必要のあるフィールドについて説明しています。

Dynamic Workload Console の既存のインスタンスを使用Dynamic Workload Console の前のバージョンが検出されたというプロンプトが出された場合、「既存のインスタンスの使用」を選択します。ドロップダウン・リストからアップグレードするインスタンスを選択します。

アプリケーション・サーバーの管理上の資格情報外部または組み込み WebSphere Application Server のユーザー名およびパスワードを入力します。


バックアップ・ディレクトリーバックアップ・ディレクトリーを選択します。このディレクトリーには、構成情報および他のプログラムに関連したオブジェクトだけが含まれており、外部ファイルまたは組み込み WebSphere Application Server ファイルは含まれていません。このディレクトリーはアップグレード完了後も、コンピューターに残ります。




注:

1. Tivoli Workload Automation インスタンスについて詳しくは、 297ページの『Tivoli Workload Automation のインスタンス』を参照してください。

2. Windows でのアップグレードの際に、ローカルの OS ユーザー・レジストリーの組み込み WebSphere Application Server Windows サービスのアカウント名は、Tivoli Integrated Portal の管理者ユーザー名に変更されます。カスタム・レジストリーまたは LDAP レジストリーを使用する場合は、サービスはインストール・ユーザーにアップグレードされます。

3. 組み込み WebSphere Application Server は、アップグレード手順の間に自動的に停止されるので、アップグレードの前に手動で停止する必要はありません。

アンインストール中

この章では、Dynamic Workload Console をアンインストールする方法を説明します。この章は、以下のセクションに分かれています。

v 『ウィザードを使用したアンインストール』

v 311ページの『サイレント・モードでのアンインストール』

ウィザードを使用したアンインストール

ウィザードを使用して Dynamic Workload Console をアンインストールするには、以下のステップを実行してください。

1. Tivoli Integrated Portal を始動します。

2. 以下のようにしてアンインストールを開始します。

Windows オペレーティング・システムの場合:以下のいずれかを実行します。

v TWA_home¥TDWC ディレクトリーから次のコマンドを実行します。

uninstall.bat


v 「コントロールパネル」から、「プログラムの追加と削除」をクリックします。ソフトウェアのリストをスクロールダウンし、Dynamic

Workload Console を選択します。「変更と削除」をクリックします。

UNIX オペレーティング・システムの場合:TWA_home/TDWC ディレクトリーから次のコマンドを実行します。

uninstall.sh

3. 言語を選択します。

4. Dynamic Workload Console アンインストールのようこそウィンドウで、「次へ」をクリックします。

5. 外部または組み込み WebSphere Application Server の管理者ユーザー名およびパスワードを入力し、「次へ」をクリックします。

6. アンインストールの要約ウィンドウで、製品が削除されるディレクトリーおよび削除されるフィーチャーが正しいことを確認して、「アンインストール」をクリックします。Dynamic Workload Console および Tivoli Integrated Portal がインストールされている場合は、それらが両方ともアンインストールされます。既存の Tivoli Integrated Portal に Dynamic Workload Console がインストールされている場合は、Dynamic Workload Console のみがアンインストールされます。

7. アンインストールが完了すると、操作が正常に実行されたことを示すメッセージがウィンドウに表示されます。「完了」をクリックして、InstallShield ウィザードを終了します。

サイレント・モードでのアンインストール

Dynamic Workload Console のサイレント・アンインストールを実行できます。

アンインストールを開始する前に、Tivoli Integrated Portal がアクティブであること、および tdwc_install_dir とは異なるディレクトリーに移動していることを確認してください。

以下のようにアンインストール・コマンドを実行します。

Windows オペレーティング・システムの場合:twa_home¥tdwc¥uninstall.bat -options

response_file.txt -silent

UNIX または Linux オペレーティング・システムの場合:twa_home/tdwc/uninstall.bin -options

response_file.txt -silent

ここで、response_file は、絶対パス名です。

インストール、アップグレード、およびアンインストールのトラブルシューティング

この章では、Dynamic Workload Console のインストール、アップグレード、およびアンインストールのトラブルシューティングの方法について説明します。この章は、以下のセクションに分かれています。


v 『インストールおよびアンインストールのログ・ファイルとトレース・ファイル』

v 『失敗した InstallShield ウィザード・インストールのリカバリー』

v 313ページの『失敗したアップグレードのリカバリー』

v 313ページの『統合 Dynamic Workload Console の手動でのアンインストール』

v 316ページの『トラブルシューティング・シナリオ』

注: 手動でのアンインストールまたは失敗したインストールからのリカバリーについては、 313ページの『統合 Dynamic Workload Console の手動でのアンインストール』のセクションを参照してください。

インストールおよびアンインストールのログ・ファイルとトレース・ファイル

インストールのログ・ファイルについて詳しくは、 299ページの『インストール・ログ・ファイル』を参照してください。

失敗した InstallShield ウィザード・インストールのリカバリー

失敗した Dynamic Workload Console のインストールのリカバリーは、「Tivoli

Workload Scheduler 計画およびインストール」および Tivoli Workload Scheduler の説明と構造的には非常によく似ています。しかし、重要な違いがいくつかあります。このセクションではそのことについて説明します。

失敗したインストールのリカバリーについては、「Tivoli Workload Scheduler 計画およびインストール」に詳細に説明されています。

「Tivoli Workload Scheduler 計画およびインストール」の指示に、「Tivoli Workload

Scheduler 計画およびインストール」の指示に、ステップの値を変更する点まで従い、それから次の指示に従います。

1. Dynamic Workload Console の各ステップで使用された値はすべて、ステップ 0

という 1 つの場所に保管されます。このため、例えば、ポートが使用中であったために組み込み Tivoli Integrated Portal を構成するステップが失敗したことに気付いた場合、ステップ 0 に移動し、そのステップのポートの値を変更する必要があります。

2. ステップ 0 の状態、および失敗したステップの状態を「作動可能」に設定します。

3. いかなる場合にも、「次を実行 (Run next)」オプションを使用して、ステップ・リストのステップ 0 を実行します。ステップ 0 は、変更されたものをオリジナル・データとして使用し、ステップを実行するすべてのスクリプトを再生成します。

4. 失敗したステップからウィザードを再開します。これを行うには、「すべて実行(Run all)」を実行して各ステップで停止せずにインストールを完了するか、「次を実行 (Run next)」を実行して段階的にインストールを完了します。

注: ステップ 0 以外の、正常に完了したステップは再実行することができません。


失敗したアップグレードのリカバリー

アップグレードが失敗した場合は、IBM ソフトウェア・サポートにお問い合わせください。

統合 Dynamic Workload Console の手動でのアンインストール

以下のステップを実行して、Dynamic Workload Console を含んでおり、組み込みTivoli Integrated Portal を使用している Tivoli Workload Automation のインスタンスを手動で除去します。インストールが失敗した場合、インストールが失敗したタイミングによっては、いくつかのステップが不要になる可能性があります。

Tivoli Workload Scheduler と Dynamic Workload Console の統合インストールが含まれている Tivoli Workload Automation のインスタンスを削除するには、以下の操作を実行します。

1. Tivoli Workload Scheduler を「Tivoli Workload Scheduler 計画およびインストール」の説明に従ってアンインストールします。

2. 以下の手順を実行して、Dynamic Workload Console を削除します。

Tivoli Workload Automation インスタンスを除去せずに Tivoli Workload Automation

のインスタンスから Dynamic Workload Console を除去する場合は、IBM ソフトウェア・サポートにお問い合わせください。

注: 以下に示す手動のステップは Dynamic Workload Console がインストールされているシステム上でのみ実行してください。それ以外のシステムで実行すると、Composite Offering Installer レジストリーを削除してしまいます。


1. インストール DVD またはダウンロードした eImage を使用してDynamic Workload Console を既に削除した場合は、¥TDWC¥WEBUI¥<operating_system>¥scripts¥ ディレクトリーから以下のコマンドを実行します。

# ./cleanDE.bat -installRoot <TWA_INSTALL_DIR>¥eWas -force true

Dynamic Workload Console がまだインストールされていて、稼働していない場合は、<TWA_INSTALL_DIR>¥TDWC¥_tdwcutils¥scripts¥ ディレクトリーから以下のコマンドを実行します。


2. サービスを停止します。

<TWA_INSTALL_DIR>¥bin¥WASService -stop TIPProfile_Port_defaulthost_port

3. サービスを削除します。

<TWA_INSTALL_DIR>¥bin¥WASService -remove

4. <TWA_INSTALL_DIR> にナビゲートし、ID ファイル twainstancexxx.id

の名前をメモします。後の手順でこの情報が必要になります。

5. 以下のディレクトリーを除去します。

<TWA_INSTALL_DIR>



C:¥Program Files¥Common Files¥InstallShield¥Universal¥TDWC

7. 以下のレジストリー・キーを削除します。

HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥Uninstall¥e625666383dedb70850864e2a6feaa2e1371705039


%windir%¥TWA¥twainstancexxx.properties




# ./cleanDE.sh -installRoot <TWA_INSTALL_DIR>¥eWas -force true



2. 次のコマンドを実行してサーバーを停止します。

<TWA_INSTALL_DIR>/wastools/stopWas.sh

3. <TWA_INSTALL_DIR> にナビゲートし、ID ファイル twainstancexxx.id

の名前をメモします。後の手順でこの情報が必要になります。


<TWA_INSTALL_DIR>


AIX の場合

/usr/lib/objrepos/InstallShield/Universal/TDWC

AIX を除くすべての UNIX システムの場合

ROOT_USER_HOME/InstallShield/Universal/TDWC


etc/TWA/twainstancexxx.properties

スタンドアロン Dynamic Workload Console バージョン 8.6.0インスタンスの手動でのアンインストール

スタンドアロン Dynamic Workload Console インスタンスをアンインストールするための正しい手順は、そのアンインストーラー・プログラムを実行することです。例えばインストールまたはアンインストールの失敗などでこれが不可能である場合には、手動作業での手順が必要になります。

組み込み Tivoli Integrated Portal を使用する Dynamic Workload Console のスタンドアロン・インスタンスを手動で削除するには、以下のステップを実行します。インストールが失敗した場合、インストールが失敗したタイミングによっては、いくつかのステップが不要になる可能性があります。


Dynamic Workload Console のインスタンスを削除するには、以下のアクションを実行します。

注: 以下に示す手動のステップは Dynamic Workload Console がインストールされているシステム上でのみ実行してください。それ以外のシステムで実行すると、Composite Offering Installer レジストリーを削除してしまいます。






2. サービスを停止します。

<TWA_INSTALL_DIR>¥bin¥WASService -stop TIPProfile_Port_defaulthost_port

3. サービスを削除します。

<TWA_INSTALL_DIR>¥eWAS¥bin¥wasservice.exe –remove TDWC_admin_username

4. ISMP インストール・レジストリー・ディレクトリーを除去します。

%CommonProgramFiles%¥InstallShield¥Universal¥TDWC

5. Tivoli Workload Automation レジストリー・ファイルを削除します。Tivoli Workload Automation インスタンス番号を示す、ファイル<TWA_INSTALL_DIR>¥ twainstancexxx.id 内の数値 n に注意し、以下のファイルを削除します。

%WINDIR%¥TWA¥twainstance<n>.TWA.properties

%WINDIR%¥TWA¥twainstance<n>.TWA.properties.ext

6. 以下のレジストリー・キーを削除します。

HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥Uninstall¥e625666383dedb70850864e2a6feaa2e1371705039


<TWA_INSTALL_DIR>







2. 次のコマンドを実行して組み込み WebSphere Application Server を停止します。

<TWA_INSTALL_DIR>/wastools/stopWas.sh


AIX の場合

/usr/lib/objrepos/InstallShield/Universal/TDWC

AIX を除くすべての UNIX システムの場合

ROOT_USER_HOME/InstallShield/Universal/TDWC

4. Tivoli Workload Automation レジストリー・ファイルを削除します。Tivoli Workload Automation インスタンス番号を示す、ファイル<TWA_INSTALL_DIR>¥ twainstancexxx.id 内の数値 n に注意し、以下のファイルを削除します。

/etc/TWA/twainstance<n>.TWA.properties

/etc/TWA/twainstance<n>.TWA.properties.ext


<TWA_INSTALL_DIR>


/var/ibm/common/acsi

/usr/ibm/common/acsi

トラブルシューティング・シナリオ

以下のカテゴリーにトラブルシューティング・シナリオがリストされています。

v 『ランチパッドに関する問題』

v 317ページの『対話式ウィザードに関する問題』

v 322ページの『サイレント・インストールに関する問題』

v 322ページの『アップグレードに関する問題』

v 323ページの『アンインストールに関する問題』

ランチパッドに関する問題

ランチパッドを使用して Dynamic Workload Console をインストールする際、以下の問題が生じる可能性があります。

v 『Linux でランチパッドを使用する際に警告メッセージが表示される』

v 317ページの『Windows オペレーティング・システムでランチパッドを使用する際に未定義エラーが表示される』

Linux でランチパッドを使用する際に警告メッセージが表示される:

問題記述

Linux でランチパッドを使用する際、警告メッセージが標準出力に表示される可能性があります。



これらのメッセージはランチパッドの誤動作を示しているわけではないので無視して構いません。

Windows オペレーティング・システムでランチパッドを使用する際に未定義エラーが表示される:

問題記述

ランチパッドを使用して Dynamic Workload Console を Windows オペレーティング・システムにインストールしようとすると、「未定義」エラー・メッセージを受け取ります。ランチパッドが開始されません。


インストールを起動したパスに 8 文字を超えるフォルダー名が含まれていないことを確認してください。含まれている場合、パスを launchpad.exe にマップして、その新しいパスからランチパッドを実行してください。

対話式ウィザードに関する問題

Dynamic Workload Console 対話式インストールの実行中に以下の問題が生じる可能性があります。

v 『Dynamic Workload Console のインストールのハング』

v 318ページの『stopWas コマンド使用時にインストールがハングする』

v 318ページの『ログにはインストールの成功が記録されているのに Tivoli

Integrated Portal のインストールが失敗する場合』

v 319ページの『Windows オペレーティング・システムでリモート共用フォルダーからのインストールが失敗する』

v 319ページの『ホスト名が完全修飾ドメイン名でない Linux 390 システムでインストールが失敗する』

v 320ページの『Red Hat Enterprise Linux (RHEL) バージョン 5 または Suse

Linux システム・バージョン 11 に Dynamic Workload Console をインストールする際に Java 仮想マシン (JVM) が失敗する』

v 321ページの『Red Hat Enterprise Linux (RHEL) バージョン 5 (x86-64) でDynamic Workload Console グラフィカル・インストールおよびアンインストールの開始に失敗する』

v 321ページの『Windows で、外部 WebSphere Application Server の異なるプロファイルに再インストールを試みると、Dynamic Workload Console インストールが失敗する』

Dynamic Workload Console のインストールのハング:

問題記述

Dynamic Workload Console のインストールを続行できません。この問題は、インストールに使った方法に関係なく発生します。



アクティブ・パーソナル・ファイアウォールによって、インストール・プロセスにおけるネットワーク接続が妨げられていないことを確認してください。妨げられている場合は、接続を許可し、インストールを続行します。

stopWas コマンド使用時にインストールがハングする:

問題記述

Dynamic Workload Console のインストールを続行できません。


stopWas コマンドがハングするために Dynamic Workload Console のインストールを続行できません。

インストールを続行するには、タスクマネージャを開き、組み込み WebSphere

Application Server の Java プロセスを見つけます。このプロセスは、関連したインストール・ユーザー名を持つ java.exe プロセスです。このプロセスを停止します。

その後、関連した WASService プロセスを探します。このプロセスは、関連したインストール・ユーザー名を持つ WASService.exe プロセスです。このプロセスを停止します。

インストールを続行します。

ログにはインストールの成功が記録されているのに Tivoli Integrated Portal のインストールが失敗する場合:

問題記述

ウィザードまたはサイレント・インストールで Tivoli Integrated Portal をインストールするときに、インストールが失敗し、以下のエラーが生成されます。

Start installing TIP - Tivoli Integrated Portal 2.2For log details, please seeC:¥Documents and Settings¥Administrator¥TIPInstaller-00.logand {install location}¥logs.zipPreparing SILENT Mode Installation...

===========================================================================GenericInstaller (created with InstallAnywhere by Macrovision)---------------------------------------------------------------------------===========================================================================Installing...=============|==================|==================|==================]

Installation Complete.SUCCESS: The overall installation is successful.Current OS is Windows XPExecuting’C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin¥tipcli.bat’ with arguments:’Version’

The ’ characters around the executable and arguments arenot part of the command.Execute:Java13CommandLauncher:Executing’C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin¥tipcli.bat’ with arguments:


’Version’

The ’ characters around the executable and arguments arenot part of the command.The following error occurred while executing this line:C:¥temp¥TDWC¥WEBUI¥WINDOWS¥xml¥commonTargets.xml:1735:Execute failed: java.io.IOException:Cannot run program "C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin¥tipcli.bat"in directory "C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin"):CreateProcess error=2, The system cannot find the file specified.****************************************************************************Installation Complete.SUCCESS: The overall installation is successful.Current OS is Windows XPExecuting’C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin¥tipcli.bat’ with arguments:’Version’

The ’ characters around the executable and arguments arenot part of the command.Execute:Java13CommandLauncher:Executing’C:¥IBM¥TWS¥TDWC¥eWAS¥profiles¥TIPProfile¥bin¥tipcli.bat’ with arguments:’Version’


このエラーが発生するのは、アンインストーラーを実行しないで Dynamic Workload

Console のインスタンスを削除したときに (例えば、TWA ディレクトリーの内容だけを手動で削除したときに)、Tivoli Integrated Portal も同じパスにインストールされていた場合です。この場合、Tivoli Integrated Portal のインスタンスは、デプロイメント・エンジンのインストール・レジストリーに登録されたままの状態になります。そのような状態で Tivoli Integrated Portal の別のインストールを実行すると、インストーラーから上記のエラーが報告されます。

313ページの『統合 Dynamic Workload Console の手動でのアンインストール』にある手順を実行して、環境をクリーンアップします。失敗したステップからインストールを再開します。

Windows オペレーティング・システムでリモート共用フォルダーからのインストールが失敗する:

問題記述

汎用命名規則 (UNC) を使用する共用ネットワーク・フォルダーから Dynamic

Workload Console を Windows オペレーティング・システムにインストールしようとしています。インストールは失敗します。


Dynamic Workload Console のインストールを行う Windows システムのローカルにリモート・フォルダーをマップし、それからローカル・パスを使用してインストールを実行してください。

ホスト名が完全修飾ドメイン名でない Linux 390 システムでインストールが失敗する:

問題記述


ホスト名が完全修飾ドメイン名ではないサーバーに Dynamic Workload Console を組み込み WebSphere Application Server と共にインストールします。インストールは失敗し、以下のエラーが twainstall.log ファイルに保管されます。

ADMU3011E: Server launched but failed initialization. startServer.log,SystemOut.log(or job log in zOS) and other log files under/oracle/ibm/TDWC/eWAS/profiles/TIPProfile/logs/tdwcservershould contain failure information.

WASX7023E: Error creating "SOAP" connection to host "localhost";exception information:com.ibm.websphere.management.exception.ConnectorNotAvailableException:com.ibm.websphere.management.exception.ConnectorNotAvailableException:ADMC0016E: The system cannot create a SOAP connector to connect to host

localhost at port 28880.


Dynamic Workload Console のインストールを試みた Linux 390 システムのシステム・プロンプトから、以下のコマンドを実行します。

hostname --fqdn

コマンドが以下を戻したとします。

hostname: Unknown host

この場合、ホスト名は解決されていません。組み込み WebSphere Application Server

をインストールするには、ホスト名を完全修飾ドメイン名で指定する必要があります。組み込み WebSphere Application Server の資料で説明されているようにホスト名の表記を更新し、その後インストールを再実行してください。

Red Hat Enterprise Linux (RHEL) バージョン 5 または Suse Linux システム・バージョン 11 に Dynamic Workload Console をインストールする際に Java 仮想マシン (JVM) が失敗する:

問題記述

Red Hat Enterprise Linux バージョン 5 または Suse Linux Version 11 のシステムに Dynamic Workload Console をインストールするときに、「VM が見つかりません - 打ち切り中 (Failed to find VM - aborting)」というエラーを受け取る可能性があります。


Linux システムには、「Security Enhanced Linux」(短縮系は SELinux) という名前のセキュリティー・フィーチャーがあります。Red Hat Enterprise Linux バージョン 4

には SELinux の下位バージョンが含まれており、デフォルトでは使用不可になっています。Red Hat Enterprise Linux および Suse Linux のこれらのバージョンでは、このセキュリティー・フィーチャーがデフォルトで有効になっています。SELinux

は、ある種の悪意のある攻撃からホストを保護する上で役立ちます。しかし、そのデフォルト設定では Java が正常に実行できないというケースが多く報告されています。

この問題を解決するには、以下のオプションのいずれかを選択してください。


v SELinux を構成し、Dynamic Workload Console Java 関連のプロセスの実行を許可します。

v コマンド行で setenforce 0 を入力することにより、SELinux のモードを「許容(Permissive)」に変更します。次回システムのリブート時またはコマンド行にsetenforce 1 を入力すると、SELinux は再び完全に使用可能になります。Dynamic Workload Console が機能するためには、setenforce 0 を設定する必要があります。setenforce について詳しくは、ご使用のオペレーティング・システムの資料を参照してください。

Red Hat Enterprise Linux (RHEL) バージョン 5 (x86-64) で Dynamic WorkloadConsole グラフィカル・インストールおよびアンインストールの開始に失敗する:

問題記述

Red Hat Enterprise Linux (RHEL) バージョン 5 x86-64 上で、対話モードでDynamic Workload Console のインストールまたはアンインストールのウィザードを起動するときに、以下のエラーを受け取る場合があります。

インストールの場合:

The installer is unable to run in graphical mode.Try running the installer with the -console or -silent flag.

アンインストールの場合:

The uninstaller is unable to run in graphical mode.Try running the uninstaller with the -console or -silent flag.


この問題が生じた場合は、サイレント・モードでインストールまたはアンインストールを起動してください。詳しくは、 268ページの『サイレント・インストールの実行』および 311ページの『サイレント・モードでのアンインストール』を参照してください。

Windows で、外部 WebSphere Application Server の異なるプロファイルに再インストールを試みると、Dynamic Workload Console インストールが失敗する:

問題記述

以下の状況は、Windows オペレーティング・システムに当てはまります。Dynamic

Workload Console を、既存の WebSphere Application Server インストール済み環境のプロファイル (例えば、ProfileA) にインストールします。Dynamic Workload

Console を正常に除去してから、同じ WebSphere Application Server の異なるプロファイルにインストールを試みます。インストールは失敗します。


Dynamic Workload Console を除去したときに、ProfileA に属するいくつかのファイルが除去されなかったことが原因として考えられます。この問題を解決するには、ProfileA を停止し、もう 1 つのプロファイルで再び Dynamic Workload

Console をインストールします。


サイレント・インストールに関する問題

Dynamic Workload Console サイレント・インストールの実行中に以下の問題が生じる可能性があります。

v 『サイレント・アンインストールが機能せず、エラー・コードが返される』

v 318ページの『ログにはインストールの成功が記録されているのに Tivoli

Integrated Portal のインストールが失敗する場合』

サイレント・アンインストールが機能せず、エラー・コードが返される:

問題記述

存在していない応答ファイルを使ってサイレント・アンインストールを実行しようとしている場合、ファイル名が正しくないか、または間違ったディレクトリーを指定しているために、エラー・コードが返され、アンインストールは実行されません。一時ディレクトリーには何も記録されず、メッセージも出されません。


有効な応答ファイル名を指定していることを確認してください。

アップグレードに関する問題

Dynamic Workload Console アップグレードの実行中に以下の問題が生じる可能性があります。

v 『メッセージ AWSUI0085E でアップグレードが失敗する場合』

メッセージ AWSUI0085E でアップグレードが失敗する場合:

問題記述

Dynamic Workload Console のアップグレードを実行すると、以下のエラーが発生します。

The instance of the Dynamic Workload Console that you want to upgradeuses an LDAP user registry.The LDAP server type you are using is not supported.The supported LDAP server types are:IBM Tivoli Directory Server, Microsoft Active Directory, Sun ONE DS,and RACF configured on IBM Tivoli Directory Server.Use a supported LDAP server type or install a fresh instanceof the Dynamic Workload Console


アップグレードが失敗するのは、サポートされていないタイプの LDAP サーバーを使用しているからです。サポートされているタイプの LDAP サーバーは、以下のとおりです。v IBM Tivoli Directory Server

v Microsoft Active Directory

v Sun ONE DS

v IBM Tivoli Directory Server 上で構成された RACF


Dynamic Workload Console で以下の項目を使用できるように構成します。

v サポートされているタイプの LDAP サーバーのいずれか。

v ローカル・オペレーティング・システム - Windows オペレーティング・システムへのインストール時のデフォルトの認証システム。

v カスタム (PAM 経由 - プラグ可能認証モジュール) - UNIX と Linux のオペレーティング・システムへのインストール時のデフォルトの認証システム。

あるいは、Dynamic Workload Console の新規インスタンスをインストールしてから、サポートされているタイプの LDAP サーバーのいずれかを使用できるように構成します。

アンインストールに関する問題

Dynamic Workload Console アンインストールの実行中に以下の問題が生じる可能性があります。

v 『インストール・ディレクトリーに @ 文字が含まれている場合、Windows でのアンインストールが失敗する』

v 『Red Hat Enterprise Linux (RHEL) バージョン 5 (x86-64) で Dynamic Workload

Console 対話式アンインストール・ウィザードの開始に失敗する』

v 324ページの『Dynamic Workload Console をアンインストールした後で再インストールするとインストールが失敗する』

インストール・ディレクトリーに @ 文字が含まれている場合、Windows でのアンインストールが失敗する:

問題記述

名前に @ の文字を含むディレクトリー、例えば C:¥Program Files¥ibm¥TDWC¥a-

.@_~a にインストールされている Dynamic Workload Console を除去するためにuninstaller.exe を実行すると、アンインストールは失敗し、以下のエラー・メッセージが表示されます。

CreateProcess failed ==> The system cannot find the file specified.


「@」は ISMP にとって特殊文字であるため、アンインストールは失敗します。ISMP はこの文字を含むインストール・ディレクトリーを管理することができません。

この問題を回避するには、以下のようにアンインストールを実行してください。

"C:¥Program Files¥ibm¥TDWC¥a-.@_~a¥_jvm¥jre¥bin¥java.exe"-cp "C:¥Pr Fi¥ibm¥TDWC¥a-.@_~a¥_tdwcuninst¥uninstall.jar" run

このコマンドはインストール・ディレクトリーの外で実行してください。そうしないと、インストール・ディレクトリーは除去されません。

Red Hat Enterprise Linux (RHEL) バージョン 5 (x86-64) で Dynamic WorkloadConsole 対話式アンインストール・ウィザードの開始に失敗する:

問題記述


Red Hat Enterprise Linux (RHEL) バージョン 5 (x86-64) で Dynamic Workload

Console 対話式アンインストール・ウィザードを起動するときに、以下のエラーが表示されます。

The uninstaller is unable to run in graphical mode.Try running the uninstaller with the -console or -silent flag.

解決策については、 321ページの『Red Hat Enterprise Linux (RHEL) バージョン 5

(x86-64) で Dynamic Workload Console グラフィカル・インストールおよびアンインストールの開始に失敗する』を参照してください。

Dynamic Workload Console をアンインストールした後で再インストールするとインストールが失敗する:

問題記述

Dynamic Workload Console がアンインストールされた Windows システムでDynamic Workload Console を再インストールしようとすると、インストールが失敗します。


この問題は、アンインストールの際に eWAS ディレクトリーが正しく削除されていないことが原因である可能性があります。 Dynamic Workload Console のアンインストールの際に別のプロセスによってロックされているために eWAS ディレクトリーを削除できない場合、アンインストール・ウィザードは失敗しませんが、ディレクトリーを除去せずに正常完了します。この問題の解決策は、eWAS ディレクトリーを削除できない場合にアンインストールを強制的に失敗させることです。これにより、eWAS ディレクトリーに関連したすべてのプロセスを強制終了することができます。あるいは、ディレクトリーを手動で削除し、最後にインストール・ステップを再実行することができます。


第 4 部チュートリアル

Tivoli Workload Scheduler チュートリアル・ユーティリティーの使用法

このセクションでは、Tivoli Workload Scheduler のチュートリアル・ユーティリティーについて説明し、スタンドアロンのテスト環境にデータを取り込み、使用する手順を段階を追って解説します。チュートリアル・ユーティリティーは、実際の環境での Tivoli Workload Scheduler の機能と能力の概要を知る必要がある、この製品を初めてご使用になるユーザーを対象としています。チュートリアル・ユーティリティーには、サンプル・データベースと、事前に定義されたスケジューリング・オブジェクトやこのオブジェクトを使用するシナリオ群が含まれています。

sampledbsetup.sh または SAMPLEDBSETUP.CMD スクリプト (UNIX 環境を使用しているか、Windows 環境を使用しているかによる) によって、ご使用の Tivoli

Workload Scheduler に一連のスケジューリング・オブジェクトが取り込まれます。シナリオのスクリプトでは、基本的なスケジューリング・アクティビティーでこれらのオブジェクトを使用します。各シナリオは自己完結型であり、最初のシナリオがほかのすべてのシナリオの前提条件であることを除いて、任意の順序で実行することができます。

Tivoli Workload Scheduler チュートリアル・ユーティリティーはマスター・ドメイン・マネージャーでのみ実行します。ご使用の Tivoli Workload Scheduler 環境内で定義されたほかのどのワークステーションにも影響を与えません。各シナリオは、conman および composer コマンド・インターフェースを使用する別々のスクリプト・ファイルとして起動されます。シナリオで使用する各コマンドの構文および使用法は、「Tivoli Workload Scheduler ユーザーズ・ガイドおよびリファレンス」で詳しく説明しています。このユーティリティーの使用を開始する前に、「Tivoli

Workload Automation 概要」にある Tivoli Workload Scheduler の概念とタスクの概要をお読みください。

この章は、以下のセクションで構成されています。

v 『Tivoli Workload Scheduler データベースへのデータの取り込み』

v 327ページの『スケジューリング・シナリオの概要』

v 328ページの『実動計画の作成と処理』

v 329ページの『スケジューリング・シナリオの実行』

v 333ページの『データベースからのチュートリアル・オブジェクトの除去』

Tivoli Workload Scheduler データベースへのデータの取り込み

このセクションでは、このユーティリティーを使用して Tivoli Workload Scheduler

データベースにデータを取り込む方法について説明します。

テスト環境のマスター・ドメイン・マネージャーに Tivoli Workload Scheduler をインストールした後、データベースへのデータの取り込みを開始することができます。


以下のステップに従います。

1. TWS_home/TWS/TWSTutorial ディレクトリーに移動します (ここで、TWS_home

は Tivoli Workload Scheduler をインストールする対象となったユーザーのホーム・ディレクトリーです)。

2. チュートリアル・ユーティリティーのインストール・スクリプトを以下のように起動します。


SAMPLEDBSETUP.CMD


sampledbsetup.sh

このスクリプトは、各シナリオ内で使用されるすべてのオブジェクトが簡単に識別できるように、先頭のストリングが SMPL で、オブジェクト・タイプとシナリオ番号がその後に続く名前を持った一連のスケジューリング・オブジェクトを追加します。一部のオブジェクトは、使用している環境が UNIX であるか Windows であるかによって異なります。

スクリプトは、データベース上でチェックを行います。同じ名前のオブジェクトが見つかった場合、これらのオブジェクトを上書きしてもよいかどうかを指示するようにプロンプトを出します。

スクリプトの処理が正常に終了すると、Tivoli Workload Scheduler データベースには、スケジューリング・シナリオを実行するために必要なオブジェクトが含まれるようになります。

Tivoli Workload Scheduler チュートリアル・シナリオで使用するオブジェクト

テスト環境に Tivoli Workload Scheduler チュートリアル・ユーティリティーを正常にインストールした後には、データベースに以下のスケジューリング・オブジェクトが取り込まれています。

表 19. チュートリアル・ユーティリティーによってダウンロードされるオブジェクト

オブジェクト・タイプオブジェクト名 (オブジェクトの合計数)

カレンダー SMPCAL6 (1)

変数 SMPLHOME、 SMPLUSER、 SMPLWIN1 からSMPLWIN4 または SMPLUNX1 からSMPLUNX4、 SMPLSLEEP、 SMPLTMP、SMPLPATH (6)

リソース SMPLRES1、SMPLRES2 (2)

プロンプト SMPLPRM4、SMPLPRM5、SMPLPRM6、SMPLPRM7 (4)


表 19. チュートリアル・ユーティリティーによってダウンロードされるオブジェクト (続き)

オブジェクト・タイプオブジェクト名 (オブジェクトの合計数)

ジョブ SMPL_JOB_3_0_1、 SMPL_JOB_3_0_2、SMPL_JOB_3_0_3、 SMPL_JOB_4_0_1、SMPL_JOB_4_0_2、 SMPL_JOB_4_0_3、SMPL_JOB_5_0_1、 SMPL_JOB_5_0_2、SMPL_JOB_7_0_1、 SMPL_JOB_7_0_2、SMPL_JOB_7_0_3、 SMPL_JOB_9_0_1、SMPL_JOB_9_1_1、 SMPL_JOB_EVN、SMPL_JOB_ODD、 SMPL_JOB_PAIR、SMPL_JOB_SBJ、SMPL_JOB_7_0_LAST、SMPL_JOB_7_0_RECV

(19)

ジョブ・ストリーム SMPL_SCHED_3_0_1、SMPL_SCHED_3_0_2、SMPL_SCHED_4_0_1、SMPL_SCHED_4_0_2、SMPL_SCHED_4_0_3、SMPL_SCHED_4_0_S、SMPL_SCHED_5_0_1、SMPL_SCHED_5_0_2、SMPL_SCHED_7_0_1、SMPL_SCHED_7_0_2、SMPL_SCHED_7_0_3、SMPL_SCHED_9_0_1、SMPL_SCHED_9_0_2、SMPL_SCHED_9_1_1、SMPL_SCHED_5-ODD、SMPL_SCHED_5_EVN、 SMPL_SCHED_SBS

(17)

イベント・ルール SMPL_FILTER_RULE (1)

変数テーブル SMPL_VAR_TABLE_9_0_1、SMPL_VAR_TABLE_9_0_2 (2)

composer コマンド・インターフェースを実行して、各オブジェクトを表示することができます。 composer インターフェースの構文に関する具体的な情報については、「Tivoli Workload Scheduler ユーザーズ・ガイドおよびリファレンス」を参照してください。

スケジューリング・シナリオの概要

次の表に、各シナリオで取り扱うトピックについて説明します。各シナリオは、別個のスクリプト・ファイルになっています。

最初にシナリオ 1 を実行する必要がありますが、他のシナリオの実行順序は自由に選択できます。

表 20. スケジューリング・シナリオのリスト

シナリオ名スクリプト名トピック

シナリオ 1 scenario1.0.bat (Windows)

scenario1.0.sh (UNIX)

実動計画の作成とその内容の表示注: このシナリオは、この後に続くその他のすべてのシナリオの前提条件です。

第 4 部チュートリアル 327

表 20. スケジューリング・シナリオのリスト (続き)

シナリオ名スクリプト名トピック



管理コマンド: Tivoli

Workload Scheduler プロセスの開始と停止



スケジューリングの基本: ジョブをスケジュールする方法、ジョブの実行順序



高度なスケジューリング: プロンプト、ファイル、およびリソースの依存関係



時間の依存関係と実行サイクル



ジョブの実行依頼 (ジョブ、ジョブ・ストリーム、随時ジョブ)



リカバリー・オプションとリカバリー・ジョブ



イベント・ドリブン・スケジューリング



変数テーブルの使用

実動計画の作成と処理

データベースに正常にデータを取り込むと、実動計画を作成するシナリオ 1 を実行する準備ができます。実動計画には、スケジューリングの対象となるデータベース・オブジェクト (ジョブおよびジョブ・ストリーム) が含まれます。

シナリオ 1 は、他のすべてのシナリオの前提条件なので、最初に実行する必要があります。その後、他のシナリオを任意の順序で実行できます。

シナリオ内のほとんどのコマンドは、簡易書式で示されています。その場合、それぞれのシナリオの説明で、コマンドの完全な名前を括弧に囲んで示しています。

シナリオ 1: 実動計画の作成とその内容の表示

シナリオは、以下を行う方法を示しています。v 実動計画を作成および拡張するv 計画が正常に作成されたかどうかを確認するv 計画の内容を表示する

シナリオは以下のアクションを実行します。v 24 時間の実動計画を作成するv チュートリアルが既にデータベースに追加した、すべてのジョブおよびジョブ・ストリームを、その依存関係と合わせて計画に入れる

v 計画の内容を表示する


このシナリオで使用するコマンドとその実行順序:

1. JnextPlan2. conman sc (showcpus)

3. planman showinfo4. conman ss @#SMPL@ (showschedules)

スケジューリング・シナリオの実行

シナリオ 1 の計画を作成した後、他のシナリオでは、データベース内のチュートリアル・オブジェクトを計画内でスケジュールすることにより、それらのチュートリアル・オブジェクトを使用します。各シナリオでは、それぞれ異なるスケジューリングの概念を説明します。シナリオで使用される各コマンドの出力が画面上に表示されます。

注: シナリオごとに異なるオブジェクトを使用するため、シナリオは任意の順序で実行することができます。ただし、シーケンスの中で同じシナリオを複数回実行する場合は、計画をリセットして、シナリオ 1 を再度実行してから、個々のシナリオを再実行する必要があります。以下のステップを実行します。


ResetPlan -scratch

2. scenario1.0.bat (Windows の場合) または scenario1.0.sh スクリプト (UNIX

の場合) を実行します。

シナリオ 2: Tivoli Workload Scheduler プロセスの開始と停止

このシナリオでは、いくつかの基本的な管理タスクを実行します。各 stop またはstart コマンドの実行後に、画面上に状況が表示されます。

このシナリオのタスクと概念v Tivoli Workload Scheduler エンジンの停止と開始v イベント処理プログラムの停止と開始v モニター・エージェントの停止と開始v プロセスの状況の表示


1. "conman stop"2. "conman status"3. "conman start"4. "conman status"5. "conman stopevtproc" (stopeventprocessor)

6. "conman startevtproc" (starteventprocessor)

7. "conman sc" (showcpus)

8. "conman stopmon;wait"9. "conman startmon"


Tivoli Workload Scheduler のプロセスおよび関連コマンドの詳細な説明については、「Tivoli Workload Scheduler ユーザーズ・ガイドおよびリファレンス」を参照してください。


シナリオ 3: スケジューリングの基本: ジョブをスケジュールする方法とジョブの実行順序

このシナリオでは、ジョブのスケジューリング方法およびスケジューリング順序の管理方法を示すことで、基本的なスケジューリング・タスクを実行します。

このシナリオのタスクと概念v ワークステーション上でのジョブおよびジョブ・ストリームの実行v ジョブの状況の表示v ワークステーションの制限の表示と変更v 従属するジョブ・ストリームおよび実行順序 (FOLLOWS) の概念と目的の理解v ジョブ実行中の依存関係の解決の表示


1. "conman ss @#SMPL_SCHED_3@" (showschedules)

2. "composer disp sched=@SMPL_SCHED_3_0_2"3. "conman lc; 10;noask" (limit)


5. "conman sj @#[email protected]_JOB_3_0_@" (showjobs)


シナリオ 4: 拡張スケジューリング: プロンプト、ファイル、およびリソースの依存関係

このシナリオでは、活動中のさまざまなタイプの依存関係を示すことにより、高度なスケジューリング作業を実行します。

このシナリオのタスクと概念v プロンプトの依存関係の表示と管理v リソースの依存関係の表示と管理v ファイルの依存関係の表示と管理v ジョブ間のリソース競合の理解


1. "composer disp sched= @#SMPL_SCHED_4@"

2. "conman ss @SMPL_SCHED_4@" (showschedules)

3. "conman sp @#SMPLPRM4" (showprompts)

4. "conman reply SMLPRM4;y" (reply)

5. "conman sp @#SMLPRM4" (showprompts)

6. "conman sj @SMPL_SCHED_4_0_@.@" (showjobs)

7. "conman sj @SMPL_SCHED_4_0_@.@" (showjobs)

8. "conman sj @SMPL_SCHED_4_0_S.@" (showjobs)

シナリオ 5: 時間の依存関係と実行サイクル

このシナリオでは、時間の依存関係と実行サイクルを使用して、高度なスケジューリングを実行します。


このシナリオのタスクと概念

v AT 時刻や UNTIL 時刻などの時間制限の管理

v 時間の依存関係の解放

v 実行サイクルを使用したスケジューリング・アクティビティーの計画作成



2. "conman ddj @#SMPL_SCHED_5_0_1.SMPL_JOB_5_0_1;at;noask" (deldep)

3. "conman sj @#SMPL_SCHED_5_0_1.SMPL_JOB_5_0_1" (showjobs)

4. "conman rj @#SMPL_SCHED_5_0_1.SMPL_JOB_5_0_2" (release)

5. "conman sj @#SMPL_SCHED_5_0_1.SMPL_JOB_5_0_2" (showjobs)

6. "conman ss @#SMPL_SCHED_5-@" (showschedules)

シナリオ 6: ジョブ、ジョブ・ストリーム、およびコマンドの手動での実行依頼

このシナリオでは、submit コマンドを使用して、ジョブ、ジョブ・ストリーム、および随時ジョブを計画内に挿入します。


v 現在の実動計画でのジョブの実行依頼

v 現在の実動計画でのジョブ・ストリームの実行依頼

v 現在の実動計画でのコマンドの実行依頼

v 計画内のジョブ、ジョブ・ストリーム、およびコマンドの状況の表示


1. "conman sbj @#SMPL_JOB_SBJ;alias=SMPL_SBJ_ALIAS" (submit)

2. "conman sj @#JOBS.SMPL_ALIAS" (showjobs)

3. "conman sbs @#SMPL_SCHED_SBS;alias=SMPL_SBS_ALIAS" (submit)

4. "conman sj @#SMPL_SBS_ALIAS" (showjobs)

5. "conman sbd "ver"; logon=^SMPLUSER^;alias=SMPL_SBD_ALIAS" (submit)

6. "conman sj @#JOBS.SMPL_SBD_ALIAS" (showjobs)

注: ステップ 5 のログオン属性の値は、パラメーター・オブジェクトを使用して指定されます。パラメーターについて詳しくは、「Tivoli Workload Scheduler ユーザーズ・ガイドおよびリファレンス」を参照してください。

シナリオ 7: リカバリー・オプションとリカバリー・ジョブ

このシナリオでは、リカバリー・オプションとリカバリー・ジョブのいくつかの例を示します。


v STOP、CONTINUE、および RERUN リカバリー・オプションの定義と使用

v スケジューリングの誤動作を解決するためのリカバリー・ジョブの使用法の理解



1. "conman reply SMPLPRM7;y" (reply)

2. "conman sp SMPLPRM7" (showprompts)

3. "conman sj @#SMPL_SCHED_7_0_1.@" (showjobs)



シナリオ 8: イベント・ドリブン・スケジューリング

このシナリオでは、イベント・ドリブン・スケジューリングのいくつかの例を示します。


v ルールの作成と、ルールへのアクションの関連付け

v 各種のルール・タイプの理解: フィルター、シーケンス、コレクション・ルール

v ルールに関連付けられたアクションの処理


1. "composer disp erule=SMPL_FILTER_RULE" (display)

2. "planman deploy -scratch"

3. "conman sj @#JOBS.SMPL_SBJ_ALIAS2" (showjobs)

シナリオ 9: 変数テーブルの使用

このシナリオは、変数テーブルを使用して以下を行う方法を示しています。

v ジョブおよびジョブ・ストリームの動作を、実行をスケジュールした理由に基づいて変更する。例えば、オペレーティング・システムごとにそれぞれ異なるコマンドを実行するジョブを作成できます。

v ジョブおよびジョブ・ストリームの動作を、いつ実行するようスケジュールされたか、つまり実行日に基づいて変更する。


1. "composer disp vartable=SMPL_VAR_TABLE_9_0_?" (display)

2. "composer disp vartable=MAIN_TABLE" (display)

3. "composer disp job=SMPL_JOB_9_1_1" (display)

4. "composer disp sched=SMPL_SCHED_9_1_1" (display)

5. "conman sj SMPL_SCHED_9_1_1(1000).SMPL_JOB_9_1_1;info (showjobs)

6. "conman sj SMPL_SCHED_9_1_1(1200).SMPL_JOB_9_1_1;info (showjobs)

実動計画は既に生成されているので、以下の結果が得られます。

v SMPL_VAR_TABLE_9_0_2 変数テーブルに関連付けられた実行サイクルに追加されたジョブ・ストリームに、デフォルトのコマンドを起動する SMPL_JOB_9_1_1

ジョブが含まれます。

v SMPL_VAR_TABLE_9_0_1 変数テーブルに関連付けられた実行サイクルに追加されたジョブ・ストリームに、変数テーブル内で指定されたコマンドを起動するSMPL_JOB_9_1_1 ジョブが含まれます。


シナリオ 9 第 1 部: 変数テーブルを使用して、同じジョブ定義を使用する異なるコマンドを実行する:

この部分では、変数テーブルを使用して、2 つの異なるコマンドを起動する、同じジョブ定義を持つ 2 つのジョブ・ストリームを作成する方法を示します。シナリオは以下のステップを実行します。v 2 つの変数テーブルを作成し、それらの中に変数を定義する。v ジョブ内で変数を使用する。v 2 つのジョブ・ストリームを定義する。v 異なる変数テーブルを各ジョブ・ストリームに関連付ける。

シナリオで使用するコマンドとその実行順序:

1. "composer disp vartable=SMPL_VAR_TABLE_9_0_?" (display)

2. "composer disp job=SMPL_JOB_9_0_1" (display)

3. "composer disp sched=SMPL_SCHED_9_0_?" (display)

4. "conman sj SMPL_SCHED_9_0_1.SMPL_JOB_9_0_1;info" (showjobs)

5. "conman sj SMPL_SCHED_9_0_2.SMPL_JOB_9_0_1;info" (showjobs)

実動計画は既に生成されているので、以下の結果が得られます。

v SMPL_SCHED_9_0_1 ジョブ・ストリームで追加されたジョブには、TWSTutorial

ディレクトリーの内容をリストするコマンドが含まれています。

v SMPL_SCHED_9_0_2 ジョブ・ストリームで追加されたジョブには、TWS ディレクトリーの内容をリストするコマンドが含まれています。

シナリオ 9 第 2 部: 変数テーブルを使用して、異なる日に異なるコマンドを実行する:

この部分では、変数テーブルを使用して、2 つの実行サイクルを含む同じジョブ・ストリームに、変数置換に基づいて 2 つのコマンドを起動させる方法を示します。これは、1 つのジョブ定義、および 2 つの異なる変数テーブルをアドレス指定する2 つの異なる実行サイクルを含むジョブ・ストリームを作成します。シナリオは以下のステップを実行します。v 2 つの変数テーブルを作成し、それらの中に変数を定義する。v ジョブ内で変数を使用する。v ジョブ・ストリームを定義する。v 異なる変数テーブルを各実行サイクルに関連付ける。

データベースからのチュートリアル・オブジェクトの除去

データベース・オブジェクトをご使用の環境内に保持して、新規オブジェクトのテンプレートとして使用することもできます。代わりに、すべてのチュートリアル・オブジェクトをデータベースから完全に除去する場合は、以下の手順を実行してください。

1. TWS_home/TWS/TWSTutorial ディレクトリーに移動します (ここで、TWS_home

は Tivoli Workload Scheduler をインストールする対象となったユーザーのホーム・ディレクトリーです)。

2. チュートリアル・ユーティリティーのインストール・スクリプトを以下のように起動します。



SAMPLEDBSETUP.CMD -uninstall


sampledbsetup.sh -uninstall


付録

レジストリー・ファイルUNIX オペレーティング・システムで、 Tivoli Workload Scheduler を InstallShield

ウィザードまたは twsinst スクリプトを使用してインストールするとき、既にインストールされた他の Tivoli Workload Scheduler インスタンスがあるかどうかを判別する検査が行われます。 TWSRegistry.dat ファイルには、インストールされているすべてのインスタンスのヒストリーが格納されます。Windows オペレーティング・システムでは、このファイルはシステムのドライブ・ディレクトリー (例えばc:¥winnt¥system32) の下に保管されます。 UNIX オペレーティング・システムでは、このファイルは /etc/TWS パスに保管されます。このファイルには、Tivoli

Workload Scheduler インストールを定義する次のような属性の値が入っています。

表 21. レジストリー・ファイルの属性

属性値

ProductID TWS_ENGINE

PackageName インストールを実行するために使用されたソフトウェア・パッケージの名前。

InstallationPath Tivoli Workload Scheduler インスタンスの絶対パス。

UserOwner インストールの所有者。

MajorVersion Tivoli Workload Scheduler のバージョン番号。

MinorVersion Tivoli Workload Scheduler のリリース番号。

MaintenanceVersion Tivoli Workload Scheduler の保守バージョン番号。

PatchVersion インストールされた最新の製品パッチ番号。

エージェント standard agent、fault-tolerant agent、master

domain manager のいずれか。

FeatureList インストールされたオプション・フィーチャーのリスト。

LPName 言語パックをインストールするソフトウェア・パッケージ・ブロックの名前。

LPList インストールされたインスタンス用にインストールされたすべての言語のリスト。

以下は、マスター・ドメイン・マネージャー上の TWSRegistry.dat ファイルの例です。

/Tivoli/Workload_Scheduler/tws_nord_DN_objectClass=OU/Tivoli/Workload_Scheduler/tws_nord_DN_PackageName=FP_Windows_tws_nord.8.3.00/Tivoli/Workload_Scheduler/tws_nord_DN_MajorVersion=8/Tivoli/Workload_Scheduler/tws_nord_DN_MinorVersion=2/Tivoli/Workload_Scheduler/tws_nord_DN_PatchVersion=/Tivoli/Workload_Scheduler/tws_nord_DN_FeatureList=TBSM/Tivoli/Workload_Scheduler/tws_nord_DN_ProductID=TWS_ENGINE/Tivoli/Workload_Scheduler/tws_nord_DN_ou=tws_nord


/Tivoli/Workload_Scheduler/tws_nord_DN_InstallationPath=c:¥TWS¥tws_nord/Tivoli/Workload_Scheduler/tws_nord_DN_UserOwner=tws_nord/Tivoli/Workload_Scheduler/tws_nord_DN_MaintenanceVersion=1/Tivoli/Workload_Scheduler/tws_nord_DN_Agent=MDM

応答ファイルの使用

InstallShield ウィザードでインストールできる Tivoli Workload Scheduler およびDynamic Workload Console のすべてのコンポーネントは、応答ファイルを使用してサイレントにインストールすることも可能です。応答ファイルは、プロパティーと値の対から成るフラット・テキスト・リストです。それぞれの対は、ウィザードが何をどこにどのような構成でインストールするかを判別するために必要なデータ項目に対応しています。サイレント・インストールを使用して、コンポーネントをローカルに、またはリモート側で、インストール、アップグレード、またはアンインストールできます。

Tivoli Workload Scheduler および Dynamic Workload Console コンポーネントには、1 つのインストール、アップグレード、またはアンインストールのアクションを実行するための適切なプロパティーを含む、テンプレート応答ファイルが用意されています。

サイレント・インストールを実行するには、ウィザードを実行するときに次のコマンド行引数を指定します。

-options "<response_file_name> -silent

提供されるファイルはテンプレート・ファイルであるため、プロパティーを適切に編集してから、そのファイルのコピーにファイル名を付けて保存することをお勧めします。ファイル名はインストールするコンポーネントとインストール先のシステムとを識別するものにします。

プロパティーには固有の名前および使用方法があり、それらについては以下のセクションで説明されています。それらの多くには、使用可能なデフォルト値が含まれます。デフォルトは、それが使用されるテンプレート・ファイルに応じて変更されることがあるので、ここではリストされていません。

注: Windows および UNIX プラットフォーム用に同じテンプレート・ファイルが提供される場合、両方の環境用にデフォルト・パスが提供され、キーが重複するため、一方はコメント化されています。一方をアンコメントして他方をコメント化しない場合、ウィザードは重複するキーの最後のものを使用することに注意してください。

Tivoli Workload Scheduler 応答ファイルのプロパティー

このセクションでは、Tivoli Workload Scheduler 応答ファイルで使用されるプロパティーをアルファベット順で説明します。

注:

1. すべての値は、二重引用符 (") で囲んで記述しなければなりません (例:

cpuCfgPanel.addFINAL="true")。


2. プロパティーは、読みやすさのために大/小文字混合で記述されますが、大/

小文字は区別されません。

3. 値の中で使用されるキーワード (例えば、"true") は、大文字と小文字が区別されません。

表 22. Tivoli Workload Scheduler 応答ファイルのプロパティー

名前説明許可される値

checkJobsLoop.wait アップグレードを開始する前に、実行中のジョブが完了するまで製品が待機する分数を指定します。この間隔の間にジョブが完了しない場合、アップグレードは続行されず、エラー・メッセージが表示されます。

整数、または製品がいつまでも待機するように指定する -1 です。デフォルトは 60 です。

checkPrerequisites.stopOnCheckPrereq

前提条件チェックの際に任意のタイプのエラーまたは警告が発生するたびにインストールを停止します。前提条件チェックについて詳しくは、 28ページの『前提条件の検査(UNIX および Linux)』を参照してください。

真前提条件チェックの際に任意のタイプのエラーまたは警告が発生するたびにインストールを停止します。

偽前提条件チェックの際にブロッキング・エラーが発生するたびにインストールを停止します。

デフォルトは false です。

cpuCfgPanel.addFINAL

final ジョブ・ストリームをデータベースに追加します。このオプションを使用すると、現在の実動計画の各処理の終了時に実動計画の自動拡張を実行することができます。デフォルトでは、このボックスはチェック・マークを外したままにします。このオプションは、マスター・ドメイン・マネージャーをインストールする場合にのみ使用可能です。

真 final ジョブ・ストリームを追加します。

偽 final ジョブ・ストリームを追加しません。

cpuCfgPanel.company

会社名。 72ページの『Tivoli Workload

Scheduler インストール・オプション』を参照してください。

cpuCfgPanel.masterCPU

マスター・ドメイン・マネージャーワークステーションの名前。マスター・ドメイン・マネージャーをインストールするときに、この値は cpuCfgPanel.thisCPU の値と同じでなければなりません。

72ページの『Tivoli Workload


cpuCfgPanel.jmPortNumberHttps

Tivoli Workload Scheduler エージェントと、Tivoli Workload Scheduler サーバー、Tivoli

Workload Scheduler for z/OS サーバー、または Dynamic Workload Broker との間の通信に HTTPS を使用するかどうかを指定します。HTTPS を使用する場合には true を、HTTP を使用する場合には false を指定します。

93ページの『エージェントのインストール』を参照してください。

cpuCfgPanel.tdwbHostName Tivoli Workload Scheduler エージェントがDynamic Workload Broker に接続するために使用する完全修飾ホスト名。



付録 337

表 22. Tivoli Workload Scheduler 応答ファイルのプロパティー (続き)


cpuCfgPanel.tcpPortNumber

コンポーネントがインストールされているシステムで netman によって使用されるポート。



cpuCfgPanel.thisCPU

コンポーネントをインストールするワークステーションの名前。マスター・ドメイン・マネージャーをインストールとき、この値はcpuCfgPanel.masterCPU の値と同じでなければなりません。



cpuCfgPanel.jmPortNumber Workload Scheduler for z/OS サーバーまたはDynamic Workload Broker が Tivoli

Workload Scheduler 動的エージェントに接続するために使用するポート。



db2CheckPrereqs.db2Directory

DB2 Enterprise Server または DB2

Administration Client のインストール・ディレクトリー

77ページの『RDBMS インストール・オプション』を参照してください。

db2ClientCfg.remoteNode

DB2 Administration Client のリモート・ノード。


db2ClientCfg.remotePort

リモートの DB2 サーバー・インスタンスが通信に使用する TCP/IP ポート番号。





db2ClientCfg.db2AdminUser

DB2 サーバー・インスタンスの管理者のユーザー名。

DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表を作成していた場合、ユーザー名はDB2 管理者が customizeDB2SQL.properties

ファイルの DB_USER プロパティーに指定したものになります。デフォルト値は以下のとおりです。Windows オペレーティング・システムの場合 db2admin。UNIX および Linux オペレーティング・システムの場合

db2inst1。

DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表をアップグレードしていた場合、ユーザー名は DB2 管理者がDB_UPGRADE_USER フィールドで指定したものになります。DB_UPGRADE_USER

フィールドに指定したユーザーに SYSMON

権限を割り当てる必要があります。


db2ClientCfg.db2AdminPwd

DB2 サーバー管理者ユーザーのパスワードか、SYSADM または SYSCTRL 権限を持つユーザーのパスワード。


db2ClientCfg.db2LocalAdminUser

DB2 クライアント・インスタンスの DB2 管理者のユーザー名。


db2ClientCfg.db2LocalAdminPwd

DB2 クライアント・インスタンスの DB2 管理者のパスワード。


db2ClientCfg.twsDBUser

DB2 ユーザーのユーザー名。 77ページの『RDBMS インストール・オプション』を参照してください。

db2ClientCfg.twsDBPwd DB2 ユーザーのパスワード。 77ページの『RDBMS インストール・オプション』を参照してください。

db2ServerCfg.instanceName

DB2 サーバー・インスタンスの名前。 77ページの『RDBMS インストール・オプション』を参照してください。

付録 339



db2ServerCfg.instancePort

DB2 インスタンスとの通信に使用するTCP/IP ポート番号。


db2ServerCfg.db2AdminUser

DB2 Server の管理者のユーザー名。

DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表を作成していた場合、ユーザー名はDB2 管理者が customizeDB2SQL.properties

ファイルの DB_USER プロパティーに指定したものになります。デフォルト値は以下のとおりです。Windows オペレーティング・システムの場合 db2admin。UNIX および Linux オペレーティング・システムの場合

db2inst1。

DB2 管理者が既に 44ページの『DB2 を使用している場合のデータベース表の作成またはアップグレード』の手順を使用してデータベース表をアップグレードしていた場合、ユーザー名は DB2 管理者がDB_UPGRADE_USER フィールドで指定したものになります。DB_UPGRADE_USER

フィールドに指定したユーザーに SYSMON

権限を割り当てる必要があります。


db2ServerCfg.db2AdminPwd

DB2 サーバー管理者ユーザーのパスワードか、SYSADM または SYSCTRL 権限を持つユーザーのパスワード。





InstallationActions.Install_Method

Tivoli Workload Automation インスタンス選択

Dynamic Workload Console を含む Tivoli

Workload Scheduler コンポーネントの多くは、Tivoli Workload Automation のインスタンスにインストールする必要があります (説明については、 32ページの『Tivoli

Workload Automation のインスタンス』を参照してください)。このプロパティーにより、コンポーネントを新しいインスタンスにインストールするか (組み込み WebSphere

Application Server および他のインフラストラクチャー・サポートもインストール)、またはコンポーネントを既存のインスタンスにインストールするかを選択できます。

前者の場合、新しいインスタンスに使用するパスがプロパティーtwsLocationPanel.directory に定義されている必要があります。後者の場合、次のプロパティーを使用して既存のインスタンスのパスも指定する必要があります。

InstallationActions.TWA_INSTANCE_PATH

new Tivoli Workload Scheduler

コンポーネントを Tivoli

Workload Automation の新しいインスタンスにインストールします (そしてインフラストラクチャー・サポートをインストールします)。

ONTWA

Tivoli Workload Scheduler

コンポーネントを Tivoli

Workload Automation の既存のインスタンスにインストールします。

注: これらの値は大/小文字が区別されます。

InstallationActions.instanceID

コマンド行クライアントは、Tivoli Workload

Scheduler によって ID と共に登録されます。インスタンスをアップグレードするときには、この ID を指定する必要があります。

その形式は次のとおりです。<remoteHost>:<remoteUser>

InstallationActions.TWA_INSTANCE_PATH

Tivoli Workload Automation インスタンス・パス。

Tivoli Workload Automation のインスタンスが既にインストールされているパスを示します。



InstallationActions.twsUser

既存の TWSUser。

アップグレードしている既存のコンポーネントの TWSUser を識別します。

付録 341



installationAgentComponents.addEclipse

拡張オプション付きジョブ・タイプを実行する Java ランタイムを動的エージェントに追加します。ランタイム環境は、以下の目的で使用されます。


v サーバー上の Dynamic Workload Broker

リソース・コマンドを、エージェントからリモートで実行する機能を有効にするため。

真拡張オプション付きジョブ・タイプを実行する Java

ランタイムを追加します。

偽拡張オプション付きジョブ・タイプを実行する Java

ランタイムを追加しません。

installationAgentComponents.addTdwb

Tivoli Workload Scheduler エージェントにダイナミック・ワークロードを実行する機能を追加します。

真ダイナミック・ワークロードを実行する機能を追加します。

偽ダイナミック・ワークロードを実行する機能を追加しません。

installationAgentComponents.instanceType

インストールするエージェントのタイプ。 LWA 分散環境で z/OS 環境からのワークロードを実行するエージェント。

FTA フォールト・トレラントおよびドメイン・マネージャー・エージェント

installationComponents.instanceType

Tivoli Workload Automation インスタンス・タイプ。

インストールするコンポーネントのタイプ。

MDM マスター・ドメイン・マネージャー

BKM バックアップマスター・ドメイン・マネージャー

DDM 動的ドメイン・マネージャー

BDM バックアップ動的ドメイン・マネージャー

AGENT

フォールト・トレラント・エージェント、動的エージェント、またはドメイン・マネージャー

CLI コマンド行クライアント

installLocation Integration Workbench のインストール・パス。

Tivoli Workload Automation のインスタンスの外部にある完全修飾パス。




IsOnlyFTAConnectorToUninstall.IsOnlyFTAConnector

アンインストールするコンポーネントを指定します。

はい分散コネクターだけをアンインストールします。

いいえフォールト・トレラント・エージェント、動的エージェント、および分散コネクターをアンインストールします。

licenseAccepted ご使用条件に同意します。

応答ファイルを使用してコンポーネントをインストールするには、ご使用条件に明示的に同意する必要があります。製品インストール・メディア (DVD またはダウンロード・イメージ) の License ディレクトリーにコピーがあります。

真ご使用条件に同意します。

偽ご使用条件に同意しません。この場合、コンポーネントはインストールされません。

TdwbConfig.tdwbCpuName

Tivoli Workload Scheduler データベースに作成する Dynamic Workload Broker ワークステーション。



TdwbConfig.tdwbCpuPort

Tivoli Workload Scheduler データベースに作成する Dynamic Workload Broker ワークステーションのポート。Tivoli Workload

Scheduler エンジンと Dynamic Workload

Broker コンポーネントは、このポートを使用して通信します。



oracleCheckPrereqs.oracleDirectory

Oracle データベースのインストール・ディレクトリー。

82ページの『Oracle データベース用のインストール』を参照してください。

oracleServerCommunicationInfo.netServiceName

クライアントが Oracle Net サーバーと、Oracle Net 接続用の特定のシステム ID またはデータベースを示すために使用する名前。


oracleServerCommunicationInfo.oracleAdminUser

Oracle データベースに対する認証に必要なデータベース管理者ユーザー名 (SYSTEM など)。

ORACLE 管理者が既に 56ページの『Oracle

を使用している場合のデータベース表の作成またはアップグレード』を使用してデータベース表を作成していた場合、ユーザー名はORACLE 管理者がcustomizeORACLESQL.properties ファイルのMDL_USER プロパティーに指定したものになります。


付録 343



oracleServerCommunicationInfo.oracleAdminPwd

Oracle データベースに対する認証に必要なデータベース管理者ユーザーのパスワード。


recovInstReg.run 製品の再インストールを必要としないで、破損したレジストリー・ファイルを持つワークステーションをアップグレードするように指定します。このオプションは、Tivoli

Workload Scheduler をインストールしたノードからのみではなく、クラスターの任意のノードからクラスター環境をアップグレードする場合にも、使用します。このオプションは、製品をインストールしたクラスター・ノードが使用不可な場合、または不整合な状態になっている場合に、特に便利です。このオプションを指定すると、Tivoli Workload

Scheduler によってインストール・レジストリーと Software Distribution 情報が再作成されます。

真製品の再インストールを必要としないで、破損したレジストリー・ファイルを持つワークステーションをアップグレードします。

偽このオプションを使用しません。

デフォルトは false です。

SDK_ECLIPSE_BUNDLED Integration Workbench は、Eclipse のバンドル・バージョンと共にインストールされます。

どちらの設定を選択した場合でも、プロパティー SDK_UPDATESITE は反対の設定値を持つ必要があります。

真 Integration Workbench をEclipse のバンドル・バージョンと共にインストールします。

偽 Integration Workbench をEclipse のバンドル・バージョンと共にインストールしません。

SDK_UPDATESITE Integration Workbench は Eclipse サイトとしてインストールされ、Eclipse のバンドル・バージョンはインストールされません。

どちらの設定を選択した場合でも、プロパティー SDK_ECLIPSE_BUNDLED は反対の設定値を持つ必要があります。

真 Integration Workbench はEclipse サイトとしてインストールされ、Eclipse のバンドル・バージョンはインストールされません。

偽 Integration Workbench をEclipse サイトとしてインストールしません。

selectRDBMSPanel.rdbmsSelected

どちらのタイプの RDBMS サポートを使用するかを選択します (DB2 または Oracle)。

"DB2" または "Oracle" に大/小文字の区別はありません。

TdwbConfig.tdwbCpuName

Tivoli Workload Scheduler データベースに作成する Dynamic Workload Broker ワークステーション。






TdwbConfig.tdwbCpuPort

Tivoli Workload Scheduler データベースに作成する Dynamic Workload Broker ワークステーションのポート。Tivoli Workload

Scheduler エンジンと Dynamic Workload

Broker コンポーネントは、このポートを使用して通信します。



twsCliCfgPanel.password

twsCliCfgPanel.user で識別されるユーザーのパスワード。

twsCliCfgPanel.remoteHost

マスター・ドメイン・マネージャーがインストールされたワークステーションのホスト名または IP アドレス。

twsCliCfgPanel.remotePort

マスター・ドメイン・マネージャーがインストールされたワークステーションの listen ポート。

twsCliCfgPanel.user

マスター・ドメイン・マネージャーへのアクセスに使用されるユーザー ID。通常は、<TWS_user> です。

TWSCLILanguagesPanel.all

コマンド行クライアント言語の選択: すべての言語

コマンド行クライアントに言語パックをインストールするとき、このプロパティーを使用してすべての言語をインストールするか、または必要な特定の言語を選択することができます (以下のプロパティーを参照してください)。

真すべての言語がインストールされます。

偽以下のプロパティーを使用して、特定の言語をインストールできます。

TWSCLILanguagesPanel.<language>

TWSCLILanguagesPanel.chineseSimplifiedchineseTraditionalgermanfrenchitalianjapanesekoreanportuguesespanish

コマンド行クライアント言語の選択: 特定の言語

コマンド行クライアントに言語パックをインストールするとき、TWSCLILanguagesPanel.all プロパティーを使用してすべての言語をインストールするか、または以下の 1 つ以上のプロパティーを使用して必要な特定の言語を選択することができます。

それぞれのプロパティーで以下を指定します。

真選択された言語がインストールされます。

偽選択された言語はインストールされません。

twsCLILocationPanel.ディレクトリー

コマンド行クライアントをインストールするパス。

Tivoli Workload Automation のインスタンスの外部にある有効な完全修飾パス。

twsDBCfg.dbName DB2 データベースの名前。 77ページの『RDBMS インストール・オプション』を参照してください。

付録 345



twsDBCfg.tablespaceName DB2 インスタンスの表スペースの名前。 77ページの『RDBMS インストール・オプション』を参照してください。

twsDBCfg.tablespacePath DB2 表スペースの相対パス。 77ページの『RDBMS インストール・オプション』を参照してください。

twsDBCfg.reportTablespaceName

レポート・データを保管する表スペースの名前。


twsDBCfg.reportTablespacePath

レポート・データを保管する表スペースのパス。


twsLocationPanel.ディレクトリー

新しい Tivoli Workload Scheduler コンポーネントをインストールするパス。

有効な完全修飾 Tivoli Workload

Automation インスタンス・パス。

twsLocationPanel.symLinkOption

シンボリック・リンクを作成するかどうかを選択します (詳しくは、 31ページの表 1 を参照してください)。

真シンボリック・リンクが作成されます。

偽シンボリック・リンクは作成されません。

twsOracleDbCfg.twsDBUser

Tivoli Workload Scheduler スキーマの所有者。


twsOracleDbCfg.twsDBPwd

Oracle データベースに対する認証に必要なデータベース管理者ユーザーのパスワード。


twsOracleDbCfg.twsDataTablespace

Tivoli Workload Scheduler データの表スペースを示す名前。


twsOracleDbCfg.twsReportTablespace

レポート・データを保管する Tivoli

Workload Scheduler の表スペースを示す名前。


twsOracleDbCfg.twsTempTablespace

Tivoli Workload Scheduler の一時表スペースを示す名前。





twsOracleDbCfg.isPartitioned

Oracle Partitioning フィーチャーを使用して、イベント・ドリブンのワークロード自動化データベース・スキーマを作成するかどうかを指定します。

真イベント・ドリブンのワークロード自動化データベース・スキーマを作成するときに、Oracle Partitioning

フィーチャーが使用されます。

偽イベント・ドリブンのワークロード自動化データベース・スキーマを作成するときに、Oracle Partitioning

フィーチャーは使用されません。

twsPortsPanel.portAdmin

管理 HTTP トランスポート・ポート。詳しくは、 75ページの『WebSphere

Application Server インストール・オプション』を参照してください。

twsPortsPanel.portAdminSec

管理 HTTPS トランスポート・ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portEif

イベント処理プログラム・ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portHTTP

HTTP トランスポート・ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portHTTPS

HTTPS トランスポート・ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portMtlAuth

CSIv2 Client Authentication Listener ポート。詳しくは、 75ページの『WebSphere


twsPortsPanel.portORB

ORB Listener ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portRMI

Bootstrap ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portSAS

SAS Server Authentication Listener ポート詳しくは、 75ページの『WebSphere


付録 347



twsPortsPanel.portSOAP

SOAP コネクター・ポート詳しくは、 75ページの『WebSphere


twsPortsPanel.portSrvAuth

CSIv2 Server Authentication Listener ポート詳しくは、 75ページの『WebSphere


twsUpgradePanel.backupOldInstance

アップグレードの際にコンポーネントの既存のインスタンスをバックアップするかどうかを判別します。

真既存のインスタンスはバックアップされます。

偽既存のインスタンスはバックアップされません。

twsUpgradePanel.bckpDirectory

アップグレードの際にコンポーネントの既存のインスタンスをバックアップする場合、バックアップ・ディレクトリーが使用されます。

既存の Tivoli Workload Scheduler

コンポーネントのパスの外部にある有効な完全修飾パス。

twsUpgradePanel.bckpProfileDirectory

アプリケーション・サーバー・プロファイルのバックアップ・ディレクトリー (マスター・ドメイン・マネージャーまたはバックアップ・マスター・ドメイン・マネージャーをバージョン 8.3 または 8.4 からアップグレードするときに使用されます)。



twsUpgradePanel.dumpDirectory

マスター・ドメイン・マネージャーをバージョン 8.2.x からアップグレードする際に使用するマイグレーション・ディレクトリー。データベースは、このディレクトリーにフラット・テキスト・ファイルとしてエクスポートされてから、新しい RDBMS サポートにインポートされます。



userUnixCfgPanel.inputUserName

<TWS_user> のユーザー ID (UNIX 上)。 ID は、サイレント・ウィザードが実行されるシステム上に既に存在している必要があります。

userUnixCfgPanel.twsPassword

<TWS_user> のパスワード (UNIX 上)。

userUnixCfgPanel.wasPassword

Dynamic Workload Console が Tivoli

Workload Automation の既存のインスタンスに既にインストールされている場合、Dynamic Workload Console を (UNIX 上に)

インストールしたときに構成した組み込みWebSphere Application Server の WebSphere

Application Server ユーザー ID のパスワードを指定します。

組み込み WebSphere Application

Server で変更していなければ、これは通常 <TWS_user> のパスワードです。




userUnixCfgPanel.wasUserName


Workload Automation の既存のインスタンスに既にインストールされている場合、Dynamic Workload Console を (UNIX 上に)

インストールしたときに構成した組み込みWebSphere Application Server の WebSphere

Application Server ユーザー ID を指定します。


Server で変更していなければ、これは通常 <TWS_user> です。

userWinCfgPanel.inputUserName

<TWS_user> の ID - これはエージェント・ワークステーションのエージェントを「所有する」ユーザーです (Windows 上)。

このユーザーがまだ存在しない場合は、それが作成されます。この場合、ID の形式はそれが作成されるコンピューターでのユーザー ID の規則に従う必要があります。

userWinCfgPanel.twsPassword

<TWS_user> のパスワード (Windows 上)。ユーザーが作成される場合、パスワードの形式はそれが作成されるコンピューターでのパスワードの規則に従う必要があります。

userWinCfgPanel.wasPassword


Workload Automation の既存のインスタンスに既にインストールされている場合、Dynamic Workload Console を (Windows 上に) インストールしたときに構成した組み込み WebSphere Application Server のWebSphere Application Server ユーザー ID

のパスワードを指定します。


Server で変更していなければ、これは通常 <TWS_user> のパスワードです。

userWinCfgPanel.wasUserName


Workload Automation の既存のインスタンスに既にインストールされている場合、Dynamic Workload Console を (Windows 上に) インストールしたときに構成した組み込み WebSphere Application Server のWebSphere Application Server ユーザー ID

を指定します。


Server で変更していなければ、これは通常 <TWS_user> です。

Dynamic Workload Console 応答ファイルのプロパティー

このセクションでは、Dynamic Workload Console 応答ファイルで使用されるプロパティーをアルファベット順で説明します。

注:

1. すべての値は、二重引用符 (") で囲んで記述しなければなりません (例:

InstallationActions.INSTALL_METHOD="new")。

2. プロパティー名は、読みやすさのために大/小文字混合で記述されますが、大/小文字は区別されません。

3. 値で使用されるキーワードには、大/小文字の区別はありません。

付録 349

表 23. Dynamic Workload Console 応答ファイルのプロパティー


BOOTSTRAP_ADDRESS ブートストラップ・ポート。詳しくは、 265ページの『拡張インストール』を参照してください。

CREATE_WAS_SERVICE Windows で、組み込み WebSphere Application

Server がシステム始動時に自動的に開始されるように定義できます。これを行うには、このプロパティーを設定して、組み込み WebSphere

Application Server を開始する Windows サービスが作成されるようにします。

真組み込み WebSphere

Application Server を自動的に開始する Windows サービスが作成されます。

偽 Windows サービスは作成されません。

CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS

CSIv2 Client Authentication Listener ポート。詳しくは、 265ページの『拡張インストール』を参照してください。

CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS

CSIv2 Server Authentication Listener ポート詳しくは、 265ページの『拡張インストール』を参照してください。

DCS_UNICAST_ADDRESS DCS ユニキャスト・ポート。詳しくは、 265ページの『拡張インストール』を参照してください。

ENABLE_TDWB Dynamic Workload Broker を有効にする

Dynamic Workload Console を使用して、以下のいずれかにアクセスできます。

v Tivoli Workload Scheduler (Tivoli Workload

Scheduler for z/OS を含む)

v Dynamic workload broker

すべてのユーザーが、これらの製品の 1 つまたは両方に対する特定のアクセス権限を持つ必要があります。

これらのアクセス権限を最初から WebSphere

Application Server 管理者に付与して、管理者が必要とするタスクを即時に実行できるようにすると便利です。

真管理者に Dynamic Workload

Broker へのアクセス権限を付与します。

偽管理者が Dynamic Workload

Broker へアクセスするのを拒否します。

ENABLE_TWS Tivoli Workload Scheduler を有効にする

詳しくは、「ENABLE_TDWB」についての説明を参照してください。

真管理者に Tivoli Workload

Scheduler へのアクセス権限を付与します。

偽管理者が Tivoli Workload

Scheduler へアクセスするのを拒否します。


表 23. Dynamic Workload Console 応答ファイルのプロパティー (続き)


INSTALL_METHOD インストール・インスタンスの選択項目

Dynamic Workload Console は、Tivoli Workload

Automation のインスタンス内にインストールする必要があります (詳しくは、Tivoli Workload

Automation のインスタンスを参照してください)。このプロパティーにより、コンポーネントを新しいインスタンスにインストールするか(組み込み WebSphere Application Server および他のインフラストラクチャー・サポートもインストール)、またはコンポーネントを既存のインスタンスにインストールするかを選択できます。

前者の場合、新しいインスタンスに使用するパスがプロパティー IS_DESTINATION に定義されている必要があります。後者の場合、プロパティー TWA_INSTANCE_PATH を使用して既存のインスタンスのパスも指定する必要があります。

さらに、このプロパティーによって、Dynamic

Workload Console を Tivoli Workload

Automation 構造の外部にある、外部的にサポートされる独自の WebSphere Application Server

バージョンにインストールできます。この場合、プロパティー ISC_APPSERVER_DIR を使用してパスを指定する必要があります。

new Dynamic Workload Console

を Tivoli Workload

Automation の新しいインスタンスにインストールします(そしてインフラストラクチャー・サポートをインストールします)。この値は、Dynamic Workload Console

の既存のインスタンスをアップグレードするときにも使用します。

ONTWA

Dynamic Workload Console

を Tivoli Workload

Automation の既存のインスタンスにインストールします。

onwas Dynamic Workload Console

を外部的にサポートされる独自の WebSphere Application

Server のバージョンにインストールします。

IPC_CONNECTOR_ADDRESS IPC コネクター。詳しくは、 265ページの『拡張インストール』を参照してください。

IS_BACKUP_DIR アップグレード用のバックアップ・ディレクトリー

Dynamic Workload Console をアップグレードするとき、ウィザードは組み込み WebSphere

Application Server をアップグレードする際にアプリケーション・サーバー構成をバックアップする必要があります (Dynamic Workload

Console アップグレード・プロセスの一部)。

外部の有効な完全修飾パス: Tivoli

Workload Automation の既存のインスタンス、および WebSphere

Application Server 組み込み版のインストール・パス。

付録 351



IS_DESTINATION コンソール・インストール・パス

Tivoli Workload Automation の新規インスタンスの場合: Dynamic Workload Console がインストールされる、Tivoli Workload Automation

の新しいインスタンスのパス。

WebSphere Application Server の既存の外部インスタンスの場合: Dynamic Workload Console

を WebSphere Application Server の独自の外部バージョンにインストールするとき、コンソール・インストール・パスを指定します。

これは、そのインストール先とする WebSphere

Application Server のインスタンスに関連したパスである必要はありません。パスを、Tivoli

Workload Automation のインスタンス内にすることはできません。

Tivoli Workload Automation の既存インスタンスの外部にある有効な完全修飾パス。

IS_UPGRADE 既存のインスタンスをアップグレードするためにウィザードが実行中かどうかを判別するboolean プロパティー。

真ウィザードは提供されるプロパティーを使用して、Dynamic Workload Console

の既存のインスタンスをアップグレードします。

偽ウィザードは提供されるプロパティーを使用して、Dynamic Workload Console

のインスタンスをインストールします。

ISC_ADMIN_FULL_USER WebSphere Application Server 管理者のユーザー ID

Tivoli Workload Automation の新規インスタンスの場合: Integrated Solutions Console 管理ユーザー用に使用されるユーザー ID を指定します。


を WebSphere Application Server の独自の外部バージョンにインストール、アップグレード、またはアンインストールするときに、Integrated

Solutions Console 管理ユーザーの既存のユーザー ID を指定します。

ユーザー ID は存在していなければなりません。




ISC_ADMIN_PASSWORD WebSphere Application Server 管理者のユーザー・パスワード

Tivoli Workload Automation の新規インスタンスの場合: Integrated Solutions Console 管理ユーザー用に使用されるパスワードを指定します。


を WebSphere Application Server の独自の外部バージョンにインストール、アップグレード、またはアンインストールするときに、既存のIntegrated Solutions Console 管理ユーザーのユーザー ID のパスワードを指定します。

ISC_APPSERVER_DIR 既存のインスタンスのインストール・ディレクトリー

Dynamic Workload Console をインストールまたはアップグレードする必要のある、外部Integrated Solutions Console のインストール・ディレクトリー。

詳しくは、 267ページの『Tivoli

Integrated Portal の既存インスタンスへのインストール』を参照してください。

licenseAccepted ご使用条件の同意

応答ファイルを使用して Dynamic Workload

Console をインストールするには、ご使用条件に明示的に同意する必要があります。製品インストール・メディア (DVD またはダウンロード・イメージ) の License ディレクトリーにコピーがあります。


偽ご使用条件に同意しません。この場合、Dynamic

Workload Console はインストールされません。

ORB_LISTENER_ADDRESS ORB Listener ポート詳しくは、 265ページの『拡張インストール』を参照してください。

REST_NOTIFICATION_ADDRESS REST 通知ポート。詳しくは、 265ページの『拡張インストール』を参照してください。

SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

SAS SSL ポート詳しくは、 265ページの『拡張インストール』を参照してください。

SOAP_CONNECTOR_ADDRESS SOAP コネクター・ポート詳しくは、 265ページの『拡張インストール』を参照してください。

TWA_INSTANCE_PATH 既存の Tivoli Workload Automation インスタンス・パス

Dynamic Workload Console がインストールされる、Tivoli Workload Automation の既存のインスタンスのパス。

有効な完全修飾 Tivoli Workload

Automation インスタンス・パス。

付録 353



UPDATE_INSTALLER_DIR WebSphere Application Server アップデート・インストーラーのパス

外部 WebSphere Application Server アップデート・インストーラーのディレクトリー。



WAS_CELL_NAME WebSphere Application Server セル名

外部 WebSphere Application Server セル名。



WAS_NODE_NAME WebSphere Application Server ノード名

外部 WebSphere Application Server ノード名。



WAS_PROFILE_NAME WebSphere Application Server プロファイル名

外部 WebSphere Application Server プロファイル名。



WAS_SERVER_NAME WebSphere Application Server サーバー名

外部 WebSphere Application Server サーバー名。



WC_adminhost 管理コンソール詳しくは、 265ページの『拡張インストール』を参照してください。

WC_adminhost_secure 管理コンソール・セキュア詳しくは、 265ページの『拡張インストール』を参照してください。

WC_defaulthost HTTP トランスポート詳しくは、 265ページの『拡張インストール』を参照してください。

WC_defaulthost_secure HTTPS トランスポート詳しくは、 265ページの『拡張インストール』を参照してください。

Job Brokering Definition Console 応答ファイルのプロパティー

このセクションでは、Job Brokering Definition Console 応答ファイルで使用されるプロパティーを説明します。

注:

1. すべての値は、二重引用符 (") で囲んで記述しなければなりません。

2. プロパティー名は、読みやすさのために大/小文字混合で記述されますが、大/小文字は区別されません。

3. 値で使用されるキーワードには、大/小文字の区別はありません。


表 24. Job Brokering Definition Console 応答ファイルのプロパティー


licenseAccepted ご使用条件の同意

応答ファイルを使用して Job Brokering

Definition Console をインストールするには、ご使用条件に明示的に同意する必要があります。製品インストール・メディア (DVD またはダウンロード・イメージ) の License ディレクトリーにコピーがあります。インストールの前に、ご使用条件に同意する必要があります。インストールを正常に行うには、この値が true



偽ご使用条件に同意しません。この場合、Job Brokering

Definition Console はインストールされません。

installLocation Job Brokering Definition Console のインストール・パス。

任意の完全修飾パス。

Tivoli Workload Scheduler Integration Workbench のインストールおよびアップグレード

Tivoli Workload Scheduler Integration Workbench を使用して、Tivoli Workload

Scheduler イベント・ドリブン・ワークロード自動化の能力を拡張するイベントおよびアクション・プラグインを開発します。さらに、Tivoli Workload Scheduler Java

API を使用する Java アプリケーションも作成できます。

Tivoli Workload Scheduler Integration Workbench は、Eclipse のバンドル・バージョンまたは Eclipse の既存のインスタンスと共にインストールできます。サポートされる最小バージョンはプラグイン開発環境 (PDE) がインストールされているEclipse HELIOS 3.6 です。

この付録は、次のセクションで構成されます。

v 356ページの『Tivoli Workload Scheduler Integration Workbench を Eclipse のバンドル・バージョンと共にインストールする』

v 356ページの『Eclipse サイトを使用して Tivoli Workload Scheduler Integration

Workbench を Eclipse の既存のインスタンスと共にインストールする』

v 357ページの『リモート Eclipse サイトを使用して Tivoli Workload Scheduler

Integration Workbench を Eclipse の既存のインスタンスと共にインストールする』

v 357ページの『Eclipse のバンドル・バージョンを使用してインストールされている Tivoli Workload Scheduler Integration Workbench をアップグレードする』

v 358ページの『プラグインとしてインストールされている Tivoli Workload

Scheduler Integration Workbench をアップグレードする』

注: エクスポートされた表示を処理する場合、Tivoli Workload Scheduler Integration

Workbench の README ファイルにアクセスするには、ブラウザーを開き、実行している必要があります。

付録 355

Tivoli Workload Scheduler Integration Workbench を Eclipseのバンドル・バージョンと共にインストールする

コンピューター上に必要なバージョンの Eclipse がない場合、ローカルでの使用のために Eclipse がバンドルされた Tivoli Workload Scheduler Integration Workbench

をインストールできます。

Tivoli Workload Scheduler Integration Workbench を Eclipse のバンドル・バージョンと共にインストールするには、以下のアクションを実行します。

1. インストール DVD から、IntegrationWorkbench ディレクトリーにナビゲートして、オペレーティング・システムに該当するセットアップ・ファイルを実行します。

あるいは、 36ページの『Launchpad』の説明に従ってランチパッドを開始し、Tivoli Workload Scheduler Integration Workbench のインストールを選択します。

2. インストール・ウィザードに従って、プロンプトが出されたら、「IntegrationWorkbench のインストール (Install Integration Workbench)」を選択します。

Eclipse サイトを使用して Tivoli Workload SchedulerIntegration Workbench を Eclipse の既存のインスタンスと共にインストールする

必要なバージョンの Eclipse がある場合、Tivoli Workload Scheduler Integration

Workbench を既存のインスタンスへのプラグインとしてインストールできます。ネットワーク内のすべてのユーザーが、Tivoli Workload Scheduler Integration

Workbench に Eclipse サイトとしてアクセスできます。

現行バージョンの Tivoli Workload Scheduler Integration Workbench を Eclipse の既存のインスタンスにインストールするには、以下のアクションを実行します。

1. インストール DVD から、IntegrationWorkbench ディレクトリーにナビゲートして、オペレーティング・システムに該当するセットアップ・ファイルを実行します。

あるいは、 36ページの『Launchpad』の説明に従ってランチパッドを開始し、Tivoli Workload Scheduler Integration Workbench のインストールを選択します。

2. インストール・ウィザードに従って、プロンプトが出されたら、「Eclipse サイトのインストール (Install Eclipse site)」を選択します。

注: プラグインの使用方法について詳しくは、Eclipse 内の README 文書を参照してください。


リモート Eclipse サイトを使用して Tivoli Workload SchedulerIntegration Workbench を Eclipse の既存のインスタンスと共にインストールする

コンピューター上に Eclipse が既に存在する場合、Tivoli Workload Scheduler

Integration Workbench の IBM リモート Eclipse サイトを使用して Tivoli Workload

Scheduler Integration Workbench を Eclipse の既存のインスタンスに対するプラグインとしてインストールできます。

現行バージョンの Tivoli Workload Scheduler Integration Workbench を Eclipse の既存のインスタンスにインストールするには、「サイト (Site)」フィールドに以下のリンクを指定して、Eclipse Software Update フィーチャーを使用します。

ftp://public.dhe.ibm.com/software/tivoli_support/misc/TWS/SDK/


Eclipse のバンドル・バージョンを使用してインストールされている Tivoli Workload Scheduler Integration Workbench をアップグレードする

Eclipse のバンドル・バージョンを使用して Tivoli Workload Scheduler Integration

Workbench バージョン 8.5.0 または 8.5.1 をインストールした場合、Eclipse

Software Updates フィーチャーを使ってアップグレードすることができます。Tivoli Workload Scheduler Integration Workbench バージョン 8.5.0 または 8.5.1 をアップグレードするには、以下のアクションを実行します。

1. Tivoli Workload Scheduler Workbench バージョン 8.5.0 または 8.5.1 を閉じます。

2. TivoliWorkloadSchedulerIntegrationWorkbenchversion_installation_directory/eclipse/

plugins に移動します。

3. このディレクトリー内の org.eclipse.ecf.identity.jar_<version> ファイルを除去します。

4. TivoliWorkloadSchedulerIntegrationWorkbenchversion_installation_directory/eclipse/

features/com.ibm.tws.sdk_<version>/feature.xml ファイル内の update タグ内に既に存在している URL を以下の URL に変更します。

<url>update label="%updatesite"url="ftp://public.dhe.ibm.com/software/tivoli_support/misc/TWS/SDK/

</url>

5. ファイルを保管して閉じます。

6. Tivoli Workload Scheduler Integration Workbench を開始します。

7. Eclipse Software Updates フィーチャーを使用して Tivoli Workload Scheduler

Integration Workbench の古いバージョンをアップグレードします。


付録 357


プラグインとしてインストールされている Tivoli WorkloadScheduler Integration Workbench をアップグレードする

Tivoli Workload Scheduler Integration Workbench バージョン 8.5.0 または 8.5.1 をプラグインとして既存のバージョンの Eclipse にインストールした場合、以下のアクションを実行することにより、Eclipse Software Updates フィーチャーを使ってアップグレードすることができます。

1. Tivoli Workload Scheduler Integration Workbench バージョン 8.5.0 または 8.5.1

をインストールした Eclipse を閉じます。

2. eclipse_installation_directory/eclipse/features ディレクトリーに移動します。

3. com.ibm.tws.sdk_<version>/feature.xml を次のアドレスで更新します。


4. Eclipse Software Updates フィーチャーを使用して Tivoli Workload Scheduler

Integration Workbench の古いバージョンをアップグレードします。


インストールされている製品の検出

Tivoli Workload Automation のインスタンス内にどの製品がインストールされているかが不明な場合、以下の手順を実行して、どの製品がインストールされているかを検出します。

コマンド・プロンプトを開いて、コンピューターのオペレーティング・システム用の Tivoli Workload Scheduler DVD 上にある次のディレクトリーに移動します (それをハード・ディスクにコピーした場合、その場所に移動します):

drive/operating_system/CLI

以下を実行して、Tivoli Configuration Manager 環境を初期化します。

swd_env.bat/.sh

以下のソフトウェア配布コマンドを実行して、どのソフトウェア・パッケージがインストールされているかを検証します。

wdlssp

以下のような、ソフトウェア・パッケージのリストが表示されます。

----------------------------------------

DISSE0164I Name : FP_TWS_WINDOWS_TWS_userDISSE0165I Version : 8.5.0.00DISSE0166I State : ICU--

----------------------------------------

DISSE0164I Name : TWS_LP_TWS_userDISSE0165I Version : 8.5.0.00DISSE0166I State : ICU--

----------------------------------------


リスト内のパッケージの詳細は、このコンピューターにどのパッケージがインストールされているかによって異なります。この場合、Windows コンピューター上で、<TWS_user> という名前の <TWS_user> のインストールは、Tivoli Workload

Scheduler スケジューリング・エンジンおよびスケジューリング・エンジン各国語サポート (LP = 言語パック) のソフトウェア・パッケージ・ブロックで構成されています。「状態」の値は、パッケージが既に「コミット」されたかどうかによって異なります。

以下を実行して、ソフトウェア・パッケージを除去します。

wdrmvsp -f <package_name>.<package_version>

このコマンドは、Tivoli Configuration Manager によって使用されたログ・ファイルおよび構成ファイルを除去しません。これらは、Tivoli Workload Scheduler インストール・ディレクトリー内、またはシステム一時ディレクトリー内に残ります。

注: これらのコマンドの実行に際して問題が生じたとき、または Tivoli

Configuration Manager について詳しく理解するためには、オンラインでhttp://publib.boulder.ibm.com/tividd/td/ConfigurationManager4.2.3.html から入手できる文書を参照してください。

Tivoli Workload Scheduler のアップグレード中にバックアップされるファイル

V8.3 および V8.4 からのアップグレードの際に、いくつかのファイルは .bk ファイルにバックアップされます。 V8.5 以上からアップグレードされるファイルは .bk

ファイルにバックアップされません。また、カスタマイズされたファイルもバックアップされません。例えば、ファイル tws_env.cmd はファイル tws_env.cmd.bk にバックアップされます。これらのバックアップ・ファイルは、新しいファイルに置き換わります。アップグレードの際にバックアップされるファイルのリストを以下に示します。

Windows オペレーティング・システム:

v tws_env.cmd

v jobmanrc.cmd

v TWSCCLog.properties (このファイルは、置換されません)

v Startup.cmd

v JnextPlan.cmd

v MakePlan.cmd

v SwitchPlan.cmd

v CreatePostReports.cm

v UpdateStats.cmd

v ResetPlan.cmd

v Sfinal

UNIX

v tws_env.sh

v tws_env.csh

付録 359

http://publib.boulder.ibm.com/tividd/td/ConfigurationManager4.2.3.html

v jobmanrc

v TWSCCLog.properties (このファイルは、置換されません)

v StartUp

v JnextPlan

v MakePlan

v SwitchPlan

v CreatePostReports

v UpdateStats

v ResetPlan

v Sfinal

DB2 表スペースの相対パス

相対パスを使用する DB2 表スペースを作成する場合、パスは次のように構成されます。

DFTDBPATH¥DB2_instance¥NODE0000¥SQLnnnnn¥TABLESPACE_REL_PATH

ここで、

DFTDBPATHWindows オペレーティング・システムの場合、これは DB2 インスタンスがインストールされるドライブです。UNIX および Linux のオペレーティング・システムの場合、これは DB2 インストールのホーム・インスタンスです。

DB2_instanceDB2 インスタンスの名前。

NODE0000DB2 データベース・インスタンスが存在するディレクトリーです。

SQLnnnnこれは、データベース・インスタンスの数によって決まる増分ディレクトリー・パスです。

TABLESPACE_REL_PATHこれは、表スペース用に指定した相対パスです。

表スペースの相対パスに関する詳細については、DB2 の資料セットを参照してください。


特記事項

本書は、米国 IBM が提供する製品およびサービスについて作成したものであり、本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510

東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。

国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。


本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758 U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

商標IBM、IBM ロゴ、および ibm.com® は、世界の多くの国で登録された International

Business Machines Corp. の商標です。他の製品名およびサービス名等は、それぞれIBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml をご覧ください。

Adobe、Acrobat、PostScript およびすべての Adobe 関連の商標は、Adobe Systems

Incorporated の米国およびその他の国における登録商標または商標です。

Intel、Intel ロゴ、 Intel Inside、Intel Inside ロゴ、 Intel Centrino、Intel Centrino ロゴ、 Celeron、Intel Xeon、Intel SpeedStep、Itanium、Pentium は、 Intel Corporation

または子会社の米国およびその他の国における商標または登録商標です。

Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。


http://www.ibm.com/legal/copytrade.shtml

Linux は、Linus Torvalds の米国およびその他の国における商標です。

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

特記事項 363

索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アカウント作成

Windows 237

Windows 2000 236

アクセシビリティー ix

アクセス方式 (access method)

サイレント・インストール 129

アップグレードインストール・ウィザードを使用するエージェント 171

インストール・ウィザードを使用するドメイン・マネージャー 171

エージェント 168

既存のソフトウェアのバージョン 134

機能の追加 190

構文 wdinstsp を使用した CIT のインストール 182

コマンド行クライアント 186

サイレント・インストールを使用するエージェント 174

セーフ 144

前提条件の検査 136

動的エージェント 183

ドメイン・マネージャー 168, 184

トラブルシューティング 214

認証 140

Tivoli Dynamic Workload

Console 306

破損したレジストリー・ファイルを使用 187

標準またはフォールト・トレラント・エージェント 184

フォールト・トレラント・エージェント 187

プラグインとしてインストールされている Integration Workbench 358

変更されるファイルとフォルダー 135

問題 262, 280

リカバリーする 228


概説 306


Server の場合 307

Dynamic Workload Console、問題 322

アップグレード (続き)

Integration Workbench 357

LDAP 140

Software Distribution を使用するエージェント 180

twsinst を使用するエージェント 174

アップグレード前データベース表のアップグレード 43

アプリケーションと統合されたワークロード環境 15

アプリケーション・サーバーインストール問題 246

インストール・ログ・ファイル 40,

300

プロファイル作成が失敗する 246

Windows 2003 ドメインでのインストールが資格情報の問題で失敗する247

Windows でインストールする際の資格情報の問題 236

アプリケーション・ジョブ・プラグイン拡張オプション付きジョブ・タイプを実行する Java ランタイムを追加するオプション 177

拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加するオプション 184

wdinstsp を使用して拡張オプション付きジョブ・タイプを実行するためにJava ランタイムを追加するオプション 121, 185

アンインストール 204

ウィザードを使用した追加プラグイン210

応答ファイルの使用 311

組み込み WebSphere Application Server

が停止しないために失敗する 278

サイレントのTivoli Workload Scheduler

for Additional Plug-ins 212

手動エージェント 283

コネクター 288

ファイル削除が遅過ぎる 288

マスター・ドメイン・マネージャー283

追加プラグイン 210

追加プラグイン変更ファイル 210

追加プラグイン・ログ・ファイル 210

手順 210

動的ドメイン・マネージャー 205


アンインストール (続き)

復元プロファイル・ステップで失敗する 278

Dynamic Workload Console 310

手動 313, 314

Dynamic Workload Console のサイレント・モード 311

Dynamic Workload Console ログ・ファイル 312

Dynamic Workload Console、問題 323

Dynamic Workload Console、Linux

RHEL 5 (x86-64) での開始に失敗する 321

Windows で InstallShield ウィザードを使用中に失敗する 278

Windows でコネクターを手動で 290

アンインストール手順 210

アンインストールのログ・ファイルtws4apps_ia_uninstall.log 210

アンインストール・ログ・ファイルtws4apps_ia_uninstall.log 210

tws4apps_ia_uninstall.log、サイレント・アンインストール 212

tws4apps_status.log のインストール210

tws4apps_uninstall.log のインストール210

tws4apps_uninstall.log、サイレント・アンインストール 212

イメージDynamic Workload Console

インストール 298

インストールアプリケーション・サーバーの、

Windows 2003 ドメイン上で資格情報の問題で失敗する 247

アプリケーション・サーバーのインストール問題 246

インストール・ウィザードの使用 71

ウィザード、今再実行または後で 225

ウィザード、再実行または再開 223


インストール・ディレクトリー 97

エージェントの表示名 97

ホスト名または IP アドレス 97

ユーザー名 95

Dynamic Workload Broker HTTPS

ポート番号 97

Dynamic Workload Broker ホスト名97

JobManager ポート 97


インストール (続き)

概説 27

各種の問題 247

機能の追加 99, 198

検証 282

構文 wdinstsp を使用した CIT のインストール 182

異なる外部 WebSphere Application

Server プロファイルにインストールする際に Dynamic Workload Console

が失敗する 321

コネクターの追加 199


パスワード 99

ユーザー名 99

リモート・ポート 99

リモート・ホスト 99

サイレント 100

応答ファイル・テンプレート 105


リカバリーする 227

Dynamic Workload Console、問題322

"Error writing file = 28" を出して失敗する 249

"Error writing file = " を出して失敗する 248

失敗したステップの訂正および続行222

失敗するアプリケーション・サーバー・プロファイルの作成が失敗する 246

ウィザードの使用によるリカバリー216

エラー AWSFAB035E 257

エラー AWSGAB566E 258

エラー DISSE0324E 254

エラー「コマンド行パラメーター、-installRoot は無効です (The

command line parameter,

-installRoot, is invalid)」を出すOracle Solaris 242

その他 259

ソフトウェア・パッケージ・ブロック 254, 255


ホスト名が切り捨てられる 234


AWSDEQ024E エラーを受け取った235

AWSFAB037E エラーを受け取った250

CMW3202E エラーを受け取った234

JVM 検証エラーによる UNIX 240


失敗する (続き)

NFS マウント上のインストール・イメージの問題により 252

NoClassDefFoundError エラー 252

Windows での InstallShield ウィザード 233

"Error writing file = 28" を受け取った 249

"Error writing file = " を受け取った 248

準備 27

使用、ウィザードの 128

ステップ、失敗、訂正および続行 222

ステップ・ウィンドウ 219

ステップ・リスト 217

セキュリティーの影響 281

前提条件の検査 28

ソフトウェア・パッケージ・ブロック116, 181

追加、方法 127

追加プラグイン、サイレント・インストールの使用 129




このワークステーション名 88

自動的にポートを生成 90

ドメイン名 88


マスター・ドメイン・マネージャー名 89

ユーザー名 87


ポート番号 90

Dynamic Workload Broker netman

ポート 93


Dynamic Workload Broker ワークステーション名 93


Netman ポート 89

password 88

途中から継続する 226


トラブルシューティング・シナリオDynamic Workload Console 316

バックアップ動的ドメイン・マネージャー 85

バックアップ・マスター・ドメイン・マネージャー 71

ワークステーション名 73

ハング (Dynamic Workload

Console) 317, 318



会社 96



Netman ポート 96



ポート 85


マスター・ドメイン・マネージャーまたはバックアップ・マスターエージェントの表示名 74

会社 73



ユーザー名 72


ポート番号 74

Dynamic workload broker ホスト名74


Netman ポート 74

password 73

問題解決手順 226

問題解決手順の例 226

問題のシナリオ 232

ランチパッドの使用 36

リモート Eclipse サイトを使用したIntegration Workbench 357

ログ・ファイル 38, 215

ログ・ファイル、組み込み WebSphere

Application Server 40, 300

ログ・ファイル、DB2 40

AIX 6100-05 でのハング 239

AIX でのハング 239

AIX、問題 238

DVD 31


イメージ 298

ウィザードの使用 297

既存の外部 WebSphere Application

Server への 267


Server 265


Server の既存のインスタンス266

サイレント・モード 297

サンプル・シナリオ 296

セットアップ・ファイル 298

タイプ 265



Dynamic Workload Console (続き)

メソッド 297


CD 298

Dynamic Workload Console ログ・ファイル 312

Dynamic Workload Console、Linux

RHEL 5 (x86-64) での開始に失敗する 321

HP-UX、問題 241

InstallShield ウィザード「実行エラー」により HP-UX 上で失敗する 241

「フィーチャーの追加」インストールが失敗する 253

HP-UX 上で開始しない 241

JRE が HP-UX にインストールされない 241

JRE が Linux にインストールされない 243

Integration Workbench 356

Java ランタイム 95

Linux

Tivoli Workload Scheduler の開始によりエラーが発生する 244

Linux、問題 243

Oracle Solaris、問題 242

Red Hat Enterprise Linux 6.0 での失敗245

Software Distribution を使用した言語パック 123

Tivoli Configuration Manager、失敗する 254, 255

Tivoli Integrated Portal

DVD または eImage から 270

Tivoli Integrated Portalのインストールの失敗 318

twsinst

エラー AWSFAB035E を出して失敗する 257

エラー AWSGAB566E を出して失敗する 258

失敗する 250


UNIX、問題 240

Windows で警告 AWSGAB005W を受け取る 235

Windows でのインストールの問題233

Windows での共用フォルダーからの失敗 319

インストール、追加プラグイン実行前 126

インストール応答ファイルTWSAPPS_RespFile_UNIX.txt サイレント・インストール 129

TWSAPPS_RespFile_windows.txt サイレント・インストール 129

インストール後動的エージェントの構成 197

動的ドメイン・マネージャーの構成195

ドメイン・マネージャーの構成 194

バックアップ動的ドメイン・マネージャーの構成 195

バックアップ・ドメイン・マネージャーの構成 194

バックアップ・マスター・ドメイン・マネージャーの構成 192

フォールト・トレラント・エージェントの構成 196

マスター・ドメイン・マネージャーの構成 191

インストール後のアクション 255

インストール前データベース表の作成 43

インストールでの実行エラー 252

インストールのセキュリティーの影響281

インストール方法Software Distribution 37

インストール前のアクション 255

インストール問題を解決するための手順226

インストールを一時停止する 226

インストール・ウィザードを再開、または再実行 223

インストール・ウィザードを再実行、または再開 223

インストール・ウィザードを即時に再開、または終了して後で再実行 225

インストール・エージェントウィザード、トラブルシューティング

258

無人、トラブルシューティング 258

インストール・サイレント・ログ・ファイル

tws4apps_install.log 129

インストール・ディレクトリーインストールエージェント 97

インストール・ディレクトリー名の @ 文字、 Dynamic Workload Console アンインストールが失敗する 323

インストール・メソッドISMP 37

ランチパッド 36

ISMP サイレント・モード 37

twsinst 37, 106

インストール・ログ・ファイルtws4apps_install.log 128

tws4plugins_install.log 128

インターネットワーク依存関係ドメイン 22

インターフェースコマンド行クライアント 7

ジョブ・ブローカリング定義コンソール 7

マスター・ドメイン・マネージャーのコマンド行 7

Dynamic Workload Broker コマンド行7


ウィザードアンインストール 206


追加プラグイン 128

追加プラグインのアンインストール210

ウィザード・インストール・エージェントswd_env 258



インストール・ディレクトリー 97



ユーザー名 95


ポート番号 97



インストール・ウィザードの使用によるアップグレード 171

エンドツーエンド環境用 94, 106

サイレント・インストールを使用したアップグレード 174

手動によるアンインストール方法 283

静的環境 3

動的エージェントのアップグレード183

標準またはフォールト・トレラント・エージェントのアップグレード 184

分散環境用 94, 106

Software Distribution の使用によるアップグレード 180

twsinst を使用したアップグレード174

エージェント (アンインストール)

ウィザード 206

サイレント 206

twsinst 207

エージェント (フォールト・トレラント)

静的環境 3

索引 367

エージェント、動的IBM i の場合 106

エージェントのアンインストールウィザード 206

サイレント 206

twsinst 207

エージェントの表示名インストールエージェント 97


マスター・ドメイン・マネージャーまたはバックアップ・マスター74

エージェント・インストール無人、トラブルシューティング 258

エンドツーエンド・スケジューリング 30

エンドツーエンド・ワークロード環境計画 14

応答ファイルサイレント・インストール 100

製品のアンインストール・オプション213

製品のインストール・オプション 130

テンプレート 105


応答ファイルのアンインストール・オプション

USER_INSTALL_DIR 213

応答ファイルのオプションPLUGINS_TO_UNDEPLOY 214

応答ファイルの欠落、サイレント・インストールが失敗する 322

応答ファイル・インストール・オプションTWSAPPS_PLUGIN_FILE_NAME 131

USER_INSTALL_DIR 130

オプション製品の応答ファイル 130, 213

製品のサイレント・アンインストール213

製品のサイレント・インストール 130

［カ行］カーネル・パラメーター、

max_thread_proc 241

開始するサーバー 276

console 301


会社インストールフォールト・トレラント・エージェント 96

会社 (続き)



概説アップグレード



外部システムと統合されたワークロード環境 15

拡張エージェント環境 4, 7

機能 4, 7

カスタマイズDB2

プロパティー・ファイル 44

Oracle

プロパティー・ファイル 56

仮想メモリーの不足 258

環境エンドツーエンド・ワークロード環境

14


拡張エージェント 4, 7

説明 1



動的なスケジューリング機能付きの分散ワークロード環境 11, 13

ドメイン 18



分散ワークロード環境 8

マスター・ドメイン・マネージャー 5

ローカライズされた処理 19

z/OS 用の分散ドリブンのワークロード環境 17

環境 (静的)


ドメイン・マネージャー 3

バックアップ・ドメイン・マネージャー 3


標準エージェント 4



管理 HTTP トランスポート・フィールド新機能追加 200

管理 HTTPS トランスポート・フィールド新機能追加 200

キー、レジストリー、Windows、除去する291

技術研修 x

既存のバージョンアップグレード 134

機能アップグレード 190

インストール 99, 198





フォールト・トレラント・エージェント 3, 4

共用 Windows フォルダー、インストールの失敗 319

グローバル・オプション、デフォルト設定の確認 282

計画エンドツーエンド・ワークロード環境

14


環境 8, 11, 13

静的および動的なスケジューリング機能付きの分散ワークロード環境 13

動的なスケジューリング機能付きの分散ワークロード環境 11

ドメイン 18, 19

ドメイン内でのローカライズ処理 19


z/OS 用の分散ドリブンのワークロード環境 17

言語パックアンインストール 209


除去する 206

追加 99


Software Distribution を使用したインストール 123

検査前提条件 28, 136

研修 x

技術 x

更新Tivoli Dynamic Workload Console

認証メカニズム 306

構成アップグレード後の動的スケジューリング 201

インストール DVD の構成 31


構成 (続き)

インストール後の動的スケジューリング 201









構文拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加する wdinstsp 121, 185

構文 CIT のインストールwdinstsp 119, 182

構文エージェントのインストールwdinstsp 120

コネクター手動によるアンインストール 288

追加 99, 199

Windows での手動によるアンインストール 290

このワークステーション名インストール動的ドメイン・マネージャー 88


コマンド拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加する wdinstsp 121, 185

標準エージェント、フォールト・トレラント、またはドメイン・マネージャー機能を追加する wdinstsp 184

標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を追加するwdinstsp 122

setup.bin 128

uninstaller.bin 210, 212

wdinstsp 119

wdinstsp CIT のインストール 119,

182

wdinstsp エージェントのインストール120

wimpspo 119

コマンド行クライアントアップグレード 186

コマンド行クライアント (続き)


パスワード 99

ユーザー名 99

リモート・ポート 99

リモート・ホスト 99

追加言語パック 200

コマンドとスクリプトリンク解除手動によるアンインストールの前に使用される 286

ln

各ディレクトリーを .swdis ディレクトリーへリンクするための249, 255

makesec

Security ファイルの作成 283

ps、手動によるアンインストールの前に使用 286

shut、手動によるアンインストールの前に使用 286

stop

手動によるアンインストールの前に使用 286

twsinst、実行前にファイルが正しくコピーされていない 250, 259

wconvcat 258

wdlssp、手動によるアンインストールの前に使用 286

wdrmvsp、手動によるアンインストールの前に使用 286

wlsinst 257

コミット・ステップが失敗する 259

コミット・ステップで AWSDEQ024E を受け取った 235

［サ行］サービス停止する 170

サービス (Windows)

インストール後の開始に失敗する 237

サービス制御マネージャー・エラー278

削除する 284

パネルを閉じてから InstallShield ウィザードを使用 233, 278

サイレントアンインストール 206

サイレント・アンインストール追加プラグイン・アンインストール・オプション 213

Dynamic Workload Console の 311

Tivoli Workload Scheduler for

Additional Plug-ins 212


応答ファイル・テンプレート 105


ログを書き込むことなく失敗する 245


Dynamic Workload Console の 297


Additional Plug-ins のインストール・オプション 130

サイレント・インストール・ウィザードリカバリーする 227

"Error writing file = 28" を出して失敗する 249

"Error writing file = " を出して失敗する 248

サイレント・インストール・ログ・ファイル

tws4apps_ia_install.log 129

tws4apps_install.log 129

サイレント・モード ISMP

インストール・メソッド 37

作成動的ドメイン・マネージャーのインストール前の SQL ファイル

Oracle 61

マスター・ドメイン・マネージャーのインストール前の SQL ファイル

Oracle 51, 58

サポートログ・ファイルのパッケージ化 215

資格情報の問題が原因でアプリケーション・サーバーの Windows 2003 ドメインでのインストールが失敗する 247

時間帯概説 25

システム (外部)

と統合されたワークロード環境 15

システム・エラー 56b、インストール時に発生する 236

実行アップグレード前の SQL ファイル

Oracle 67

動的ドメイン・マネージャーのインストール前の SQL ファイル

DB2 51

Oracle 61

マスター・ドメイン・マネージャーのインストール前の SQL ファイル

DB2 49

Oracle 58

Tivoli Workload Scheduler のアップグレード前の SQL ファイル

DB2 51, 54

Oracle 62

実行エラー、HP-UX でのインストールの失敗 241

索引 369

自動的にポートを生成インストール動的ドメイン・マネージャー 90

出力タブ、ステップ・ウィンドウの 220

手動Dynamic Workload Console

アンインストール 313, 314

手動によるアンインストールエージェント 283

コネクター 288


準備インストール 27

使用可能な機能Dynamic Workload Broker の 273

Tivoli Workload Scheduler 273

状況タブ、ステップ・ウィンドウの 219

除去Dynamic Workload Console

手動 313, 314

資料 ix

新機能追加管理 HTTP トランスポート・フィールド 200

管理 HTTPS トランスポート・フィールド 200

ブートストラップ・フィールド200

CSIv2 Server Authentication Listener

フィールド 200

CSIv2 クライアント認証リスナー・フィールド 200

HTTP トランスポート・フィールド200

HTTPS トランスポート・フィールド 200

ORB Listener フィールド 200

RMI フィールド 200

SAS Server Authentication Listener

フィールド 200

SOAP コネクター・フィールド200

TWSuser パスワード・フィールド199

スクリプトwebui 271

ステップ動的エージェントの構成 197

動的ドメイン・マネージャーの構成195

ドメイン・マネージャーの構成 194

バックアップ動的ドメイン・マネージャーの構成 195

ステップ (続き)

バックアップ・ドメイン・マネージャーの構成 194

バックアップ・マスター・ドメイン・マネージャーの構成 192

フォールト・トレラント・エージェントの構成 196

マスター・ドメイン・マネージャーの構成 191

ステップ、インストール、失敗、訂正および続行 222

ステップ・ウィンドウ使用 219

ステップ・リスト使用 217

状況 219

スワップ・スペース、不足 258

セーフアップグレード 144

成功のログTivoli Integrated Portal のインストールの失敗 318

生成SQL ファイル

DB2 47

Oracle 58

静的および動的なスケジューリング機能環境 13

静的機能標準エージェント 4


静的ネットワークドメイン・マネージャー 3



製品インストール前、追加プラグインの

126

ウィザードを使用したアンインストール 210

サイレント・アンインストール 212


製品ディレクトリーマスター・ドメイン・マネージャーのアップグレード 147

製品の除去 204

ウィザード 206

サイレント 206


twsinst 207

接続Tivoli Workload Scheduler 273

切断されたコマンド行、Tivoli

Configuration Manager の 257

セットアップ・ファイルDynamic Workload Console


前提条件検査 28, 136

属性、レジストリー・ファイル 335

ソフトウェア配布のゲートウェイ・コンポーネント、非互換性 257

ソフトウェア・パッケージ・ブロック作成およびインストール 181

ソフトウェア・パッケージ・ブロックのインストールおよびアンインストールのログ・ファイル 39

［タ行］対話式ウィザード

Dynamic Workload Console の使用に関する問題 317

段階的なインストール・ウィザード 216

ツールIntegration Workbench 355

追加言語パック 99


コネクター 99

新機能管理 HTTP トランスポート・フィールド 200

管理 HTTPS トランスポート・フィールド 200

ブートストラップ・フィールド200

CSIv2 Server Authentication Listener

フィールド 200

CSIv2 クライアント認証リスナー・フィールド 200

HTTP トランスポート・フィールド200

HTTPS トランスポート・フィールド 200

ORB Listener フィールド 200

RMI フィールド 200

SAS Server Authentication Listener

フィールド 200

SOAP コネクター・フィールド200

TWSuser パスワード・フィールド199

プラグイン、ウィザードの使用による128

wdinstsp を使用した標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能 122


追加 (続き)

wdinstsp を使用して Dynamic

Workload Broker リソース・コマンドを追加するオプション 121

wdinstsp を使用して拡張オプション付きジョブ・タイプを実行する Java

ランタイム 185

wdinstsp を使用して拡張オプション付きジョブ・タイプを実行するためにJava ランタイムを追加するオプション 121

追加プラグインアンインストールウィザードを使用した 210

変更されたファイル 210

ログ・ファイル 210

アンインストール手順 210

データベース表作成アップグレード前 43

インストール前 43

データベース表の作成アップグレード前 43


データベース表の作成 (DB2)

プロパティー・ファイルCOMPANY_NAME プロパティー

46

DB_USER プロパティー 45

EIF_PORT プロパティー 47

HOST_NAME プロパティー 47

TWS_DATA_TS_PATH プロパティー 46

TWS_DB プロパティー 45

TWS_LOG_TS_NAME プロパティー 46

TWS_LOG_TS_PATH プロパティー46

TWS_TS_NAME プロパティー 45

TWS_USER プロパティー 45

WAS_SEC_PORT プロパティー47

停止したインストールの途中から継続226

停止するインストール 226

サーバー 276

サービス 170


ディスク・スペースインストール用に不十分 259

ディレクトリーバックアップ 254

swdis 254

work 254

手順アンインストール 210

動的エージェントいくつかのインストール 259


ユーザー名 95

環境 6

機能 6

構成 197

再インストール 259

名前の維持 259

反復インストール 259

複数のインストール 259

IBM i の場合 106

ID の維持 259

ID の取得 259

動的および静的なスケジューリング機能環境 13

動的スケジューリングアップグレード後に使用可能化 201

インストール後に使用可能化 201

有効化 99, 190

動的スケジューリング機能環境 11

動的ドメイン・マネージャーアンインストール 205




自動的にポートを生成 90

ドメイン名 88


マスター・ドメイン・マネージャーnetman ポート 85


ユーザー名 87


ポート 93


Dynamic Workload Broker・ワークステーション名 93


Netman ポート 89

password 88

インストールが失敗する 251

インストール前の SQL ファイルの実行

DB2 51

Oracle 61

環境 6

構成 195

データベース構成後にインストールが失敗する 251

動的にスケジューリングアップグレード後に使用可能化 201

インストール後に使用可能化 201

ドメインアプリケーションのタイプ 20

インターネットワーク依存関係 22

計画 18, 19

時間帯 20

システム・パフォーマンスおよびその他の基準 20

ジョブ間の依存関係 20

地理的位置の数 20

トポロジー単一 21

複数 23

ネットワーク・トラフィックの量 20

必要なフォールト・トレランスのレベル 20

ファイアウォール 21

ローカライズされた処理 19

ワークステーション、アプリケーション、およびジョブの数 19

SSL または GSKit 21

Windows ネットワーク 20

ドメイン名インストール動的ドメイン・マネージャー 88

ドメイン・マネージャーアップグレード 184

インストール・ウィザードの使用によるアップグレード 171

構成 194

静的環境 3

トラブルシューティングアップグレード 262

アプリケーション・サーバーのインストール問題 246



AIX 238

HP-UX 241

Linux 243

Oracle Solaris 242

UNIX 240

インストール・シナリオDynamic Workload Console 316

各種インストール問題 247

フィックスパックのインストール 280

［ナ行］名前会社マスター・ドメイン・マネージャーまたはバックアップ・マスター73

索引 371

名前 (続き)

このワークステーション名マスター・ドメイン・マネージャーまたはバックアップ・マスター73

ドメイン名 88

マスター・ドメイン・マネージャー名89

ユーザー名 87


ワークステーション名バックアップ・マスター・ドメイン・マネージャー 73

password


認証アップグレード 140

認証メカニズムTivoli Dynamic Workload Console

更新 306

ネットワーク 1







ネットワーク (静的)


エージェント (フォールト・トレラント) 3




標準エージェント 4


［ハ行］バージョン 8.3

Tivoli Workload Scheduler のアップグレード前の SQL ファイルの実行

DB2 51

Oracle 62

バージョン 8.4


DB2 51

バージョン 8.4 (続き)

Tivoli Workload Scheduler のアップグレード前の SQL ファイルの実行 (続き)

Oracle 62

バージョン 8.5


DB2 51

Oracle 62

バージョン 8.5.1


DB2 54

Oracle 67

バージョン 8.5.1.1


DB2 54

Oracle 67

パスワードインストールコマンド行クライアント 99

パスワードが UNIX の TWS_user に対して誤っている 240

バックアップディレクトリー 254

バックアップ動的ドメイン・マネージャー環境 6

構成 195

バックアップ動的ドメイン・マネージャーインストール 85

バックアップ・ドメイン・マネージャー構成 194

静的環境 3

バックアップ・パッケージの作成が失敗した 254

バックアップ・マスターインストール


ポート番号 74

バックアップ・マスターまたはマスター・ドメイン・マネージャーインストールエージェントの表示名 74

会社 73



ユーザー名 72



Netman ポート 74

password 73

バックアップ・マスター・ドメイン・マネージャーインストール 71

名前 73

環境 6

構成 192

静的環境 3

表示名インストールエージェント 97


エージェントマスター・ドメイン・マネージャーまたはバックアップ・マスター74

標準エージェント環境 (静的) 4

機能 (静的) 4

標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を追加する構文

wdinstsp 122

ブートストラップ・フィールド新機能追加 200

ファイルコピー中に大/小文字が変更される

259

実行する前に twsinst が正しくコピーされていない 250, 259

名前、コピー中に大/小文字が変更される 259

ログアンインストール 215


FINAL 191

Security

有無のチェック 283

swdis.ini 119

Symphony 24

tws4apps_ia_uninstall.log のアンインストール 210


tws4apps_status.log のアンインストール 210

tws4apps_uninstall.log のアンインストール 210


TWSAPPS_RespFile_UNIX.txt サイレント・インストール 129


twsinst、実行する前に正しくコピーされていない 250, 259


ファイル (続き)

TWSRegistry.dat 286, 335

/etc/password 179

ファイル書き込みエラー = 28、エラー・メッセージ 249

ファイル書き込みエラー、エラー・メッセージ 248

ファイルの削除手動のアンインストール後に遅過ぎる

288

ファイル名、コピー中に変更された大文字小文字 259

ファイル・システムの構造マスター・ドメイン・マネージャーのアップグレード 149

フィーチャーの追加インストールが失敗する 253

フィックスパックサイレント・インストールが失敗する

248, 249

4.2-SWDGW-F1P1、互換性の問題 257

4.2-TCM-FP02、互換性の問題を解決する 257

Tivoli Configuration Manager を使用したインストール非互換性の問題 257

不十分なディスク・スペース 254

フィックスパックのインストール中に組み込み WebSphere Application Server の更新が失敗する 280

フォールト・トレラント・エージェントインストール 94

会社 96


ユーザー名 95


Netman ポート 96

構成 196

静的機能 3

プラグイン追加、ウィザードによる 128

プロパティー・タブ、ステップ・ウィンドウの 219

プロパティー・ファイルDB2

カスタマイズ 44

Oracle

カスタマイズ 56

プロパティー・ファイル (DB2)

データベース表の作成COMPANY_NAME プロパティー

46




プロパティー・ファイル (DB2) (続き)

データベース表の作成 (続き)








プロファイル、 WebSphere Application

Server、異なる、 Dynamic Workload

Console インストールが失敗する 321

分散ドリブンz/OS 用のワークロード環境 17


静的および動的なスケジューリング機能付きの環境 13

動的なスケジューリング機能付きの環境 11

ページ・ファイルが小さすぎる 258

変更されたファイル追加プラグインのアンインストール

210

変更されるファイルアップグレード 135

変更されるフォルダーアップグレード 135

変数言語イタリア語 124

韓国語 124

スペイン語 124

中国語 (簡体字) 124

中国語 (繁体字) 124

ドイツ語 124

日本語 124

ブラジル・ポルトガル語 124

フランス語 124

install_dir 124

tws_user 124

ソフトウェア・パッケージ・ブロックbackup 116

company 116

domain 117

fresh_install 117

from_release 117

install_dir 117

jm_port 117

jm_sec_port 117

master_cpu 118

pwd 118

変数 (続き)

ソフトウェア・パッケージ・ブロック(続き)

tcp_port 118

tdwb_hostname 118

tdwb_port 118

this_cpu 118

tws_user 118

upgrade 119

symlink

TWA/TWS/bin/at 31

TWA/TWS/bin/batch 31

TWA/TWS/bin/datecalc 31

TWA/TWS/bin/jobstdl 31

TWA/TWS/bin/maestro 31

TWA/TWS/bin/mdemon 31

TWA/TWS/bin/morestdl 31

TWA/TWS/bin/muser 31

TWA/TWS/bin/parms 31

ポートDynamic Workload Broker HTTPS 番号

90

JobManager 90, 97


Netman



WebSphere Application Server 265

ポート番号 HTTPS Dynamic Workload

Broker

インストールマスター・ドメイン・マネージャーまたはバックアップ・マスター74

ポートフォリオconsole 301

方法インストール 127

ホスト名インストールエージェント 97

Dynamic Workload Broker

JobManager 90

FQDN でないために Linux でのインストールが失敗する 319

ホスト名、Dynamic workload broker


索引 373

ホスト名が切り捨てられたため、インストールが失敗する、Windows 234

ホスト名または IP アドレスインストール動的ドメイン・マネージャー 89


本書の規則 ix

［マ行］マスター、グローバル・オプション 282

マスター・ドメイン・マネージャーインストール 71


ポート番号 74



インストール前の SQL ファイルの実行

DB2 49

Oracle 58

環境 5

構成 191

手動によるアンインストール 283

静的環境 2

マスター・ドメイン・マネージャーのアップグレード製品ディレクトリー 147

ファイル・システムの構造 149

SSL ファイルのディレクトリー 149

マスター・ドメイン・マネージャーまたはバックアップ・マスターインストールエージェントの表示名 74

会社 73



ユーザー名 72



Netman ポート 74

password 73

マスター・ドメイン・マネージャー名インストール動的ドメイン・マネージャー 89


マスター・ドメイン・マネージャー・アップグレード製品ディレクトリー 147

ファイル・システムの構造 149

SSL ファイルのディレクトリー 149

無人インストール・エージェントswd_env 258

メソッドアンインストール 210

メッセージInstallAnywhere 戻りコード 228

メモリー仮想、不足 258

問題のシナリオ、インストール 232

［ヤ行］ユーザーアカウント作成

Windows 237

Windows 2000 236

権利TWS_user のための割り当て 237

TWS_user

権利の割り当て 237

UNIX 上でレジストリーから削除する 286

Windows 上でレジストリーから削除 284

ユーザー名インストールコマンド行クライアント 99



作成 118

有効化アップグレード後の動的スケジューリング 201

インストール後の動的スケジューリング 201

動的スケジューリング 99, 190

用語集 ix

［ラ行］ランチパッドインストール 36


リモート・ポートインストールコマンド行クライアント 99

リモート・ホストコマンド行クライアントインストール 99

リレーショナル・データベース管理システムインストール 34

例レジストリー・ファイル 335

Software Distribution を使用した言語のインストール 124

レジストリー項目、手動で削除するUNIX 286

Windows 284, 291

レジストリー属性 335

レジストリー・ファイル再作成 187

属性 335

破損したファイルを使用したアップグレード 187

例 335

ローカライズされた処理ドメイン 19

ログ・アナライザー説明 355




組み込み WebSphere Application Server


サポート用のパッケージ化 215

追加プラグインのアンインストール210

DB2 インストール 40



tws4apps_status.log のアンインストール 210

tws4apps_uninstall.log のアンインストール 210


tws4plugins_install.log 128

ログ・ファイル、サイレント・インストール

tws4apps_ia_install.log 129

ログ・ファイルは、失敗したサイレント・インストールによって書き込まれない245

［ワ行］ワークステーションリンク解除する 170

ワークステーションのリンク解除 170

ワークステーション名インストールバックアップ・マスター・ドメイン・マネージャー 73



ワークステーション名 Dynamic Workload

Broker

インストール動的ドメイン・マネージャー 93


ワークステーション・クラス定義 25

［数字］4.2-SWDGW-F1P1 フィックスパック、互換性の問題 257

4.2-TCM-FP02 フィックスパック、互換性の問題を解決する 257

56b - インストール時に発生するシステム・エラー 236

AAgent、レジストリー属性 335

AIX

インストール問題 238

InstallShield ウィザードのインストールの失敗 252

AIX 6100-05 でのインストールのハング239

AIX でのインストールのハング 239

APAR 237

IY50574 282

IZ79105 301

AWSFAB035E を受け取った 257

AWSFAB037E を受け取った 250

AWSGAB005W を受け取った 235

AWSGAB566E を受け取った 258

Bbatchman

アクティブかどうかを確認する 286

bc、Linux 上の InstallShield ウィザードに必要なユーティリティー 243

BOOTSTRAP_ADDRESS 応答ファイル・プロパティー 350

CCD



checkJobsLoop.wait 応答ファイル・プロパティー 337

checkPrerequisites.stopOnCheckPrereq 応答ファイル・プロパティー 337

CLI

パラメーター、 -installRoot は無効です (parameter, -installRoot, is

invalid)、Oracle Solaris 上で戻されるエラー 242

wdinstsp 119

wimpspo 119

CMW3202E を受け取った 234

COMPANY_NAME プロパティーカスタマイズ

DB2 46

Oracle 57

console

開始 301

ポートフォリオ 301

cpuCfgPanel.addFINAL 応答ファイル・プロパティー 337

cpuCfgPanel.company 応答ファイル・プロパティー 337

cpuCfgPanel.jmPort NumberHttps 応答ファイル・プロパティー 337

cpuCfgPanel.masterCPU 応答ファイル・プロパティー 337

cpuCfgPanel.tcp PortNumber 応答ファイル・プロパティー 338

cpuCfgPanel.tdwbHostName 応答ファイル・プロパティー 337

cpuCfgPanel.thisCPU 応答ファイル・プロパティー 338

cpuCfgPanel.tws PortNumber 応答ファイル・プロパティー 338

CREATE_WAS_SERVICE 応答ファイル・プロパティー 350

CSIv2 Server Authentication Listener フィールド新機能追加 200

CSIv2 クライアント認証リスナー・フィールド新機能追加 200

CSIV2_SSL_MUTUALAUTH_

LISTENER_ADDRESS 応答ファイル・プロパティー 350

CSIV2_SSL_SERVERAUTH_


customizeDB2SQL.properties ファイルカスタマイズ

DB2 44

customizeORACLESQL.properties ファイルカスタマイズ

Oracle 56

customizeSQL

SQL ファイルの生成DB2 47

DDB2

インストール・ログ・ファイル 40

カスタマイズプロパティー・ファイル 44

COMPANY_NAME プロパティー46




TWSTEMPDIR プロパティー 44








生成SQL ファイル 47

データベース表のアップグレードアップグレード前 44

データベース表の作成インストール前 44

動的ドメイン・マネージャーのインストール前の実行

SQL ファイル 51

マスター・ドメイン・マネージャーのインストール前の実行

SQL ファイル 49

SQL ファイルの生成customizeSQL 47

images_dir 47, 48

javahome_dir 48

operating_system 47

property_file_path 48

Tivoli Workload Scheduler のアップグレード前の実行

SQL ファイル 51, 54

db2CheckPrereqs. db2Directory. 応答ファイル・プロパティー 338

db2ClientCfg. remoteNode. 応答ファイル・プロパティー 338

db2ClientCfg. remotePort. 応答ファイル・プロパティー 338

db2ClientCfg. twsDBPwd. 応答ファイル・プロパティー 339

db2ClientCfg. twsDBUser. 応答ファイル・プロパティー 339

db2ClientCfg.db2 AdminPwd. 応答ファイル・プロパティー 339

索引 375

db2ClientCfg.db2 AdminUser. 応答ファイル・プロパティー 339

db2ClientCfg.db2 LocalAdminPwd. 応答ファイル・プロパティー 339

db2ClientCfg.db2 LocalAdminUser. 応答ファイル・プロパティー 339

db2ServerCfg. instanceName 応答ファイル・プロパティー 339

db2ServerCfg.db2 Admin ユーザー応答ファイル・プロパティー 340

db2ServerCfg.db2AdminPwd 応答ファイル・プロパティー 340

db2ServerCfg.instancePort 応答ファイル・プロパティー 340

DB_USER プロパティーカスタマイズ

DB2 45

DCS_UNICAST_ADDRESS 応答ファイル・プロパティー 350

DISSE0005E を受け取った 254




DVD


Dynamic Workload Broker

インストールDynamic Workload Broker HTTPS

ポート番号 90

サーバー接続 275

使用可能な機能 273

Dynamic Workload Broker HTTPS ポート番号インストールエージェント 97



Dynamic Workload Broker ホスト名インストールエージェント 97


Dynamic workload broker ホスト名インストールマスター・ドメイン・マネージャーまたはバックアップ・マスター74

Dynamic Workload Broker ワークステーション名インストールマスター・ドメイン・マネージャー

85

Dynamic Workload Broker・ワークステーション名インストール動的ドメイン・マネージャー 93


アクセシビリティー ix

アップグレードウィザードの使用 309

概説 306


Server でのアップグレード 307

サイレント 309

失敗した、リカバリー 313




クリーンアップ 313, 314

サイレント・モード 311

手動 313, 314

インストールイメージ 298


応答ファイルの使用 268

拡張 265

既存の外部 WebSphere Application

Server への 267


Server 265


Server の既存のインスタンス266

サイレント 268

サンプル・シナリオ 296

セットアップ・ファイル 298

タイプ 265

デフォルト 265

メソッド 297



CD 298

インストールおよびアンインストールのログ・ファイル 312

概説 295

更新認証メカニズム 306

構成 300

Tivoli Workload Scheduler バージョン 8.3 フィックスパック 3 用270

始動および停止 276

除去手動 313, 314

接続Dynamic Workload Broker コンポーネントへの 275


Dynamic Workload Console (続き)

始めに 301

ユーザー・インターフェース 272


Dynamic Workload Console のインストール時の stopWas コマンドのハング 318

Dynamic Workload Console のインストールを停止させるファイアウォール 317

Dynamic Workload Console のサイレント・インストールの問題 322

Dynamic Workload Console の問題アップグレード 322


EEIF_PORT プロパティーカスタマイズ

DB2 47

Oracle 57

ENABLE_TDWB 応答ファイル・プロパティー 350

ENABLE_TWS 応答ファイル・プロパティー 350

FFeatureList、レジストリー属性 335

FINAL

追加 191

final ジョブ・ストリーム追加 191

HHOST_NAME プロパティーカスタマイズ

DB2 47

Oracle 57

HP-UX


InstallShield ウィザードのインストール開始されない 241

「実行エラー」を出して失敗する241

失敗する 252

JRE をインストールできない 241

HTTP トランスポート・フィールド新機能追加 200

HTTPS トランスポート・フィールド新機能追加 200


HTTPS ポート番号Dynamic Workload Broker 90

HTTPS ポート番号 Dynamic Workload

Broker


IIBM i

エージェント、動的 106

images_dir

SQL ファイルの生成DB2 47, 48

InstallAnywhere エラー・メッセージメッセージ 228

InstallationActions. Install_Method 応答ファイル・プロパティー 341

InstallationActions. TWA_ 341

InstallationActions. twsUser 応答ファイル・プロパティー 341

InstallationActions.instanceID 応答ファイル・プロパティー 341

installationAgent Components. addEclipse

応答ファイル・プロパティー 342

installationAgent Components. addTdwb 応答ファイル・プロパティー 342

installationAgentComponents. instanceType

応答ファイル・プロパティー 342

installationComponents.instance Type 応答ファイル・プロパティー 342

InstallationPath、レジストリー属性 335

installLocation 応答ファイル・プロパティー 342, 355

InstallShield ウィザードインストールおよびアンインストールのログ・ファイル 38, 299

インストールのリカバリー 216

「実行エラー」で失敗する 252

「実行エラー」により AIX またはHP-UX 上で失敗する 252

「実行エラー」を出して HP-UX 上で失敗する 241

「フィーチャーの追加」インストールが失敗する 253


HP-UX 上で開始しない 241

JRE を HP-UX にインストールできない 241

JRE を Linux にインストールできない 243

Windows でのアンインストールに失敗する 278

InstallShield ウィザードバックアップ・マスター・ドメイン・マネージャーのインストール

localopts 261

InstallShield ウィザード Oracle インストール失敗する

AWSJIS145E 260

InstallShield ウィザードのインストール失敗する

AWSJIS145E 260


localopts 261

INSTALL_METHOD 応答ファイル・プロパティー 351

INSTANCE_PATH 応答ファイル・プロパティー 341

Integration Workbench

アップグレード 357


プラグインとしてのインストールのアップグレード 358

リモート Eclipse サイトを使用したインストール 357

IP アドレスインストールエージェント 97

IP アドレスまたはホスト名インストール動的ドメイン・マネージャー 89


IPC_CONNECTOR_ADDRESS 応答ファイル・プロパティー 351

ISC_ADMIN_FULL_USER 応答ファイル・プロパティー 352

ISC_ADMIN_PASSWORD 応答ファイル・プロパティー 353

ISC_APPSERVER_DIR 応答ファイル・プロパティー 353

ISMP

インストール・メソッド 37

ISMP サイレント・モードインストール・メソッド 37

IsOnlyFTAConnectorToUninstall.

IsOnlyFTAConnector 応答ファイル・プロパティー 343

IS_BACKUP_DIR 応答ファイル・プロパティー 351

IS_DESTINATION 応答ファイル・プロパティー 352

IS_UPGRADE 応答ファイル・プロパティー 352

IY50574、APAR 282

IY52481、APAR 237

JJava ランタイムインストール 95

Java ランタイム環境HP-UX 上でインストールできない

241

Linux にインストールできない 243

UNIX での検証の問題 240

javahome_dir


jobman および JOBMAN


JobManager ポートインストールエージェント 97



JVM

Linux RHEL 5 で製品のインストールが失敗する 244

Linux RHEL V5 でインストールが失敗する 320

Suse Linux でインストールが失敗する320

Suse Linux で製品のインストールが失敗する 244

jvmtimer の使用、UNIX インストールに必要 240

LLDAP

アップグレード 140

Tivoli Dynamic Workload

Console 306

license Accepted 応答ファイル・プロパティー 355

licenseAccepted 応答ファイル・プロパティー、TDWC 353

licenseAccepted 応答ファイル・プロパティー、TWS 343

Linux

インストール後の Tivoli Workload

Scheduler の開始によりエラーが発生する 244


ホスト名が FQDN でない場合にインストールが失敗する 319

索引 377

Linux (続き)

ランチパッドから表示される誤った警告メッセージ 316

Dynamic Workload Console の RHEL

5 (x86-64) インストールまたはアンインストールの開始に失敗する 321

InstallShield ウィザードのインストールは、JRE をインストールできない

243

RHEL 5 および Suse 11 製品のインストールの失敗 (JVM) 244

RHEL V5 および Suse V11 のインストールの失敗 (JVM) 320

Linux ユーザー・アカウント 40

ln、コマンド各ディレクトリーを .swdis ディレクトリーへリンクするための 249, 255

localopts

デフォルト設定を確認する 282

LPList、レジストリー属性 335

LPName、レジストリー属性 335

Mmailman


MaintenanceVersion、レジストリー属性335

MajorVersion、レジストリー属性 335

makesec

Security ファイルの作成 283

MAXDSIZ、HP-UX に必要な構成パラメーター 241

max_thread_proc カーネル・パラメーター241

MDL_USER プロパティーカスタマイズ

Oracle 56

MinorVersion、レジストリー属性 335

Nnetman


Netman ポートインストール動的ドメイン・マネージャー 89


フォールト・トレラント・エージェントインストール 96

netman ポート Dynamic Workload Broker



NFS マウントのインストール・イメージ、インストールが失敗する 252

NoClassDefFoundError エラー 252

Ooperating_system


Oracle

カスタマイズプロパティー・ファイル 56

COMPANY_NAME プロパティー57



MDL_USER プロパティー 56

TWSTEMPDIR プロパティー 56


TWS_PASSWORD プロパティー56


TWS_TS_TEMP_NAME プロパティー 57



生成SQL ファイル 58

データベース表のアップグレードアップグレード前 43, 56

データベース表の作成インストール前 43, 56


SQL ファイル 61

のアップグレード前の実行SQL ファイル 67


SQL ファイル 58


SQL ファイル 62

Oracle E-Business Suite アプリケーションと統合されたワークロード環境 15

Oracle Solaris 上で installRoot が無効242

oracleCheckPrereqs. oracleDirectory 応答ファイル・プロパティー 343

oracleServerCommunication

Info.netServiceName 応答ファイル・プロパティー 343

oracleServerCommunication

Info.oracleAdminPwd 応答ファイル・プロパティー 344

oracleServerCommunicationInfo.

oracleAdminUser 応答ファイル・プロパティー 343

ORB Listener フィールド新機能追加 200

ORB_LISTENER_ADDRESS 応答ファイル・プロパティー 353

PPackageName、レジストリー属性 335

password



PatchVersion、レジストリー属性 335

Peoplesoft アプリケーションと統合されたワークロード環境 15

PLUGINS_TO_UNDEPLOY

応答ファイルのオプション 214

ProductID、レジストリー属性 335

property_file_path


ps、手動によるアンインストールの前に使用されるコマンド 286

RrecovInstReg.run 応答ファイル・プロパティー 344

Red Hat Enterprise Linux 6.0 でのインストールの失敗 245

Red Hat Enterprise Linux V5

(JVM) での製品のインストールが失敗244

Red Hat Enterprise Linux V5

(x86-64)、Dynamic Workload Console のインストールまたはアンインストールに失敗する 321

Red Hat Enterprise Linux V5、(JVM) でのインストールが失敗 320

REST_NOTIFICATION_ADDRESS 応答ファイル・プロパティー 353


RHEL 5


RHEL 5 (x86-64)、Dynamic Workload

Console のインストールまたはアンインストールに失敗する 321

RHEL V5 および Suse V11、(JVM) でのインストールが失敗 320

RMI フィールド新機能追加 200

SSAP R/3 アプリケーションと統合されたワークロード環境 15

SAS Server Authentication Listener フィールド新機能追加 200

SAS_SSL_SERVERAUTH_


SDK_ECLIPSE_BUNDLED 応答ファイル・プロパティー 344

SDK_UPDATESITE 応答ファイル・プロパティー 344

Security ファイル有無のチェック 283

selectRDBMSPanel.rdbmsSelected 応答ファイル・プロパティー 344

setup.bin

コマンド、インストール用 128

shut、コマンド、手動によるアンインストールの前に使用 286

SOAP コネクター・フィールド新機能追加 200

SOAP_CONNECTOR_ADDRESS 応答ファイル・プロパティー 353

Software Distribution

言語パックのインストール 123

Solaris

インストールがエラー「コマンド行パラメーター、 -installRoot は無効です(The command line parameter,

-installRoot, is invalid)」を出して失敗する 242


SQL ファイル生成

DB2 47

Oracle 58


DB2 51

SQL ファイル (続き)

動的ドメイン・マネージャーのインストール前の実行 (続き)

Oracle 61

のアップグレード前の実行Oracle 67


DB2 49

Oracle 58


DB2 51, 54

Oracle 62

SQL ファイルの生成DB2

customizeSQL 47

images_dir 47, 48

javahome_dir 48

operating_system 47

property_file_path 48

SSL ファイルのディレクトリーマスター・ドメイン・マネージャーのアップグレード 149

SSL ファイル・ディレクトリーマスター・ドメイン・マネージャーのアップグレード 149

stageman


stop、コマンド手動によるアンインストールの前に使用される 286

summary.log、ファイル 215

Suse Linux 11


Suse Linux V11、(JVM) でのインストールが失敗 320

swdis ディレクトリー不十分なスペース 254

swd_env

ウィザード、トラブルシューティング258

Symphony ファイル 24

TTdwb Config. tdwbCpuName 343, 344

TdwbConfig. tdwbCpuPort 343, 345

Tivoli Configuration Manager

インストールが失敗する 254, 255

フィックスパックとの非互換性の問題257

不十分なディスク・スペース 254

Tivoli Configuration Manager の SWDGW

コンポーネント、非互換性 257

Tivoli Dynamic Workload Console

アップグレード概説 306


概説 295

更新認証メカニズム 306

構成 300

始動および停止 276


始めに 301

Tivoli Integrated Portal

インストールDVD または eImage から 270

Tivoli Netman、TWS_user 用、サービスを削除する 284

Tivoli Token サービスインストール後の開始に失敗する 237

TWS_user 用、サービスを削除する284

Tivoli Workload Scheduler 295

エンジン接続 273

使用可能な機能 273

Tivoli Workload Scheduler for Additional

Plug-ins

アンインストールサイレント・アンインストールを使用する 212

インストール追加プラグイン 127



Plug-ins 一時インストール失敗する十分なスペースがない 261


Plug-insのインストール失敗する

AWSJIS145E 261


Applications 295

Tivoli Workload Scheduler for z/OS 295

Tivoli Workload Scheduler インストールを検証する 282

Tivoli Workload Scheduler エージェント106

Tivoli Workload Scheduler エージェント(アンインストール)

ウィザード 206

サイレント 206

twsinst 207

Tivoli Workload Scheduler バージョン 8.3

フィックスパック 3

構成Dynamic Workload Console の 270

Tivoli 技術研修 x

索引 379

TWA_INSTANCE_PATH 応答ファイル・プロパティー 353

tws4apps_ia_install.log

ログ・ファイル、サイレント・インストール 129

tws4apps_ia_uninstall.log

アンインストールのログ・ファイル210

サイレント・アンインストールのログ・ファイル 212

tws4apps_install.log

ログ・ファイル、サイレント・インストールの 129

tws4apps_uninstall.log

アンインストールのログ・ファイル210

サイレント・アンインストールのログ・ファイル 212

tws4plugins_install.log

ログ・ファイル、インストール 128

TWSAPPS_PLUGIN_FILE_NAME

zip ファイル 131

TWSAPPS_RespFile_UNIX.txt 129

TWSAPPS_RespFile_Windows

インストール応答ファイル、製品の129

twsCliCfgPanel.password 応答ファイル・プロパティー 345

twsCliCfgPanel.remoteHost 応答ファイル・プロパティー 345

twsCliCfgPanel.remotePort 応答ファイル・プロパティー 345

twsCliCfgPanel.user ユーザー応答ファイル・プロパティー 345

TWSCLILanguagesPanel.* 応答ファイルのプロパティー 345

twsCLILocationPanel.directory 応答ファイル・プロパティー 345

TWSConnRegistry.dat 289

twsDBCfg.dbName 応答ファイル・プロパティー 345

twsDBCfg.report TablespaceName 応答ファイル・プロパティー 346

twsDBCfg.report TablespacePath 応答ファイル・プロパティー 346

twsDBCfg.tablespaceName 応答ファイル・プロパティー 346

twsDBCfg.tablespacePath 応答ファイル・プロパティー 346

twsinst 106


インストールおよびアンインストールのログ・ファイル 39

インストール・メソッド 37, 106

実行前にファイルが正しくコピーされていない 250, 259

twsinst (続き)

失敗するエラー AWSFAB035E 257

エラー AWSGAB566E 258

その他 259

"The twsinst script is being run

from the wrong directory." 250

無人、トラブルシューティング 246

UNIX での使用法 176

Windows での使用法 177

twsinst インストール・エージェントswd_env 258

twsinst パラメーターによる更新-addjruntime 177

-backup_dir 177

-displayname 178

-domain 178

-hostname 178

-inst_dir 178

-jmport 178

-jmportssl 178

-lang 179

-nobackup_dir 179

-password 179

-reset_perm 179

-skip_usercheck 179

-tdwbhostname 179

-tdwbport 179

-uname 179

-update 179

-wait 180

twsinst を使用する無人インストール 246

twsismp.log、ファイル 215

twsLocationPanel.directory 応答ファイル・プロパティー 346

twsLocationPanel.symLinkOption 応答ファイル・プロパティー 346

twsOracleDbCfg. isPartitioned 応答ファイル・プロパティー 347

twsOracleDbCfg. twsDBPwd 応答ファイル・プロパティー 346

twsOracleDbCfg. twsDBUser 応答ファイル・プロパティー 346

twsOracleDbCfg.tws DataTablespace 応答ファイル・プロパティー 346

twsOracleDbCfg.tws ReportTablespace 応答ファイル・プロパティー 346

twsOracleDbCfg.tws TempTablespace 応答ファイル・プロパティー 346

twsPortsPanel.portAdmin 応答ファイル・プロパティー 347

twsPortsPanel.portAdminSec 応答ファイル・プロパティー 347

twsPortsPanel.portEif 応答ファイル・プロパティー 347

twsPortsPanel.portHTTP 応答ファイル・プロパティー 347

twsPortsPanel.portHTTPS 応答ファイル・プロパティー 347

twsPortsPanel.portMtlAuth 応答ファイル・プロパティー 347

twsPortsPanel.portORB 応答ファイル・プロパティー 347

twsPortsPanel.portRMI 応答ファイル・プロパティー 347

twsPortsPanel.portSAS 応答ファイル・プロパティー 347

twsPortsPanel.portSOAP 応答ファイル・プロパティー 348

twsPortsPanel.portSrvAuth 応答ファイル・プロパティー 348

TWSRegistry.dat ファイル 286, 335

TWSTEMPDIR プロパティーカスタマイズ

DB2 44

Oracle 56

twsUpgradePanel.backupOldInstance 応答ファイル・プロパティー 348

twsUpgradePanel.bckpDirectory 応答ファイル・プロパティー 348

twsUpgradePanel.bckpProfileDirectory 応答ファイル・プロパティー 348

twsUpgradePanel.dumpDirectory 応答ファイル・プロパティー 348

TWSUser

アカウント作成Windows 237

Windows 2000 236

レジストリーから削除するUNIX 286

Windows 284

TWSuser パスワード・フィールド新機能追加 199

TWSZConnRegistry.dat 289

TWS_DATA_TS_PATH プロパティーカスタマイズ

DB2 46

TWS_DB プロパティーカスタマイズ

DB2 45

TWS_LOG_TS_NAME プロパティーカスタマイズ

DB2 46

Oracle 57

TWS_LOG_TS_PATH プロパティーカスタマイズ

DB2 46

TWS_PASSWORD プロパティーカスタマイズ

Oracle 56


TWS_TS_NAME プロパティーカスタマイズ

DB2 45

Oracle 57

TWS_TS_TEMP_NAME プロパティーカスタマイズ

Oracle 57

TWS_user パスワードが UNIX 上で誤っている 240

TWS_USER プロパティーカスタマイズ

DB2 45

Oracle 57

TWS_user 用の Tivoli Workload Scheduler

サービスインストール後の開始に失敗する 237

削除する 284

UUNC マップ済みドライブからインストールできない 248

uninstaller.bin

アンインストール用コマンド 210,

212

UNIX


サイレント・フィックスパック・インストールが失敗する 248, 249


パスワードが TWS_user に対して誤っている 240

JVM 妥当性検査エラーによりインストールが失敗する 240

UNIX ユーザー・アカウント 40

unlink、コマンド手動によるアンインストールの前に使用される 286

UPDATE_INSTALLER_DIR 応答ファイル・プロパティー 354

UserOwner、レジストリー属性 335

userUnixCfgPanel.inputUserName 応答ファイル・プロパティー 348

userUnixCfgPanel.twsPassword 応答ファイル・プロパティー 348

userUnixCfgPanel.wasPassword 応答ファイル・プロパティー 348

userUnixCfgPanel.wasUserName 応答ファイル・プロパティー 349

userWinCfgPanel.inputUserName 応答ファイル・プロパティー 349

userWinCfgPanel.twsPassword 応答ファイル・プロパティー 349

userWinCfgPanel.wasPassword 応答ファイル・プロパティー 349

userWinCfgPanel.wasUserName 応答ファイル・プロパティー 349

USER_INSTALL_DIR

アンインストール応答ファイルのオプション 213

インストールの応答ファイル・オプション 130

WWAS_CELL_NAME 応答ファイル・プロパティー 354

WAS_NODE_NAME 応答ファイル・プロパティー 354

WAS_PROFILE_NAME 応答ファイル・プロパティー 354

WAS_SEC_PORT プロパティーカスタマイズ

DB2 47

Oracle 58

WAS_SERVER_NAME 応答ファイル・プロパティー 354

wconvcat、コマンド 258

WC_adminhost 応答ファイル・プロパティー 354

WC_adminhost_secure 応答ファイル・プロパティー 354

WC_defaulthost 応答ファイル・プロパティー 354

WC_defaulthost_secure 応答ファイル・プロパティー 354

wdinstsp

拡張オプション付きジョブ・タイプを実行するために Java ランタイムを追加するための構文 121, 185

構文 CIT のインストール 119, 182

構文エージェントのインストール 120

標準エージェント、フォールト・トレラント、またはドメイン・マネージャー機能を追加する構文 184

標準エージェント、フォールト・トレラント・エージェント、またはドメイン・マネージャー機能を追加する構文 122

wdlssp、手動によるアンインストールの前に使用されるコマンド 286

wdrmvsp、手動によるアンインストールの前に使用されるコマンド 286

WebSphere Application Server

インスタンスの選択 264

ポート 265

WebSphere Application Server、異なるプロファイルにインストールする際にDynamic Workload Console のインストールが失敗する 321

webui

スクリプト 271

Windows

アプリケーション・サーバーにインストールする際の資格情報の問題 236

アンインストールが復元プロファイル・ステップで失敗する 278

アンインストールは、組み込みWebSphere Application Server が停止しないために失敗する 278

インストール警告 AWSGAB005W を受け取る

235

InstallShield ウィザードにより、失敗する 233

インストールが失敗するホスト名が切り捨てられる 234


共用フォルダー、インストールの失敗319

異なる外部 WebSphere Application

Server プロファイルでの Dynamic

Workload Console のインストールが失敗する 321

コネクターを手動でアンインストール290


手動のアンインストール後のファイル削除が遅い 288

ランチパッドから表示される未定義エラー・メッセージ 317

レジストリー・キーを除去する 291

2003 ドメイン、アプリケーション・サーバーのインストールが資格情報の証明書で失敗する 247

InstallShield ウィザードによるアンインストールが失敗する 278

Windows でインストールする際のアプリケーション・サーバーの資格情報の問題

236

Windows でホスト名が切り捨てられる:


wlsinst、コマンド 257

work ディレクトリー 254

writer

アクティブかどうかを確認 286

Zz/OS アプリケーションと統合されたワークロード環境 15

索引 381

��

プログラム番号: 5698-WSH

Printed in Japan

SC88-9679-08

Spineinformation:

IBM

Tiv

oli

Wo

rklo

adS

ched

ule

rバージョン

8.6

(201

2年

6月改訂

)計画およびインストール

��

�