IBM Workload Automationバージョン 9 リリース 4

概要

IBM

IBM Workload Automationバージョン 9 リリース 4

概要

IBM

注記

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

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

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

本書は下記原典を翻訳したものです。

原典： IBM Workload AutomationVersion 9 Release 4Overview

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

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

© Copyright IBM Corporation 1999, 2016. © Copyright HCL Technologies Limited 2016, 2017

目次

図 . . . . . . . . . . . . . . . . . vii

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

機能拡張の要約 . . . . . . . . . . . xiiiIBM Workload Scheduler バージョン 9.4 フィックスパック 2 の拡張機能 . . . . . . . . . xiii

各種の価格設定モデル . . . . . . . . . xiii複数のジョブの再実行 . . . . . . . . . xivロールバック手順 . . . . . . . . . . . xivプールおよび動的プール内で実際に実行されたワークステーション . . . . . . . . . . . xv機能拡張要求 (RFE) への適合 . . . . . . . xv

IBM Workload Scheduler バージョン 9.4 フィックスパック 1 の拡張機能 . . . . . . . . . xvi

グラフィカル・ビューの改良 . . . . . . . xvii仮定分析の拡張機能 . . . . . . . . . . xviiiIBM Workload Scheduler ジョブ管理プラグイン . . . . . . . . . . . . . . . . xix反復ワークフローの自動化 . . . . . . . . xix再実行における柔軟性の向上 . . . . . . . xxIBM Workload Scheduler ジョブ・ストリームの実行依頼プラグイン . . . . . . . . . xxi条件ベースのワークロード・オートメーション xxifilemonitor ユーティリティーを使用したファイル変更のモニター . . . . . . . . . . . xxiiジョブ・ストリーム内で最遅開始時刻を定義するための新しいキーワード . . . . . . . . xxii遅延ジョブに対するアクションを定義するための新しいキーワード . . . . . . . . . . xxiii仮定分析のより高度な制御. . . . . . . . xxiii動的エージェント用に Docker イメージを準備してインストールする . . . . . . . . . xxivバージョン 8.6.x からのアップグレード . . . xxivワークロード・アプリケーションを管理するための新しいオプション . . . . . . . . . xxvIBM UrbanCode Deploy との統合 . . . . . xxvi機能拡張要求 (RFE) への適合 . . . . . . xxvi

IBM Workload Scheduler バージョン 9.4 の機能拡張 . . . . . . . . . . . . . . . . xxvii

スケジューリングの中断が最小のエージェント・アップグレード . . . . . . . . . xxviiiCloudant 用の IBM Workload Scheduler プラグイン . . . . . . . . . . . . . . xxix

スケジューリング・オブジェクトに対する変更の追跡 . . . . . . . . . . . . . . xxixリリース管理の監査 . . . . . . . . . . xxxバージョン管理 . . . . . . . . . . . xxxitws_env スクリプトのバックアップ・コピー xxxiiServiceNow インシデントを開くための新しいイベント・ドリブン・ワークロード自動化アクション . . . . . . . . . . . . . . xxxiiIBM i ジョブ定義の機能拡張 . . . . . . xxxiiジョブ間での変数の引き渡し . . . . . . . xxxiiグラフィカル・ビューの機能拡張 . . . . . xxxiiiIBM Workload Scheduler REST API . . . xxxiii機能拡張要求 (RFE) への適合 . . . . . . xxxiv

IBM Workload Scheduler バージョン 9.3 フィックスパック 2 での機能拡張 . . . . . . . . xxxv

DB2 および Oracle のデータベース・スキーマを更新する新しい方法 . . . . . . . . . xxxvハイブリッド・ワークロード・オートメーション . . . . . . . . . . . . . . . xxxviサイレント・インストールの実行前の前提条件の検査 . . . . . . . . . . . . . xxxviiIBM Workload Scheduler インスタンスの自動初期設定 . . . . . . . . . . . . xxxviiIBM Workload Scheduler の役割ベースのセキュリティーの定義と管理 . . . . . . . xxxviiiIBM i ジョブのメッセージへの DynamicWorkload Console からの応答 . . . . . xxxviiiIBM i ジョブに対する待機メッセージへの自動応答 . . . . . . . . . . . . . xxxviiiIBM Workload Scheduler plug-in forApache Oozie . . . . . . . . . . . xxxixジョブの完了時のスクリプトの実行 . . . . xxxix新しい向上した Web インターフェース . . . xxxixコンテキストに合わせて計画ビューを起動するURL の作成 . . . . . . . . . . . . . xlRFE 84003 - グラフィカル・ビューのエクスポート時のスタイルの変更 . . . . . . . . . . xlRFE 75635 - 幅広モニターに対応するグラフィカル・ビュー拡張 . . . . . . . . . . . . xlワークステーション名とユーザー ID のオートコンプリート . . . . . . . . . . . . . . xlDynamic Workload Console を使用したワークロード・セキュリティーの管理 . . . . . . . . xl障害点からの Informatica PowerCenter ジョブの再始動 . . . . . . . . . . . . . . xliシングル・エントリ・ポイント . . . . . . . xliMS SQL データベースに対して拡張されたTivoli Common Reporting レポート . . . . xlii

IBM Workload Scheduler バージョン 9.3 フィックスパック 1 の機能拡張 . . . . . . . . . xlii

条件付き依存関係 . . . . . . . . . . . xliii

iii

//////////////==========================================|||||||||

|||||||||||||||||||||||

Liberty 用の IBM Workload Scheduler プラグイン . . . . . . . . . . . . . . . xliiiMQTT 用の IBM Workload Scheduler プラグイン . . . . . . . . . . . . . . . xliiiWebSphere Application Server ツールの機能拡張 . . . . . . . . . . . . . . . . xlivエージェント集中更新のスケジューリング . . xlivIBM Tivoli Monitoring 統合の機能拡張: 状態のリファクタリングおよび新規ビューの関連付け . xlivクーロン・ジョブと Windows タスク・スケジューラー・ジョブのインポート . . . . . . xlv仮定分析による変更の計画への実装 . . . . . xlvIBM i の機能拡張 . . . . . . . . . . . xlvDynamic Workload Console バージョン 9.3 フィックスパック 1 のその他の機能拡張 . . . . xlvi

IBM Workload Scheduler バージョン 9.3 の機能強化 . . . . . . . . . . . . . . . . xlvi

IBM WebSphere MQ の IBM WorkloadScheduler プラグイン . . . . . . . . . xlviiIBM Workload Scheduler Plug-in for RESTfulWeb サービス . . . . . . . . . . . . xlviiIBM Workload Scheduler Plug-in for SAPBusinessObjects . . . . . . . . . . . xlviiiNetezza Performance Server に対する IBMWorkload Scheduler サポート . . . . . . xlviiiIBM Sterling Connect:Direct の IBM WorkloadScheduler プラグイン . . . . . . . . . xlixIBM Workload Scheduler Plug-in forSalesforce . . . . . . . . . . . . . xlixIBM Workload Scheduler Plug-in for Hadoop xlixIBM Workload Scheduler Plug-in for BigInsightsfor Hadoop . . . . . . . . . . . . . . lIBM Workload Scheduler plug-in for OracleE-Business Suite . . . . . . . . . . . . lファイル転送プラグインの機能拡張 . . . . . . l「繰り返し」オプションによるジョブ・ストリーム定義の拡張 . . . . . . . . . . . . . liIBM Workload Scheduler を使用した SAP でのジョブ機能の拡張. . . . . . . . . . . . liWorkload Automation の障害によるビジネスへの影響の遮断 . . . . . . . . . . . . . liii動的エージェントのファイル依存関係サポート liii中央制御エージェントの更新 . . . . . . . liv基本製品に付属してインストールされるようになった IBM Tivoli Workload Scheduler forApplications . . . . . . . . . . . . . livドメイン・ユーザーを使用したエージェントのインストール. . . . . . . . . . . . . . lvその他の機能拡張 . . . . . . . . . . . lvDynamic Workload Console の新しいウェルカム・ページ. . . . . . . . . . . . . . lvIBM Workload Scheduler の分析 . . . . . . lvワークロードのモニター . . . . . . . . . lvi重要な情報を一目でモニターできるダッシュボード . . . . . . . . . . . . . . . . lvi

クーロン・ジョブと Windows タスク・スケジューラー・ジョブのインポート . . . . . . lviiApplication Lab . . . . . . . . . . . lviiTivoli Common Reporting レポート . . . . lvii変数テーブル内における変数の迅速かつ簡単な位置特定 . . . . . . . . . . . . . . lviiiデータベースでジョブ終了時刻が追跡され、Dynamic Workload Console からジョブ終了時刻を表示できる . . . . . . . . . . . lviii作動不可 (NOP) としてのジョブの定義 . . . lviii動的ワークステーション上の SAP イベントの管理 . . . . . . . . . . . . . . . lviiiその他の Dynamic Workload Console 機能拡張 lix

第 1 章 IBM Workload Automation の概要 . . . . . . . . . . . . . . . . . 1最新技術によるソリューション . . . . . . . . 1

包括的なワークロード計画 . . . . . . . . . 2集中システム管理 . . . . . . . . . . . . 2システム管理の統合 . . . . . . . . . . . 2自動化 . . . . . . . . . . . . . . . 6ワークロードのモニター . . . . . . . . . 7自動ワークロード・リカバリー . . . . . . . 7生産性 . . . . . . . . . . . . . . . 7

業務のソリューション . . . . . . . . . . . 8ユーザーの生産性 . . . . . . . . . . . . . 8生産性向上の誘因 . . . . . . . . . . . . . 8IBM Workload Automation がスタッフに利点をもたらす仕組み . . . . . . . . . . . . . . . 8

スケジューリング・マネージャーのフォーカル・ポイントとしての役割 . . . . . . . . . . . 9操作マネージャーの役割 . . . . . . . . . 9シフト・スーパーバイザーのための強力なツール 10アプリケーション・プログラマーの役割 . . . . 10コンソール・オペレーター . . . . . . . . 10ワークステーション・オペレーター . . . . . 10エンド・ユーザーとサービス・デスク . . . . 11

要約 . . . . . . . . . . . . . . . . . 11

第 2 章 IBM Workload Automation および ITUP . . . . . . . . . . . . . 13ITUP プロセス . . . . . . . . . . . . . 13サービスの実行およびワークロード管理 . . . . . 14IBM Workload Automation を使用したワークロード管理 . . . . . . . . . . . . . . . . 14

第 3 章 ワークロード管理の実行者 . . . 17

第 4 章 業務シナリオ. . . . . . . . . 19会社 . . . . . . . . . . . . . . . . . 19課題 . . . . . . . . . . . . . . . . . 21ソリューション . . . . . . . . . . . . . 23

毎日実行する標準シナリオ . . . . . . . . 27利点 . . . . . . . . . . . . . . . . . 32

iv IBM Workload Automation: 概要

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

|||||||||||||||||||||

第 5 章 IBM Workload Scheduler . . . 35概要 . . . . . . . . . . . . . . . . . 35

IBM Workload Scheduler とは. . . . . . . 35IBM Workload Scheduler ネットワーク. . . . 35マネージャーおよびエージェントのタイプ . . . 37トポロジー . . . . . . . . . . . . . 39ネットワーキング . . . . . . . . . . . 39IBM Workload Scheduler のコンポーネント . . 41IBM Workload Scheduler スケジューリング・オブジェクト . . . . . . . . . . . . . 42実動プロセス . . . . . . . . . . . . . 46

スケジューリング . . . . . . . . . . . . 47スケジューリング・オブジェクトの定義 . . . . 47ジョブ・ストリームの作成 . . . . . . . . 47ジョブのリカバリーの設定 . . . . . . . . 47主幹業務であるジョブの定義と管理 . . . . . 48ワークロードの動的なスケジューリング . . . . 49

実動の実行 . . . . . . . . . . . . . . 50計画の実行 . . . . . . . . . . . . . 50ジョブ・ストリームの実行 . . . . . . . . 52モニター . . . . . . . . . . . . . . 52報告 . . . . . . . . . . . . . . . . 54監査 . . . . . . . . . . . . . . . . 54イベント・ドリブン・ワークロード自動化の使用 55

オプションおよびセキュリティー . . . . . . . 55IBM Workload Scheduler オプションの設定 . . 55セキュリティーの設定 . . . . . . . . . . 56時間帯の使用 . . . . . . . . . . . . . 58

IBM Workload Scheduler のアクセス方式の使用. . 58サポートされているエージェント . . . . . . 59

第 6 章 IBM Workload Scheduler forz/OS . . . . . . . . . . . . . . . . 61実動ワークロードを管理する方法 . . . . . . . 61

構造 . . . . . . . . . . . . . . . . 61概念 . . . . . . . . . . . . . . . . 62

IBM Workload Scheduler for z/OS での計画の使用 . . . . . . . . . . . . . . . . 66実動ワークロードの自動制御 . . . . . . . 67IBM Tivoli Monitoring との統合 . . . . . . 72他のプログラムとのインターフェース . . . . 73手動での制御と介入 . . . . . . . . . . 73クリティカル・ジョブの管理 . . . . . . . 75セキュリティー . . . . . . . . . . . . 76

IBM Workload Scheduler for z/OS の構成 . . . 78制御システム . . . . . . . . . . . . . 78制御される z/OS システム . . . . . . . . 79リモート・パネルおよびプログラム・インターフェース・アプリケーション . . . . . . . . 80IBM Workload Scheduler 内のジョブのスケジューリング . . . . . . . . . . . . . . 80

第 7 章 Dynamic Workload Console 83

第 8 章 エンドツーエンド・スケジューリング . . . . . . . . . . . . . . . . 85フォールト・トレランス機能付きのエンドツーエンド・スケジューリング . . . . . . . . . . . 85z-セントリック機能付きのエンドツーエンド・スケジューリング . . . . . . . . . . . . . . 87分散エージェント . . . . . . . . . . . . 88エンドツーエンド・スケジューリングの利点 . . . 89

第 9 章 ハイブリッド・スケジューリング環境 . . . . . . . . . . . . . . . . 91

特記事項 . . . . . . . . . . . . . . 93商標 . . . . . . . . . . . . . . . . . 95製品資料に関するご使用条件 . . . . . . . . 95

索引 . . . . . . . . . . . . . . . . 97

目次 v

vi IBM Workload Automation: 概要

図1. IBM Workload Scheduler for z/OS の統合シ

ナリオ。 . . . . . . . . . . . . . . 62. Fine Cola 社の統合ワークロード・ソリューシ

ョン . . . . . . . . . . . . . . . 233. IBM Workload Scheduler の動的スケジューリ

ング機能を使用することにより、ピーク期間中に SLA 応答時間の要件を満たす方法 . . . . 30

4. 2 つのドメインで構成される IBM WorkloadScheduler ネットワーク . . . . . . . . 36

5. サポートされているエージェント構成 . . . . 59

6. 自動リカバリーと再始動 . . . . . . . . 697. 実動ワークロードの再始動とホット・スタンバ

イ . . . . . . . . . . . . . . . . 718. セキュリティー . . . . . . . . . . . 769. IBM Workload Scheduler for z/OS の構成 79

10. フォールト・トレランス機能付きのエンドツーエンド構成 . . . . . . . . . . . . . 87

11. z-セントリック機能付きのエンドツーエンド構成 . . . . . . . . . . . . . . . . 88

vii

viii IBM Workload Automation: 概要

この資料について

IBM Workload Automation 製品スイートに関する情報については、本書を参照してください。

「IBM Workload Automation: 概要」では、IBM Workload Scheduler 製品のファミリーおよびそのエンタープライズ・ワークロード管理機能について説明します。以下の製品に関する入門情報を提供します。

v IBM Workload Scheduler

v IBM Workload Scheduler for z/OS

v Dynamic Workload Console

注: バージョン 9.3 では、製品ファミリー名が IBM Tivoli Workload Automationから IBM Workload Automation に変更され、製品名が IBM Tivoli WorkloadScheduler から IBM Workload Scheduler に変更されました。

当リリースでの新規機能このリリースでの新機能について説明します。

このリリースに含まれる新しい機能および変更された機能に関しては、 xiii ページの『機能拡張の要約』 を参照してください。

本書の対象読者この資料の対象読者について説明します。

本書の対象読者は、以下のような方です。

v データ処理 (DP) の運用管理者、およびこの製品を評価するか、またはそのスケジューリング・サービスを計画する技術アドバイザー

v この製品を評価、インストール、または使用するための一般情報を必要とする方

アクセシビリティアクセシビリティー機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるようにサポートします。

この製品では、支援機能を使用してインターフェースを聞き、ナビゲートできます。また、マウスの代わりにキーボードを使用してグラフィカル・ユーザー・インターフェースのすべての機能を操作することもできます。

詳細については、「IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンス」でアクセシビリティーに関する付録を参照してください。

ix

技術研修クラウド & スマーター・インフラストラクチャーでは技術研修を提供しています。

クラウド & スマーター・インフラストラクチャーの技術研修については、http://www.ibm.com/software/tivoli/education を参照してください。

サポート情報IBM では、問題が発生した場合にお客様がサポートを得るための複数の手段をご用意しています。

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

v 知識ベースの検索: 既知の問題と回避策、技術情報、およびその他の情報の大規模なコレクションを検索することができます。

v フィックスの入手: ご使用の製品について、既に使用可能な最新のフィックスを見つけることができます。

v IBM ソフトウェア・サポートへの連絡: 問題を解決することができず、IBM 担当者と協力して解決を図る必要がある場合は、IBM ソフトウェア・サポートとのさまざまな連絡方法が用意されています。

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

構文図の見方構文図は、構文をグラフィカルな方法で表示するのに役立ちます。

本書では、構文は以下のような構文図で示されています。以下の例は SRSTAT TSOコマンドの構文図です。

►► SRSTAT ' resource name 'OPCA

SUBSYS ( subsystem name )MSTR

►

►KEEP

AVAIL ( RESET )NOYES

KEEPDEVIATION ( amount )

RESET

►

►KEEP

QUANTITY ( amount )RESET

YESCREATE ( NO )

►

x IBM Workload Automation: 概要

►0

TRACE ( trace level )

►◄

記号の意味は以下のとおりです。

►►─────ステートメントはここから始まります。

──────►ステートメントは次の行に続きます。

►──────ステートメントは前行から続いています。

─────►◄ステートメントはここで終了します。

構文図は線のパスに沿って、左から右、上から下へと読みます。

構文図で使用される規則を以下に示します。

v 必須項目は水平線上 (メインパス) に記述します。

►► STATEMENT required item ►◄

v オプション項目は、メインパスの線よりも下に記述します。

►► STATEMENToptional item

►◄

v 項目の上に左向き戻り矢印がある場合は、その項目が繰り返し可能な項目であることを示します。項目間の区切り記号が必要なときは、繰り返し矢印の上に区切り記号を記述します。

►► STATEMENT ▼

,

repeatable item ►◄

v 2 つ以上の項目から選択する場合は、それらの項目を縦に重ねて記述します。

– 複数の項目から 1 項目を選択しなければならない場合には、縦に重ねた項目の 1 つをメインパス上に記述します。

►► STATEMENT required choice 1required choice 2

►◄

– 複数の項目から任意で 1 項目を選択する場合は、縦に重なった選択項目全体をメインパスの線よりも下に記述します。

►► STATEMENToptional choice 1optional choice 2

►◄

この資料について xi

– 重なり上の反復矢印は、重なっている項目から複数の項目を選択できることを示します。

►► STATEMENT ▼

,

optional choice 1optional choice 2optional choice 3

►◄

►► STATEMENT ▼

,

required choice 1required choice 2required choice 3

►◄

v メイン行よりも上にあるパラメーターは、デフォルトのパラメーターです。

►► STATEMENTdefault

alternative►◄

v キーワードは英大文字で表示されます (たとえば、STATEMENT)。

v 括弧およびコンマは、コマンド構文の一部として構文図に示されているとおりに入力しなければなりません。

v 複合コマンドでは、項目属性が 1 本の水平線では表せない場合があります。構文図中で線を分割することができない場合には、構文図の下に項目属性を記述します。

►► STATEMENT required choice 1option 1 option 2

required choice 2required choice 3

►◄

option 1

defaultoptional choice 1 ( alternative )

option 2

defaultoptional choice 2 ( alternative )

xii IBM Workload Automation: 概要

機能拡張の要約

IBM Workload Automation では、以下の機能拡張が行われています。

バージョン 9.4 フィックスパック 2『IBM Workload Scheduler バージョン 9.4 フィックスパック 2 の拡張機能』

バージョン 9.4 フィックスパック 1xvi ページの『IBM Workload Scheduler バージョン 9.4 フィックスパッ

ク 1 の拡張機能』

バージョン 9.4

v xxvii ページの『IBM Workload Scheduler バージョン 9.4 の機能拡張』

バージョン 9.3 フィックスパック 2

v xxxv ページの『IBM Workload Scheduler バージョン 9.3 フィックスパック 2 での機能拡張』

バージョン 9.3 フィックスパック 1

v xlii ページの『IBM Workload Scheduler バージョン 9.3 フィックスパック 1 の機能拡張』

バージョン 9.3

v xlvi ページの『IBM Workload Scheduler バージョン 9.3 の機能強化』

IBM Workload Scheduler バージョン 9.4 フィックスパック 2 の拡張機能

IBM Workload Scheduler バージョン 9.4 フィックスパック 2 の拡張機能について説明します。

IBM Workload Scheduler バージョン 9.4 フィックスパック 2 には、以下の拡張機能が含まれています。

v 『各種の価格設定モデル』

v xiv ページの『複数のジョブの再実行』

v xiv ページの『ロールバック手順』

v xv ページの『プールおよび動的プール内で実際に実行されたワークステーション』

v xv ページの『機能拡張要求 (RFE) への適合』

各種の価格設定モデルご使用の環境内のワークステーションでさまざまな価格設定モデルを簡単に定義します。

xiii

|

/

/

/

=

=

=

|

|

|

|

|

|

|

|

|

|

|

|

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

IBM® License Metric Tool は、お客様が所有する IBM Workload Scheduler ライセンスに応じたライセンスへの準拠を維持できるように支援します。License MetricTool を使用すると、ライセンス使用量を要約したレポートを生成できます。生成されたレポートは License Metric Tool サーバー上で維持されます。そのレポートは、定期的に検討し署名する必要があり、そのプロセスで監査目的の履歴が作成されます。サード・パーティーのソフトウェア・コンプライアンス監査員から、会社を訪問してソフトウェア監査を実施するという連絡を受けた場合は、すべてのレポートが最新版で、かつ署名入りであることを確認したうえで、監査員から要求された期間を対象としたレポートのコピーを提供します。

価格設定モデルを定義する際に、以前に増して優れた柔軟性を活用できるようになりました。適用する価格設定モデルを環境内のワークステーションごとに定義できます。

licenseType キーワードを optman の byWorkstation に設定すると、ワークステーションの作成時に、適用する価格設定モデルをワークステーションごとに定義できます。

ライセンス管理について詳しくは、「管理ガイド」のライセンス管理に関するセクションを参照してください。

複数のジョブの再実行複数のジョブを再実行します。個々のジョブごとに再実行アクションを確認する必要はありません。

Dynamic Workload Console から複数のジョブを選択し、そのすべてを 1 回のアクションで再実行できるようになりました。以前は、選択したジョブごとに確認ダイアログで再実行の確認が要求されていました。多数のジョブを再実行するときは、この確認に時間がかかります。この機能拡張により、確認ダイアログでは、再実行対象のすべてのジョブがリストされ、そのすべてのジョブの再実行の確認を求めるプロンプトが 1 回表示されます。

この新機能の副次作用は、ユーザー・インターフェースの即応性が向上し、応答時間が向上することです。よく使用するアクション (Dynamic Workload Console のモニター・ポートレットから優先順位または制限を設定するなど) がよりスムーズに実行されるように、更新されています。

ロールバック手順

マスター・ドメイン・マネージャーが IBM Installation Manager によってインストールされている場合に、マスター・ドメイン・マネージャーを前のフィックスパック・レベルまたはリリースにロールバックします。

マスター・ドメイン・マネージャーを前のフィックスパック・レベルまたはリリースにロールバックする場合、最初にバックアップを作成したうえで新しいフィックスパックまたはリリースをインストールする必要があります。これにより、そのフィックスパックまたはリリースをインストールした後にロールバック手順の実行が可能になります。

xiv IBM Workload Automation: 概要

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

この手順について詳しくは、「計画およびインストール」にあるマスター・ドメイン・マネージャーのロールバックに関するトピックを参照してください。

プールおよび動的プール内で実際に実行されたワークステーションプールまたは動的プールで実行されるようにスケジュールされたジョブが実際に実行されたワークステーションの名前。

プールまたは動的プールで実行されるようにジョブがスケジュールされている場合、ジョブまたはジョブが実行されたワークステーションのモニターが必要になることがあります。以前は、この情報はジョブ・ログでのみ取得できました。この機能拡張により、ジョブが実際に実行されたワークステーションの名前をジョブ・モニター照会内の新しい列でも確認できるようになりました。この詳細は、ジョブが開始済みまたは実行済みの場合に取得できます。この情報はレポートにも出力できます。

ライセンス使用量を判別する必要があるためにプール内でジョブが実際に実行されたワークステーションを知る必要があるときにも、この情報が役立つ可能性があります。

機能拡張要求 (RFE) への適合IBM Workload Scheduler は機能拡張要求 (RFE) を満たします。

機能拡張要求 (RFE) は、お客様が製品開発チームや他のユーザーと直接共同作業する機会を提供します。製品開発チームでは、お客様からの提案に基づいて製品の新機能に優先順位を付けて開発を進めます。

IBM Workload Scheduler V9.4 フィックスパック 2 では、以下の RFE を導入しています。

RFE 179819: データベース・ジョブ実行プログラムがストアード・プロシージャーのエラーを処理

データベース・ジョブ実行プログラムが強化され、ストアード・プロシージャーのエラーを処理するようになりました。

RFE 109287: 複数のジョブを再実行しても確認プロンプトは 1 回のみジョブのモニター時に選択された複数のジョブを再実行しても、すべてのジョブのアクションの確認は 1 回のみになりました。 xiv ページの『複数のジョブの再実行』を参照してください。

RFE 102143: スクリプト・パスのテキスト・フィールドを延長実行するスクリプトに関連するフィールドのサイズが長くなりました。スクリプトをタスクとして実行するジョブを定義する際に、そのスクリプトへのパスを指定するテキスト・フィールドに収容できるストリングが大幅に延長されました。例えば、パスが非常に長い場合やパスに多数の変数が含まれる場合、それらのパスは、Workload Designer と「ワークロード定義のリスト」ポートレットのどちらからジョブ定義を表示する場合でもテキスト・フィールドに表示されるようになりました。

IBM i 子ジョブに関するメッセージへの応答IBM i 親ジョブに関するメッセージへの応答のサポートは前回のリリースで導入されました。このリリースでは同じサポートが IBM i 子ジョブまで拡

機能拡張の要約 xv

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

張されています。IBM i ジョブがメッセージへの応答を待機して SUSP (中断) 状況にある場合、親ジョブのモニター時に Dynamic WorkloadConsole から親ジョブと子ジョブに関するメッセージに応答できます。

ジョブ・ストリーム・ビューへの実際の開始日の追加スケジュールされた開始日に加え、実際の開始日に関する情報が、分散エンジンと z/OS エンジンの両方の「ジョブ・ストリーム・ビュー」にあるジョブとジョブ・ストリームのツールチップに追加されました。

RFE 15616: ジョブのモニター時に実際のワークステーションを表示プールまたは動的プールで実行されるようにジョブがスケジュールされている場合、ジョブが開始済みまたは実行済みであれば、ジョブが実際に実行されたワークステーションの名前をモニターできます。 xv ページの『プールおよび動的プール内で実際に実行されたワークステーション』を参照してください。

RFE 108425: 既存ファイルに対するファイル・モニターのサポート通常、filemonitor ユーティリティーは初期スキャンを実行し、その後に、後続スキャンを行って新規ファイルまたは初期スキャン以降に変更されたファイルのうち、特定の基準を満たすものがあるか検出します。これは、初期スキャンの実行時には、基準を持たす既存ファイルがある場合でもそれらは検出対象にならないことを意味します。このユーティリティーが更新され、初期スキャンの実行時に基準を満たしている既存ファイルを検出してイベントを生成できるようにするための、新規パラメーターが追加されました。詳しくは、「ユーザーズ・ガイドおよびリファレンス」にある filemonitorユーティリティーの -generateEventsOnFirstScan 引数を参照してください。

RFE 106345: 同じネットワーク内で PJP ライセンス・ネットワークと PVU ライセンス・ネットワークを実行

ご使用の環境内のワークステーションでさまざまな価格設定モデルを簡単に定義します。詳しくは、「IBM Workload Scheduler 管理ガイド」にあるIBM License Metric Tool のライセンス管理に関するセクションを参照してください。

新規の RFE、計画済みの RFE、および提供済みの RFE の完全なリストを表示するには、RFE オンライン・コミュニティーを参照してください。

IBM Workload Scheduler バージョン 9.4 フィックスパック 1 の拡張機能

IBM Workload Scheduler バージョン 9.4 フィックスパック 1 の拡張機能について説明します。

IBM Workload Scheduler バージョン 9.4 フィックスパック 1 には、以下の拡張機能が含まれています。

v xvii ページの『グラフィカル・ビューの改良』

v xviii ページの『仮定分析の拡張機能』

v xix ページの『IBM Workload Scheduler ジョブ管理プラグイン』

v xix ページの『反復ワークフローの自動化』

xvi IBM Workload Automation: 概要

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

/

=

=

=

=

=

=

=

=

=

=

v xx ページの『再実行における柔軟性の向上』

v xxi ページの『IBM Workload Scheduler ジョブ・ストリームの実行依頼プラグイン』

v xxi ページの『条件ベースのワークロード・オートメーション』

v xxii ページの『filemonitor ユーティリティーを使用したファイル変更のモニター』

v xxii ページの『ジョブ・ストリーム内で最遅開始時刻を定義するための新しいキーワード』

v xxiii ページの『遅延ジョブに対するアクションを定義するための新しいキーワード』

v xxiii ページの『仮定分析のより高度な制御』

v xxiv ページの『動的エージェント用に Docker イメージを準備してインストールする』

v xxiv ページの『バージョン 8.6.x からのアップグレード』

v xxv ページの『ワークロード・アプリケーションを管理するための新しいオプション』

v xxvi ページの『IBM UrbanCode Deploy との統合』

v xxvi ページの『機能拡張要求 (RFE) への適合』

グラフィカル・ビューの改良データベース・オブジェクトのグラフィカル・ビューの拡張機能が計画にまで拡張され、一貫性のあるビューとユーザー・エクスペリエンスが実現しました。

グラフィカルビュー (ジョブ・ストリーム・ビュー、実動前計画ビュー、計画ビューの表示、モデリング・グラフィカル・ビュー) 全体での一貫性のあるビューとユーザー・エクスペリエンスの改善

オブジェクトを容易に識別できるシンプルな形状が使用され、対話を改善しアクションを素早く識別するための新規アイコンが作成され、オブジェクトの視覚化を向上させる新しい色と背景が用意されています。

インパクト・ビューとジョブ・ストリーム・ビューのマージにより、モニター・アクションとリカバリー・アクションに関するより包括的なビューを提供

以前のリリースでは、インパクト・ビューとジョブ・ストリーム・ビューは、計画内のジョブ・ストリームの進行状況をモニターする別々のビューとして提供されていました。このリリースでは、インパクト・ビューとジョブ・ストリーム・ビューがマージされ、1 つのビューとして提供されます。このビューでは、1 つ以上のジョブ・ストリーム、ジョブ、依存関係の分析、さらにジョブ・ストリームとそのジョブが計画の残りの部分に与える可能性がある影響の分析が可能です。また、ジョブ・ストリームとそのジョブが計画の残りの部分に与える可能性がある影響についても、分析できるようになりました。このビューは、分散環境と z/OS 環境の両方で使用することができます。

ジョブ・ストリーム・ビューの自動最新表示以前のリリースでは、計画に影響するアクションをこのビューで実行した場合に、「最新表示」オプションを使用して、手動でビューを最新表示する必要がありました。このリリースでは、ビューが自動的に最新表示されるた

機能拡張の要約 xvii

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

め、常に最新の情報が表示されるようになりました。ただし、自動最新表示がサポートされるのは、バージョン 9.4 フィックスパック 1 レベル以降のエンジンに接続している場合だけです。

一貫性のあるレイアウト分散環境の場合、Workload Designer のグラフィカル・ビューの柔軟なレイアウトにより、用途に応じた最適な方法でオブジェクトを位置変更できるようになりました。レイアウトを Workload Designer に保存すると、ジョブ・ストリーム・ビューで同じジョブ・ストリームを開いたときに、同じレイアウト (配置) が維持されます。

詳細については、「Dynamic Workload Console ユーザーズ・ガイド」で、計画内のグラフィカル・ビューに関するトピックを参照してください。

Workload Automation の YouTube チャンネルで公開されているビデオ『Dynamic Workload Console Graphical Views Revamped』および『EnsuringWorkload Automation operation continuity 24/7 』をご覧ください。専用再生リスト Workload Scheduler v9.4, Fix Pack 1 では、V9.4 FP1 で公開された機能に関するその他のビデオを視聴できます。

仮定分析の拡張機能フィックスパック 1 では、仮定分析のガント・ビューに関する各種の拡張機能を提供しています。

z/OS 環境の非クリティカル・ジョブで使用可能な仮定分析z/OS 環境内のクリティカル・ジョブで仮定分析を起動するだけでなく、クリティカル・ネットワークを構成する非クリティカル・ジョブで仮定分析を起動することもできるようになりました。

後続ジョブの表示をクリティカル・ジョブだけに制限することにより、クリティカル・ジョブへの影響を素早く評価

クリティカル・ジョブに対する影響だけを表示できるようになりました (他の後続ジョブは、すべて除外されます)。この方法で影響を表示すると、最も重要な影響だけが表示されるため、表示対象の後続ジョブが多数存在する場合のパフォーマンスが向上します。

先行ジョブをビューから除外する機能を使用してパフォーマンスを最適化新しいオプションである whatIfAutoLoadPreds が Tdwcglobalsettings.xmlファイルに追加され、先行ジョブを自動的にビューにロードするかどうかを指定できるようになりました。数百もの先行ジョブがある場合、パフォーマンスを最適化するために先行ジョブをビューから除外するようにします。デフォルト設定では、仮定分析のガント・ビューにすべての先行ジョブがロードされます。

最早開始時刻を、サーバーで計算された推定開始時刻に設定すべての先行がビューに表示されていない場合でも、ジョブの最早開始時刻に対する、先行の影響を検討できます。サーバーはジョブの推定開始時刻を計算します。「最早開始時刻をサーバー推定時刻に設定」という新しいアクションを使用すると、ジョブの最早開始時刻を、サーバーが推定開始時刻として計算した時刻に設定できます。

xviii IBM Workload Automation: 概要

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

仮定分析機能の詳細については、「Dynamic Workload Console ユーザーズ・ガイド」で、変更による環境への影響を分析する方法に関するトピックを参照してください。

IBM Workload Scheduler ジョブ管理プラグイン新しいジョブ管理プラグインを使用して、ジョブ・ストリーム内のジョブに対してアクションを実行することができます。

新しいジョブ管理プラグインは、自動化ユーティリティー・プラグイン・カテゴリーで使用することができます。自動化ユーティリティーは、IBM WorkloadScheduler の特定の操作を容易にするプラグインです。ジョブ管理プラグインを使用すると、ジョブ管理ジョブが稼働しているジョブ・ストリーム内の任意のジョブに対して、以下に示すいずれかのアクションを実行することができます。

表 1.

ジョブに対して実行できるアクション

v 再実行

v ジョブおよびそのすべての後続ジョブの再実行

v ジョブおよび同じジョブ・ストリーム内の後続ジョブの再実行

v 解放

v 依存関係の解放

v キャンセル

v 保留の取り消し

v 保留

v 強制終了

v ABEND の確認

v SUCC の確認

ジョブ管理プラグインを使用すると、リカバリー処理が簡素化され、反復ワークフローを自動化することができます。

詳細については、「IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンス」で、ジョブ管理ジョブに関するトピックを参照してください。

Workload Automation の YouTube チャンネルで公開されているビデオ『Automation of Iterative Workflows』を参照してください。

反復ワークフローの自動化特定の条件を満たしている場合、新しいジョブ管理プラグインを使用して、ジョブ・ストリーム内の一連のジョブを反復的に処理することができます。

複雑なワークフローの場合、オーケストレーション全体における一連のジョブを反復させることは難しい場合があります。同じジョブ・ストリーム内のすべての後続ジョブとともにジョブを再実行させるオプションを選択すると、特定の条件を満たしている場合に、ジョブ管理プラグインを使用して、一連のジョブを反復的に処理することができます。これは、プログラミング言語の DO WHILE ステートメントに類似しています。

機能拡張の要約 xix

=

=

=

=

=

=

=

=

=

=

=

==

=

=

=

=

=

=

=

=

=

=

=

==

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

そのために必要な作業は、反復させる一連のジョブの最後にジョブ管理ジョブを追加するという作業だけです。ジョブ管理ジョブにより、シーケンス内の最初のジョブをその後続ジョブとともに再実行するよう要求されます。反復は、シーケンス内の最初のジョブの出力条件によって制御され、その条件が満たされなくなったときに停止します。

詳細については、「IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンス」で、ジョブ管理ジョブに関するトピックを参照してください。

詳細なシナリオについては、Workload Automation の YouTube チャンネルで公開されているビデオ『Automation of Iterative Workflows』を参照してください。

再実行における柔軟性の向上失敗したジョブの新しいリカバリー・オプションと改善されたリカバリー・オプションを使用して、ワークロードの継続性を確保します。

新しい拡張再実行オプションによってワークフローをシームレスに調整することが可能となり、リカバリー・ロジックをジョブ定義自体に作成したり、「ワークロードのモニター」ビューから後続ジョブを直接再実行したりできます。

ジョブ定義の作成時に、ジョブが失敗した場合に特定の回数、特定の間隔の後に再実行することを指定できるようになりました。これにより、生成されるアラートが少なくなり、ワークフローの処理がスムーズに続行されます。 例えば、定期的に再始動されるサーバーに接続する必要があるジョブがある場合、ジョブを特定の回数、指定の間隔の後で再実行することをジョブ定義に指定できます。

親ジョブがプールまたは動的プールの一部であるワークステーションで実行されている場合、同じワークステーションと別のワークステーションのどちらで再実行する必要があるかを決定できます。これは、プールおよび動的プールのワークロードは複数の条件に基づいて動的に割り当てられ、ジョブは別のワークステーションで再実行される場合があるためです。

また、ジョブが失敗した場合に、その後続ジョブを一目で特定し、失敗したジョブを後続ジョブとともに再実行するかどうかを判断することができます。同じジョブ・ストリーム内のすべての後続ジョブ、または同じジョブ・ストリームおよび他のジョブ・ストリーム (ある場合) の両方のすべての後続ジョブ全体を再実行できます。

ジョブ定義内の再実行オプションをコマンド行から指定する方法については、「ユーザーズ・ガイドおよびリファレンス」で、ジョブの再実行アクションおよびリカバリー・アクションの定義に関するセクションを参照してください。ジョブ定義内の再実行オプションを Dynamic Workload Console から指定する方法については、「Dynamic Workload Console ユーザーズ・ガイド」で、ジョブ・リカバリー・アクションを使用してジョブ処理を制御する方法に関するセクションを参照してください。

コマンド行からジョブとその後続ジョブを再実行する方法について詳しくは、「ユーザーズ・ガイドおよびリファレンス」にある listsucc コマンドと rerunsucc コマンドに関するセクションを参照してください。

xx IBM Workload Automation: 概要

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

ワークフローをさらに自動化するには、ジョブ管理プラグインを使用します。このプラグインを使用すると、後続ジョブを含む再実行、後続ジョブを含まない再実行、その依存関係の解放、ジョブのキャンセルなど、多数のアクションをジョブに対して実行できます。 例えば、リカバリー・シナリオで、ワークフローにジョブ管理ジョブを挿入できます。 これにより、関連するリカバリー・ジョブが正常に完了したときに元のジョブが再実行されるため、労力と時間が削減されます。

この機能に関する詳しいビデオを視聴するには、Workload Automation のYouTube チャンネルで公開されているビデオ『Advanced Rerun Flexibility』をご覧ください。

IBM Workload Scheduler ジョブ・ストリームの実行依頼プラグイン

新しいジョブ・ストリームの実行依頼プラグインを使用して、ジョブ・ストリームの処理の実行依頼を自動化することができます。

新しいジョブ・ストリームの実行依頼プラグインは、自動化ユーティリティー・プラグイン・カテゴリーで使用することができます。自動化ユーティリティーは、IBM Workload Scheduler の特定の操作を容易にするプラグインです。ジョブ・ストリームの処理を実行依頼するには、ジョブ・ストリームの実行依頼プラグインを使用します。

ジョブ・ストリームの実行依頼プラグインをワークフローに追加することにより、特定のジョブ・ストリームの実行依頼を自動化することができます。これにより、コード・スクリプトに関する作業と手動による作業を最小化することができます。また、ジョブ・ストリームの最早開始時刻を指定したり、ジョブ・ストリームに関連付けられた変数テーブルを定義することもできます。

詳細については、「IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンス」で、ジョブ・ストリームの実行依頼ジョブに関するトピックを参照してください。

条件ベースのワークロード・オートメーション最適なタイミングでワークフローを開始させることができます。

条件ベースのワークロード・オートメーションにより、最適なタイミングで、素早く簡単にワークフローを開始することができます。ジョブ・ストリームに条件を定義し、その条件が満たされたときに、ジョブ・ストリームを解放してスケジュールどおりに実行させることができます。

例えば、1 つ以上のファイルを分析するジョブが含まれたジョブ・ストリームがある場合、1 つ以上のファイルが変更または作成された後にのみジョブ・ストリームを開始させることができます。また、データベース内のデータを処理するジョブが含まれたジョブ・ストリームの場合、十分な行がデータベースに書き込まれた後でそのジョブ・ストリームが開始されるようにすることができます。 また、条件が満たされたかどうかを IBM Workload Scheduler に繰り返しチェックさせることもできます。

以下のいずれかの条件に基づいて、ワークフローを開始できます。

機能拡張の要約 xxi

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

v 1 つ以上のファイルが作成された

v 1 つ以上のファイルが変更された

v 出力条件が満たされた状態でジョブが完了した。このロジックを、ジョブ・ストリームまたはジョブ・ストリーム内の特定のジョブに適用できます。

詳細については、「ユーザーズ・ガイドおよびリファレンス」で、条件ベースのワークフロー自動化に関するセクションを参照してください。

この拡張機能による利点の詳しい説明については、Workload Automation のYouTube チャンネルで公開されているマーケティング用のビデオとハウツー・ビデオでも参照することができます。

filemonitor ユーティリティーを使用したファイル変更のモニター使いやすいユーティリティー・コマンドを使用してファイルの変更をモニターします。

filemonitor ユーティリティーを使用して、ファイルが変更されたかどうか (ファイルの作成または変更) を確認することができます。これが役に立つのは、例えば、ファイルを処理するジョブを実行する前にそのファイルが存在することを確認する必要がある場合などです。filemonitor ユーティリティーを実行するジョブを定義することにより、ファイルの依存関係を実装することができます。ファイルの依存関係とは、ファイルに対する特定の活動によって操作の開始が決定される、ファイルと操作の関係です。

Workload Designer 内または composer コマンド行から、単独のコマンドとしてfilemonitor ユーティリティーを使用するか、あるいはジョブ・ストリームの開始条件の追加パラメーターとして filemonitor キーワードを設定できます。開始条件の詳細については、「ユーザーズ・ガイドおよびリファレンス」で、条件ベースのワークフロー自動化に関するセクションを参照してください。

詳細については、「ユーザーズ・ガイドおよびリファレンス」で、filemonitor に関するセクションを参照してください。

このリリースの新機能に関する包括的なビデオ・ライブラリーについては、Workload Automation の YouTube チャンネルで公開されている WorkloadScheduler バージョン 9.4 フィックスパック 1 の再生リストを参照してください。

ジョブ・ストリーム内で最遅開始時刻を定義するための新しいキーワード

ジョブ・ストリームの最遅開始時刻をより効率的に管理することができます。

jsuntil キーワードは、ジョブ・ストリームの最遅開始時刻を定義します。また、ジョブ・ストリームがその最遅開始時刻に近づいたときのジョブ・ストリーム内のジョブの動作を決定します。jsuntil キーワードを使用して、ジョブ・ストリームがその最遅開始時刻の直前に開始した場合にそのジョブ・ストリームが抑止、キャンセル、または続行するように設定 (onuntil キーワードで指定されているアクションに応じて) されることを回避します。例えば、jsuntil が午前 10 時に設定されたジョブ・ストリームがあり、そのうちの 1 つのジョブが午前 9 時 59 分に実行開始された場合でも、そのジョブと後続はスケジュールどおりに実行されます。

xxii IBM Workload Automation: 概要

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

このキーワードは、until キーワードと相互に排他的です。

また、until キーワードと jsuntil キーワードには、次のような大きな違いがあります。

ジョブ・ストリーム定義内に until キーワードを指定する場合このキーワードは、ジョブ・ストリームが開始された後も評価されます。その結果、ジョブ・ストリームが正常に完了する前に最遅開始時刻が経過した場合、関連する onuntil キーワードで指定されているアクションが、まだ開始されていないジョブ・ストリームおよびそのジョブで実行されます。

ジョブ・ストリーム定義内に jsuntil キーワードを指定する場合このキーワードは、ジョブ・ストリームのすべての依存関係が満たされて、ジョブ・ストリームの状態が READY に変更された直後に 1 回だけ評価されます。jsuntil キーワードを使用して定義された最遅開始時刻の期限がこの時点で切れていない場合、このキーワードがこれ以上評価されることはなく、ジョブ・ストリームはキーワードに関係なく実行されます。ただし、ジョブ・ストリームが無期限に READY 状態のままにならないようにするため、jsuntil キーワードに指定された時刻の期限が切れてから 2 日後に、ジョブ・ストリームはデフォルトで抑止されます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」の jsuntil キーワードに関するセクションを参照してください。

遅延ジョブに対するアクションを定義するための新しいキーワードジョブ・ストリーム内のジョブの締切をより効率的に管理することができます。

onlate キーワードは、ジョブの締切が過ぎたときにジョブ・ストリーム内のジョブに対して実行するアクションを定義します。締切が過ぎた時点でジョブが実行されている場合、そのジョブは強制終了されます。 強制終了されたジョブは ABEND状態で終了します。強制終了されたジョブに依存しているジョブまたはジョブ・ストリームは解放されません。 ジョブの依存関係が、ABEND 状態で完了するジョブの条件依存関係である場合、その依存関係は解放されます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」の onlate キーワードに関するセクションを参照してください。

仮定分析のより高度な制御管理者は、新しいグローバル・オプション optman を使用して、ご使用の環境で仮定分析機能を任意指定にすることができます。

新しいグローバル・オプション optman の導入により、管理者による仮定分析の制御レベルが強化されました。optman enWhatIf | wi グローバル・オプションを noに設定することにより、管理者は仮定分析機能を一元的に無効にすることができます。環境内では、仮定分析機能はデフォルトで有効になっており、変更が最新計画に及ぼす影響をシミュレートし、評価します。変更内容を有効にするには、「JnextPlan」を実行する必要があります。

詳細については、「Dynamic Workload Console ユーザーズ・ガイド」で、使用環境に及ぼす変更の影響を分析する方法についてのトピックを参照してください。

機能拡張の要約 xxiii

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

enWhatIf | wi グローバル・オプションと、主幹業務ジョブとその先行ジョブの特権処理を有効または無効にする enWorkloadServiceAssurance | wa グローバル・オプションの相互作用については、「管理ガイド」で、仮定分析を無効にする方法に関するトピックを参照してください。

動的エージェント用に Docker イメージを準備してインストールする

新しい動的エージェントを素早く簡単にプロビジョニングします。

Docker コンテナーにより、実行中の動的エージェントと、それを実行するために必要なコード、ランタイム、システム・ツール、システム・ライブラリー、および設定をインストールするタスクを自動化することができます。

Docker コンテナーは、Dockerfile と呼ばれるメカニズムを提供します。このメカニズムを使用して、動的エージェントをインストールして構成するステップをコーディングします。これは、インストールおよび構成のすべてのステップを実行するコマンドの標準セットを使用するプレーン・テキスト・ファイルです。結果として作成される Docker イメージは、正確に構成された、動的エージェント用の完全なソフトウェア・セットの静的イメージです。

その後、イメージが作成されて Docker コンテナーになります。Docker コンテナーは、専用のプロセス、状態、および構成を持つソフトウェアの固有の実行インスタンスです。特定のイメージから、必要な数の Docker コンテナーを開始することができます。これにより、専用のプロセス、状態、および構成を持つ各ソフトウェアの複数の実行インスタンスを、素早く簡単にプロビジョニングすることができます。

詳細については、「ユーザーズ・ガイドおよびリファレンス」で、動的エージェント用に Docker イメージを準備してインストールする方法に関するセクションを参照してください。

この機能に関する詳しいビデオを視聴するには、Workload Automation のYouTube チャンネルで公開されているビデオ『Docker Agent for WorkloadScheduler』をご覧ください。

バージョン 8.6.x からのアップグレード旧バージョンからのアップグレードをサポートします。

IBM Workload Scheduler V9.4 の一般出荷版では、V9.x からのアップグレードがサポートされていました。今回のフィックスパックでは、サポートが V8.6.x インスタンスに拡張されています。

IBM Workload Scheduler V8.6.x インスタンスの場合、マスター・ドメイン・マネージャーのアップグレードは、並列アップグレード方式を使用する場合にのみサポートされます。 IBM Workload Scheduler V8.6.x インスタンスでは直接アップグレードはサポートされません。V8.6.x のマスター・ドメイン・マネージャーのアップグレードでサポートされる唯一のシナリオは、バックアップとして構成された新規マスター・ドメイン・マネージャーをインストールする方法です。

xxiv IBM Workload Automation: 概要

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

Dynamic Workload Console の V8.6.x の単一インスタンスのアップグレードは、バックレベルがインストールされているものと同じワークステーション上の異なるディレクトリー内、または新規ワークステーション上で行うことができます。

Dynamic Workload Console の V8.6.x インスタンスが同じディレクトリー内に 1つ以上のコンポーネントとともにインストールされている場合、DynamicWorkload Console を新規ディレクトリー内でアップグレードしてから、古いバージョンをアンインストールする必要があります。追加のコンポーネントは、V8.6 レベルのままにすることも、V9.4 にアップグレードすることもできます。

注:

V9.1、V9.2、または V9.3 から V9.4.x にアップグレードする場合、1 回のステップで最新のフィックスパック・レベルに直接アップグレードできます (最初に V9.4.0にアップグレードする必要はありません)。詳しくは、フィックスパックのREADME ファイルを参照してください。

ワークロード・アプリケーションを管理するための新しいオプション

ご使用の環境でより柔軟にワークロード・アプリケーションを管理するための新しいオプションが導入されました。

以下の新しいオプションが導入されました。

ジョブ・ストリーム定義をワークロード・アプリケーション・テンプレートとしてエクスポートする

Workload Designer からジョブ・ストリーム定義をエクスポートし、ワークロード・アプリケーション・テンプレートとして圧縮ファイルに保存することができます。その後、そのジョブ・ストリーム定義を別の環境にインポートできます。

詳細については、「Dynamic Workload Console ユーザーズ・ガイド」で、ワークロード・アプリケーション・テンプレートとしてジョブ・ストリーム定義をエクスポートする方法に関するトピックを参照してください。

インポート・プロセス中にワークロード・アプリケーションを名前変更する新しいパラメーター -workloadApplicationName<workload_application_name> を wappman -import コマンドで指定すると、インポート・プロセス中にワークロード・アプリケーションを名前変更できます。ワークロード・アプリケーションを Dynamic WorkloadConsole からインポートする場合にも同様のオプションを使用できます。

詳細については、「ユーザーズ・ガイドおよびリファレンス」で、wappman コマンドに関するトピックを参照してください。

正規表現を使用して定義されたルールに従いマッピング・ファイルを変更するオプションで、エクスポート・プロセスによって生成されたマッピング・ファイルを、正規表現を使用して定義され、随時ファイルに指定されたルールに従って、インポート・プロセスで自動的に変更するように要求することができます。

機能拡張の要約 xxv

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

詳細については、「ユーザーズ・ガイドおよびリファレンス」で、正規表現を使用してマッピング・ファイルを変更する方法に関するトピックを参照してください。

IBM UrbanCode Deploy との統合IBM UrbanCode Deploy との新しい統合機能を使用して、アプリケーションのデプロイメントを効率化することができます。

ワークロード・アプリケーションを作成してエクスポートすることにより、ワークロード・アプリケーションを他の IBM Workload Scheduler 環境にインポートすることができます。

ワークロード・アプリケーションのインポートとエクスポートを行うには、Dynamic Workload Console または wappman コマンド行を使用します。

インポート処理の代わりに、IBM UrbanCode Deploy ツールの WorkloadAutomation プラグインを使用して、特定の環境から別の環境へのアプリケーションのデプロイメントを自動化することができます。再使用可能なテンプレートの定義を利用することで、IBM UrbanCode Deploy との統合によってアプリケーションとその関連の全スケジューリング・オブジェクトのデプロイメントが簡素化されます。このプラグインに詳細については、IBM UrbanCode Deploy の資料を参照してください。

このリリースの新機能に関する包括的なビデオ・ライブラリーについては、Workload Automation の YouTube チャンネルで公開されている WorkloadScheduler バージョン 9.4 フィックスパック 1 の再生リストを参照してください。

機能拡張要求 (RFE) への適合IBM Workload Scheduler は機能拡張要求 (RFE) を満たします。

機能拡張要求 (RFE) は、お客様が製品開発チームや他のユーザーと直接共同作業する機会を提供します。製品開発チームでは、お客様からの提案に基づいて製品の新機能に優先順位を付けて開発を進めます。

IBM Workload Scheduler V9.4 フィックスパック 1 では、以下の RFE を導入しています。

RFE 17980ジョブ・ストリームの特定のジョブからジョブ・ストリームを再始動できるようになりました。(内部 ID 57221)

RFE 25295特定のジョブとそのすべての後続ジョブを、同じジョブ・ストリーム内と他のジョブ・ストリーム内の両方で再実行できるようになりました。詳細については、「ユーザーズ・ガイドおよびリファレンス」で、条件ベースのワークフロー自動化に関するセクションを参照してください。(内部 ID 65671)

RFE 33200グラフィカルな計画ビューから外部の依存関係を作成できるようになりました。(内部 ID 79752)

xxvi IBM Workload Automation: 概要

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

RFE 44226「ジョブのモニター」パネルの EDIT JCL にコピー・ボタンが必要になりました。(内部 ID 99136)

RFE 46521ジョブのリカバリー・オプションが向上しました。(内部 ID 103418)

RFE 65873Dynamic Workload Console でのテーブルにおける選択動作が変更されました。右クリック操作またはツールバーを使用して、テーブル内で選択した項目に対してアクションを実行する場合、アクションの実行が完了すると選択項目がクリアされるため、別の項目を選択して別のアクションを実行することができます。また、テーブル内で複数の項目を選択し、それらすべての項目に対して同じアクションを実行することもできます。(内部 ID 125267)

RFE 69212プール内のジョブを再実行する際に、オプションで、以前に実行されたのと同じワークステーションでそのジョブを再実行できるようになりました。詳細については、「ユーザーズ・ガイドおよびリファレンス」で、条件ベースのワークフロー自動化に関するセクションを参照してください。(内部 ID130343)

RFE 78682複数のエンジンでジョブをモニターするときに、追加の列が使用可能になりました。(内部 ID 144976)

RFE 80759更新時にハイパーリンクされたプロパティーが Dynamic WorkloadConsole で自動最新表示されるようになりました。(内部 ID 146988)

RFE 101904Dynamic Workload Console Workload Designer の検索オプションが改善され、キーワードを入力する前にオブジェクトを選択できるようになりました。これにより、選択したオブジェクトに対して検索を実行することができます。 (内部 ID 172565)

RFE 101905Dynamic Workload Console Workload Designer の検索フィールドにユーザー支援機能が追加され、検索フィールドで使用可能な構文例が表示されるようになりました。 (内部 ID 172564)

RFE 104082Dynamic Workload Console で Internet Explorer の互換表示が無効になりました。(内部 ID 175746)

新規の RFE、計画済みの RFE、および提供済みの RFE の完全なリストを表示するには、RFE オンライン・コミュニティーを参照してください。

IBM Workload Scheduler バージョン 9.4 の機能拡張IBM Workload Scheduler バージョン 9.4 の機能拡張について説明します。

IBM Workload Scheduler バージョン 9.4 では、以下の機能拡張が行われています。

機能拡張の要約 xxvii

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

=

|

|

|

|

v 『スケジューリングの中断が最小のエージェント・アップグレード』

v xxix ページの『Cloudant 用の IBM Workload Scheduler プラグイン』

v xxix ページの『スケジューリング・オブジェクトに対する変更の追跡』

v xxx ページの『リリース管理の監査』

v xxxi ページの『バージョン管理』

v xxxii ページの『tws_env スクリプトのバックアップ・コピー』

v xxxii ページの『ServiceNow インシデントを開くための新しいイベント・ドリブン・ワークロード自動化アクション』

v xxxii ページの『IBM i ジョブ定義の機能拡張』

v xxxii ページの『ジョブ間での変数の引き渡し』

v xxxiii ページの『グラフィカル・ビューの機能拡張』

v xxxiii ページの『IBM Workload Scheduler REST API』

v xxxiv ページの『機能拡張要求 (RFE) への適合』

スケジューリングの中断が最小のエージェント・アップグレードジョブ・スケジューリングに対する影響を最小限に抑えてエージェントをアップグレードします。

エージェントのメンテナンスを計画する際に、めったにないアイドル時間枠をやりくりする必要はもはやありません。 アップグレード作業を最小限にする一方で、スケジューリングの継続性を確保する必要があります。アップグレードを慎重に計画しないと、スケジューリング・ダウン時間が長期化し、サービス・レベル・アグリーメントを満たせないリスクが発生します。

スケジューリングの中断が最小の IBM Workload Scheduler のエージェント・アップグレードでは、スケジューリング・アクティビティーへの影響を最小限にして、フォールト・トレラント・エージェント・インスタンスと動的エージェント・インスタンスの両方をアップグレードできます。エージェントが停止する時間は最小限に抑えられ、アップグレード・プロセス開始時に既に実行されているジョブはすべて予定どおりに実行が継続されますが、この短い停止期間の間、新規ジョブは実行を開始しません。アップグレードが完了すると、エージェントは再始動され、すぐにジョブと再接続します。アップグレード前にアクティブに実行中であったジョブでまだ完了していないものは、スケジュールに従って実行が継続され、実行が終了しているジョブは、通常どおり正常な状況を報告します。

これと同じ動作が、 conman や composer などのアクティブなエージェントのコマンド・ライン・インターフェースおよびプロセスにも適用されます。エージェントのアップグレード後、すべてのプロセスおよびコマンド・ライン・インターフェースは再開し、通常の実行を継続します。

アップグレード・プロセス全体は信頼性が高く、フェイルセーフです。また、障害時に備えて自動バックアップおよびリストア機能があります。アップグレード・プロセスはわずか数分ですべて完了します。

xxviii IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

重要: スケジューリングの中断が最小のエージェント・アップグレードは、バージョン 9.x のフォールト・トレラント・エージェント・インスタンスおよび動的エージェント・インスタンスのアップグレードでのみサポートされています。

中断が最小のエージェント・アップグレードについては、計画およびインストールでエージェントのアップグレードに関するトピックを参照してください。

Workload Automation の YouTube チャンネルで公開されているビデオ『Agentupgrade with minimal scheduling disruption』を参照してください。

Cloudant 用の IBM Workload Scheduler プラグインCloudant 用の新しい IBM Workload Scheduler プラグインを使用すると、IBMCloudant NoSQL データベースとその文書および添付ファイルに対するアクションの実行をスケジュール、モニター、および制御できます。

IBM Cloudant NoSQL データベース用の IBM Workload Scheduler プラグインを使用すると、以下のアクションをスケジュール、モニター、および制御できます。

v Cloudant データベースの作成、読み取り、および削除

v Cloudant データベース複製の開始とモニター

v Cloudant データベース文書の作成、読み取り、更新、および削除

v Cloudant データベース添付ファイルの作成、読み取り、更新、および削除

この統合から多くの利点を得ることができます。以下に例を示します。

v 時間ベースまたはイベント・ベースでデータベース複製をスケジュールおよびモニターできます。1 つのジョブから別のジョブに渡される変数の値 (データベースのサイズなど) に基づいて、データベース複製の条件依存関係を設定することもできます。

v Dynamic Workload Console または Application Lab から Cloudant 操作をモニターおよび制御することができ、障害が発生した場合に再始動することもできます。

v Cloudant アプリケーションにより生成される日次ログを、文書または文書添付ファイルとして Cloudant データベースに自動的にアップロードできます。

v Cloudant のワークロードのバランスを取り、残りのプロセス・フローと統合することができます。

このプラグインは、オンプレミス、オンクラウド (SaaS)、および Bluemix プラットフォームの IBM Workload Scheduler で使用可能です。

詳しくは、「IBM Workload Automation を使用したアプリケーションのスケジューリング」で Cloudant ジョブの定義に関するセクションを参照してください。

スケジューリング・オブジェクトに対する変更の追跡環境内のスケジューリング・オブジェクトに対するすべての変更を監査用に詳細に追跡します。

複雑なスケジューリング環境の維持および管理は困難な作業です。複数のスケジュール担当者、オペレーター、および管理者がジョブ・フローへのアクセス権限を持っており、変更を行う可能性があります。この作業の複雑さにかかわらず、実装さ

機能拡張の要約 xxix

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

れるすべての変更の記録を維持する必要があります。IBM Workload Scheduler を使用すると、すべての変更内容を簡単に追跡し、Tivoli Common Reporting との統合により数回のクリックで詳細レポートを入手できます。

オプションで、管理者は、オブジェクトに対する変更を行う各ユーザーに変更の理由を入力させるポリシーを強制できます。

管理者は監査証跡を保守できます。この監査証跡には、変更されたすべての項目について、変更を行ったユーザー、変更が行われた日時、変更がインプリメントされた理由、および、変更の詳細な情報が含まれます。

IBM Workload Scheduler の管理者、オペレーターおよびスケジューラーは、Dynamic Workload Console から、データベースと計画の両方におけるスケジューリング・オブジェクトに対するすべての変更を確認して、特定の変更を実行したユーザーと、変更が実行された日時を検出することができます。

スケジューラーは、いつでも特定のオブジェクトに対するすべての変更の履歴を確認して、スケジューリング言語でオブジェクトの以前のバージョンを調べることができます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で変更の追跡についてのセクションを参照してください。

詳細および詳しいビジネス・シナリオについては、『Stay in control of yourworkload』のビデオで説明されています。

この新機能により、デフォルトの optman 設定に次の 3 つの変更が加えられています。

auditStoreマスター・ドメイン・マネージャーを以前のリリースからアップグレードすると、このグローバル・オプションのデフォルト値が変更されます。デフォルト値は both になりました。以前のリリースでデフォルト値をカスタマイズしていた場合、DB 値が割り当てられている auditStore オプションを除いて、この新しい値により値が上書きされます。auditStore オプションがDB に設定されていた場合は、その値が保持され、上書きされません。

enDbAuditマスター・ドメイン・マネージャーを以前のリリースからアップグレードすると、このグローバル・オプションのデフォルト値が変更されます。デフォルト値は 1 になりました。以前のリリースでデフォルト値をカスタマイズしていた場合、この新しい値により値が上書きされます。

enPlanAuditマスター・ドメイン・マネージャーを以前のリリースからアップグレードすると、このグローバル・オプションのデフォルト値が変更されます。デフォルト値は 1 になりました。以前のリリースでデフォルト値をカスタマイズしていた場合、この新しい値により値が上書きされます。

リリース管理の監査リリース管理プロセスを監査することにより、変更が常に一貫性を保ち、同じ品質レベルで提供されるようになります。

xxx IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

アプリケーションやビジネス・プロセスの開発、テスト、実稼働環境へのプロモーションを自動化およびスケジューリングし、問題が発生した場合には以前のバージョンにロールバックできます。変更を実動に移す際は、通常、開発、テスト、修正というさまざまなサイクルを経由します。また、これを行うためにさまざまな環境を経由しますが、すべての環境が同一とは限りません。ここでは、バージョン管理が極めて重要になります。テスト環境および実稼働環境のさまざまなバージョンを追跡することは、競合を回避するうえで重要です。単純で、しかも変更を一貫した信頼できる方法で実動に移すことができるリリース管理プロセスが必要です。

IBM Workload Scheduler を使用すると、ワークロード・アプリケーション・テンプレートを作成してエクスポートすることにより、変更をある環境から別の環境にプロモートできます。ワークロード・アプリケーション・テンプレートは、1 つ以上のジョブ・ストリームおよびそれに含まれるすべての関連ジョブ (依存関係、ファイル、リソース、カレンダー、実行サイクル・グループ、プロンプトなど) を含む圧縮ファイルです。さまざまな環境間でジョブ・フローを複製するこの容易な方法を使用すると、開発、テスト、および実稼働環境へのプロモーションを自動化およびスケジュールすることは単純で簡単です。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で変更の追跡についてのセクションを参照してください。

ワークロード・アプリケーション・テンプレートの定義について詳しくは、「ユーザーズ・ガイドおよびリファレンス」を参照してください。

詳細および詳しいビジネス・シナリオについては、『Streamline your releasemanagement process』のビデオで説明されています。

バージョン管理スケジューリング環境の変更を完全に管理します。

ソフトウェア・ソース・コードの変更を追跡および管理するために、バージョン管理が最もよく使用されます。ただし、変更管理および監査の要件を満たすために、特定のアプリケーションに関連するジョブやジョブ・ストリームなどのスケジューリング・オブジェクトにもバージョン管理を適用する必要があります。

IBM Workload Scheduler は、バージョン管理をサポートする最新のワークロード・オートメーション・ソリューションです。IBM Workload Scheduler は、スケジューリング・オブジェクトのすべてのバージョンをデータベースに維持するため、それらに Dynamic Workload Console から簡単にアクセスできます。スケジューリング・オブジェクトごとに、変更履歴を表示し、特定の変更を実行したユーザー、変更のタイム・スタンプ、および変更の理由を確認できます。その後、比較ビューアーで異なる 2 つのバージョンを比較し、前のバージョンを復元できます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で変更の追跡についてのセクションを参照してください。

詳しいビジネス・シナリオについては、ビデオ『Version Control』を参照してください。

機能拡張の要約 xxxi

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

tws_env スクリプトのバックアップ・コピーエージェントまたはマスター・ドメイン・マネージャーをアップグレードする際に、tws_env スクリプトのバックアップ・コピーが作成され、新しいスクリプトがインストールされます。

製品の新機能に対応するために、マスター・ドメイン・マネージャーおよびエージェントのアップグレード・インストール・プロセスにより、tws_env スクリプトの新規バージョンがディレクトリー <TWA_HOME>/TWS にインストールされます。ここで、<TWA_HOME> は IBM Workload Scheduler のインストール・ディレクトリーです。元のバージョンのバックアップ・コピーがバックアップ・ディレクトリーに作成されます。アップグレード・プロセスの後、新規バージョンの内容と元のバージョンの内容をマージし、カスタマイズ内容を新規バージョンに取り込んでください。

詳しくは、「計画およびインストール」で環境変数の設定について説明している『構成』のセクションを参照してください。

ServiceNow インシデントを開くための新しいイベント・ドリブン・ワークロード自動化アクション

IBM Workload Scheduler は、イベント・ドリブン・ワークロード自動化アクション Open Incident を提供します。このアクションは、ServiceNow と統合することにより使用可能になり、定義されているポリシーに一致するジョブがエラーで終了すると、インシデントのオープンを自動的にトリガーします。

Open Incident アクションについて詳しくは、「ユーザーズ・ガイドおよびリファレンス」の『アクション・プロバイダーと定義』セクションを参照してください。

IBM i ジョブ定義の機能拡張IBM i ジョブ定義が、SBMJOB コマンドを実行しているジョブ用に拡張されました。

SBMJOB コマンドを実行しているジョブの入力パラメーターの指定に関して、IBMi ジョブのジョブ定義が簡素化されました。入力パラメーターには、システム・ライブラリーに加えて、ユーザーが指定できるカスタム・ライブラリーが含まれます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で IBM i ジョブの定義に関するセクションを参照してください。

ジョブ間での変数の引き渡しIBM i ジョブ定義が、SBMJOB コマンドを実行しているジョブ用に拡張されました。

ジョブ間での変数の引き渡しを簡単に行えるようになりました。現在では、変数テーブルを使用して、ジョブからエクスポートされた変数を設定し、その変数を同じジョブ・ストリームまたは異なるジョブ・ストリーム内の後続ジョブに渡すことができます。

xxxii IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

変数をジョブから変数テーブルにエクスポートするには、IBM Workload Schedulerの随時ジョブ・タイプである VariableTable ジョブ・タイプを使用できます。VariableTable ジョブは、変数をエクスポートしているジョブの後続ジョブとしてジョブ・ストリームに追加する必要があります。VariableTable ジョブはエクスポートされた変数を変数テーブルで設定し、同じジョブ・ストリームまたは異なるジョブ・ストリーム内の他の後続ジョブがその変数を使用できるようにします。

Dynamic Workload Console または composer コマンド行を使用することにより、VariableTable ジョブを容易に定義できます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で変数テーブルを使用した変数の引き渡しに関するセクションを参照してください。

グラフィカル・ビューの機能拡張新規グラフィカル・ビューは、最新の UX 設計方針を使用してリリースされました。

新規グラフィカル・ビューは、最新の UX 設計方針を使用してリリースされました。

グラフィカル・ビューが再設計され、ユーザー・エクスペリエンス (UX) が強化されました。 新しい設計では、ユーザーがタスクを簡単かつ効率的に完了できるようにしています。オブジェクトを容易に識別できるシンプルな形状が使用され、対話を改善しアクションを素早く識別するための新規アイコンが作成され、オブジェクトの視覚化を向上させる新しい色と背景が用意されています。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」でグラフィカル・ビューに関するセクションを参照してください。

IBM Workload Scheduler REST APIIBM Workload Scheduler REST API により、ワークロード・スケジューリング機能と外部の製品やソリューションを簡単に統合することができます。

IBM Workload Scheduler には、完全に機能する一連の API が付属しています。これらの API は、Representational State Transfer (REST) サービスに基づいて実装されます。REST API を使用すると、ワークロード・スケジューリング機能を、外部の製品やソリューションに簡単に統合することができます。既存の J2EE APIで提供されているものと同じ製品機能が、REST API でも使用できます。 RESTAPI はプログラミング言語から独立しており、ネットワーク構成およびファイアウォール・トラバーサルを簡素化します。 この API により、異機種混合環境を活用し、生産性に直接影響を与える新しいオートメーションの機会を実現することができます。

REST API の詳細、および REST API を Swagger 文書で試す方法については、「IBM Workload Automation 開発者ガイド: IBM Workload Automation の活用」で、REST API を使用した IBM Workload Scheduler の活用に関するトピックを参照してください。

機能拡張の要約 xxxiii

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

機能拡張要求 (RFE) への適合IBM Workload Scheduler は機能拡張要求 (RFE) を満たします。

機能拡張要求 (RFE) は、お客様が製品開発チームや他のユーザーと直接共同作業する機会を提供します。製品開発チームでは、お客様からの提案に基づいて製品の新機能に優先順位を付けて開発を進めます。

IBM Workload Scheduler V9.4 は、多数の RFE を提供しています。以下に挙げるのはその一例です。

v RFE 56898: 2 つの重要な変更が変数テーブルに導入されました。1 つ目の変更では、変数名と変数値の文字長に対応しています。長さがそれぞれ 64 文字と1024 文字に拡張されました。2 つ目の変更では、動的エージェントのファイル依存関係を定義する際に、静的ファイル名の代わりに変数を使用できるようになりました。変数は、ファイルが置かれているワークステーションの変数テーブルで定義され、後で解決されます。これにより、ファイル名を計画内で動的かつより柔軟に使用できるようになりました。

v RFE 73944: ジョブ・ログは、失敗に終わった動的エージェントのジョブの開始時刻と終了時刻に関する情報が付加されることで内容が強化されました。

v RFE 109970: ジョブ・ログは、ジョブが失敗したユーザーのユーザー ID に関する情報が付加されることで内容が強化されました。

v RFE 162189: 動的エージェントのジョブ・ログには FTA と同じ形式のタイム・スタンプが表示されるようになりました。

v RFE 81886: changePassword コマンドに、db ユーザー・パスワードの更新をスキップするための新規パラメーター -skipdbuser が設けられました。

v RFE 162160: Dynamic Workload Console V9.3 を AIX V7.2 にインストールできるようになりました。

v RFE 133854: IBM Workload Scheduler は、エージェント・アップグレードの最適な時間枠を識別します。この RFE には、スケジューリングの中断が最小のエージェント・アップグレードの新機能で対応します。

v RFE 125642、RFE 79392: IBM Workload Scheduler で、Workload Designerのグラフィカル・ビューでジョブおよびジョブ・ストリームを表示する際の柔軟性が向上しています。

v RFE 79391: Workload Designer のグラフィカル・ビューは、ジョブおよびジョブ・ストリームの検索機能が追加されることで強化されました。

v RFE 76136: データベースに保管された監査情報のタイム・スタンプに、秒および 100 分の 1 秒の単位が表示されるようになりました。

v RFE 79395: ユーザーは、計画で変更されたジョブおよびジョブ・ストリームについてのメモを入力できるようになりました。

v RFE 108197: IBM Workload Scheduler は、スケジューリング・オブジェクトの定義に関する変更バージョン管理を提供しています。

v RFE 126406: Dynamic Workload Console は、最新計画に対するすべての重要なアクションに関するメッセージを表示します。

v RFE 141427: Workload Designer でごみ箱を使用できるようになりました。

xxxiv IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v RFE 156327: ワークロード・アプリケーション・テンプレートには、テンプレートに含まれているワークステーションおよびジョブ・ストリームのイベント・ルールも含まれるようになりました。

v RFE 156524: ジョブがリソースを必要としなくなったときに、進行中のジョブに割り当てられているリソースを制御するための機能が追加されました。

新規の RFE、計画済みの RFE、および提供済みの RFE の完全なリストを表示するには、RFE オンライン・コミュニティーを参照してください。

IBM Workload Scheduler バージョン 9.3 フィックスパック 2 での機能拡張

IBM Workload Scheduler バージョン 9.3 フィックスパック 2 での機能拡張について説明します。

IBM Workload Scheduler バージョン 9.3 フィックスパック 2 では、次の機能拡張が行われています。

v 『DB2 および Oracle のデータベース・スキーマを更新する新しい方法』.

v xxxvi ページの『ハイブリッド・ワークロード・オートメーション』

v xxxvii ページの『サイレント・インストールの実行前の前提条件の検査』

v xxxvii ページの『IBM Workload Scheduler インスタンスの自動初期設定』

v xxxviii ページの『IBM Workload Scheduler の役割ベースのセキュリティーの定義と管理』

v xxxviii ページの『IBM i ジョブのメッセージへの Dynamic WorkloadConsole からの応答』

v xxxviii ページの『IBM i ジョブに対する待機メッセージへの自動応答』

v xxxix ページの『IBM Workload Scheduler plug-in for Apache Oozie』

v xxxix ページの『ジョブの完了時のスクリプトの実行』

DB2 および Oracle のデータベース・スキーマを更新する新しい方法

A new mechanism to update or upgrade the database schema製品のアップグレードやフィックスパックの更新のためにデータベース・スキーマを更新またはアップグレードする新しい手段により、DB2® クライアントが必要なくなり、全般的に、動的で信頼性が高く柔軟な方法が提供されます。

マスター・ドメイン・マネージャーとそのバックアップ、または動的ドメイン・マネージャーとそのバックアップを作成、アップグレード、または更新するときは、データベース表を作成、アップグレード、または更新する必要があります。

環境内の IBM Workload Scheduler コンポーネントを更新する前に、標準的に手動でデータベース表を更新する場合、SQL ファイル内に必要な SQL ステートメントを迅速に生成し、オプションで、それらのステートメントを単一のステップでデータベースに直接適用するスクリプトを含むこの新しい方法を使用できます。

この新しい更新方法の利点は次のとおりです。

機能拡張の要約 xxxv

|

|

|

|

|

|

|

v 単一のスクリプトにより、SQL ステートメントを動的に生成し、それらのステートメントをデータベースに直接適用します。オプションで、生成のみを行うようにスクリプトを構成し、後で製品コンポーネントのインストール前に適用することもできます。

v スクリプトは、実行間のクリーンアップなしに、必要に応じて何度でも実行および再実行できます。例えば、何らかの理由でデータベース・オブジェクトが破損した場合、スクリプトを再実行して、SQL ファイルを再生成し、適用できます。

v DB2 データベースについては、この方法により、リモートの DB2 サーバーに配置されているデータベースを更新するために DB2 クライアントをインストールする必要がなくなります。スクリプトは、JDBC ドライバーを使用し、データベース・サーバーに直接接続して動作するため、データベース・クライアントのインストールと保守の労力が最小限に抑えられます。

v この方法をスタンドアロン・ツールとして使用して、データベース・スキーマの整合性を検査できます。データベース管理者は、データベース・スキーマが変更されたかどうかを検査し、不整合を修復できます。

Installation Manager ウィザードとサイレント・インストール方法のいずれかを使用して製品コンポーネントをインストール、更新、またはアップグレードすると、同じ方法を使用してデータベース表が自動的にアップグレードされます。

詳しくは、「IBM Workload Scheduler: 計画およびインストール」で、データベース表を作成および更新する方法に関するセクションを参照してください。

ハイブリッド・ワークロード・オートメーションワークロード・オートメーションをオンクラウドまたはオンプレミスで管理するか、両方の組み合わせを選択します。ハイブリッド・ワークロード・オートメーションでは、共通のユーザー・インターフェースを使用して、オンプレミスとオンクラウドの両方のエンジンを管理できます。

ワークロード・オートメーションをオンクラウドまたはオンプレミスで管理するか、両方の組み合わせを選択します。ハイブリッド・ワークロード・オートメーションでは、共通のユーザー・インターフェースを使用して、オンプレミスとオンクラウドの両方のエンジンを管理できます。オブジェクト (ジョブ、クリティカル・ジョブ、ワークステーション、リソース、プロンプト、ジョブ・ストリーム、ファイル、およびドメイン) について、計画内でモニターし、アクションを実行できます。

オンプレミス環境で効率的に管理されていたのと同じワークロードをクラウド環境で実行するようにスケジュールできます。単純なインポート手順を使用して、オンプレミス環境から Workload Automation on Cloud にワークロードを転送できます。ワークロードはすぐに複製され、エージェントで使用できる状態になります。クラウド環境でワークロードを処理すると、オンプレミス・インフラストラクチャーに依存することなく、必要なときにのみ、クラウド内のリソースを費用対効果の高い方法で使用できます。

Workload Automation on Cloud は、IT インフラストラクチャーのコストを削減し、ワークロードを実行するビジネス・ニーズがあるときにのみ、リソースを使用するためのソリューションです。

xxxvi IBM Workload Automation: 概要

詳しくは、「概説」で、ハイブリッド・スケジューリング環境に関するセクションを参照してください。

サイレント・インストールの実行前の前提条件の検査マスター・ドメイン・マネージャーや Dynamic Workload Console をインストールするには、サイレント・インストールを開始する前に、前提条件検査スクリプトを実行することで、遅延や混乱なしにインストールが正常に実行されるようにします。

サイレント・インストール方法はユーザー介入を必要としない無人インストールですが、システム要件の欠落や不足によってインストールが一時停止にならないように、インストールの開始前にスクリプトを実行して、製品のシステム要件を検査できるようになりました。

前提条件検査スクリプトは、マスター・ドメイン・マネージャーと DynamicWorkload Console のインストールに使用でき、次のような要件を検査します。

v サポートされるオペレーティング・システム。

v 十分な RAM。

v 十分なスワップ・ファイル・スペース。

v スクリプトへの入力として渡されるインストール・ディレクトリーと一時ディレクトリーの作成用のディスク・スペース。

詳しくは、IBM Workload Scheduler バージョン 9.3 フィックスパック 2 のreadme ファイル、および Dynamic Workload Console バージョン 9.3 フィックスパック 2 の readme ファイルで、サイレント・インストールに関するセクションを参照してください。

製品のシステム要件について詳しくは、製品の readme ファイルで、ディスク・スペース要件に関するセクションを参照してください。

IBM Workload Scheduler インスタンスの自動初期設定デフォルトの初期化システムとして systemd を使用する Linux ディストリビューションについては、始動時の IBM Workload Scheduler インスタンスの自動的な初期化をサポートするサンプルのサービス・ファイルが用意されています。

デフォルトの初期化システムとして systemd を使用する Linux ディストリビューション (RedHat Enterprise Linux v7.0、SUSE Linux Enterprise Server V12 など)については、始動時の IBM Workload Scheduler インスタンスの自動的な初期化をサポートするように既に構成されているサンプルのサービス・ファイルが用意されています。

詳しくは、「IBM Workload Scheduler の管理」で、IBM Workload Scheduler インスタンスを自動的に初期化する方法に関するセクションを参照してください。

機能拡張の要約 xxxvii

IBM Workload Scheduler の役割ベースのセキュリティーの定義と管理

Dynamic Workload Console の「ワークロード・セキュリティーの管理」インターフェース、または composer コマンド行プログラムを使用することで、役割ベースのセキュリティー・モデルに従って、セキュリティー・ファイルを定義および更新できます。

役割ベースのセキュリティー・モデルを使用すると、マスター・ドメイン・マネージャー・データベースに定義しているセキュリティー・オブジェクトでセキュリティー・ファイル を迅速かつ簡単な方法で更新できます。 optmanenRoleBasedSecurityFileCreation グローバル・オプションを yes に設定して、役割ベースのセキュリティー・モデルを有効にします。

役割ベースのセキュリティー・モデルに従って定義できるセキュリティー・オブジェクトは次のとおりです。

セキュリティー役割各役割は、特定の許可レベルを表し、ユーザーまたはグループが実行できる一連のアクションを含んでいます。

セキュリティー・ドメイン各ドメインは、ユーザーまたはグループが管理できる一連のスケジューリング・オブジェクトを表します。

アクセス制御リスト各アクセス制御リストは、特定のセキュリティー・ドメイン上でセキュリティー役割をユーザーまたはグループに割り当てるように定義されます。

マスター・ドメイン・マネージャーでセキュリティー・ファイルを更新すると、マスター・ドメイン・マネージャーのセキュリティー設定は、バックアップ・マスター・ドメイン・マネージャーに自動的に同期されます。

詳しくは、「管理ガイド」で、セキュリティーの概要に関するセクションを参照してください。

IBM i ジョブのメッセージへの Dynamic Workload Console からの応答

IBM i ジョブのメッセージに Dynamic Workload Console から応答できます。

IBM i ジョブがメッセージへの応答を待機して SUSP (中断状態) 状況にあるときに、Dynamic Workload Console の「ワークロードのモニター」から直接、メッセージに応答できます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で、IBM i システムでのスケジューリング方法に関するセクションを参照してください。

IBM i ジョブに対する待機メッセージへの自動応答IBM i ジョブに対する待機メッセージへの応答を自動化する標準ルールを定義できます。

xxxviii IBM Workload Automation: 概要

IBM i ジョブを定義するときに、Dynamic Workload Console または composer コマンド行を使用することで、自動応答のセットアップ対象のメッセージのリストを指定できます。出力ジョブ・ログに、IBM i システムによってキューに入れられたメッセージと、ジョブによって自動的に送信された応答が表示されます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で、IBM i ジョブのジョブ定義に関するセクションを参照してください。

IBM Workload Scheduler plug-in for Apache Oozie新しい IBM Workload Scheduler plug-in for Apache Oozie を使用すると、Oozie ワークフローおよび Hadoop ジョブ (Hive、MapReduce、Pig、Sqoop など) のスケジュール、モニター、および制御を実行できます。

Hadoop の採用が拡大するにつれて、Hadoop ジョブのボリュームと複雑さが増大しています。Hadoop ジョブの実行を最適化するために、さまざまな Hadoop ジョブをワークフローと呼ばれる単一の作業論理単位にまとめることができます。Apache Oozie は、Hadoop ジョブの複雑なワークフローの作成と管理を行う強力なツールです。ただし、Oozie ワークフローを、ビジネス・プロセス・フローの残りの部分と統合することが重要です。新しい plug-in for Oozie を使用すると、Hadoop 環境に対する会社のワークロードの中央管理機能が拡張されて、他の IBMWorkload Scheduler ジョブと同様にワークフローおよび Hadoop ジョブを管理できます。

IBM Workload Scheduler Plug-in for Apache Oozie。

ジョブの完了時のスクリプトの実行ジョブが完了したときに、そのジョブ完了に関連する情報を使用して、スクリプトを実行できます。

多くのシナリオでは、ジョブが完了すると、ジョブの完了に関連する情報を使用して、1 つ以上のアクションを実行します。このために、スクリプト・ファイルを記述し、それをエージェントのファイル・システムのディレクトリーに格納できます。このスクリプトは、正常に実行されるかどうかに関係なく、ジョブが完了するたびに実行されます。このスクリプトは、ジョブを実行するエージェント・ユーザーと同じ資格情報で実行されます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」でジョブ完了時のスクリプトの実行に関するセクションを参照してください。

新しい向上した Web インターフェースWorkload Designer と Dynamic Workload Console のインターフェースが向上しました。

Workload Designer は完全に再設計されて、ユーザー・エクスペリエンスが向上しました。新しいインターフェースには、1 クリックのみでメインタスクを開始することができるウェルカム・ページが用意されています。Dynamic WorkloadConsole のウェルカム・ページで同様の機能を使用できます。これにより、IBMWorkload Scheduler のすべての Web インターフェースにアクセスするための単一のエントリー・ポイントが提供されます。

機能拡張の要約 xxxix

詳しくは、「ユーザーズ・ガイドおよびリファレンス」でユーザー・インターフェースに関するセクション、「Dynamic Workload Console ユーザーズ・ガイド」でワークロードの設計方法に関するセクションを参照してください。

コンテキストに合わせて計画ビューを起動する URL の作成コンテキストに合わせて計画ビューを起動する URL を作成できます。

Dynamic Workload Console を起動し、それを計画ビュー内で直接開く URL を作成できます。次に、この URL を外部アプリケーションに含めることで、例えば、計画ビューへの迅速で簡単なアクセスを実行できます。

詳しくは、「IBM Workload Scheduler 管理ガイド」で、コンテキストに合わせて計画ビューを起動する URL を作成する方法に関するセクションを参照してください。

RFE 84003 - グラフィカル・ビューのエクスポート時のスタイルの変更

グラフィカル・ビューに対してカスタムのスタイル・シートを定義できます。

カスタム・スタイル・シートを定義して、グラフィカル・ビューで使用するスタイル (例えば、背景色、リンクの色、オブジェクトの色) を変更できます。変更は、グラフィカル・ビューのエクスポート時に適用されます。

注: V9.4 フィックスパック 1 で新しく再設計されたグラフィカル・ビューを実装すると、この機能は使用できなくなります。

RFE 75635 - 幅広モニターに対応するグラフィカル・ビュー拡張幅広モニターにグラフィカル・ビューを表示できます。

複雑なジョブ・ストリームも見やすくするために、幅広モニターにグラフィカル・ビューを表示できます。

ワークステーション名とユーザー ID のオートコンプリートワークステーション名とユーザー ID について、オートコンプリートを利用できるようになりました。

Workload Designer のジョブ定義で、ワークステーション名とユーザー ID について、オートコンプリートを利用できるようになりました。

Dynamic Workload Console を使用したワークロード・セキュリティーの管理

Dynamic Workload Console を使用して、ご使用の環境のセキュリティー設定を迅速かつ簡単に管理できます。

ナビゲーション・ツールバー ->「管理」->「ワークロード環境の設計」で、「ワークロード・セキュリティーの管理」を選択します。ここで、データベース内のセキュリティー・オブジェクトを作成および管理できます。

xl IBM Workload Automation: 概要

=

=

役割ベースのセキュリティー・モデルに従って定義できるセキュリティー・オブジェクトは次のとおりです。

セキュリティー役割各役割は、特定の許可レベルを表し、ユーザーまたはグループが実行できる一連のアクションを含んでいます。

セキュリティー・ドメイン各ドメインは、ユーザーまたはグループが管理できる一連のスケジューリング・オブジェクトを表します。

アクセス制御リスト各アクセス制御リストは、特定のセキュリティー・ドメイン上でセキュリティー役割をユーザーまたはグループに割り当てるように定義されます。

ツールチップとオンライン・ヘルプは、セキュリティー・タスクの遂行中に役立ちます。

マスター・ドメイン・マネージャーでセキュリティー・ファイルを更新すると、マスター・ドメイン・マネージャーのセキュリティー設定は、バックアップ・マスター・ドメイン・マネージャーに自動的に同期されます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で、ワークロード・セキュリティーの管理方法に関するセクションを参照してください

障害点からの Informatica PowerCenter ジョブの再始動障害点から Informatica PowerCenter ジョブを再始動できます。

Dynamic Workload Console から Informatica PowerCenter ジョブをモニターしているときに、Informatica PowerCenter ワークフローに関する詳細情報を表示し、ワークフロー、またはワークフロー内の任意の第 1 レベル・タスク (そのタスクがセッションまたはワークレットである場合) に対してアクションを実行できます。

Informatica PowerCenter ワークフローに障害が発生した場合、障害が発生したタスクからそのワークフローを再始動できます。

詳しくは、「IBM Workload Automation を使用したアプリケーションのスケジューリング」で、Informatica PowerCenter ジョブのモニター方法に関するセクションを参照してください。

シングル・エントリ・ポイントシングル・エントリ・ポイント を使用することで、すべてのユーザー・インターフェースにアクセスできます。

シングル・エントリ・ポイント は、IBM Workload Scheduler のすべてのユーザー・インターフェースにアクセスするための Web ベースのページです。

シングル・エントリ・ポイント は、安全な HTTPS 経由で Web ブラウザー を使用することで、環境内の任意のコンピューターからアクセスできる役割ベースのインターフェースです。

機能拡張の要約 xli

詳しくは、「IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンス」で、Single Entry Point に関するセクションを参照してください。

MS SQL データベースに対して拡張された Tivoli CommonReporting レポート

Tivoli Common Reporting は、IBM WebSphere 用の Jazz for ServiceManagement 拡張機能のオプションの統合サービスであり、WebSphereApplication Server とともにインストールされます。

Tivoli Common Reporting には、IBM Cognos のポータルとして機能する Webユーザー・インターフェースが用意されていて、このユーザー・インターフェースを使用して、IBM Workload Scheduler レポートの管理、実行、カスタマイズ、および作成を行うことができます。

これまでは、レポートは IBM® DB2 データベースに対してのみ使用できましたが、分散環境の Microsoft SQL Server データベースも含めるようにサポートが拡張されました。レポートには、次のようなものがあります。

v ジョブ実行ヒストリー

v ジョブ実行統計グラフ

v ジョブ実行統計テーブル

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で、Tivoli CommonReporting レポートに関するトピックを参照してください。

IBM Workload Scheduler バージョン 9.3 フィックスパック 1 の機能拡張

IBM Workload Scheduler バージョン 9.3 フィックスパック 1 の機能拡張について説明します。

IBM Workload Scheduler バージョン 9.3 フィックスパック 1 では、以下の機能拡張が行われています。

v xliii ページの『条件付き依存関係』

v xliii ページの『Liberty 用の IBM Workload Scheduler プラグイン』

v xliii ページの『MQTT 用の IBM Workload Scheduler プラグイン』

v xliv ページの『エージェント集中更新のスケジューリング』

v xliv ページの『WebSphere Application Server ツールの機能拡張』

v xliv ページの『IBM Tivoli Monitoring 統合の機能拡張: 状態のリファクタリングおよび新規ビューの関連付け』

v xlv ページの『IBM i の機能拡張』

xlii IBM Workload Automation: 概要

条件付き依存関係

条件付き依存関係を使用して、特定のジョブの状況や出力を評価し、指定した条件に基づいて、ジョブ・ストリーム内のどのジョブを実行するかを決定することができます。特定の条件が満たされた場合にのみ実行されるワークフローの分岐があることもあります。

ワークフロー内の 1 セグメントを実行するかどうかを決定する条件があるときは常に、それらは条件付き依存関係です。

条件付き依存関係は、強力かつ柔軟で、簡単に使用することができ、ワークフローを確実にスムーズに進行させるために役立ちます。

条件付き依存関係について詳しくは、「ユーザーズ・ガイドおよびリファレンス」で条件分岐ロジックの適用に関するセクションを参照してください。

Liberty 用の IBM Workload Scheduler プラグインJSR 352 Java Batch 用の新しい IBM Workload Scheduler プラグイン (Liberty 用のプラグイン) を使用して、Java Batch アプリケーションをスケジュール、実行、およびモニターし、それらをさらに複雑な複合バッチ・ワークフローに統合することができます。

バッチ処理は、長年にわたり情報技術の主要な部分となっています。このタイプの処理では、完了までに数時間から数日かかることがあり、実行中は大量のメモリーまたは処理能力を使用します。Java Batch も同じ問題を抱えています。このため、Java Batch の実行をエンタープライズ・スケジューラーでスケジュールおよび制御できるようにすることが重要です。JSR 352 Java Batch 用の IBM WorkloadScheduler プラグインを使用すると、WebSphere Liberty サーバーに接続し、JavaBatch アプリケーションを自動化し、制御することができます。

Liberty 用の IBM Workload Scheduler プラグインについて詳しくは、IBM TivoliWorkload Scheduler Plug-in for Liberty を参照してください。

MQTT 用の IBM Workload Scheduler プラグインIBM Workload Scheduler は、MQTT と統合して、IoT (モノのインターネット)デバイスの集中管理を提供します。MQTT は、パブリッシュ/サブスクライブ型の単純で軽量のメッセージ・プロトコルです。

MQTT は、ローカルのインテリジェント・デバイスがデータをパブリッシュし、アプリケーションからのコマンドを受け取ることができるようにします。MQTT 用のIBM Workload Scheduler プラグインを使用して、MQTT メッセージ・ブローカーに接続し、以下の操作を実行することができます。

v 使いやすい Web インターフェースを通じて、カレンダーおよびイベント・ベースのスケジューリング機能を使用して、デバイスをサブスクライブし、メッセージをパブリッシュし、コマンドを送信する。

v ゲートウェイ・エージェントを利用して、ハイブリッド・クラウド環境のセキュリティー準拠性を確保する。

機能拡張の要約 xliii

v 分析ツールと統合して、デバイス関連データから、リアルタイム情報と予測的知見を抽出する。

MQTT 用の IBM Workload Scheduler プラグインについて詳しくは、IBM TivoliWorkload Scheduler Plug-in for MQTT を参照してください。

WebSphere Application Server ツールの機能拡張製品に付属する WebSphere Application Server ツール (wastools) のスクリプトを実行依頼するために必要な資格情報は、オプション・パラメーターになりました。

IBM Workload Scheduler に付属する WebSphere Application Server 管理スクリプト (WebSphere Application Server の開始および停止など) は、WebSphereApplication Server プロファイルのプロパティー・ディレクトリーにあるsoap.client.props ファイルを使用して、コマンド行でユーザー名と平文パスワードを指定する必要がないようにします。

追加されたセキュリティー保護に加えて、この機能拡張により、頻繁なパスワード変更に関連する保守コストが不要になります。ユーザー ID およびパスワードはオプションとなり、資格情報は soap.client.props ファイルから取得されます。ただし、soap.client.props ファイルが自動的にそれらの資格情報によってカスタマイズされるマスター・ドメイン・マネージャーのインストールの場合とは異なり、Dynamic Workload Console では、この機能拡張を使用できるようにするには、ユーザーが手動で資格情報によって soap.client.props ファイルをカスタマイズする必要があります。

詳しくは、「管理ガイド」で、アプリケーション・サーバーの開始と停止に関するセクションを参照してください。

エージェント集中更新のスケジューリングDynamic Workload Console または composer コマンド行を使用して、エージェントの集中更新ジョブを作成することにより、複数のエージェント・インスタンスの集中更新をスケジュールすることができます。

ジョブが実行されると、ジョブは、選択されたすべてのフォールト・トレラント・エージェント・インスタンスまたは動的エージェント・インスタンスの Updateagent 要求をマスター・ドメイン・マネージャーに転送してから完了します。

IBM Tivoli Monitoring 統合の機能拡張: 状態のリファクタリングおよび新規ビューの関連付け

このフィックスパックを適用すると、Tivoli Enterprise Portal コンソールで、新しい Tivoli Workload Scheduler ビューまたは任意のビュー内のデフォルトの状態を、支援を受けながら容易に作成できます。デフォルトの状態は、それぞれの重大度と共に、コンソール内のビューに関連付けられます。デフォルトの状態は、TivoliEnterprise Portal 上の任意の物理ビューまたは論理ビューに関連付けることができます。

xliv IBM Workload Automation: 概要

デフォルトの状態の作成および表示について詳しくは、「IBM Workload Scheduler他の製品との統合」でデフォルトの状態の作成に関するセクションを参照してください。

クーロン・ジョブと Windows タスク・スケジューラー・ジョブのインポート

Dynamic Workload Console を使用して、Crontab ファイルまたは Windows タスク・スケジューラー・ジョブを読み取り、それらを IBM Workload Scheduler オブジェクトに変換することができます。

ジョブは、元のジョブと同じ仕様でワークロードに追加されます。ジョブ・ストリームには、クーロン・コマンドまたは Windows タスク・スケジューラー・コマンドの時間定義が反映されます。また、これらは他のすべてのオブジェクトとともに、変更、スケジュール、およびモニターすることができます。1 つの中心的な場所からジョブを制御し、それらを複雑なスケジュールに従ってスケジュールすることができます。

Dynamic Workload Console を使用したクーロン・ジョブと Windows タスク・スケジューラー・ジョブのインポートについて詳しくは、クーロン・ジョブとWindows タスク・スケジューラー・ジョブのインポートを参照してください。

仮定分析による変更の計画への実装IBM Workload Scheduler の仮定分析は、アクティビティーを時系列で表示し、リアルタイムに一目で分かるように計画を視覚的に表現します。

実際の計画を実装する前に仮定分析を実行すると、予測される結果が一目で分かるように表示されます。事前にこの結果を参照することにより、計画の開始前に、潜在的なすべての問題を考慮して計画することができます。仮定分析で行った変更はすべて、実際の計画に対して「変更の適用」オプションを使用するまでは、シミュレーション目的でのみ適用されます。「変更の適用」オプションは、分散環境内でのみ使用することができます。z/OS 環境の場合、変更はシミュレート目的としてのみ行われます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で、変更による環境への影響の分析に関するセクションを参照してください。

IBM i の機能拡張Dynamic Workload Console および conman showjobs コマンド行を使用して、IBM i ジョブがメッセージへの応答を待機しているかどうかを確認できるようになりました。

メッセージ応答を待機している IBM i ジョブは、SUSP (中断) 状況にあります。この状況は、入力を待機している間にジョブが実行されていることを示します。入力を受け取ると、ジョブ状況は EXEC (実行中) に変わります。

応答を待機している IBM i ジョブ・メッセージを表示することもできます。メッセージ・テキストと応答は、対応する IBM Workload Scheduler ジョブ・ログに書き

機能拡張の要約 xlv

込まれ、IBM i ジョブが応答を待機している正確なメッセージを IBM WorkloadScheduler オペレーターが確認できるようになっています。

JobManager.ini ファイルのネイティブ・ジョブ・ランチャー・セクションにあるMonitorQueueName プロパティーを使用して、モニター・エージェント・コンポーネントが実行されるキューの名前を指定できます。このプロパティーを指定しなければ、デフォルトのキュー (QBATCH) が使用されます。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で IBM i システムでのジョブのスケジューリングに関するセクションを参照してください。

Dynamic Workload Console バージョン 9.3 フィックスパック1 のその他の機能拡張

Dynamic Workload Console バージョン 9.3 フィックスパック 1 のその他の機能拡張

Dynamic Workload Console バージョン 9.3 フィックスパック 1 では、以下の機能拡張も利用できるようになりました。

v ユーザーが列のサイズを永続的に設定できます。サイズ変更を行うたびに、Dynamic Workload Console は新しい列サイズを記憶し、同じ情報が表示されるときは常にそのサイズ変更を適用します。すなわち、列のサイズ変更は 1 度実行するだけでかまいません。

v グラフィカル・ビューの新しい機能拡張により、ジョブ依存関係が、依存されるジョブのより近くに描画されるようになりました。これにより、レイアウト全体が大きく改善され、複雑なジョブ・ストリームのグラフィカル・ビューが大幅に使いやすくなりました。さらに、ズーム能力が向上し、ジョブを表すボックスの寸法が、さらに長いジョブ名を表示できるように拡張されました。そのため印刷能力が向上しています。SVG にサード・パーティーのツールを使用する場合、ビュー全体をカスタマイズできるようになりました。オブジェクトを識別するために必要なすべての情報が使用可能であるためです。

IBM Workload Scheduler バージョン 9.3 の機能強化IBM Workload Scheduler バージョン 9.3 の機能強化について説明します。

IBM Workload Scheduler バージョン 9.3 では、以下の機能強化が行われています。

v xlvii ページの『IBM WebSphere MQ の IBM Workload Scheduler プラグイン』

v xlvii ページの『IBM Workload Scheduler Plug-in for RESTful Web サービス』

v xlviii ページの『IBM Workload Scheduler Plug-in for SAPBusinessObjects』

v xlviii ページの『Netezza Performance Server に対する IBM WorkloadScheduler サポート』

v xlix ページの『IBM Sterling Connect:Direct の IBM Workload Scheduler プラグイン』

xlvi IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v xlix ページの『IBM Workload Scheduler Plug-in for Salesforce』

v xlix ページの『IBM Workload Scheduler Plug-in for Hadoop』

v l ページの『IBM Workload Scheduler Plug-in for BigInsights for Hadoop』

v l ページの『IBM Workload Scheduler plug-in for Oracle E-Business Suite』

v l ページの『ファイル転送プラグインの機能拡張』

v li ページの『「繰り返し」オプションによるジョブ・ストリーム定義の拡張』

v li ページの『IBM Workload Scheduler を使用した SAP でのジョブ機能の拡張』

v liii ページの『Workload Automation の障害によるビジネスへの影響の遮断』

v liii ページの『動的エージェントのファイル依存関係サポート』

v liv ページの『中央制御エージェントの更新』

v liv ページの『基本製品に付属してインストールされるようになった IBMTivoli Workload Scheduler for Applications』

v lv ページの『ドメイン・ユーザーを使用したエージェントのインストール』

v lv ページの『その他の機能拡張』

IBM WebSphere MQ の IBM Workload Scheduler プラグインIBM WebSphere MQ の IBM Workload Scheduler プラグイン

メッセージとキューを使用してアプリケーション・プログラムが相互に通信できるようにするために IBM WebSphere MQ を使用します。個々のアプリケーションの代わりにジョブまたはアプリケーションのフローを実行する場合は、メッセージ・キューとの間でメッセージを送受信するアプリケーションにフローをリンクする必要があります。IBM Workload Scheduler とその IBM WebSphere MQ 用プラグインを使用すると複数の混合プロセスを管理でき、複数の自動バックグラウンド・ワークフローがメッセージ・キューを使用してリアルタイムでそのデータを同期します。

IBM WebSphere MQ ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler plug-in for IBM WebSphere MQ について詳しくは、「IBM Workload Scheduler Plug-in for WebSphere MQ」を参照してください。

IBM Workload Scheduler Plug-in for RESTful Web サービスIBM Workload Scheduler Plug-in for RESTful Web サービス

REST 設計モデルは、Web サービス開発用のより簡潔でリソース・ベースのインターフェース言語として Web 全体で幅広く受け入れられており、最も人気があるサービス・プロバイダーでこのほど採用されました。 この IBM Workload Schedulerプラグインを使用すると、HTTP メソッドを使用した RESTful Web サービスで、JSON、XML、XHTML などの任意の使用可能なコンテンツ・タイプでリソースやデータを追加、ダウンロード、削除、および変更するジョブをスケジュールすることができます。

機能拡張の要約 xlvii

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

RESTful Web サービス・ジョブの作成について詳しくは、ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for RESTful Web サービスについて詳しくは、『IBM Workload Scheduler plug-in for RESTful Web サービス』を参照してください。

IBM Workload Scheduler Plug-in for SAP BusinessObjectsIBM Workload Scheduler Plug-in for SAP BusinessObjects

IBM Workload Scheduler は SAP BusinessObjects と統合して、SAPBusinessObjects Business Intelligence レポートの作成を自動化およびモニターします。カレンダー・ベースとイベント・ベースの両方のワークロード自動化の使用により、SAP BusinessObjects レポート作成をより詳細に制御することができます。この統合により、SAP BusinessObjects やその他のすべての従属操作を中央の場所から管理およびモニターし、問題を自動的に検出し、リカバリー・アクションを適用することができます。これにより、妥当であり信頼できるデータに基づいた将来の戦略と意思決定を実現します。

SAP BusinessObjects ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for SAP BusinessObjects について詳しくは、『IBM Workload Scheduler plug-in for SAP BusinessObjects』を参照してください。

Netezza Performance Server に対する IBM WorkloadScheduler サポート

Netezza Performance Server に対する IBM Workload Scheduler サポート

ほとんどのデータウェアハウス環境のデータは、営業日の終わりに抽出、変換、およびロードされます。 しかし、さまざまなデータ・ソースと大量のデータを処理する場合は、データに最新の更新が確実に含まれるようにして、意思決定のための参照として役立つ有意義なレポートをユーザーが作成できるようにする必要があります。 IBM Workload Scheduler は、Netezza Performance Server をサポートするようになりました。これにより、事前操作が正常に実行されたときに大量のデータがロードされるのを調整できます。これにより、問題がユーザーに影響する前にその問題が検出されて解決されます。Netezza のサポートは、データベース・ジョブ・タイプに統合されました。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」でデータベース・プラグインに関するセクションを参照してください。

Netezza Performance Server との IBM Workload Scheduler 統合について詳しくは、『Netezza Performance Server に対する IBM Tivoli Workload Scheduler サポート』を参照してください。

xlviii IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

IBM Sterling Connect:Direct の IBM Workload Scheduler プラグイン

IBM Workload Scheduler Plug-in for IBM Sterling Connect:Direct は、すべての後続処理 (ファイルの暗号化解除、名前変更、構文解析、再送信など) が正常に実行されるように、ファイル転送プロセス全体を自動化します。 リアルタイムのモニター、レポート作成、イベント管理、および監査を手動で実行することもできます。

IBM Sterling Connect:Direct ジョブの作成について詳しくは、IBM WorkloadScheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for IBM Sterling Connect:Direct について詳しくは、『IBM Sterling ファイル転送』を参照してください。

IBM Workload Scheduler Plug-in for SalesforceIBM Workload Scheduler Plug-in for Salesforce

IBM Workload Scheduler は Salesforce と統合して、バッチ APEX ジョブを含むワークフローを自動化、モニター、および制御します。カレンダー・ベースのワークロード自動化およびイベント・ベースのワークロード自動化の両方の使用と、例外処理と自動化のための単一の制御ポイントにより、Salesforce ジョブをより詳細に制御することができます。

Salesforce ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for Salesforce について詳しくは、『IBM TivoliWorkload Scheduler Plug-in for Salesforce』を参照してください。

IBM Workload Scheduler Plug-in for HadoopIBM Workload Scheduler Plug-in for Hadoop

IBM Workload Scheduler は、Apache Hadoop バッチ処理を単純化および自動化するために、以下の 3 つの新規プラグインを提供します。

v Hadoop MapReduce プロシージャーの実行の定義、スケジューリング、モニター、制御を行うための Hadoop Mapreduce 用プラグイン。

v 任意のマシンから Hadoop 分散ファイル・システムにアクセスし、ファイルとディレクトリーで作業を行うための Hadoop 分散ファイル・システム用プラグイン。

v SQL に類似したインターフェースを Hadoop で使用するための Apache Hiveデータベース用プラグイン。

IBM Workload Scheduler は、Hadoop のプロセスを企業のその他のワークフローと統合することにより、ビッグデータの価値を最大限に高めます。

Hadoop Mapreduce ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

ビデオ・チュートリアル『IBM Workload Scheduler integration with HadoopMapReduce』も参照してください。

機能拡張の要約 xlix

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

Hadoop 分散ファイル・システム・ジョブの作成について詳しくは、IBM WorkloadScheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for BigInsights for HadoopIBM Workload Scheduler Plug-in for BigInsights for Hadoop

IBM Workload Scheduler を IBM BigInsights for Hadoop に統合することにより、Apache Hadoop の機能を企業内で活用することができます。IBM WorkloadScheduler plug-in for BigInsights for Hadoop を使用して、以下の処理を行うことができます。

v 新しいタイプのデータの情報を社内で検索できる BigInsights のワークブックとアプリケーションが含まれているワークフローのモニターと制御を行う。

v カレンダー・ベースとイベント・ベースのスケジューリング機能、および例外を処理するための単一の制御ポイントを使用して、BigInsights プロセス実行を完全に自動化し、リカバリー・プロセスを自動化する。

BigInsights for Hadoop ジョブの作成について詳しくは、IBM Workload Schedulerユーザーズ・ガイドおよびリファレンスを参照してください。

ビデオ・チュートリアル『IBM Workload Scheduler integration with BigInsightsfor Hadoop』も参照してください。

IBM Workload Scheduler plug-in for Oracle E-BusinessSuite

IBM Workload Scheduler plug-in for Oracle E-Business Suite

IBM Workload Scheduler plug-in for Oracle E-Business Suite は、OracleE-Business Suite のスケジューリング機能を拡張し、ビジネス・プロセス・チェーン全体の自動化を支援します。

Oracle E-Business Suite ジョブの管理について詳しくは、「IBM WorkloadAutomation を使用したアプリケーションのスケジューリング」を参照してください。

IBM Workload Scheduler plug-in for Oracle E-Business Suite について詳しくは、『IBM Workload Scheduler plug-in for Oracle E-Business Suite』を参照してください。

ファイル転送プラグインの機能拡張ファイル転送プラグインの機能拡張

ファイル転送用の IBM Workload Scheduler プラグインの機能が大幅に拡張され、いくつかの新しい機能が実装されました。

v ファイル名に対してワイルドカード (「*」および「?」) がサポートされるため、同じジョブを使用して複数のファイルを容易に転送できます。ジョブ・ログとジョブ・プロパティーの両方で、転送された各ファイルの名前、サイズ、および転送時間を表示できます。

l IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v SSH プロトコルの場合の証明書認証がサポートされるようになりました。リモート・サーバーでの認証のためにユーザー名およびパスワードを使用することなく鍵ストア・ファイルのパスを指定できます。

v ファイルをダウンロードするときにローカル・システムのユーザーに対するファイル・アクセス権を設定できるようになっています。

v ローカル・ソース・ファイルを転送後に自動的に削除するように要求できます。

ファイル転送ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

「繰り返し」オプションによるジョブ・ストリーム定義の拡張IBM Workload Scheduler ジョブ・ストリーム定義では以下の機能を使用できるようになりました。

v 「繰り返し頻度」オプションは、同じジョブ・ストリームの複数インスタンスが計画内で作成および実行されるときの繰り返しの頻度と、相関的な終了時刻を指定します。したがって、同じジョブ・ストリームの 1 つのインスタンスが一定期間にわたって数分または数時間ごとに実行されるように指定できます。 このオプションは、コンポーザーと Dynamic Workload Console の両方で使用可能であり、ジョブ・ストリームをスケジュールするのに使用された実行サイクル(または実行サイクル・グループ) で定義されます。

v Dynamic Workload Console のジョブ・ストリーム定義の「スケジューリング・オプション」ページにある新規の「アクション」タブでは、別のジョブ・ストリーム・インスタンスがまだ実行中のときに、開始しようとしているジョブ・ストリーム・インスタンスをスケジューラーがとにかく開始するか、キューに入れるか、廃棄するかを指定します。

コンポーザーでは、このフィーチャーは ONOVERLAP ジョブ・ストリーム定義キーワードによって実装されます。

「繰り返し」オプションによるジョブ・ストリーム定義の拡張について詳しくは、『「繰り返し」オプションによるジョブ・ストリーム定義の拡張』を参照してください。

IBM Workload Scheduler を使用した SAP でのジョブ機能の拡張

IBM Workload Scheduler を使用した SAP でのジョブ機能の拡張

SAP 環境の可視性、コントロール、および自動化を向上させるために、IBMWorkload Scheduler は、設計から実行と最適化に至るまで、ワークロードのライフサイクル全体を支援できます。SAP との長年の認定されたパートナーシップによって、IBM Workload Automation は、SAP 環境のプラクティスのガバナンス、SAP Solution Manager やその他のツールとのデータ統合など、SAP アプリケーションと SAP 以外のアプリケーションを管理およびモニターする単一の制御ポイントを提供することができます。R3batch プロセスは、最新の SAP NetWeaver RFCライブラリーで更新されています。

v xlviii ページの『IBM Workload Scheduler Plug-in for SAPBusinessObjects』

機能拡張の要約 li

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

v 『IBM Workload Scheduler を使用した SAP Solution Manager の機能強化』

v liii ページの『インストール済みの SAP トランスポートのバージョンを報告する RFC の追加』

v liii ページの『SAP アプリケーション・ログの処理』

IBM Workload Scheduler Plug-in for SAP BusinessObjectsIBM Workload Scheduler Plug-in for SAP BusinessObjects

IBM Workload Scheduler は SAP BusinessObjects と統合して、SAPBusinessObjects Business Intelligence レポートの作成を自動化およびモニターします。カレンダー・ベースとイベント・ベースの両方のワークロード自動化の使用により、SAP BusinessObjects レポート作成をより詳細に制御することができます。この統合により、SAP BusinessObjects やその他のすべての従属操作を中央の場所から管理およびモニターし、問題を自動的に検出し、リカバリー・アクションを適用することができます。これにより、妥当であり信頼できるデータに基づいた将来の戦略と意思決定を実現します。

SAP BusinessObjects ジョブの作成について詳しくは、IBM Workload Scheduler ユーザーズ・ガイドおよびリファレンスを参照してください。

IBM Workload Scheduler Plug-in for SAP BusinessObjects について詳しくは、『IBM Workload Scheduler plug-in for SAP BusinessObjects』を参照してください。

IBM Workload Scheduler を使用した SAP Solution Manager の機能強化IBM Workload Scheduler と SAP Solution Manager は統合されていて、SolutionManager ユーザー・インターフェースから使用できるジョブ・スケジューリング・タスクを実際に実行するエンジンは IBM Workload Scheduler になっています。この統合は、マスター・ドメイン・マネージャーで実行される SMSE アダプターによって実現されています。 SMSE アダプターは、SAP から提供されている SAPSolution Manager Scheduling Enabler (SMSE) インターフェースを使用して、外部スケジューラーが Solution Manager のスケジューリングを実行できるようにします。 この統合では、Solution Manager の「スケジューリング」パネルからジョブをスケジュールすると、IBM Workload Scheduler がジョブのトリガーと通知に加えて、ジョブ・スケジューリング、モニタリング、および管理の各タスクを担当します。 このような条件下で、IBM Workload Scheduler はジョブのスケジューリングのための共通インターフェースを持つ RFC サーバーとして動作します。これは、SMSE に登録されている RFC 宛先を通じて識別されます。

SAP Solution Manager からの IBM Workload Scheduler 上のジョブのスケジューリングについて詳しくは、IBM Workload Automation を使用したアプリケーションのスケジューリングを参照してください。

ビデオ・チュートリアル『Empowering SAP Solution Manager with IBMWorkload Scheduler』も参照してください。

lii IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

インストール済みの SAP トランスポートのバージョンを報告するRFC の追加インストール済みの SAP トランスポートのバージョンを報告する RFC の追加

IBM Workload Scheduler アプリケーション用にロードされた SAP トランスポートのレベルの識別を容易にするために、リモート機能呼び出し (RFC) が追加されました。 RFC を呼び出すには、SAP にトランスポートされたリリースに対応するストリングを取得するジョブを使用します。 この方法は特に、複数の SAP ランドスケープで IBM Workload Scheduler のアップグレードを実行しているときに、情報を手動で記録する方法に頼らずに IBM Workload Scheduler トランスポートのバージョンを識別するために役立ちます。

SAP アプリケーション・ログの処理SAP アプリケーション・ログの処理

SAP アプリケーション戻りコードが設定されていなくても SAP アプリケーション・ログを取得できるように、SAP アプリケーション・ログは SAP アプリケーション戻りコードとは無関係に処理できるようになりました。したがって、「E_T_LOGHANDLES」テーブルにリストされている SAP アプリケーション・ログ・フィールドに提供されている情報とは無関係に、R3batch は「E_T_RETUN_CODES」テーブルの SAP アプリケーション戻りコード・フィールドを処理できるようになりました。

Workload Automation の障害によるビジネスへの影響の遮断Workload Automation の障害によるビジネスへの影響の遮断

ビジネス・イベントをリアルタイムでモニターおよび分析することで、分散環境とz/OS 環境の両方でサービス・モデルまたは基幹業務にどのような影響が及ぶかを突き止めることができます。 ワークステーション、ジョブ・ストリーム、ジョブなどの IBM Workload Scheduler オブジェクトを IBM Tivoli Business ServiceManager にインポートし、それらのオブジェクトに関連したイベントを送信することができます。それらを IBM Tivoli Business Service Manager で迅速に分析して、ビジネスへの影響に応じた優先順位を付けて対応します。

IBM Tivoli Business Service Manager との統合について詳しくは、他の製品との統合を参照してください。

Workload Automation の障害によるビジネスへの影響の遮断について詳しくは、『Workload Automation の障害によるビジネスへの影響の遮断』を参照してください。

動的エージェントのファイル依存関係サポート動的エージェント、プール、および動的プールでファイル依存関係を使用および管理できるようになりました。

ファイル依存関係の定義と動的環境でのファイル依存関係の使用について詳しくは、「ユーザーズ・ガイドおよびリファレンス」で動的スケジューリングでのファイル依存関係の定義に関するトピックを参照してください。

機能拡張の要約 liii

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

中央制御エージェントの更新パッケージをダウンロードしてマスター・ドメイン・マネージャー・ワークステーションのみにインストールすることで、フィックスパックをインストールしたり、複数のフォールト・トレラント・エージェント・インスタンスや動的エージェント・インスタンスをアップグレードしたりできます。また、Dynamic WorkloadConsole から単一のアクションを実行することで、インストールまたはアップグレードを管理することもできます。

エージェント・インスタンスの更新について詳しくは、「計画およびインストール」でエージェントの集中更新に関するトピックを参照してください。

基本製品に付属してインストールされるようになった IBM TivoliWorkload Scheduler for Applications

IBM Workload Automation バージョン 9.3 には、IBM Tivoli WorkloadScheduler for Applications のすべての機能が組み込まれています。

このリリースでは、IBM Tivoli Workload Scheduler for Applications は、別個の製品ではなくなりました。以前に IBM Tivoli Workload Scheduler forApplications とともに提供されていたアクセス方式およびプラグインは、現在ではIBM Workload Scheduler バージョン 9.3 をインストールすると自動的にインストールされます。ただし、これらのプラグインを使用する資格を得るには、別個に有料コンポーネントを購入する必要があります。

注: 以前 IBM Tivoli Workload Scheduler for Applications で使用できた OracleE-Business Suite アクセス方式は、製品のオファリングから削除されました。IBMWorkload Scheduler バージョン 9.3 では、Oracle E-Business 用の拡張エージェントはサポートされません。IBM Workload Scheduler バージョン 9.3 では、新しいジョブ・プラグインである IBM Workload Scheduler plug-in for OracleE-Business Suite が導入されました。既存の拡張エージェントを新しいジョブ・プラグイン定義に迅速かつ簡単に移行するための変換ツールが用意されています。Integrated Service Management Library でこの解決方法を説明する readme ファイルを参照してください。

IBM Workload Scheduler の機能を拡張する方法について詳しくは、「IBMWorkload Scheduler ユーザーズ・ガイドおよびリファレンス」を参照してください。

IBM Workload Scheduler のジョブ・スケジューリング機能を外部システムおよびアプリケーションに拡張するには、PeopleSoft、SAP R/3、および z/OS のアクセス方式を使用します。

IBM Workload Scheduler ジョブ・プラグインを使用して、IBM WorkloadScheduler のジョブ・スケジューリング機能を外部アプリケーションに拡張することもできます。

アクセス方式およびプラグインについて詳しくは、「IBM Workload Automation:IBM Workload Automation を使用したアプリケーションのスケジューリング」を参照してください。

liv IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

重要: IBM Workload Scheduler バージョン 9.3 のインストール済み環境に IBMTivoli Workload Scheduler for Applications バージョン 8.6 をインストールしないでください。インストールすると、ジョブの実行時に問題が発生する可能性があります。製品のバージョン 9.3 には、IBM Tivoli Workload Scheduler forApplications バージョン 8.6 以降の更新されたバージョンのプラグインが組み込まれています。

ドメイン・ユーザーを使用したエージェントのインストールドメイン・ユーザーを使用したエージェントのインストール

ローカル・ユーザーをローカル管理グループのメンバーとし、ドメイン・ユーザーをローカル管理グループのメンバーとするような方法で、エージェントをインストールできるようになりました。

その他の機能拡張その他の機能拡張

IBM Workload Scheduler バージョン 9.3 では、以下の機能拡張も利用できるようになりました。

v IBM Workload Scheduler データベースとして Microsoft SQL Server を使用するためのサポートの追加。

v Informix RDBMS サポート。

v FTA エージェント・タイプのインストールおよびアップグレードのプロセス。

v root 以外のユーザーとしてのインストールの追加。

v ジョブ結果分析機能の強化。

Dynamic Workload Console の新しいウェルカム・ページDynamic Workload Console の新しいウェルカム・ページ

Dynamic Workload Console の概要を迅速に確認できるように、ログイン後に、Dynamic Workload Console のウェルカム・ページが Dashboard ApplicationServices Hub コンソール・ウィンドウに表示されます。

ウェルカム・ページについて詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で Dynamic Workload Console のナビゲート方法に関するトピックを参照してください。

IBM Workload Scheduler の分析IBM Workload Scheduler で、以下の分析機能を使用できます。

v IBM Workload Scheduler仮定分析

v 高度な統計を使用したジョブ所要時間の正確な予測

IBM Workload Scheduler仮定分析IBM Workload Scheduler 仮定分析を使用すると、開始日の変更、依存関係の追加と削除、ワークステーションの使用不可の設定、計画内のジョブ・

機能拡張の要約 lv

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

ストリームの実行依頼、およびクリティカル・パスの強調表示を実行して、これらの変更が計画にどのように影響するかを確認し、試行錯誤手法を使用して多様な結果を検討できます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で変更による環境への影響の分析に関するセクションを参照してください。

高度な統計を使用したジョブ所要時間の正確な予測SPSS ベースの統計分析により、クリティカルなジョブを適切なタイミングで完了する上での問題をピンポイントで特定できるようになります。 90 日間の履歴に基づいてこの先 5 日間にわたるジョブ所要時間を信頼区間の形で予測することができます。 予測は秒単位の精度で行われます。このツールは、既に認められた周期性に伴う既知の影響だけでなく、クリティカル・ジョブの期限内完了を妨げる潜在的な影響を把握する上で非常に有用です。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で高度な統計を使用したジョブ推定所要時間の予測に関するトピックを参照してください。

ビデオ・チュートリアル『Using advanced statistics to improve yourscheduling』も参照してください。

ワークロードのモニターIBM Workload Scheduler の「ワークロードのモニター」では、以下の機能拡張が行われています。

v アーカイブ計画内での照会の実行

v 「ワークロードのモニター」上でレポートとして表示

v 「ワークロードのモニター」上のクリティカル・ジョブ

注: IBM Workload Scheduler バージョン 9.3 では、名前が「動的モニター照会」から「ワークロードのモニター」に変更されました。

ワークロードのモニター方法について詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で、モニター・タスク照会を作成する方法に関するトピックを参照してください。

ビデオ・チュートリアル『Dynamic Monitoring Query』も参照してください。

重要な情報を一目でモニターできるダッシュボード効率的なワークロード・モニターにより素早い対応が可能になります。素早く対処すれば、ビジネスへのリスクを回避できます。事前定義されたダッシュボードをモニターしてドリルダウンしたり、提供されるウィジェットを組み合わせて、ワークロードの必要な部分のみを単一の統合されたビューですべてモニターします。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で、モニターのためのダッシュボードを作成する方法に関するセクションを参照してください。

ビデオ・チュートリアル『Control your Workload Scheduling At-a-glance withthe customizable dashboards』も参照してください。

lvi IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

クーロン・ジョブと Windows タスク・スケジューラー・ジョブのインポート

IBM Workload Automation Application Lab を使用してクーロン定義ファイルとWindows タスク・スケジューラー・ファイルを読み取り、それらを ApplicationLab プロセスに変換します。ご使用のサーバー上で定義したクーロン定義ファイルと Windows タスク・スケジューラー・タスクを Workload Automation 環境に移動して、複雑なスケジューリング・シナリオを利用できます。

すべてのビジネス・タスクのスケジューリングを単一の制御ポイントから制御して、複数のスケジューラーの使用に関わるリスクと時間を減らします。

詳しくは、「Application Lab ユーザーズ・ガイド」で、クーロン・ジョブとWindows タスク・スケジューラー・ジョブをインポートする方法に関するセクションを参照してください。

クーロン定義について詳しくは、IBM Service Engage で利用できるクーロン定義のインポートのビデオも参照してください。

Application Lab使いやすいインターフェースを使用してビジネス・プロセスをモデル化、スケジュール、およびモニターし、より短期間でビジネス価値を実現します。

新しいグラフィカル・ユーザー・インターフェースである Application Lab は、ワークロードの処理において制御と自律性は求められるが、複雑なワークロード自動化の概念への対応は求められていないアプリケーション開発者に特化しています。組織には、複雑なワークロードを自動化する IT 専門家のチームがある場合もあります。しかし、組織内のある種の個人または個人のグループにとっては、各自の個人ビジネス・タスクを自動化するための使いやすいツールがあると、役立つことがあります。このような個人としては、アプリケーション開発者が考えられます。アプリケーション開発者が Application Lab を使用して独自のプロセス (ステップのシーケンス) を開発してから、そのプロセスを自動化するかまたは必要に応じてオンデマンドで実行するかを選択できるように、管理者はセットアップの支援を行います。Application Lab を使用して作業するために別個のコンポーネントをインストールする必要はありません。Dynamic Workload Console がインストールされていれば、URL を通じてアクセスできます。

この新しいインターフェースについて詳しくは、「IBM Workload Automation:Application Lab ユーザーズ・ガイド」を参照してください。

Tivoli Common Reporting レポートTivoli Common Reporting レポート

Tivoli Common Reporting は、IBM WebSphere 用の Jazz for ServiceManagement 拡張機能のオプションの統合サービスであり、WebSphereApplication Server とともにインストールされます。 Tivoli Common Reportingを使用して、レポートを管理、実行、カスタマイズ、および作成できます。

詳しくは、「Dynamic Workload Console ユーザーズ・ガイド」で Tivoli CommonReporting レポートに関する情報を参照してください。

機能拡張の要約 lvii

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

変数テーブル内における変数の迅速かつ簡単な位置特定変数テーブル内の変数を素早く簡単に見つけることができます。

変数テーブルに変数エントリーの複数のページがある場合、特定の変数を見つけることが非常に困難な場合があります。 現在、Dynamic Workload ConsoleWorkload Designer は更新されて変数名と変数値のいずれかで列をソートできるようになっているため、更新する必要がある変数を瞬時に見つけることができます。

データベースでジョブ終了時刻が追跡され、Dynamic WorkloadConsole からジョブ終了時刻を表示できる

データベースでジョブ終了時刻が追跡され、Dynamic Workload Console からジョブ終了時刻を表示できる

現在、ジョブ実行ヒストリーで、ジョブ開始時刻と所要時間に加えてジョブ終了時刻を表示できます。 以前は、ジョブ終了時刻を求めるには、ジョブ開始時刻に所要時間を加える必要がありました。JOB_HISTORY_V テーブルが更新されて、カスタム・レポートの定義の際にこの終了時刻が組み込まれます。 Dynamic WorkloadConsole からジョブ実行ヒストリーの表示を要求するときにジョブ終了時刻も表示できます。

作動不可 (NOP) としてのジョブの定義作動不可 (NOP) としてのジョブの定義

ジョブを作動不可として定義して、計画の実行時にそのジョブを「保留の取り消し」状況にして実行されないようにすることができます。ただし、このジョブの後続ジョブは実行されます。 ジョブを作動不可として定義するには、DynamicWorkload Console のジョブ定義ウィンドウの NOP ボックスにチェック・マークを付けるか、または composer でジョブ・ステートメントに NOP オプションを追加します。 NOP に設定したジョブは、conman または Dynamic WorkloadConsole から計画の実行時に作動可能にすることができます。 これにより、その特定のジョブ・ストリーム・インスタンスに対してのみ、そのジョブが「作動可能」状況に設定されます (そのジョブを永続的に実行可能にするには、その定義からNOP フラグを削除する必要があります)。

詳しくは、「ユーザーズ・ガイドおよびリファレンス」で、NOP に関するセクションを参照してください。

動的ワークステーション上の SAP イベントの管理動的ワークステーション上の SAP イベントの管理

SAP イベントのイベント・ドリブン・ワークロード自動化は、動的エージェントまで拡張されました。 したがって、基本的な SAP バックグラウンド・イベント、IDoc レコード、および CCMS Monitoring Architecture アラートを、動的エージェントおよび r3batch メソッドに基づいた拡張エージェントで管理するルールを実行できます。

lviii IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

詳しくは、「IBM Workload Automation を使用したアプリケーションのスケジューリング」で、Dynamic Workload Console から SAP 標準 R/3 ジョブを作成する方法に関するトピックを参照してください。

その他の Dynamic Workload Console 機能拡張その他の Dynamic Workload Console 機能拡張

Dynamic Workload Console バージョン 9.3 では、以下の機能拡張も利用できるようになりました。

v ワークロード・アプリケーション・テンプレートのインポート。

v 動的エージェント用の SAP オプション・ファイルおよび PeopleSoft オプション・ファイルのコンフィギュレーター。

v Dynamic Workload Console 上の UI ラベルのパーソナライズ。

v セルフサービス・ダッシュボードからのすべてのエンジンのモニター。

機能拡張の要約 lix

|

|

|

|

|

|

|

|

|

|

|

|

lx IBM Workload Automation: 概要

第 1 章 IBM Workload Automation の概要

IBM Workload Automation は、現在および将来のデータ処理の課題への対応に役立つように設計された、最新技術による実動ワークロード・マネージャーです。その有効範囲は、異機種の環境を含む企業情報システム全体にわたります。

今日のデータ処理 (DP) 環境にはさまざまなプレッシャーがかかっており、顧客に対する同一レベルのサービスを維持するのがますます困難になってきています。多くのインストール・システムでバッチ時間が減少しています。また、より多くの重要なジョブを、朝のオンライン作業が始まる前に終了する必要が生じています。逆に言えば、従来のバッチ時間中にオンライン・サービスの統合的な可用性が求められるので、実動ワークロードを処理するために使用できるリソースにプレッシャーがかかっています。週に 7 日、日に 24 時間まで稼働を増大させることは、DP の目標だけでなく、要件にすらなりつつあります。

また、DP サービスのユーザーと所有者は、以前に比べ、より多くのバッチ・サービスを使用するようになっています。バッチのワークロードは、オンラインのワークロードの増加率よりもわずかに低い率で毎年増加する傾向にあります。これとバッチ・ジョブによるデータの使用の増加が相まって、作業量が著しく増加することになります。

さらに、ますます複雑化する DP 環境を操作し管理するために必要なスキルを身につけたスタッフが不足しています。実動活動間、手作業と機械タスク間の複雑な相互関係はワークロード管理ツールなしでは管理が難しくなっています。

IBM Workload Automation は、システム管理機能を統合することによって、異機種の環境にわたるシステム管理を単純化します。このポートフォリオには、以下のような 3 つの主要なコンポーネントがあります。

IBM Workload Scheduler for z/OSz/OS® 環境におけるスケジューラー。

IBM Workload Scheduler分散環境におけるスケジューラー

Dynamic Workload ConsoleIBM Workload Scheduler for z/OS と IBM Workload Scheduler の双方用の Web ベース・グラフィカル・ユーザー・インターフェース。

最新技術によるソリューションこのポートフォリオは、実動ワークロード管理の問題に対する最新のソリューションを提供します。バッチ・サブセットだけでなく、企業全体の実動ワークロードの処理を自動化、計画、および管理することができます。このポートフォリオは、実動ワークロードに対して「自動ドライバー」として機能し、作業のスループットを最大化し、リソースを最適化しますが、必要に応じて手作業による介入も可能にします。

1

このポートフォリオは、他のシステム管理製品とのインターフェースとして機能する場合、DP 操作用の統合自動化およびシステム管理プラットフォームの一部を形成します。

包括的なワークロード計画このポートフォリオは、運用部門とその実動ワークロードのユーザー記述に基づいて運用計画を形成します。これらの計画は、サービス・レベル・アグリーメントの基礎となり、任意の特定の時点での実動ワークロードの状況を示すことができます。

優れた計画は、すべての管理手法の成功の要です。また、実効性のある計画を行うと、情報技術への投資の回収を最大限にする助けにもなります。

集中システム管理このポートフォリオは、ローカル・システムとリモート・システムの両方のシステムで、企業の DP 操作全体のワークフローを自動化、モニター、および制御します。このポートフォリオは、単一の制御点から実動作業の状況を分析し、インストール・システムのビジネス・ポリシーに従ってワークロードの処理を行います。複数ユーザー環境をサポートし、企業内のサイトと部門間の分散処理と制御を使用可能にします。

システム管理の統合今日のシステム管理の問題に対するソリューションには、アプリケーション・プログラムとプロセスの統合が必要とされます。このポートフォリオは、以下の要素との統合を提供します。v 非 z/OS プラットフォームでのワークロードを制御するためのエージェントv 他のシステム管理アプリケーションおよびアーキテクチャー環境

このポートフォリオは、他の多くの IBM 製品との直接のインターフェースとして機能するだけでなく、一部の z/OS 製品との直接のインターフェースにもなり、複雑な実動ワークロードを制御するための包括的な自動処理機能と、統合されたアプローチを提供します。

NetView®。 NetView は、ネットワーク管理と自動化のための IBM プラットフォームです。NetView と IBM Workload Scheduler for z/OS のインターフェースを使用して、処理している作業についての情報を渡すことができます。このポートフォリオによって、実動ワークロード処理と一緒に、NetView と通信することができます。IBM Workload Scheduler for z/OS は、実動ワークロードの処理中に生じる状況への対応として、NetView にアラート処理用の情報を渡すこともできます。NetView は、IBM Workload Scheduler for z/OS を自動的に起動して、これらの状況に応じてさまざまな方法を使用してアクションを実行することができます。IBM Workload Scheduler/NetView は、IBM Workload Scheduler ネットワークを NetView 管理ノードからモニターして診断する能力をネットワーク・マネージャーに提供する NetView アプリケーションです。これには、IBM WorkloadScheduler ネットワークを形態的に表示し、各ワークステーションにおけるジョブ・スケジューリング活動の状況とクリティカルな IBM Workload Scheduler プロセスを判別するための、サブマップとシンボルのセットが含まれています。

2 IBM Workload Automation: 概要

ワークロード・マネージャー (WLM)。 WLM は、ホスト環境の各作業単位に使用可能なシステム・リソースの数量を制御します。 IBM Workload Scheduler forz/OS は、WLM と連携して働いてクリティカル・ジョブを検出し、それらを高パフォーマンス・サービス・クラスに移動します。また、WLM によって、重要なジョブはより多くのシステム・リソースを受け取り、より迅速に完了します。

リソース・オブジェクト・データ・マネージャー (RODM)。 RODM は、ネットワーク管理とシステム管理に必要な操作可能リソース情報の保管、検索、および管理用の中央設置場所を提供します。 1 つの特殊リソースを 1 つの RODM オブジェクトにマップすることもできます。この機能を使用すると、動的に更新される実際のリソース可用性を考慮して、実動ワークロードをスケジュールすることができます。

Tivoli® Decision Support for z/OS (Decision Support)。Decision Support を使用すると、パフォーマンス・データを DATABASE 2 (DB2) データベースに収集し、そのデータをシステム管理で使用するためにさまざまな形式で提示して、システムのパフォーマンスを効率的に管理できます。 Decision Support は、IBMWorkload Scheduler for z/OS からのデータを使用して、計画と実際の両方の結果について、実動ワークロードに関する要約報告書と管理報告書を作成します。

Output Manager for z/OS。このプログラムを使用すると、z/OS 環境で報告書を保管し処理する手段を提供することにより、顧客が生産性を向上させ、印刷コストを削減するのを助けます。ダイアログ・ユーザーがジョブ・ログの表示を要求したり、ステップ・レベルの再始動用の JCL を自動的に作成し直す場合に、IBMWorkload Scheduler for z/OS は、Output Manager とのインターフェースとして機能します。このインターフェースは、ジョブ・ログ情報の複写の必要を除去し、CPU サイクルと直接アクセス記憶装置 (DASD) スペースの両方を節約します。

Tivoli Information Management for z/OS。 企業のハードウェア、ソフトウェア、および関連リソースのシステム管理プロセスの管理をサポートします。実動ワークロードの処理中に検出された問題の報告用に、Tivoli Information Managementfor z/OS とのインターフェースが提供されます。

リソース・アクセス管理機能 (RACF®)。 RACF はデータ・セキュリティー用のIBM 製品です。RACF を基本ツールとして使用し、IBM Workload Scheduler forz/OS サービスおよびデータを、企業に必要なレベルで保護することができます。RACF 2.1 以降では、IBM Workload Scheduler for z/OS 予約リソース・クラスを使用して、リソースを保護することができます。

IBM Tivoli Monitoring (ITM)。これは、ハードウェア、オペレーティング・システム、アプリケーション、データベースをモニターするのに使用できます。それにより、プロアクティブなモニタリングおよび自動化故障管理が提供されます。これには、ビジネス・インテグレーションのための特定のモジュールが含まれます。また、構成を管理したり、レポート作成、パフォーマンス分析、傾向予測、およびエンタープライズ規模のビジネス・インパクト・アセスメントのためのモニタリング情報を収集したりできます。

IBM SmartCloud Control Desk (SCCD)。インシデント管理システムの 1 つです。 SSCD は、社内または社外でホストされている IT 資産と非 IT 資産の両方のためのサービス・デスクとして機能できます。SCCD を利用すると、さまざまなプ

第 1 章 製品概要 3

ロセスの自動化機能が提供され、サービス・サポート機能やコミットメントや測定の可視性が高くなって、IT パフォーマンス向上に役立ちます。

Tivoli System Automation for z/OS (SA z/OS)。SA z/OS は、z/OS コンポーネント、データ・セット、およびサブシステムを管理するためのオペレーター機能を実行する自動化手順を開始します。SA z/OS には、IBM Workload Schedulerfor z/OS のための自動化機能が組み込まれています。 IBM Workload Schedulerfor z/OS で自動化ワークステーションを定義することにより、特定のオプション・セットを使用したシステム自動化操作をハンドルすることができます。

データ機能階層記憶管理プログラム (DFHSM)。IBM Workload Scheduler forz/OS カタログ管理機能は、DFHSM を呼び出して、失敗したジョブまたは再実行ジョブに対するデータ・セットのクリーンアップ中に、マイグレーション済みデータ・セットの再呼び出しを行います。

CICS® および IMS™ (顧客情報管理システムおよび情報管理システム)。 IBMWorkload Scheduler for z/OS によって、開始タスクの開始と停止をスケジュールすることができます。IBM Workload Scheduler for z/OS は開始タスクの状況を追跡するので、ユーザーの CICS サブシステムまたは IMS サブシステムの状況に応じて、トランザクション・データベースのバックアップなどの作業を逐次化することができます。

Tivoli Business Systems Manager。Tivoli Business Systems Manager は、企業に対して連続可用性を提供する目的で、リソース、アプリケーション、およびサブシステムのモニターと、そのイベント管理を提供します。このポートフォリオでTivoli Business Systems Manager を使用して、戦略的なアプリケーションを固有の業務システムの観点から管理することができます。Tivoli Business SystemsManager は、バッチ関連アプリケーションおよびこのポートフォリオが表す操作をモニターし、それらのオブジェクトを Tivoli Business Systems Manager がモニターする他のすべての業務オブジェクトとシームレスに統合します。

Tivoli Enterprise Console®。 Tivoli Enterprise Console は、ネットワーク、システム、データベース、およびアプリケーション管理を統合する強力な規則ベースのイベント管理アプリケーションです。これは、アプリケーションおよびコンピューター・リソースの高可用性を確保する一方で、コンピューター企業の中央でのグローバルなビューを提供します。 Tivoli Enterprise Console は、Tivoli アプリケーションを含む、さまざまなソースからのアラームとイベントの中央収集点としての役割を果たします。IBM Workload Scheduler は、IBM Workload Scheduler ログ・ファイルからイベントを読み取る Tivoli Enterprise Console アダプターを稼働させます。

これらの IBM 製品以外に、このポートフォリオとともに機能するか、あるいはこのポートフォリオからのデータを処理する、他のソフトウェア・ベンダーからの製品も数多くあります。

IBM 製品の使用に関するホワイト・ペーパーを参照するには、http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/WP-ByProduct?OpenDocument&Start=1&Count=1000&Expand=18 にアクセスしてください。

4 IBM Workload Automation: 概要

統合シナリオこのセクションでは、IBM Workload Scheduler for z/OS と下記の製品の統合により、実行の遅いクリティカル・ジョブ をモニターしたり、インシデント管理を実行したりする方法を示します。

v IBM Tivoli Monitoring (ITM)

v IBM SmartCloud Control Desk (SCCD)

v Tivoli System Automation (SA)

IBM Workload Scheduler for z/OS は、定義されている最新計画に従ってジョブをスケジュールに入れます。 ITM は、クリティカル・ジョブの実行に時間がかかる場合に、E メール通知を SCCD に送る状況 で構成されています。

統合コンポーネントは、以下のように動作します。

1. ITM が WLM スケジューリング環境に結び付けられたクリティカル・ジョブを検出します。

2. ITM が E メールを送信し、それによりサービス要求が自動的にオープンされます。

3. SCCD のオペレーターは、サービス要求を収集し、Dynamic WorkloadConsole のコンテキスト起動を実行して、インシデント分析を実行します。

4. その分析により、クリティカル・ジョブが WLM スケジューリング環境を待機していることが確認されます。

5. Dynamic Workload Console によりシステム自動化ジョブが実行依頼され、WLM スケジューリング環境が使用可能になります。

6. WLM スケジューリング環境が使用可能になるとすぐに、スケジューラーは、再びクリティカル・ジョブを実行依頼します。

7. サービス要求がクローズされます。

第 1 章 製品概要 5

自動化このポートフォリオを使用して実動ワークロードの管理を自動化することによって、実動ワークロード処理での人為的なミスを最小限にし、スタッフをより生産性の高い作業に割り振ることができます。このポートフォリオを使用すると、実動ワークロードの処理の計画、駆動、および制御を行うことができます。これらは、自動化および無人操作において重要なステップです。 1 つ以上のシステムを単一のサイトで実行しているか、あるいは複数の分散されたサイトで実行しているかに関係なく、このポートフォリオは、以下の方法によって実動ワークロードの自動化を支援します。

v すべてのサイズのインストール・システムについて、単一の制御点からすべてのシフトと実動作業を調整します。

v 複雑で繰り返されるオペレーター・タスクを自動化します。

v 実稼働環境の変化 (緊急ジョブ、優先順位の変更、またはハードウェア障害など)に応じて、実動ワークロードのスケジュールを動的に変更し、さらにそれに応じてワークロードを管理します。

v ワークロード依存関係を解決します。

v 共用リソースの使用状況を管理します。

v 各作業単位を追跡します。

v 正常に終了しなかった処理を検出します。

図 1. IBM Workload Scheduler for z/OS の統合シナリオ。

6 IBM Workload Automation: 概要

v 操作スタッフに各自の作業に関するガイドを出すために、状況情報と指示を表示します。

v 他の主要な IBM 製品とのインターフェースを取り、統合化された自動化プラットフォームを提供します。

このポートフォリオによって、実動ワークロードの制御を集中化して統合し、スタッフが実行する必要のあるタスクの数を減らすことができます。

ワークロードのモニターこのポートフォリオは、ユーザーの複数のシステムにわたる実動ワークロードに対して単一の制御点を提供することに加え、以下のことを行います。

v 問題が生じたときに迅速に対処できるように、実動ワークロードをリアルタイムでモニターして、ワークロードに関する最新の情報を操作スタッフにリアルタイムで提供します。

v サービスとデータの保護を確実にするためのセキュリティー・インターフェースを提供します。

v 作業処理中の手操作による介入を可能にします。

v 実動ワークロード処理の現行状況を報告します。

v ユーザーとのサービス・レベル・アグリーメントを文書化する際の基礎として役立てることができる報告書を提供します。顧客は、作業がいつどのように処理されるかを知ることができます。

自動ワークロード・リカバリーこのポートフォリオは、システムまたは接続の障害が起こった場合にも、実動ワークロードの処理の継続を可能にします。1 つのシステムが障害を起こしても、このポートフォリオは別のシステムで処理を再始動させることができます。制御システムが z/OS 複合システム (シスプレックス) で実行されている場合は、ホット・スタンバイ機能が、自動的に実動ワークロードの制御をシスプレックス内の他のシステムに移すことができます。このポートフォリオは障害中も実動ワークロードを管理し続けるので、処理スケジュールの整合性を維持し、顧客に対するサービスを継続することができます。

IBM Workload Scheduler においては、switchmgr 機能により、障害のあるマスター・ドメイン・マネージャーまたはドメイン・マネージャー・ワークステーションを、適切に構成されたバックアップ・フォールト・トレラント・エージェントまたはドメイン・マネージャーで置き換える可能性が提供されます。

生産性このポートフォリオは、自動化によって高速で正確なパフォーマンスを確実にすることによって、真の生産性の利益を表します。今日の自動化ソリューションの多くは、非現実的な生産性の利点を提示しています。自動化されたタスクのいくつかは、まったく実行されないか、または自動化するほど頻繁には実行されません。このため、実際の生産性の利点を企業と関連付けることは容易ではありません。

このポートフォリオが実行するタスクは、単に実行しなければならないというだけでなく、正確に、常に、なおかつできるだけ迅速に実行しなければならないタスクです。従来、DP スタッフによって実行されてきたこれらのタスクの多くは、退屈

第 1 章 製品概要 7

であり、その結果エラーを起こしがちです。このポートフォリオにより、DP スタッフは時間をより効率的に使うことができます。

業務のソリューションこのポートフォリオは、以下の方法で業務のソリューションを提供しています。v ユーザーの業務目的に従って実動業務を実行するv 実動ワークロードを自動化して、企業の生産性を向上させるv 現在と将来のワークロードについての情報を提供するv 多くの活動を効果的に管理する

ユーザーの生産性DP スタッフとユーザーは、このポートフォリオの以下の機能によって大幅な生産性の向上を実現することができます。

v ファースト・パスの設定。

v ワークロード状況の照会へのダイアログ要求に対するの即時応答。ユーザーは、エラーを検出し迅速に訂正することができるように、実動ワークロード処理についての詳細なリアルタイム情報を提供されます。

v エラー・リカバリーおよびデータ・セット・クリーンアップなどのオペレーター・タスクの自動化。

生産性向上の誘因自動化と制御をインプリメントする場合、より大きい実動ワークロードのボリュームを管理できます。このポートフォリオでは、以下に挙げるものを提供することによって DP 操作を向上させることができます。

v 操作スタッフを増やさずに、増加するバッチ・ワークロードを吸収する手段。

v 各種のオペレーティング・システムでワークロードを実行依頼および追跡するためのオープン・インターフェース。

v 他のシステム管理アプリケーション・プログラムとのインターフェース。

v 他のプラットフォームのプログラムとの、オープン・インターフェースと通信。

v 現行と将来の実動ワークロード・ボリュームの管理。

v 将来のワークロードを予測するためのシミュレーション機能。

IBM Workload Automation がスタッフに利点をもたらす仕組み典型的な企業では、以下のような多くの人々が IBM Workload Automation のインプリメンテーションと操作に貢献しています。

v スケジューリング・マネージャー

v 操作マネージャー

v シフト・スーパーバイザー

v アプリケーション・プログラマー

v コンソール・オペレーター

8 IBM Workload Automation: 概要

v 印刷オペレーター、ジョブ・セットアップ・スタッフ、ログイン受付などのワークステーション・オペレーター

v エンド・ユーザー

v サービス・デスク

以下のセクションでは、このポートフォリオがどのように DP スタッフに直接的に利益を与えられるかを説明します。

スケジューリング・マネージャーのフォーカル・ポイントとしての役割

IBM Workload Automation では、スケジューリング・マネージャーが、企業全体にわたって現在と将来の実動処理を維持管理できるようにします。このポートフォリオは、以下のような方法でスケジューリング・マネージャーに利益をもたらします。

v すべての実動ワークロード活動を自動的にスケジュールします。

v 実動ワークロードの依存関係の複雑さを自動的に解決し、最も効果的な方法で作業を実行します。

v システムにおける将来のワークロードのシミュレーションをサポートします。スケジューリング・マネージャーは、実動ワークロード・ボリュームまたは処理リソースの変更がもたらす影響を事前に評価することができます。

v スケジューリング・マネージャーが、以下に挙げることを迅速に行うことができるように、システムを流れていくときの作業の状況をリアルタイムで表示します。– 顧客の作業の状況についての照会への応答– ワークロード処理の問題の識別

v 手操作による介入の機能を提供します。

v 多くのワークロードの問題を自動的に管理できます。実動ワークロード再始動機能、ホット・スタンバイ、ジョブと開始タスクの自動リカバリー、およびデータ・セット・クリーンアップにより、スケジューリング・マネージャーには広範囲のエラー管理機能と災害時管理機能が提供されます。

v 監査証跡機能を使用して、実動ワークロード・データへの変更についてのログが提供されます。これは、スケジューリング・マネージャーがユーザー・エラーに起因する問題を解決する際に役立ちます。

v 計画しにくい作業を管理します。

操作マネージャーの役割報告、計画、および制御機能は、操作マネージャーが以下のことを行う際に役立ちます。v 操作の効率を向上させるv サービス・レベルと品質の制御を向上させるv 提供されるユーザー・アプリケーションとサービスのサービス・レベル・アグリ

ーメントを設定するv ユーザー部門との関連を向上させるv IT 投資に対する回収を増すv スタッフの可能性を開拓する

第 1 章 製品概要 9

シフト・スーパーバイザーのための強力なツールこのポートフォリオは、特にローカル・システムとリモート・システムを中央側で制御するマルチシステム複合体のシフト・スーパーバイザーにとって重要です。このポートフォリオは、シフト・スーパーバイザーが以下のことを行う際に役立ちます。

v マルチシステム複合体全体に関する実動ワークロードをモニターし、制御する

v マウント可能装置の使用を制御する

v システムとその他の情報から、作業状況についての情報を分ける

v ユーザーに状況情報を直接提供する

v システム障害が生じた場合にワークロードを管理する

v 装置障害、人員の不在、およびジョブの混雑などの計画外のイベントに対応して、最新計画に変更を行う

アプリケーション・プログラマーの役割ユーザー権限検査機能により、アプリケーション開発グループは、すべての計画と制御機能を実動システムおよびサービスと並行しながらも、分離して使用することができます。

このポートフォリオは、アプリケーション開発スタッフが以下のことを行う際に有効なツールになります。v 実稼働環境用に新規アプリケーションをパッケージ化するv 最終パッケージ形式で新しい JCL をテストするv 新規アプリケーションをテストし、既存のアプリケーションを変更する

コンソール・オペレーターこのポートフォリオは、以下のような時間のかかるタスクからコンソール・オペレーターを解放することができます。v 開始タスクの開始と停止v ジョブ実行依頼前の JCL の準備v ジョブの実行依頼v 作業の順序検証v ジョブ状況の報告v リカバリー状態と再実行状況のデータ・セット・クリーンアップの実行v ワークロード障害への対応v ステップ・レベル再始動の JCL の準備

ワークステーション・オペレーターこのポートフォリオは、以下のものを提供することによって、ワークステーション・オペレーターが作業を行うのを助けます。v 完全でタイムリーな状況情報v ワークフローを優先順位付けする最新の実行可能リストv 操作員指示のオンライン援助

10 IBM Workload Automation: 概要

エンド・ユーザーとサービス・デスクユーザーは、しばしば、ワークロードの処理状況に通じている必要があります。エンド・ユーザーは、Dynamic Workload Console を使用して、そのジョブ・ストリームの処理状況を自身でパーソナル・ワークステーションから調べることができます。ユーザーは、このポートフォリオ、ISPF、または TSO に習熟する必要も、ローカル・システムにログオンされる必要もなく、Dynamic Workload Console を使用して照会を行うことができます。

さらに、ユーザーは、ジョブ・ストリームの処理の状況についての情報を、モバイル・デバイスから常に受け取ることができます。ユーザーは、セルフサービス・カタログおよびセルフサービス・ダッシュボードの 2 つのモバイル・アプリケーションを通じて作業環境に接続され、そこで、実行するジョブ・ストリームを実行依頼し、進行状況を継続的にモニターすることができます。

ビジネス・プロセスを自動化する必要があるアプリケーション開発者は、複雑なワークロード自動化の概念の知識がなくても、Application Lab の Web ベースのユーザー・インターフェースを使用して、一連のシンプルなビジネス・プロセスを作成、実行、およびモニターできます。これは、より迅速にビジネス価値を実現する単純化されたユーザー・インターフェースです。

ヘルプ・デスクは、ワークロード処理の進行についてのユーザーからの照会に応答するために Dynamic Workload Console を同じように使用することができます。

要約IBM Workload Automation は他の主要な IBM 製品と通信して、すべての実動ワークロードの制御に対して広範囲の自動処理機能および統合されたソリューションを提供します。このポートフォリオが提供する利点を以下に示します。

自動化の増加効率が増し、DP リソースをより効果的に使用できるようになり、その結果、顧客へのサービス・レベルが向上します。

システム管理の統合の改良ユーザー・システムの管理問題に対する統一されたソリューションを提供します。

より効果的な DP 操作の制御より効果的に変更をインプリメントし、拡張を管理できます。

可用性の増大自動ワークロード・リカバリーによって可能になります。

拡張の機会より大きなワークロード・ボリュームを管理できることによって可能になります。

投資の保護z/OS への現在の投資資産で構築し、既存の顧客がワークロード管理への既存の投資で構築できるようにすることで容易になります。

第 1 章 製品概要 11

|

|

|

|

|

|

|

|

|

|

お客様の満足度の向上より高水準のサービス、可用性、より少ないエラー、および問題へのより迅速な対応により達成されます。

生産性の向上エラーが発生しがちな反復タスクを自動化することにより、操作担当者は、時間をより有効に活用できるようになります。

複数操作環境の統合DP 操作を構成する連携システム用の単一の制御点を提供します。

このポートフォリオは、単なるバッチ・スケジューリング・ツールではなく、あらゆるシステムで実行中のすべての 作業をスケジュールする能力を備えた実動管理システムです。

12 IBM Workload Automation: 概要

第 2 章 IBM Workload Automation および ITUP

この章では、IBM Tivoli Unified Process (ITUP) における IBM WorkloadAutomation の位置付けについて説明します。

IBM Tivoli Unified Process は業界におけるベスト・プラクティスに基づく ITService Management プロセスを詳細に文書化して、組織の能率および実効性の大幅な向上に役立ちます。ITUP は、ユーザーがプロセス、プロセス間の関係、および効率的なプロセスのインプリメンテーションに関係のある役割とツールを容易に理解できるようにします。

ITUP に記述されているプロセスは、IT 業界で順守されているベスト・プラクティスに基づく Information Technology Infrastructure Library (ITIL) と協調できるように厳密に調整されています。ITIL が提供するのは、インプリメント方法についてではなく、何をインプリメントするべきかについての高水準のガイダンスです。ITUP には、より容易に ITIL の推奨に従うことができるように、ユーザーがプロセスおよびプロセス間の関係を理解するのに役立つ詳細なプロセスのダイアグラムと説明が含まれています。

ITUP は、IBM グローバル・サービスと Tivoli が共同開発した IBM ProcessReference Model for IT™ (PRM-IT) に基づいています。PRM-IT は、IT ServiceManagement も含め (IT Service Management のみではありません)、CIO のオフィスの監督下に置かれるすべてのアクティビティーに関する詳細なプロセス・ガイダンスを提供します。

ITUP プロセスITUP は、IT 組織内の広範囲の一連のプロセスについて記述します。各プロセスは、以下のものによって定義されます。

プロセス・コンテキストで IBM ツールを使用する場合のベスト・プラクティスについて説明するツール・メンター

ツール・メンターは、特定のプロセス・アクティビティーを実行するのに使用できる IBM 製品およびソリューションをユーザーが識別するのを手助けし、それらの適切な使用方法を詳細に説明します。このガイダンスに従うことで、時間と労力の節約、およびエラーの減少が可能になり、投資に対して最大の価値を得ることができます。

役割の定義、責務、およびリソースITUP は、プロセス・モデル内のすべてのアクターの役割と責務を記述します。ユーザーは、各自の役割を識別し、実行する必要のあるアクティビティー、および使用可能な支援ツールについて理解することができます。

作業生産物およびその他の情報ITUP は、プロセスおよびアクティビティーによって出力として生成されたり入力として必要とされるすべての作業生産物 (しばしば成果物と呼ばれます) を記述します。また、その他の情報 (主要な用語や概念など) も定義されます。

13

共通問題およびベスト・プラクティス・ソリューションを記述するシナリオシナリオは、プロセスを改良および統合し、適切なツールを使用し、さらに役割と責務を定義することで、現実世界の問題をどのように扱うことができるかをユーザーが理解するのに役立ちます。

サービスの実行およびワークロード管理IBM Workload Automation がサポートするプロセスの中でも、サービスの実行はITUP によって記述される主要な IT プロセスの 1 つです。その使命は、操作可能なサービスを IT インフラストラクチャーおよび企業に配布することです。

IBM Workload Automation がサポートする主なサービス実行アクティビティーは次のとおりです。

v サービスの配布

v 配布リソースの管理

v ワークロード管理

ワークロード管理の目標は、タスク実行リソースの使用率の最大化、およびタスク処理の出力の配布に要する合計時間の最小化です。このアクティビティーは、マクロ・レベルとミクロ・レベルの両方で作動して、作業スケジュールを作成し、必要に応じて作業項目の前処理を行って、作業フローの要求に合致する配布リソースを最適な方法で提供できるようにします。

ワークロード・スケジューリングの目標においては、以下のことに重点が置かれます。

v 業務予定表に従い、さらに時間的制約およびリソースの可用性に応じて、アクティビティーの実行を管理すること。

v 相互作用するアクティビティー、およびアクティビティー間の依存関係と外部のエンティティーおよびイベントとの間の依存関係を持つアクティビティーの管理。

v SAP R3 や PeopleSoft のようなビジネス・アプリケーション環境との統合を可能にし、それらの環境でのアクティビティーの実行を管理すること。

v 実行するアクティビティーとそれらの実行を定義するためのライフ・サイクルの管理。

v これらのアクティビティーの実行をモニターおよび制御できるようにし、さらに結果とヒストリカル実行データを収集すること。

IBM Workload Automation を使用したワークロード管理IBM Workload Automation は、すべてのワークロード管理作業を自動化するための IBM 提供の製品ポートフォリオです。IBM Workload Automation のスケジューリング機能は、ワークロード作成の各フェーズを計画するのに役立ちます。処理期間中は、各種実動制御プログラムによって実稼働環境が管理され、オペレーター・アクティビティーのほとんどが自動化されます。スケジューラーは、実行用にジョブを準備し、相互依存関係を解決し、ジョブを起動し追跡します。ジョブの実行は依存関係が満たされると同時に開始されるので、アイドル時間は最小限に抑えられ、スループットは顕著に改善されます。ジョブは必ず順序どおりに実行され、

14 IBM Workload Automation: 概要

ジョブが失敗すると、オペレーターの介入をほとんど、またはまったく必要とせずに、スケジューラーがリカバリー・プロセスを処理します。

ワークロード管理は、スケジューリング・オブジェクトの定義が含まれているデータベースに基づいています。スケジューリング・オブジェクト・データベースには2 つのバージョンがあり、両者の違いはメイン・ワークロード・コントローラーの配置の仕方にあります。このコントローラーは、メインフレーム・コンピューター(このケースでは z/OS) ベースにも、分散プラットフォーム・ベースにもすることができます。スケジューリング・オブジェクトの中には、上記のデータベースの両方に入れておくことができるものもありますが、分散プラットフォームにのみ適用されるもの、およびメインフレーム・プラットフォームにのみ適用されるものもあります。

ワークロードの作成に必要なオブジェクト定義の最小セットは、ワークステーション、ジョブ、およびジョブ・ストリームから構成されます。他の必要なスケジューリング・オブジェクトは、事前定義されていてデフォルトで存在している可能性があります。

ワークステーションとは、特定のタスクを実行可能で、さらにスケジューラーに対してタスク実行の状況を報告する機能を持つコンピューター・システムまたは別のエンティティーを表す定義のことです。 IBM Workload Automation のインターフェースを使用すると、ワークステーションに関連付けられている物理リソースを確認できます。

ジョブは、スケジューラーによってスケジュールされて起動されるタスク (実行可能ファイル、プログラム、またはコマンド) を表します。ジョブはワークステーションによって実行され、実行後にある状況になります。この状況によりその実行が正常に完了したかどうかが示されます。ジョブ定義では、実行が正常に完了しなかった場合に必ず行う処理に関する情報を指定できます。ジョブ・ストリームに組み込まれていないジョブは、実行に関する属性を持ちません。それらは、あるタスクの実行方法を、指定されたワークステーションにとって既知の形式で記述した定義を持つ、単なるタスクの説明にすぎません。

ジョブ・ストリームは、関連ジョブのコンテナーを表し、関連ジョブを編成します。実行時の観点から説明すれば、ジョブを順序付けし、並行性に関する制限を守り、繰り返しを実行し、優先順位やリソースを割り当てるといったことを行うということです。ジョブ・ストリームは、ユーザーが管理するワークロードのマクロ・エレメントです。

スケジューリング計画は、IBM Workload Scheduler または IBM WorkloadScheduler for z/OS に対し、どのジョブを実行するか、および各ジョブを起動する前にどの依存関係を満たす必要があるかを指示する予定リストです。IBMWorkload Scheduler または IBM Workload Scheduler for z/OS は、スケジューリング・データベースに保管されているエレメントを使用して計画を作成します。

計画の実行には、作業生産物の効率的な配布に影響を与える潜在的な問題を識別するためのトラッキングを行う必要があります。このトラッキングは、Web ベースのJava™ インターフェースである Dynamic Workload Console から行うことができます。プラットフォームは z/OS でも分散プラットフォームでも構いません。Dynamic Workload Console への代替インターフェースとして、z/OS プラットフ

第 2 章 IBM Workload Automation および ITUP 15

ォームの場合には ISPF パネル・インターフェースを、分散プラットフォームの場合にはコマンド行インターフェースを使用することもできます。

19 ページの『第 4 章 業務シナリオ』を参照してください。この章では、IBMWorkload Automation を基にしたワークロード管理の可能なインプリメンテーションについて説明しています。

16 IBM Workload Automation: 概要

第 3 章 ワークロード管理の実行者

ワークロード管理に対して最も直接的な責任を負う主要な役割は、次のとおりです。

IT 管理者会社で使用されるすべてのハードウェアとソフトウェアの一般的な IT 管理者のことです。サーバーやその他のコンピューター・システムのインストール、サポート、および保守と、サービスの停止やその他の問題についての計画と対応に責任を持ちます。

ジョブ・スケジューリング・ツールのインストールと保守を行います。

IBM Workload Scheduler IT 管理者ジョブ・スケジューリングを円滑に実行できるようにするために、多くの時間を割きます。自らは実際のスケジューリングはほとんど行わず、それを行う人を後方から支援する担当者の役割をします。IBM Workload SchedulerIT 管理者は以下のことを行います。

v ジョブ・スケジューリング・ツールのセキュリティーを定義および保守する。

v 場合によって、ジョブ・スケジューリング・ツールの最小のチューニングとカスタマイズを行う。

v ジョブ・スケジューリング・ツール環境が常に稼働状態にあることを保証する。問題が発生した場合は、迅速に問題を解決する必要があります。

v ジョブ・スケジューリング・ツール・インフラストラクチャーの正常性状況をモニターする。警告して (通常は E メールやポケットベルを使用)アラートを作成するツールか、トラブル・チケットを自動的に開いて問題が発生したことを担当者に知らせるツールを使用します。

v 時々、少し時間を割いて、ジョブ・スケジューラーでは認識されないジョブ・スケジューリング上の問題の修正を援助する。

v レポートを生成し、使用する。

v 時々、コミュニティー Web サイト上に主要な問題点や回避策を記載する。

v 主に、同僚のチーム・メンバー、プログラマー、およびジョブ・スケジューラーとやり取りを行う。

v 場合によって、キャパシティー・プランニングや IT ソフトウェアの購入に関して経営幹部に提案する。

ジョブ・スケジューラーワークロード管理における主要なアクターであり、この役割にとっては、社内ワークロードが含まれている計画の作成および保守が容易に行えることが必要です。その責務は、社内ワークロードのモデル化と、スケジュールの設計、修正、および保守です。主な職責は次のとおりです。

v ワークロードの複雑さと依存関係の管理

17

v スケジュールの効率、柔軟性、および弾力性の最適化

v モデル化に関する問題の分析と修正

v スケジュールの保全性を積極的に求めること

スケジューリング・オペレーターその責務は、すべての操作可能なプロセスおよび手順を実行して、ワークフローの業務継続性を保証することです。主な職責は次のとおりです。

v クリティカル・イベントのモニターおよび最初の問題分析の実行

v 問題解決の管理および調整

v 業務の継続の保証

通常、ジョブ・スケジューリングのモニターのみを専門に行うことはありません。

スケジューリングおよび操作マネージャー以下のことを行います。

v 自らはジョブ・スケジューリング・ツールを使用しない。その代わりに、実行が長引いて遅延しているジョブに関するレポートやサービスレベル・アグリーメント (SLA) の状況など、ツールからのオペレーショナル・データに関心を払います。

v 自分のチームが、ジョブの効率的なスケジュールと管理に必要な知識とツールを持つようにする。

v 自分のチームの効率を上げることによって、組織内でコストを削減する方法を常に探究する。

v プロセスが IT 管理の要であり、チームのジョブ・スケジューリング・プロセスを改善できると確信している。ITUP (ここから自分の IT 組織が変更管理の基本的側面を実装した) に精通しています。したがって、チームはこのプロセスに従います。

18 IBM Workload Automation: 概要

第 4 章 業務シナリオ

以下のシナリオの目的は、正しいワークロード・スケジューリング製品を選択して、さらにプロセスを改善および統合し、役割と責任を適切に定義すると、製造業の企業の業務がいかに改善されるかを示すことです。

会社Fine Cola は、清涼飲料を製造して全国の小売店に流通させている中規模の企業です。自社の製造工場と戦略的に配置されたいくつかの流通センターを持っています。 Fine Cola の主な顧客は食料品のチェーンストアで、顧客オーダーの数量およびサイズは通常は一定で安定しています。しかし、温暖な季節や休日中には、オーダーの数量がピークを迎えます。さらに中間期には、Fine Cola は他の国の市場を獲得することによって、業務を増やそうとしています。Fine Cola のセールス担当者は常に、新規の受注と顧客の品ぞろえの増加に熱心です。これらの特性によって、Fine Cola の製造プロセスと流通プロセスが決定されます。製造および流通は、絶えず互いにインターロックされている継続的なサブプロセスまたはフェーズに分解できます。それらは以下のとおりです。

在庫 製造プロセス全体がこれを下敷きとします。原料データベースのサイズは、最小安全レベルによって補われる製造レベルに基づきます。同様に、製造レベルは特定の期間のオーダー量に基づきます。

オーダー原料の数量レベルは、事前設定されている製造レベルに応じた製造に使用可能なレベルでなければなりません。オーダーは、第三者供給業者による配送時間を考慮に入れて、前もって計画および発行しておく必要があります。

製造 一般製造レベルは、顧客オーダーに基づいて、前もって入念に計画されます。計画外のオーダーも引き受ける能力をもたらすように、製造量は定期的に 5 % ずつ増加されます。

供給 顧客配送スケジュールに従って、清涼飲料が製造工場から流通センターへと移送されます。

配送 プロセスの最終フェーズです。 Fine Cola の炭酸飲料が流通センターから顧客の店頭へと配送されます。

在庫、オーダー、および製造は、製造工場で発生します。供給は、製造工場から流通センターへと行われます。配送は、流通センターから最終の届け先へと行われます。

これらのフェーズは互いに固く結び付いています。店頭に置かれたそれぞれの炭酸飲料は、在庫から始まって配送で終わる特定のシーケンスの結果と見なすこともできますが、実際にはすべてのフェーズは絶えず混在しています。実際、同じデータがすべてまたはほとんどのフェーズで何らかの形で共用されており、アプリケーションは毎日のオペレーションを継続的に実行し、将来のオペレーションをセットアップするように設計されています。

19

Fine Cola では、上述したサブプロセスの実行のために、以下のデータベースを使用しています。

顧客オーダーFine Cola の顧客ベースからの、次期分のすべてのオーダーが含まれています。以下のデータベースへの入力を提供します。v 在庫

原料 Fine Cola の炭酸飲料の製造に必要な原料の在庫量が含まれています。在庫レベルが事前設定されている最小レベルに達すると、オーダーがここから供給業者にディスパッチされます。以下のデータベースからの入力を受け取ります。v 製造量

製造量オーダー量に応じて毎日製造される炭酸飲料の量が含まれています。以下のデータベースへの入力を提供します。v 在庫v 原料

以下のデータベースからの入力を受け取ります。v 在庫

在庫 完成品の在庫量が含まれています。これは、ある特定の時間間隔内のオーダーを引き受けられるだけの十分な在庫量があるかどうかを確認するためにモニターされます。以下のデータベースとの間で入力を提供し、入力を受け取ります。v 製造量v 供給

供給 食料品店からの次期分のオーダーに応じるために、製造工場から流通センターに定期的に送る必要のある炭酸飲料の量が含まれています。以下のデータベースへの入力を提供します。v 在庫v 配送

配送 各流通センターからその地域の食料品店に配送される数量が含まれています。以下のデータベースへの入力を提供します。v 顧客オーダー

以下のデータベースからの入力を受け取ります。v 供給

企業のワークロードは、アプリケーション指向 (会計、給与計算、供給業者およびユーティリティーの支払い、購入、オーダー、フルフィルメントなど) とシステム指向 (データのバックアップ、マイグレーション、エクスポート、転送、またはロード操作など) の両方です。一般に、ワークロードは、会計、オーダー、トランザクション、データベース・レコードなどの複数のデータ項目を同時に処理します。

これらのコア・アプリケーションは、会社の収益に大きく関係しており、同時にお客様の満足度にも直接影響を与えます。

20 IBM Workload Automation: 概要

付加価値を作成し、お客様の期待を上回るために、企業はビジネス・アプリケーションとの統合を強化し、完全なスケジューリング機能およびエンタープライズ・アプリケーションとの密接な統合を実現する必要があります。

課題現在、データベースは自動的には互いに統合されないので、データベース更新のための人手による介入が絶えず必要とされます。以下の理由により、これは FineCola の業務に影響を与えます。

v このプロセス全体が面倒で、間違いを犯しやすい。

v フェーズ間のインターフェースが低速で、非常に効率が悪い。

温暖な季節や休日中には通常の営業時間中に処理が非常に低速になるため、企業は流通センターと適切に連携する必要があることを認識しています。ユーザーはアプリケーションのフリーズを経験します。アプリケーションが再び使用できるようになるまで、かなりの時間がかかることがあります。連携が行われていないと、アプリケーションがオンラインに戻る間、生産性の損失という点で組織に問題を引き起こすことになります。企業が業務を拡大する際に、重要な処理の中断は受け入れられないことであるため、これは問題です。リソースの低下、ワークステーションの中断、またはメンテナンスの緊急性が生じている場合、ましてピーク期間にはリソースが地理的に分散している場合であっても、サービス・レベル・アグリーメント(SLA) の応答時間が継続して満たされている必要があります。その一方で、年度中の他の期間に使用されないため、企業は新規の IT リソース (ハードウェア、ソフトウェア、アプリケーション) を購入するつもりはありません。

Fine Cola では、主な弱点は処理方法にあることを理解しています。この会社の場合は、次のようなソリューションを実施する必要があります。

v 処理のワークフローの背後にあるデータを「在庫」から「流通」に統合します。これにより、人手による介入をほとんど行わなくても、毎日実行される操作が自動的にトリガーされるようにできます。また、これによって Fine Cola ではビジネス・プロセス全体の完全な制御も可能となり、人手による介入は例外処理のみに減らすことができます。

v 選ばれた顧客や原料の供給業者などの第三者から送られてくる外部データをプロセス・フローに統合します。このようなデータは、Fine Cola に対して複数のフォーマットでさまざまなアプリケーションから提供されます。Fine Cola のデータベースには、このデータをシームレスに統合する必要があります。

v プロセスに与える影響を最小限に抑えつつ、データのバックアップを毎日実行し、同時にその後の DB2 データベースの再編成を行えるようにします。次のステップは、前日中にオンラインで収集されたデータの処理です。

v リソースが地理的に分散している場合であっても、共用リソースを使用して、ITインフラストラクチャー間の能力を最適化し、かつてないほどの高ワークロードを実行します。

v クリティカルなビジネス・サービスの 1 日 24 時間 週 7 日 年 365 日の可用性を保証します。企業は数日ではなく数時間以内の回復を必要とするため、災害時回復計画はもはや十分ではありません。昨夜の磁気テープからの回復やシステムまたはアプリケーション障害後の失われたトランザクションの再取り込みは、競争力の高い市場では、企業にとって実行可能な選択肢ではなくなっています。

第 4 章 業務シナリオ 21

v 失敗の見込みが非常に低いため、システムの信頼性を最大限に引き出します。

この時点での会社の主なゴールは、業務アプリケーション・タスク全体を総合的に演出できる統合ワークロード・ソリューションを獲得することです。これは、IT インフラストラクチャー間のキャパシティーを最適化し、少ないリソースを使用して、かつてなく膨大な量のワークロードを実行するソリューションを意味します。例えば、企業が問題を抱えており、1 次サーバーがワークロードを処理しない場合、企業はワークロードを処理するためにシステム・リソースの迅速な再分配を自動化し、完璧な実行を目指して拡大または縮小を行います。このようにして、どのソースであっても企業はリカバリー時間を高速化するので、コストが削減されます。そのゴールは、この動的にシフトするエンタープライズ間プールにおいて最も使用可能なリソースを展望することです。

22 IBM Workload Automation: 概要

ソリューションFine Cola では、プロセス実行の改善に向けての重要なステップの 1 つは、自動的および動的なワークロード・スケジューリングに基づくソリューションを導入することであるという判断を下しました。ソリューションは、ビジネス・アプリケーションとの統合を強化して以下のタスクを実行する選択に基づいています。

図 2. Fine Cola 社の統合ワークロード・ソリューション

第 4 章 業務シナリオ 23

v 1 つのデータベースからデータを読み取って、他のデータベースを更新します。

v 外部アプリケーションからデータを読み取り、そのデータを処理し、次に適切なデータベースに追加します。

v 各フェーズでの操作に必要な情報を提供します。

v 所定のしきい値に達すると、いくつかのフェーズをトリガーします。

v 実動を中断させずにデータのバックアップを取ります。

v キャパシティー管理の観点から、アプリケーションのサイズおよび必要とされるリソースを理解し、既存のリソースに対してそれをモデル化し、企業で定義されている、新規アプリケーションが必要とするキャパシティーを予測することができます。

v 可用性管理の観点から、アプリケーションをサポートするための環境で使用可能なリソースを使用し、そのアプリケーションを実行依頼されたとおりに効率的にスケジュール、モニター、および管理するためにどのように作動すればよいかを理解します。次に、リソースが使用不可の場合、変更管理およびプロビジョニング・プロセスと相互作用して、必要なリソースを動的に割り振ります。

v ビジネス管理プロセスにさまざまなポリシーすべてをモニターさせ、アプリケーション用のポリシーの一貫性のあるビューを駆動させます。

入手可能な市販のワークロード管理製品をいくつか分析した後、Fine Cola は IBMWorkload Scheduler (具体的には動的ドメイン・マネージャー) を次の目的で使用することを選択しました。

v アプリケーションを処理するためのタスクを最適化および自動化し、環境内の変更に応答してその処理を動的に調整する。

v クリティカルな実動ワークロードに対する変更の影響を最小限に抑えるための、アプリケーションに対する必要な変更の計画、演出、およびスケジュール。および、資産のライフ・サイクル全体において変更を反映するようにワークロード・プロセスが更新されていることを確実にする。

v タスク解決プロセスの出力を配布するのに要する合計時間を最小化する。

v タスク、データ、および外部アプリケーションの間に存在する依存関係を処理する。これにより、ワークロード全体を同じプロセス・フロー内で均一に管理できます。

v ワークフロー自動化 (ワークロード自動化ではなく、企業間ワークフロー) のポリシー・ベースのビューを作成し、これらすべての事柄を計画、スケジュール、管理、およびモニターしながら企業間でそのワークフローを送信する。企業間のキャパシティーを動的に調整して、このワークロードの動的ビューをサポートする。

v 複数のプラットフォーム間でワークロード全体を自動的に転送し、複数のプラットフォーム間でポリシーを更新する。

v サーバーおよびネットワーク・リソースの要件を最小限に抑えながら、フォールト・トレランスを備えたワークロード・プロセスの高度な計画、テスト、演出、モニター、および調整を提供する機能と、スケジューリング・インフラストラクチャーの高可用性を実現するための冗長度の間のバランスを取る。

v 相互に完全に統合する。

24 IBM Workload Automation: 概要

IBM Workload Scheduler は、マクロ・レベルとミクロ・レベルの両方で作動して、作業スケジュールを作成し、必要に応じて作業項目の前処理を行って、作業フローの要求に合致する配布リソースを最適な方法で提供できるようにします。

動的ドメイン・マネージャーは、アプリケーション要件およびビジネス・ポリシーに基づき、ワークロードを最適な使用可能リソースに動的に経路指定します。さらに、SLA に従って、IT コンピューティング・リソースの使用を最適化します。

Fine Cola のアプリケーションは、IBM Workload Scheduler の用語ではジョブと呼ばれる作業単位にマップされました。これらのジョブの一部は実行のため専用リソースに静的に割り振られ (静的ジョブ定義)、その他はジョブの重要度、要件、スケジューリング・ポリシーに応じて、および環境リソース特性、関係、可用性、ロード、およびパフォーマンスに基づいて、物理リソースまたは仮想リソースに動的に割り振られます (動的ジョブ定義)。これらにより、ジョブ SLA を満たすリソース割り振りおよびリソース最適化が行われます。

ジョブがジョブ・ストリームにグループ化される正確な順序を判別する回数、優先順位、およびその他の依存関係と合わせて 1 つの単位 (週次のバックアップ・アプリケーションなど) として実行するジョブ。

Fine Cola のジョブ・ストリームは、組織の目的に合わせてグループ化されたジョブの集合です。以下の理由により、どのジョブ・ストリームの場合でも、ある特定のジョブ・ストリームのジョブは互いに関連しています。

v 関連タスクを完了に向けて作動しているため。例えば、Jobstream100 のジョブは、着信顧客オーダーをオペレーショナル・データに変換するように設計されているタスクを実行します。

v 相互依存している可能性があるため。ジョブの中には、先行ジョブが完了するのを待ってからでなければ実行を開始できないものもあります。そのようなジョブは通常、先行ジョブの実行結果が後続ジョブに送られるという手順の中に組み入れられています。

v 同じプログラム、アプリケーション、およびデータベースを共用するため。

v 計画期間内で同じ時間フレームを共用するため。

IBM Workload Scheduler を使用して、Fine Cola のビジネス・プロセスは次のように構造化されました。

1. 毎日の開始時に、Jobstream100 が以下のことを実行します。

a. 「顧客オーダー」データベースから、新規の受信オーダーを抽出します。

b. 数人の選ばれた顧客が予定外のオーダーを入れることができる外部アプリケーションを検査します。オーダーが入っていた場合は、それらを抽出して他のデータとマージします。

c. 1 つにまとめたオーダーを別個のデータベース・ビューにコピーします。

d. それらを配送予定日および数量によってソートし、レポートを作成します。

2. このレポートが使用可能になると同時に、Jobstream200 がレポートから数を抽出して「在庫」データベース内の関連データと比較します。ゴールは、これらのオーダーに応えるには次の製造サイクルでどれだけの量を製造すればよいのかを判別することです。

第 4 章 業務シナリオ 25

3. Jobstream300 は、製造量に関するデータを抽出し、次のサイクルで製造される予定の炭酸飲料のそれぞれのタイプごとの数量で「製造量」データベースを更新します。

4. Jobstream400 は、「製造量」データベースのデータを読み取って、以下のことを実行します。

a. 次の製造サイクルを実行するのに必要な原料の量を計算します。

b. 「原料」データベース内で、それらの数量に「次のサイクルに割り振り済み」を意味するフラグを立てます。

c. 数量を検査して、それらが最小在庫レベルに達しているかどうかを確認し、必要であれば、Fine Cola の原料供給業者へのオーダーをトリガーします。

5. Jobstream500 は、「顧客オーダー」データベースから配送予定日が間近のオーダーに関するレポートを読み取って、以下のことを実行します。

a. 配送のスケジュールと宛先を生成します。

b. 「供給」データベースを更新します。

c. 配送スケジュールを流通センターに送信します。

6. Jobstream600 は、流通センターのデータベースを読み取って、以下のことを実行します。

a. 入力済みのオーダーを抽出します。

b. 「顧客オーダー」データベースを更新して、送り状を作成し、発送できるようにします。

7. Jobstream700 は、各データベースのバックアップを取ります。

Fine Cola では、毎日決まって実行されるジョブ・ストリームから、それ以外の形で何度か実行されるジョブ・ストリームにいたるまでの、ワークロード全体を包含する長期計画を設定しています。各時間単位の開始時に、最新計画がこの長期計画から抽出されます。最新計画の期間は、数時間から数日の間で自由に選択できます。 Fine Cola では、最新計画を日次計画として設定することにしました。毎日の開始時に、新しい日次計画がワークロード・スケジューリング・ソフトウェアによって作成されます。その際には、長期計画と前日の日次計画からデータが取得されて、完了していない可能性のあるすべてのジョブが組み込まれます。

また、企業はピーク期間中にクリティカル・パスにあるジョブが必須の時間フレームで必ず実行されるようにする必要があります。これを確実にするために、動的ドメイン・マネージャーを使用して追加オーダーを管理するようにいくつかのジョブを静的定義から動的定義に変換しました。動的ドメイン・マネージャーを使用して、会社は以下のことを実行できます。

v リソースの特性および関係を備えたスケジューリング環境で、その使用可能なリソースの自動ディスカバリーを管理する。

v ジョブ要件および管理ポリシーに基づいて実行するための適切なリソースをジョブに割り当てる。

v SLA に基づいた必要なリソースをジョブに割り当てることにより、リソースの使用を最適化する。

v リソースの消費およびロードを管理および制御する。

v ジョブの実行要件を満たすターゲット・リソースにジョブをディスパッチする。

26 IBM Workload Automation: 概要

IBM Workload Scheduler リレーショナル・データベースには、ジョブ、ジョブ・ストリーム、それらが実行されるワークステーション、およびそれらの操作を規定する時間指定に関連した情報が含まれています。また、これには現在の IT 環境、リソースのリアルタイム・パフォーマンス、およびロード・データに関する情報など、動的ドメイン・マネージャーによって使用されるデータが含まれています。また、ジョブ定義が保管され、各ジョブに割り当てられるリソースのトラックを保持します。

このようにして、Fine Cola のスケジューリング・アナリストは、いつでもこれらのオブジェクトを作成および変更できます。また、Fine Cola の IT 管理者は業務に影響を与えずに、定義されたポリシーに基づいて割り振り要求を満たす最適なリソースのセットを動的に割り当てることもできます。

さらに、IT 管理者はリソースの特性に応じてさまざまなジョブにまたがるリソースの正確な同時使用または排他使用を確保できます。リソース要求をすぐに満たすことができない場合、彼は、動的スケジューリングを使用することにより、リソース使用率、または環境を変更することによって要求を満たせるようになるまで、リソースを自動的にキューに入れるようにすることができます。

ワークロード・スケジューリング計画は、業務上および操作上のニーズに十分に応えられるほど迅速かつ動的に変更できます。スケジューリング・アナリストは、スケジューラーで使用可能な試行計画オプションと予測計画オプションを完全活用してワークロード・スケジューリングを調整および最適化し、その結果として FineCola の業務ラインを調整および最適化します。

あらゆる予期しない、計画外の需要に応えられるように、いつでも個々のジョブをスケジューリング計画に随時追加できます。

さらに、企業は動的スケジューリングを使用して、ワークロードの仮想化の必要性が高まるピーク期間中のワークロードの増加に、迅速に対応することができます。ワークロードの仮想化とは、ワークロードを分割し、適切なリソースおよびキャパシティーに配信し、論理リソース・プール内で動的に移動できるようにワークロードを管理および制御する機能です。

リソースが使用不可の場合、ジョブ処理は障害の発生地点から再始動されるため、定義された SLA は継続して満たされます。

毎日実行する標準シナリオこのセクションでは、Fine Cola の IT スタッフの役割と責任、および彼らが直面する毎日の状況を、典型的な一日として説明します。ワークロード・スケジューリングに関係する Fine Cola の IT スタッフとは、以下のような人たちです。

v スケジューリング・アナリストの場合。担当しているのは、社内ワークロードのモデル化と、スケジュールの設計、修正、および保守です。主な職務は次のとおりです。

– Fine Cola のワークロードの複雑さと依存関係の管理。

– スケジュールの効率、柔軟性、および回復力の最適化。

– モデル化に関する問題の分析および修正。スケジュールの保全性を積極的に求めること。

第 4 章 業務シナリオ 27

v オペレーション・アナリストの場合。主な職務は次のとおりです。

– クリティカル・イベントのモニターおよび最初の問題分析の実行。

– 問題解決の管理および調整。

– 確実に操作を継続できるようにすること。

v IT インフラストラクチャー管理者。主な職務は次のとおりです。

– ジョブの重要度、要件、スケジューリング・ポリシーに応じて、および環境リソース特性、関係、可用性、ロード、およびパフォーマンスに基づいて、物理リソースまたは仮想リソースをジョブに割り当てる必要を実現する。

– 必須リソースの詳細予約またはプロビジョニングを管理する。

– サービスを中断せずに、またユーザーに対してできる限り透過的に、ジョブSLA およびリソース最適化データを満たすリソース割り振りを駆動する。

– 操作に影響を与えずにスケジュールを毎日バックアップする。

– インフラストラクチャーの高可用性を確保する。リソースが低下したり、ワークステーションが使用不可であったりする場合も、SLA が定義した可用性が継続して満たされている必要があります。

– 環境トポロジーを定義および保守する。

ワークロードの管理IT インフラストラクチャー管理者およびその他の IT スタッフとの合意の上で、スケジューリング・アナリストは、1 月以内に実動が始まるアプリケーション・ワークフローの変更に同意しました。この変更は Jobstream100 に影響を与え、以下のものが含まれます。

v 新しいジョブの定義、およびジョブ・ストリーム内の一部のジョブ依存関係の置換。

v 1 週間の間 1 日 2 回、および夏の期間中に実行される 2 つの Jobstream100インスタンスの定義。そのために、以下のことを行う必要があります。

– この 2 つのインスタンスのそれぞれについて実行サイクルを定義します。最初の実行サイクルの予想開始時刻は午前 9 時にします。2 番目の実行サイクルは午後 5 時に開始するようにスケジュールします。

– RAM およびマイクロプロセッサーに関してジョブ SLA を満たすリソースのプールについて、IT インフラストラクチャー管理者に同意します。

その後、スケジューリング・アナリストは次のようにして先に進みます。

1. 新しいストリームのロジックを検討し、計画を設定します。変更を設計し、それらを 3 日間にわたってテストし、1 週間以内に最初の自動テスト実行を実施したいと考えています。

2. 次のステップとして、変更を Jobstream100 に適用します。これを行いながら、一部のジョブに含まれているタスク (スクリプト) はアプリケーションの専門家に変更してもらう必要があることを実感しました。

3. この理由から、作業自体は引き続き先に進めながら、そのジョブ・ストリームはドラフト状態のままにして、毎日生成される計画にそれが組み込まれないようにしました。

4. 変更を適用するために、Fine Cola のスケジューリング製品で使用可能なジョブ・ストリーム・エディターを使用して直接操作します。既存のジョブ定義の名前変更により新規ジョブを定義し、新規の依存関係を追加します。

28 IBM Workload Automation: 概要

5. 変更のドラフトの完了後、明日に設定した有効日付およびアクティブ状況と一緒にジョブ・ストリームをテスト・システムに保管します。

6. 変更したジョブ・ストリームが含まれている計画を起動する前に、試行計画を生成して、依存関係が正しく解決されるかどうかを検査します。

7. 試行計画が終了したら、ジョブの統計を分析します。その際に、依存関係の設計を現在のものとは異なる設計にすると、合計経過時間が改善される可能性があることが分かりました。

8. 変更を適用し、新しい依存関係を設定し、次に計画を延長します。ジョブ・ストリームは、スケジュール変更され、テスト環境で正しくかつタイムリーに実行されました。

9. IT インフラストラクチャー管理者に会って、新しい計画の実行に関係するリソースが明日以降すべて使用可能であるかどうかを確認します。

10. IT インフラストラクチャー管理者から、IT リソースの可用性の計画を分析した後で、必要なリソースの 1 つが来週は使用できないことを通告されました。

11. IT インフラストラクチャー管理者は、スケジューリング・アナリストに予測計画を実行するように依頼します。

12. そこで、来週にスケジュールされているアクティビティーを含む予測計画を実行し、そのリソースが使用不可でもそれが原因で大きな問題が起こることはないことを検証します。

13. スケジューリング・アナリストは、そのリソースが使用不可の場合には他のリソースが過負荷になるため、パフォーマンスの低下が生じることに気付きます。

14. IT インフラストラクチャー管理者に潜在的な問題について通知します。

15. IT インフラストラクチャー管理者は、部門間のリソースの可用性を分析し、別の部門に属するリソースがジョブ定義を実行するための要件を満たすことを認識します。

16. スケジューリング分析者が、ワークロードを静的リソース割り振りから、動的リソース割り振りに移します。彼は動的ドメイン・マネージャーを使用して、ロード要件とビジネス・ポリシーを、使用可能なリソース・キャパシティーに一致させることにより、使用可能な最適のシステムにワークロードを経路指定します。

17. クリティカル・パスのジョブを識別し、それらが動的に実行可能になるよう、その定義を変更します。

18. 最後に、新しい計画を実稼働環境で実行する日付を設定し、IT インフラストラクチャー管理者に通知します。

30 ページの図 3 は、Fine Cola 社が IBM Workload Scheduler に追加された動的スケジューリング機能を使用し、SLA 応答時間の要件を満たすことにより、ワークロードを動的に管理する様子を示しています。

第 4 章 業務シナリオ 29

ワークロードのモニターある通常の就業日に、自動化されたワークロードをモニターしていたオペレーション・アナリストは、スケジュールのクリティカル・パスに位置する Job306 がabend 状況になっていることに気付きました。そのために Jobstream300 が必要な時間フレーム内に完了せず、残りのスケジュールに悪影響が出ています。その結果として計画の実行に生じた遅延が原因で、Fine Cola の日常業務に問題が生じる可

図 3. IBM Workload Scheduler の動的スケジューリング機能を使用することにより、ピーク期間中に SLA 応答時間の要件を満たす方法

30 IBM Workload Automation: 概要

能性があります。そこで、オペレーション・アナリストは Dynamic WorkloadConsole の助けを借りて、以下のことを行いました。

1. 最新計画のジョブおよびエラー・ログを分析し、ある管理されていない例外が原因でエラーが発生したことを発見しました。このエラーは再発する可能性があるため、単純に Job306 を再始動するわけにはいきません。

2. Job306 に対する責任を負うアプリケーションの専門家を特定し、このジョブに関する情報がすべて含まれている問題チケットを開きます。

3. 依存ジョブの状況を照会し、そのリストを CSV (Comma Separated Variables)形式でエクスポートし、それをチケットに添付してスプレッドシートで表示できるようにします。そのチケットに対する高い優先度での返答を要求します。

アプリケーションの専門家は、内部分析を行って、修正が必要な破損した実行パスがあることを発見しました。修正パッチの適用およびレグレッション・テストも含め、解決までの予想所要時間は 3 時間です。

しかし 1 時間後には、オペレーション・アナリストは、アプリケーション・サポート・チームが残業したとしても修正はその日の終わりまでに完了せず、その日の日次処理のクローズは不可能であることを実感しました。依存ジョブの状況を確認し、修正パッチを夜間に実動にロードさせるように目標時間を設定しました。

その後、夜中のある時点で、以下のことが行われました。

1. アプリケーション・チームが修正パッチをリリースし、新しいジョブを実動システムにロードするスケジューリング・アナリストに通知し、さらにオペレーション・アナリストに通知しました。

2. オペレーション・アナリストは、ジョブ・ストリームを再始動するために、自宅からスケジューリング・システムに接続しました。

3. オペレーション・アナリストが Job306 を再始動しました。修正が機能してジョブが完了しましたが、予想通り、日次計画がもう一度延長される前に依存ジョブを完了するには 1 時間遅い時刻になってしまいました。

4. 翌日の早朝に、その日の計画が作成されました。 Job306 に依存し、時間内に完了できなかったジョブは、最新バージョンの IBM Workload Scheduler の機能により、ジョブ名もすべてのアクティブ・ファイル依存関係も維持されたまま、単にその日に実行されるように移動されただけで済みました。

5. オペレーション・アナリストは、リモートからプロセスをモニターします。朝出社すると、日次ワークロードが実際に完了したかどうかを確認します。すべてが正常に完了していたので、チケットを閉じました。

IT インフラストラクチャーの組織の管理クリスマスの 2 週間前に、IT インフラストラクチャー管理者はスケジューリング・アナリストから通知を受け取ります。計画外のオーダーがクリティカル・パスのジョブ・ストリームにかなり多くのタスクを追加しており、完了が 1 日近く遅れているというものです。これはまた、クリスマスの前の週に実行するようにスケジュールされている計画の完了を遅らせる原因ともなります。スケジューリング・アナリストは、IT インフラストラクチャー管理者に、予測計画をすでに実行しており、この追加により、ジョブ・ストリームの SLA を満たすことができず、リソースも過負荷になることを検証したと忠告します。これを避けるために、同じリソー

第 4 章 業務シナリオ 31

スを使用する必要がある並行ジョブは、オーダーの配送の遅延を引き起こす要求された数量が使用可能になるまで待機する必要があります。

動的ドメイン・マネージャーを使用して潜在的な問題の解決策を見つけ、追加リソースを購入することなく、ワークロード処理に関して設定された目標を達成するには、以下の手順を実行します。

1. リソースの特性および関係を備えた、スケジューリング・ドメイン内で使用可能なリソースの自動ディスカバリーを実行します。

2. 在庫部門のリソースのプールが、ジョブを実行するための SLA を満たしていることを見つけます。これらのリソースには、新規のジョブ・ストリームを実行するための必須の RAM、マイクロプロセッサー、オペレーティング・システム、およびアプリケーション環境があり、クリスマス中にキャパシティーの半分で使用されます。

動的スケジューリングを使用しなければ、新規のワークロード処理が、ビジネス・ポリシーおよび優先順位を指定したロード要件、リソースの可用性とキャパシティーと一致するように調整できませんでした。既存のリソースの使用を最適化せずに問題を解決する唯一の方法は、追加のジョブ・ストリームを実行するために、IT 管理インフラストラクチャーのコストを増やす新規ハードウェアを購入することだったでしょう。

3. ポリシーおよびジョブ・ディスパッチングに基づいて、新規のジョブ・ストリームを実行するために必要な新規リソースの数を決定します。

4. ドメイン全体のサーバーについてビジネス指向パフォーマンス・ゴールの定義を管理し、それらのゴールに関連した実際のパフォーマンスの終端間ビューを提供し、パフォーマンス・ゴールを満たすためにサーバー・リソース割り振りとロードを管理します。

5. 必要なリソースを確認し、在庫部門のマネージャーとの合意を見い出すため、2つの部門間で必要なリソースを共有します。

6. 新規の論理リソースを定義します。そこで、部門間で共有されるマシンの概略を記述します。

7. リソース最適化の新たな合意を得るためにオーダー部門と連絡を取ります。

8. これで、ポリシー、ルール、リソースの計画済み可用性に従った、時間フレーム内でのジョブの実行を保証できます。また、このようにして、リソース使用率を最大化して最適化ポリシーを満たすことができます。

9. ここで、スケジューリング・アナリストは実行可能な実動計画を作成します。

動的スケジューリングを使用して、ルールおよびポリシーによって課せられる制約を満たし、実行時間、スループット、コスト、および信頼性を最適化してSLA のゴールを達成しました。

利点ワークロード・スケジューリング戦略を採用し、特に IBM Workload Scheduler とその動的スケジューリング機能を使用することにより、Fine Cola は、直ちに多くの利益を経験しています。それには次のことが含まれます。

v すべての製造プロセスと流通プロセスの統合の成功

32 IBM Workload Automation: 概要

Fine Cola で実施された新しい処理フローの実施により、すべての顧客オーダーは、顧客サービス担当者がそのオーダーを受けてから、発送センターが商品を出荷し、財務部が送り状を発送するまで、アクティブです。オーダーは、より容易に追跡できるようになり、製造、在庫、および多くの異なるロケーション間で行われている配送を同時に調整できるようになりました。計画外のオーダーが届く場合、新規の動的 IT インフラストラクチャーで容易に管理できます。

v 製造プロセスの標準化および迅速化

IBM Workload Scheduler は、Fine Cola の製造プロセスのステップの多くを自動化するのを手助けしました。その結果、時間が節約され、生産性が向上しました。

v 在庫の削減

製造プロセスのフローがよりスムーズになり、それによって、社内におけるオーダー・フルフィルメント・プロセスの可視性が向上しました。その結果として、使用される原料の在庫が削減され、顧客への配送をよりよく計画できるようになり、倉庫および配送センターの製品在庫が削減される可能性があります。

v IT インフラストラクチャーの最適化

IT リソースの動的割り振りにより、企業間のワークロード・スループットを最大限にし、コストの削減、パフォーマンスの向上、および IT と業務の必要およびサービスの要求との調整を実現します。

v フォールト・トレランスおよび高可用性の保証

IBM Workload Scheduler はサーバー、エージェント、および通信障害から回復し、障害の発生地点から再始動できます。障害イベントによる状況情報の消失はありません。さらに、コンピューターが中断する場合、そのワークロードは SLAを保証できる別のコンピューターに自動的に経路指定されます。

結論として、以下の理由により、このソリューションは企業に価値をもたらします。

v サービス・レベル・オブジェクト (SLO) に応じたサービス応答時間を提供します。

v 業務の種類ごとのサービスに関する依存関係を理解しています。

v 予測不能な使用パターンに対する予測論理を提供します。

v 相互サービス関係と、IT インフラストラクチャーおよびビジネス・プロセス・レイヤーとのサービス関係を理解しています。

v スケジューリング・インフラストラクチャーのネットワーク・フォールト・トレランスおよび高可用性を提供します。

v システムおよび操作の複雑さを軽減し、IT スタッフのスキルと知識を利用します。

v 混乱を最小限に抑えて、迅速かつ容易にシステムを既存のビジネス・プロセスと統合します。

第 4 章 業務シナリオ 33

34 IBM Workload Automation: 概要

第 5 章 IBM Workload Scheduler

IBM Workload Scheduler のスケジューリング機能は、実動のすべてのフェーズの計画に役立ちます。計画の処理期間中は、IBM Workload Scheduler の各種実動制御プログラムによって実稼働環境が管理され、オペレーター・アクティビティーのほとんどが自動化されます。 IBM Workload Scheduler は、ジョブを実行のために準備し、相互依存関係を解決して、それぞれのジョブを起動して追跡します。ジョブの実行は依存関係が満たされると同時に開始されるので、アイドル時間は最小限に抑えられ、スループットは顕著に改善されます。ジョブは常に順序どおりに実行され、ジョブが失敗すると、オペレーターの介入をほとんど、またはまったく必要とせずに、IBM Workload Scheduler がリカバリー・プロセスを実行します。

概要次のシナリオでは、IBM Workload Scheduler の概要を示します。

IBM Workload Scheduler とはIBM Workload Scheduler は、以下の部分から構成されています。本書は英語版を翻訳したものです。

IBM Workload Scheduler エンジンスケジューリング・エンジン。これは、IBM Workload Scheduler ネットワークのすべてのコンピューターで実行されます。インストール時に、マスター・ドメイン・マネージャー、ドメイン・マネージャー、またはエージェントなど、ワークステーションがスケジューリング・ネットワークの中で果たす役割に応じて、エンジンが構成されます。

Dynamic Workload ConsoleWeb ベースであり、軽量で強力な使いやすいコンソールです。これは、現行の IBM Workload Scheduler 機能すべてに対するアクセスが提供されていて、かつ Web ブラウザーが搭載されている任意のコンピューターで使用できます。 IBM Workload Automation ポートフォリオ全体の戦略的グラフィカル・ユーザー・インターフェースです。

IBM Workload Scheduler ネットワークIBM Workload Scheduler のネットワークは、ジョブおよびジョブ・ストリームが実行されるワークステーションまたは CPU で構成されています。

IBM Workload Scheduler のネットワークには、少なくとも 1 つの IBMWorkload Scheduler ドメイン (マスター・ドメイン・マネージャーが管理ハブとなるマスター・ドメイン) が存在します。追加のドメインを使用して、広範囲に分散したネットワークをより小さい、ローカルに管理されるグループに分割できます。

35

複数のドメインを使用すると、マスター・ドメイン・マネージャーと他のコンピューターとの間で行う必要のある通信の量が減少するため、ネットワーク・トラフィックの量が減少されます。

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

複数ドメイン構成では、マスター・ドメイン・マネージャーは、そのドメイン内のワークステーション、およびその従属ドメイン・マネージャーと通信します。次いで従属ドメイン・マネージャーは、そのドメイン内のワークステーション、およびその従属ドメイン・マネージャーと通信します。複数のドメインは、また、ドメイン・マネージャーの喪失による問題を単一ドメインに限定することによって、フォールト・トレランスを提供することができます。それ以上の影響を制限するために、ドメイン・マネージャーに障害があった場合にそれを引き継ぐバックアップ・ドメイン・マネージャーを指定することができます。

実動計画を作成または拡張するたびに、マスター・ドメイン・マネージャーによって Symphony® という名前の実動制御ファイルが作成されます。次に、ネットワーク内の IBM Workload Scheduler が再始動され、マスター・ドメイン・マネージャーは、自動的にリンクされた各エージェントおよび従属ドメイン・マネージャーのそれぞれに、新規の実動制御ファイルのコピーを送信します。次いで、ドメイン・マネージャーは、自動的にリンクされたエージェントおよび従属ドメイン・マネージャーにコピーを送信します。

いったんネットワークが開始されると、ジョブの開始および完了などのスケジューリング・メッセージが、エージェントからそのドメイン・マネージャーへ、親ドメイン・マネージャーを通じてマスター・ドメイン・マネージャーへ渡されます。マスター・ドメイン・マネージャーは、次に、階層ツリー全体にメッセージをブロードキャストして、フル状況モードで実行中のドメイン・マネージャーおよびフォールト・トレラント・エージェントの実動制御ファイルを更新します。

図 4. 2 つのドメインで構成される IBM Workload Scheduler ネットワーク

36 IBM Workload Automation: 概要

マネージャーおよびエージェントのタイプ基本的に、ワークステーション定義は物理ワークステーションを指します。しかし、拡張およびネットワーク・エージェントの場合には、ワークステーションは、物理 IBM Workload Scheduler ワークステーションがホストとなる必要がある論理定義です。

IBM Workload Scheduler ワークステーションのタイプとしては、以下のいずれかが可能です。

マスター・ドメイン・マネージャー (MDM)IBM Workload Scheduler ネットワークの最上位ドメイン内のドメイン・マネージャー。これは、スケジューリング・オブジェクト定義が保管されているリレーショナル・データベースを含んでいる場合と、このデータベースに接続する場合とがあります。計画が作成または延長されると、マスター・ドメイン・マネージャーは、実動ファイルを作成または更新し、ネットワーク内に配布します。ネットワークに関するロギングおよびレポート作成は、すべてマスター・ドメイン・マネージャーによって行われます。

バックアップ・マスター自動ワークロード・リカバリーのためのマスター・ドメイン・マネージャーの役割を果たすことができるフォールト・トレラント・エージェントまたはドメイン・マネージャー。

ドメイン・マネージャードメイン内の管理ハブ。ドメイン内のエージェントとのすべての通信は、ドメイン・マネージャーを介して経路指定されます。

バックアップ・ドメイン・マネージャー自身のドメイン・マネージャーの役割を担うことができるフォールト・トレラント・エージェント。

動的ドメイン・マネージャードメインの管理ハブである、分散 IBM Workload Scheduler ネットワークのインストール済みコンポーネント。ドメイン内の動的エージェントとの通信はすべて、動的ドメイン・マネージャーを介して経路指定されます。

バックアップ 動的ドメイン・マネージャー問題発生時に、動的ドメイン・マネージャーのバックアップとして稼働できるワークステーション。これは実質的に、活動化待ちの動的ドメイン・マネージャーです。これを使用するかどうかはオプションです。

フォールト・トレラント・エージェント (FTA)ドメイン・マネージャーが存在しない場合にローカル依存関係を解決し、そのジョブを起動することができるワークステーション。

動的エージェント動的エージェントは、フォールト・トレラント・エージェントと同じタイプのジョブを実行します。例を挙げると、docommand やスクリプトなどのクラシック・ジョブ・タイプから、より具体的なジョブ・タイプ (Java、データベース、ファイル転送、InfoSphere DataStage、Cognos、OSLC など) まであります。動的エージェントは、プールや動的プールで定義できます。

第 5 章 IBM Workload Scheduler 37

|

|

|

|

|

|

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

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

計画内のジョブ・ストリームの一部として、または動的なサブミットを通して、ジョブがサブミットされると、IBM WorkloadScheduler はジョブ要件、使用可能なリソース、および関連する特性を検査し、それを実行するための要件を最も満たすリソースにジョブをサブミットします。

既存のジョブ・タイプおよび拡張オプション付きジョブ・タイプの両方の実行 以下を実行できます。

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

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

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

プールプールは、ジョブの要件に従って、特定の動的エージェント・ワークステーションが追加されるグループです。ジョブは、実行するジョブの量がより少ないエージェントを選択してロード・バランシング・ポリシーを適用する、使用可能な最善の動的エージェントに、動的に割り当てられます。

動的プール動的プールは、要件が指定されるグループであり、IBM WorkloadScheduler は、この要件を満たす動的エージェントを選択します。ジョブは、最善のエージェントを識別するための最適化ポリシーを適用する、使用可能な最善の動的エージェントに、動的に割り当てられます。

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

38 IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

||

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

拡張エージェントPeopleSoft、SAP、z/OS など、他のシステムおよびアプリケーション上のジョブを起動し、制御するのに役立つ、論理ワークステーション定義。

z-セントリック・エージェントIBM Workload Scheduler for z/OS からスケジュールされたジョブを実行するが、IBM Workload Scheduler 環境にインストールされている。フォールト・トレランスの機能はなく、RESTful HTTP インターフェースを介して IBM Workload Scheduler for z/OS コントローラーと直接通信します。IBM Workload Scheduler for z/OS では、分散環境で実行しますが、コンピューター自動ワークステーションと同じ機能を持ちます。

ネットワーク・エージェント別個の IBM Workload Scheduler ネットワーク内のジョブとジョブ・ストリームの間の依存関係を作成するための論理ワークステーション定義。

トポロジー企業の IBM Workload Scheduler ドメインのセットアップ方法を選択する手掛かりは、ローカライズされた処理の概念にあります。この考え方とは、企業のスケジューリングの要求を、一連の共通特性に基づいて分離またはローカライズすることです。

共通特性とは、地理的な場所、業務機能、およびアプリケーションのグループ化といった事項です。関連する処理をグループ化することによって、ドメイン間での通信を必要とする相互依存関係の情報量を制限することができます。ドメインでの処理をローカライズする利点は、以下のとおりです。

v ネットワーク・トラフィックの減少。処理をドメインにローカライズしておくことは、ドメイン相互間の頻繁な通信の必要を除去します。

v セキュリティーを強化し、管理を単純化するための便利な方法が提供されます。セキュリティーと管理は、ドメイン・レベルで定義でき、またそのレベルに限定することができます。ネットワーク全体の、または個々のワークステーションの管理ではなく、ドメインの管理が行えます。

v ネットワークおよびワークステーションのフォールト・トレランスを最適化できます。複数ドメインの IBM Workload Scheduler ネットワークでは、1 つのドメインにおける問題が他のドメインでの操作を混乱させることがないように、各ドメイン・マネージャーのバックアップを定義することができます。

ネットワーキング企業の IBM Workload Scheduler ネットワークのセットアップ方法に関する決定を行う際には、以下の質問が役立ちます。ユーザーのネットワークに関係する質問もあれば、IBM Workload Scheduler によって制御されるアプリケーションに関係する質問もあります。一部の問題を解決するには、ユーザーの組織内の他の担当者と相談することが必要な場合があります。

v IBM Workload Scheduler ネットワークはどの程度の大きさか。そこで保持されるコンピューターの数。そこで実行するアプリケーションおよびジョブの数。

ネットワークのサイズは、単一ドメインかまたは複数ドメインのどちらのアーキテクチャーを使用するかを決定するのに役立ちます。 IBM Workload Scheduler

第 5 章 IBM Workload Scheduler 39

を使用して制御するコンピューターの数が少ないか、あるいはアプリケーションの数が少ない場合には、複数のドメインは必要ないと考えられます。

v IBM Workload Scheduler ネットワークによってカバーされる地理的な場所の数。複数の場所間での通信の信頼性および効率性の程度。

これは、複数ドメイン・アーキテクチャーを選択する主要な理由の 1 つです。地理的場所ごとに 1 つのドメインを用いるのが一般的構成です。単一ドメイン・アーキテクチャーを選択した場合には、連続的な処理を維持するために、ネットワークへの依存度が高くなります。

v IBM Workload Scheduler の集中管理または非集中管理のどちらの必要があるか。

単一ドメインか複数ドメインのいずれかを使用する IBM Workload Schedulerネットワークでも、IBM Workload Scheduler をマスター・ドメイン・マネージャーである単一ノードから管理することができます。複数の場所を別々に管理したい場合には、それぞれの場所に別個の IBM Workload Scheduler ネットワークをインストールすることを考慮することができます。スタンドアロンの IBMWorkload Scheduler ネットワークであっても、ファイル・システムをマウントするか共用することによって、ある程度の非集中管理は可能であることに注目してください。

v 単一のサイトに複数の物理または論理エンティティーがあるかどうか。複数のビルディングと、各ビルディングに複数のフロアがあるかどうか。種々の部門または業務機能があるかどうか。種々のアプリケーションがあるかどうか。

これらは、複数ドメイン構成を選択する理由となる場合があります。たとえば、それぞれのビルディング、部門、業務機能、または各アプリケーション (製造、財務、技術など) ごとのドメインです。

v IBM Workload Scheduler で作動する SAP R/3 などのアプリケーションの実行を行うかどうか。

それらが離散的であり、かつ他のアプリケーションから分離している場合は、別個の IBM Workload Scheduler ドメインに入れることを選択することができます。

v IBM Workload Scheduler ドメインで Windows ドメインをミラーリングしたいかどうか。

これは必須ではありませんが、有用な場合があります。

v パフォーマンスまたは他の基準に基づいてシステムのセットを分離または区別したいかどうか。

これは、複数の IBM Workload Scheduler ドメインを定義して、システムをパフォーマンスまたはプラットフォーム・タイプに基づいてローカライズする理由となる場合があります。

v 現在のネットワーク・トラフィックの量はどの程度か。

ネットワーク・トラフィックが管理可能である場合には、複数ドメインの必要はさほど重要でなくなります。

40 IBM Workload Automation: 概要

v ジョブの依存関係が複数のシステム境界、地理的境界、またはアプリケーション境界にわたっているかどうか。たとえば、CPU3 でのジョブ 1 の開始が CPU4で実行中のジョブ 2 の完了に依存しているかどうか。

ジョブ間の相互依存関係の程度は、IBM Workload Scheduler ネットワークをレイアウトする場合の重要な考慮事項となります。複数のドメインを使用する場合には、相互依存型オブジェクトを同じドメイン内で保持することを試みる必要があります。これによって、ネットワーク・トラフィックは減少し、ドメイン・アーキテクチャーがより有効に利用されます。

v どのレベルのフォールト・トレランスのレベルが必要か。

単一ドメイン構成の明らかな欠点は、単一のドメイン・マネージャーに依存することです。複数ドメイン・ネットワークでは、1 つのドメイン・マネージャーが失われても、そのドメイン内のエージェントにしか影響しません。

IBM Workload Scheduler のコンポーネントIBM Workload Scheduler は、いくつかの管理機能のプロセスを使用して、ネットワーキング、依存関係の解決、およびジョブの起動を効率的に分離し、管理します。これらのプロセスの間では、メッセージ・キューの使用を介して通信が行われます。コンソール・マネージャー (conman) は、オペレーター・コマンドをバッチ処理に組み込むためメッセージ・キューも使用します。

IBM Workload Scheduler を実行中のどのコンピューターにも、一連のアクティブ管理プロセスがあります。それらは、システム・サービスとして、または StartUpコマンドによって開始されます。以下に、フォールト・トレラント・エージェントの主要なプロセスを示します。

Netmanリモートの mailman プロセスとローカルの writer プロセスとの間にネットワーク接続を確立するネットワーク管理プロセス。

MailmanCPU 間メッセージを送受信するメール管理プロセス。

Batchman実動制御プロセス。実動制御ファイルである Symphony からの作業で、これは、ジョブ・ストリームを実行し、依存関係を解決して、ジョブを起動するよう jobman に指示します。

Writer着信メッセージをローカルの mailman プロセスに渡すネットワーク writerプロセス。

Jobmanbatchman の指示のもとでジョブを起動し、追跡するジョブ管理プロセス。

以下に、動的エージェントの主要なプロセスを示します。

エージェントマスター・ドメイン・マネージャーまたは動的ドメイン・マネージャーへのネットワーク接続を確立するネットワーク管理プロセス。

第 5 章 IBM Workload Scheduler 41

|

|

|

JobManagerイベントの送信、TaskLauncher に対するジョブ起動の指示などの、すべての動的エージェントの操作を管理するプロセス。

TaskLauncherJobManager の指示のもとでジョブを起動し、追跡するジョブ管理プロセス。

JobManagerGWファイアウォールを介して、動的エージェントと、マスター・ドメイン・マネージャーや動的ドメイン・マネージャーとの間の通信を管理します。

さらに、IBM Workload Scheduler では以下の 2 つのコマンド行インターフェースを使用します。

ComposerIBM Workload Scheduler データベースでスケジューリング・オブジェクトの定義、保管、および管理に使用するコマンド行プログラム。 composerコマンド行プログラムは、マスター・ドメイン・マネージャーがインストールされているシステムに TCP/IP を介して接続されている任意のコンピューターにインストールして使用できます。このプログラムは、前提条件として IBM Workload Scheduler ワークステーションをインストールしておく必要はありません。このプログラムは、リレーショナル・データベース管理システム (RDBMS) がインストールされているマスター・ドメイン・マネージャーと HTTP/HTTPS を介して通信します。 HTTP/HTTPS 通信のセットアップおよび認証検査は、WebSphere® Application Server - Express®

インフラストラクチャーによって管理されます。composer は、編集ファイルを使用してスケジューリング・データベースを更新します。

Conmanコンソール・マネージャー。これは、コマンド行インターフェースによる計画実行アクティビティーのためのユーザー・インターフェースです。 .Conman は、netman または mailman のいずれかのローカル・プロセスが受信した情報を書き込みます。

IBM Workload Scheduler スケジューリング・オブジェクトIBM Workload Scheduler によるスケジューリングには、以下のことを実行できる機能が含まれています。

v ネットワークを超えてジョブをスケジュールします。

v たとえば、機能またはアプリケーションに従ってジョブをジョブ・ストリームにグループ化します。

v 並行して実行できるジョブの数に限度を設定します。

v ジョブ・ストリームを曜日、指定された日時、またはカスタマイズされたカレンダーを基にして作成します。

v 直前のジョブの正常終了、リソースの可用性、または必須ファイルの存在などの依存関係を識別することによって、正しい処理順序を確保します。

v 失敗したジョブに対する自動リカバリー手順を設定します。

v 未完了ジョブを次の実動日に持ち越します。

42 IBM Workload Automation: 概要

|

|

|

|

|

|

|

|

|

バージョン 8.3 からは、IBM Workload Scheduler スケジューリング・オブジェクトはリレーショナル・データベースに保管されるようになりました。その結果、以前のバージョンと比較して、データベース内でのオブジェクトの定義方法と管理方法が大幅に改善されました。それぞれのオブジェクトは、カレンダー、パラメーター、プロンプト、およびリソースのようなスケジューリング・オブジェクトのリストを使用しなくても、他とは無関係に管理できるようになりました。また、これらのオブジェクトの定義および管理に使用されるコマンド構文も、直接的かつ強力になりました。

IBM Workload Scheduler 管理者および担当者は、そのスケジューリング活動に応じて、以下のオブジェクトを処理します。ワークステーション

CPU とも呼ばれます。通常は、ジョブおよびジョブ・ストリームが実行される個々のコンピューターです。ワークステーションは、IBM WorkloadScheduler データベースの中で固有のオブジェクトとして定義されます。IBM Workload Scheduler ネットワークでジョブまたはジョブ・ストリームを実行するコンピューターごとに、ワークステーション定義が必要です。

ワークステーション・クラスワークステーションのグループ。任意の数のワークステーションを 1 つのクラスに入れることができます。ジョブ・ストリームおよびジョブは、ワークステーション・クラスで実行するように割り当てることができます。それにより、多くのワークステーションにわたるジョブまたはジョブ・ストリームの複製が容易になります。

ドメイン分散 IBM Workload Scheduler ネットワーク内のすべてのワークステーションは 1 つ以上のドメインに編成されます。各ドメインは 1 つ以上のエージェントと、管理ハブとして機能する 1 つのドメイン・マネージャーから構成されます。ドメイン内のエージェントとの通信は、ほとんどの場合、ドメイン・マネージャーを経由して行われます。ネットワーク内のすべてのエージェントは、単一のドメインに編成することも、複数のドメインに編成することもできます。単一ドメイン・ネットワークは、マスター・ドメイン・マネージャーと、任意の数のエージェントで構成されます。マルチドメイン・ネットワークは、マスター・ドメイン・マネージャー、任意の数の下位層ドメイン・マネージャー、および各ドメイン内の任意の数のエージェントで構成されます。

ジョブユーザーに代わって実行されるスクリプトまたはコマンド。IBM WorkloadScheduler により実行および制御されます。

ジョブ・ストリームジョブの実行順序を正確に指定する実行サイクル、回数、優先順位、その他の依存関係と合わせて 1 つの単位 (週次のバックアップ・アプリケーションなど) として実行するジョブのリスト。

カレンダースケジューリング日付のリストのこと。それぞれのカレンダーは、複数のジョブ・ストリームに割り当てることができます。カレンダーをジョブ・ストリームに割り当てると、そのジョブ・ストリームはカレンダーに指定された日に実行されます。カレンダーは、正または負の実行サイクルとして使用することができます。

第 5 章 IBM Workload Scheduler 43

実行サイクルジョブ・ストリームの実行がスケジュールされる日数を指定するサイクル。実行サイクルは、ジョブ・ストリームの一部として定義されるもので、定義済みのカレンダーを含めることができます。実行サイクルには、単純実行サイクル、週次実行サイクル、またはカレンダー実行サイクル (一般にはカレンダーと呼ばれる) の 3 つのタイプがあります。どのタイプの実行サイクルも、正にも負にもすることができます。すなわち、各実行サイクルは、ジョブ・ストリームが実動サイクルに組み込まれる日数、あるいはジョブ・ストリームが実動サイクルから除外される日数を定義することができます。

実行サイクル・グループ実行サイクル・グループは、実行サイクルのリストです。これらの実行サイクルが結合されて、一連の実行日付が生成されます。オプションで、単一実行サイクルの代わりに (あるいは単一実行サイクルに追加して)、ジョブ・ストリームに対して実行サイクル・グループを定義できます。実行サイクルとは異なり、実行サイクル・グループは特定のジョブ・ストリームに結合されません。したがって、実行サイクル・グループを複数の異なるジョブ・ストリームに再利用して、毎回同じスケジューリング・ルールを適用できます。

実行サイクルは、実行サイクル・グループのサブセットに編成されます。これらのサブセットには、論理 OR の相互関係があります。これらのサブセットにより、除外実行サイクルを組み込み実行サイクルのサブセットに適用できます。実行サイクル・グループの結果は、1 つの実行日付または一連の実行日付です。

プロンプトジョブおよびジョブ・ストリームの依存関係として使用できるオブジェクト。従属ジョブまたはジョブ・ストリームを起動するにはプロンプトに対して肯定的に応答しなければなりません。プロンプトには、事前定義と随時の2 つのタイプがあります。随時プロンプトは、ジョブまたはジョブ・ストリームのプロパティーの中で定義されるもので、そのジョブまたはジョブ・ストリームに固有のものです。事前定義プロンプトは、IBM WorkloadScheduler データベースの中で定義されるもので、任意のジョブまたはジョブ・ストリームで使用できます。

リソースユーザーのシステム上の物理リソース、論理リソースのいずれかを表すオブジェクト。リソースがいったん IBM Workload Scheduler データベースで定義されると、リソースはジョブおよびジョブ・ストリームの依存関係として使用することができます。たとえば、2 のユニット値を持つ「テープ」という名前のリソースを定義することができます。次に、依存関係として 2つの使用可能な磁気テープ装置を必要とするジョブを定義します。この依存関係を持つジョブは、ジョブが実行されるたびに tapes リソースが使用中になるため、並行して実行することができません。

変数および変数テーブル変数を使用して、ジョブやジョブ・ストリーム (JCL、ログオン、プロンプト依存関係、ファイル依存関係、およびリカバリー・プロンプト) に含まれるスケジューリング・オブジェクトに値を代入することができます。実行時にジョブ・スクリプトで値に置き換わります。変数はグローバルであり (つまり、任意のドメイン・エージェントで使用可能)、変数テーブル と呼ばれるグループ内のデータベースで定義されます。

44 IBM Workload Automation: 概要

パラメーターグローバル変数と同じように、パラメーターを使用して、値をジョブやジョブ・ストリームに代入することができます。相違は、パラメーターは、関連するジョブが実行される特定のワークステーションで定義されるため、その特定のワークステーションに対してのみ影響し、グローバルには影響しない点にあります。拡張エージェント・ジョブのスクリプト記述時には、パラメーターは使用できません。

ユーザーWindows ワークステーションの場合、ジョブ定義の「ログオン」フィールドに指定されたユーザー名は、一致するユーザー定義を持っていなければなりません。これらの定義が、ジョブを起動するために IBM WorkloadScheduler が必要とするユーザー・パスワードを提供します。

イベント・ルールスケジューリング・イベント・ルールは、特定のイベント条件が発生したときに実行されるアクション・セットを定義します。イベント・ルールの定義によって、イベントが関連付けられ、アクションがトリガーされます。イベント・ルールを定義する場合、1 つ以上のイベント、相関ルール、およびそれらのイベントによってトリガーされる 1 つ以上のアクションを指定します。さらに、有効日付、アクティビティーの日次時間間隔、および設定されるすべての時間制限の共通時間帯を指定することもできます。

ワークロード・アプリケーションワークロード・アプリケーションは、1 つ以上のジョブ・ストリームのコンテナーとして機能する IBM Workload Scheduler データベース・オブジェクトです。ワークロード・アプリケーションを使用してワークロード自動化ソリューションを標準化し、そのソリューションを 1 つ以上の IBMWorkload Scheduler 環境で再利用してビジネス・プロセスを自動化することができます。

ソース IBM Workload Scheduler 環境内にワークロード・アプリケーション・テンプレートを作成した後、そのテンプレートをエクスポートします。これにより、ターゲット環境へのワークロード・アプリケーション・テンプレートのデプロイが可能になります。エクスポート処理により、別の環境にソリューションを複製するために必要なすべての要素がソース環境から抽出されます。そして、ターゲット環境にワークロード・アプリケーションをインポートするために必要な複数のファイルが含まれる圧縮ファイルを生成します。

以下の属性を使用して、ジョブおよびジョブ・ストリームの処理方法を制御できます。

依存関係ジョブまたはジョブ・ストリームを実行する前に満たす必要がある条件。以下のタイプの依存関係を設定できます。

v 先行ジョブまたは先行ジョブ・ストリームが正常に完了していなければならない。

v 1 つ以上の特定のリソースが使用可能でなければならない。

v 特定のファイルへのアクセスが認可されていなければならない。

v プロンプトに対する肯定応答が必要。

第 5 章 IBM Workload Scheduler 45

時間制限次のような時刻に基づく条件。

v ジョブまたはジョブ・ストリームが開始されなければならない時刻

v それを過ぎるとジョブまたはジョブ・ストリームを開始できなくなる時刻

v 指定されたタイム・スロット内において、それに従ってジョブまたはジョブ・ストリームを実行する反復率

ジョブ優先順位優先順位のシステムで、それに従ってジョブおよびジョブ・ストリームが実行用のキューに入れられる。

ジョブ・フェンスワークステーションに対して定義されるフィルター。ジョブ・フェンス値を超える優先順位を持つジョブおよびジョブ・ストリームのみがワークステーションで実行できます。

制限 ワークステーション上で並行して起動できるジョブの数に対する限度を設定します。

実動プロセスIBM Workload Scheduler の実動は、実動期間 内に実行される計画に基づきます。実動期間は、実動計画の作成時または延長時にユーザーが定義します。そのスパンは、数時間から数日にすることができます (デフォルトでは 24 時間の期間となっています)。各実動期間の開始前には、データベース内に保管されているモデル化データから、および実動前計画 と呼ばれる中間計画から始めて実動計画を作成するプログラムが IBM Workload Scheduler によって実行されます。次に、別のプログラムにより、直前の実動期間内に完了しなかったスケジュールが最新計画に組み込まれ、さらに別のプログラムにより、直前の実動期間内のすべての統計がアーカイブに記録されます。

その実動期間で必要なすべての情報は、Symphony という名前の実動制御ファイルに配置されます。実動期間中に、実動制御ファイルは実行が必要な作業、進行中の作業、および完了した作業を反映するために、継続的に更新されます。 Symphonyファイルのコピーが、すべての従属ドメイン・マネージャーおよび同じドメイン内のすべてのフォールト・トレラント・エージェントに送られます。従属ドメイン・マネージャーは、そのコピーをそのドメイン内のすべてのフォールト・トレラント・エージェントとそれらに従属するすべてのドメイン・マネージャーに配布し、その次の従属ドメイン・マネージャーに (この線の下方に以下同様に) 配布します。これにより、ドメイン・マネージャーへのネットワーク接続が停止しても、ネットワーク全体にわたってフォールト・トレラント・エージェントが処理を続行します。オペレーターは、グラフィカル・インターフェースまたはコマンド行インターフェースから、現行の実動を表示したり、Symphony ファイルを変更することによってその実動に変更を加えたりすることができます。

IBM Workload Scheduler プロセスは、実動制御ファイルをモニターして、必要に応じてジョブを起動するためにオペレーティング・システムに対して呼び出しを行います。オペレーティング・システムはそのジョブを実行し、返報としてジョブが正常に完了したかどうかを IBM Workload Scheduler に通知します。この情報は実動制御ファイルに入力されて、ジョブの状況を示します。

46 IBM Workload Automation: 概要

スケジューリングスケジューリングは、IBM Workload Scheduler コマンド行インターフェースか、2つのグラフィカル・インターフェースのどちらかを通じて行うことができます。

スケジューリングには、以下のタスクが含まれます。

v ワークステーションの定義と保守

v スケジューリング・オブジェクトの定義

v ジョブ・ストリームの定義

v 実動処理の開始と停止

v ジョブおよびジョブ・ストリームの表示と変更。

スケジューリング・オブジェクトの定義スケジューリング・オブジェクトとは、ワークステーション、ワークステーション・クラス、ドメイン、ジョブ、ジョブ・ストリーム、リソース、プロンプト、カレンダー、変数、変数テーブル、パラメーター、イベント・ルール、および実行サイクル・グループです。スケジューリング・オブジェクトは composer プログラムを使用して管理され、IBM Workload Scheduler データベースに保管されます。オブジェクトを作成または変更するには、IBM Workload Scheduler コマンド行インターフェースか、いずれかのグラフィカル・インターフェースを使用することができます。

ジョブ・ストリームの作成IBM Workload Scheduler の主要な処理タスクは、ジョブ・ストリームの実行です。ジョブ・ストリームは、ジョブのリストから構成されたバッチ処理の枠組みです。ジョブ・ストリームは、コマンド行インターフェースか、いずれかのグラフィカル・インターフェースを使用して定義することができます。いずれかのグラフィカル・インターフェースを使用して、ジョブ・ストリームを簡単に作成および変更できます。それらのジョブ・ストリーム・エディターを使用して、ジョブやジョブ間の従属依存関係、およびジョブ・ストリーム実行サイクルを処理できます。ジョブ・ストリーム・レベルでの時間制限、リソース依存関係、ファイル依存関係、およびプロンプト依存関係を簡単に指定することもできます。

ジョブ・ストリームは、ドラフト として定義することができます。ドラフトのジョブ・ストリームは、依存関係を解決する際に考慮されず、実動計画には追加されません。このジョブ・ストリームは、draft キーワードがその定義から除去され、これを実動前計画に追加するために JnextPlan コマンドが実行され、その結果として実動計画に追加されてはじめて、実ジョブ・ストリームとなります。

ジョブのリカバリーの設定ジョブを定義する場合は、ジョブが正常に完了しないことがあることを考慮に入れてください。管理者は、ジョブの定義時にリカバリー・オプションおよびリカバリー・アクションを定義することができます。以下のリカバリー・オプションを使用できます。

v 次のジョブを続けない。これは、ジョブ・ストリームの実行を停止し、それをスタック 状態にします。これはデフォルトのアクションです。

第 5 章 IBM Workload Scheduler 47

v 次のジョブを続ける

v ジョブを再度実行する

オプションで、リカバリー・プロンプトをジョブに関連付けることができます。リカバリー・プロンプトは、ジョブが正常に完了しなかった場合に表示されるローカル・プロンプトです。処理は、プロンプトに対する肯定的な応答があるまでは続行されません。

もう 1 つのオプションとして、元のジョブが正常に完了しなかった場合に代わりに実行するためのリカバリー・ジョブを定義できます。リカバリー・ジョブは、事前に定義しておく必要があります。リカバリー・ジョブが正常に完了しない場合は、処理が停止します。

主幹業務であるジョブの定義と管理ジョブ・スケジューラー は、IBM Workload Scheduler コマンド行またはDynamic Workload Console を使用して、ジョブに主幹業務のフラグを立て、それらの締め切りを指定できます。クリティカル・ジョブとすべての先行ジョブは、クリティカル・ネットワーク と呼ばれるものを構成します。計画時に、IBMWorkload Scheduler は、クリティカル・ジョブの締め切りと推定所要時間に基づいて、クリティカル・ジョブと各先行ジョブの開始時刻を計算します。計画が実行される間、この情報は、計画の進行状況に基づいて動的に最新の状態に保持されます。先行ジョブやクリティカル・ジョブ自体が遅れていると、IBM WorkloadScheduler は、自動的にその実行依頼を優先し、それがより多くのシステム・リソースを確保できるようプロモートすることによって、締め切りに間に合うようにします。

クリティカル・ネットワーク内で、IBM Workload Scheduler は、潜在的にリスクの最も高い先行ジョブのパス (クリティカル・パス と呼ばれる) を動的に特定します。IBM Workload Scheduler は、各クリティカル・ジョブが持つ、締め切りに間に合わないリスクのレベルを計算します。高リスクは、クリティカル・ジョブの推定終了時期が締め切りを超えることを意味し、潜在的なリスクは、クリティカル・ジョブの先行ジョブの一部が、「遅れている」または「エラー状態にある」などの警告状態にあることを意味します。

Dynamic Workload Console には、クリティカル・ジョブと先行ジョブの進行を追跡するための専門ビューがあります。ジョブ・スケジューラー とオペレーターは、ダッシュボードから、または Monitor Critical Jobs タスクを作成することによって、このビューにアクセスできます。

初期ビューには、エンジンのすべてのクリティカル・ジョブがリストされ、通常、潜在的なリスク、または高リスクのいずれかの状況が示されます。オペレーターはこのビューをナビゲートして、以下を確認できます。

v クリティカル締切をリスク状態にするジョブのホット・リスト。

v クリティカル・パス。

v すべてのクリティカル先行ジョブの詳細。

v 完了したクリティカル先行ジョブの詳細。

v 既に稼働済みのジョブのジョブ・ログ。

48 IBM Workload Automation: 概要

このビューを使用して、オペレーターは、クリティカル・ネットワークの進行状況のモニター、現在および将来の問題の検出、依存関係の解放、およびジョブの再実行を行うことができます。

例:

1. 特定のクリティカル・ジョブにフラグを立て、それを追跡するために、ジョブ・スケジューラー は、Dynamic Workload Console で Workload Designer を開き、特定のジョブにクリティカルのマークを付け、締め切りを午前 5 時に設定します。

JnextPlan を実行すると、このジョブと、先行ジョブと識別されたすべてのジョブのクリティカル開始日付が計算されます。

2. 特定のクリティカル・ジョブを追跡するために、operatorは以下のようにします。

a. オペレーターはダッシュボードを調べて、エンジンの 1 つでクリティカル・ジョブがスケジュールされていることを確認します。

b. リンクをクリックし、クリティカル・ジョブのリストを取得します。

特定のジョブが潜在的なリスク の状況を示しています。

c. そのジョブを選択して「ホット・リスト」をクリックし、クリティカル・ジョブがリスク状態になる原因となった 1 つ以上の先行ジョブを確認します。

先行ジョブのいずれかが、エラーになったジョブとしてリストされています。

d. そのジョブを選択し、「ジョブ・ログ」をクリックします。

ログには、関連するデータベースの資格情報が誤っているためにジョブが失敗したことが示されます。

e. データベース・パスワードがその日に変更されたことが判明したので、symphony ファイルでジョブ定義を変更し、ジョブを再実行します。

f. ダッシュボードに戻って、潜在的なリスク状態にあるジョブがなくなっていることを確認します。また、ジョブの再実行後は、潜在的リスク・リンクをクリックしたときに開いたクリティカル・ジョブ・リストに、クリティカル・ジョブが表示されなくなります。

g. ジョブは、自動的にプロモートされた後に実行中であり、実行依頼とシステム・リソースに関して、より高い優先順位を持っています。

h. さらに問題を修正する必要はなく、クリティカル・ジョブは、午前 4:45 に最終的に完了します。

ワークロードの動的なスケジューリング実行時に、実行依頼されたワークロード (またはその一部) を使用可能な最善のリソースと動的に関連付けるよう IBM Workload Scheduler を設定することが選択できます。

第 5 章 IBM Workload Scheduler 49

IBM Workload Scheduler インストール処理の中に、動的なスケジューリング機能をインストールするオプションが含まれています。このオプションを選択すると、以下の機能を利用できるようになります。

v スケジューリング環境リソースの自動ディスカバー

v ジョブの要件と使用可能なリソースとを一致させること

v リソース利用の制御と最適化

v リソースの変更への自動的な対応

v 必要に応じた付加的なリソースの要求

拡張されたエージェントに対して実行されるよう定義されたジョブを含め、IBMWorkload Scheduler ジョブを実行依頼することができます。さらに、インストール時に J2EE のスケジュール実行のオプションを選択した場合は、J2EE アプリケーションについてもそれが可能です。ワークロードを動的にスケジュール実行するには、以下を実行します。

1. Dynamic Workload Console を使用して、ワークロードを実行するために論理リソースまたはリソース群として使用するエージェントを定義します。

2. IBM Workload Scheduler ジョブ定義を更新して、Dynamic Workload Brokerワークステーションを宛先 CPU にします (このワークステーションは、スケジューラー・エンジンとリソース・プールの間のブリッジの役割を果たします)。

3. すべての IBM Workload Scheduler ジョブについて、それぞれ JSDL (ジョブ実行依頼記述言語) ジョブ定義を追加します。その中で、必要なリソース、候補となるホスト、スケジューリングおよび最適化のさまざまな設定値とジョブとが一致するようにします。これは、Dynamic Workload Console を使用して簡単に実行できます。

このようにして計画内のジョブ・ストリームの一部として、または随時実行依頼により、ジョブが実行依頼されると、IBM Workload Scheduler は、ジョブ要件、使用可能リソース、および関連する特性をチェックし、要件を満たす最適なリソースに対してジョブを実行依頼します。

実動の実行実動は、データベースから、スケジューリング・オブジェクトの定義、およびそれらの時間制限と依存関係を取得すること、および実動制御ファイルを構築し、実行することから構成されます。

計画の実行実動計画には、実行するジョブ (およびそれらをどのフォールト・トレラント・エージェントで実行するか) についての情報と、各ジョブを起動する前に満たしておく必要のある依存関係についての情報が含まれています。IBM Workload Schedulerは、データベース内に保管されているモデル化データから、および実動前計画と呼ばれる中間計画から始めて実動計画を作成します。実動前計画は、製品が自動的に作成し、管理します。問題が起こらないように、データベースは、計画の生成中にはロックされます。生成が完了したとき、またはエラー条件が発生したとき、データベースはアンロックされます。実動前計画は、指定された時間枠に関係のあるジョブ・ストリーム・インスタンスおよび外部従属ジョブ・ストリーム依存関係を前もって識別するために使用されます。

50 IBM Workload Automation: 概要

マスター・ドメイン・マネージャーで JnextPlan コマンドを使用して実動計画を生成し、それを IBM Workload Scheduler ネットワーク全体に配布します。

新しい実動計画を生成して開始するために、IBM Workload Scheduler は以下のステップを実行します。

1. データベース内に定義されているオブジェクト (実動前計画が最後に作成または延長されてから追加または更新されたもの) を使用して実動前計画を更新します。

2. 指定された期間内に実行するジョブ・ストリームに関する情報を実動前計画から検索し、それを中間実動計画に保管します。

3. 直前の実動計画で完了しなかったジョブ・ストリームを新しい実動計画に組み込みます。

4. 新しい実動計画を作成し、Symphony という名前のファイルに保管します。実動計画データは、データベースにも複製されます。

5. この Symphony ファイルのコピーを、新しい実動計画の処理に関与するワークステーションに配布します。

6. 直前の実動計画に関するすべての統計をアーカイブに記録します。

7. 実動前計画内のジョブ・ストリーム状態を更新します。

新しく生成された Symphony ファイルのコピーは、最上位ドメインのフォールト・トレラント・エージェントと子ドメインのドメイン・マネージャーから始まり、ツリーの最下部のすべての従属ドメインに至るまで使用されます。

実動計画を受け取った各フォールト・トレラント・エージェントは、たとえドメイン・マネージャーとのネットワーク接続が停止しても、処理を継続することができます。

各宛先フォールト・トレラント・エージェントで、IBM Workload Scheduler は、ジョブ処理を管理するために以下のアクションを実行します。

1. Symphony ファイルのコピーにアクセスし、どのジョブを実行するかについての指示を読み取ります。

2. 必要に応じて、ジョブを起動するためにオペレーティング・システムを呼び出します。

3. 手持ちの Symphony ファイルのコピーをジョブ処理結果で更新し、ツリーの上部に位置するマスター・ドメイン・マネージャーとすべてのフル状況フォールト・トレラント・エージェントに通知を返信します。Symphony ファイルのオリジナル・コピーはマスター・ドメイン・マネージャー上に保管され、バックアップ・マスター・ドメイン・マネージャー上に保管されているコピー (バックアップ・マスター・ドメイン・マネージャーが定義されている場合) は、適宜更新されます。

つまり、ジョブ処理の実行時には、各フォールト・トレラント・エージェントは各自が実行中のジョブ (フォールト・トレラント・エージェントがフル状況エージェントまたはドメイン・マネージャーである場合にはそのドメインおよび子ドメインで実行中のジョブ) に関する情報で更新される独自の Symphony ファイルのコピーを持つことになります。また、マスター・ドメイン・マネージャー (定義されている場合にはバックアップ・マスター・ドメイン・マネージャーも) は、すべてのフ

第 5 章 IBM Workload Scheduler 51

ォールト・トレラント・エージェントから送られてくるすべての更新を含むSymphony ファイルのコピーを持つことになります。このようにして、マスター・ドメイン・マネージャー上の Symphony ファイルは、これから実行すべきジョブ、実行中のジョブ、およびすでに完了したジョブについて、常に最新に保たれます。

実動計画は、最初の生成後、JnextPlan コマンドを使用して次の実動期間に延長できます。 Symphony ファイルが最新の変更で更新され、ネットワーク全体に再配布されます。

ジョブ・ストリームの実行実行サイクルの定義に応じて、ジョブ・ストリームは IBM Workload Scheduler データベースから取り出され、現行実動計画に自動的に挿入されます。

ジョブ・ストリームが計画内にあり、完了していない間は、どのコンポーネントでも変更できます。すなわち、ジョブ・ストリームのプロパティー、そのジョブのプロパティー、順序、それらが使用するワークステーションまたはリソースなどを変更し、最終段階の要件を満たすことができます。

また、並行して実行できるジョブ・ストリーム内のジョブの最大数を変更できるだけでなく、ジョブ・ストリームを保留、解放、または取り消すことができます。すでにジョブ・ストリームに割り当てられている優先順位を変更したり、ジョブ・ストリームをそのすべての依存関係から解放することができます。

現行の実動計画に対する最終段階での変更には、すでに IBM Workload Schedulerデータベース内では定義されているが、計画には組み込まれなかったジョブおよびジョブ・ストリームを実行依頼する可能性が含まれます。随時定義されるジョブも実行依頼することができます。これらのジョブは、最新計画に対して実行依頼されますが、データベースには保管されません。

バージョン 8.3 からは、同じジョブ・ストリームの複数のインスタンスの作成および管理を、数日間にわたって、または同じ日のそれぞれ異なる時刻に行うことができるようになりました。この新機能により、1 つの計画内に同じジョブ・ストリームの複数のインスタンスを同じ名前で含めることが可能になりました。各ジョブ・ストリーム・インスタンスは、ジョブ・ストリーム名、その実行がスケジュールされているワークステーションの名前、および実動計画に定義されている開始時刻によって識別されます。

モニターモニターは、計画オブジェクトをリストすることによって行われます。リストを使用して、最新計画内の以下のオブジェクトのすべてまたはサブセットの状況を参照することができます。

v ジョブ・ストリーム・インスタンス

v ジョブ・インスタンス

v ドメイン

v ワークステーション

v リソース

52 IBM Workload Automation: 概要

v ファイル依存関係

v プロンプト依存関係

このリストを使用して、これらのオブジェクトのいくつかを管理することもできます。たとえば、リソースの再割り振り、ワークステーションのリンクまたはリンク解除、ジョブの強制終了、あるいはドメイン・マネージャーの切り替えなどを行えます。

さらに、Tivoli Business Service Manager を使用して日次計画をモニターできます。これは、IBM Workload Scheduler と統合されているオブジェクト指向システム管理アプリケーションで、リソース、アプリケーション、およびサブシステムのモニターとイベント管理を行う機能を提供します。

ネットワーク・マネージャーは、NetView アプリケーションの IBM WorkloadScheduler/NetView を使用して、IBM Workload Scheduler ネットワークをNetView 管理ノードからモニターおよび診断することができます。これには、IBMWorkload Scheduler ネットワークを形態的に表示し、各ワークステーションにおけるジョブ・スケジューリング活動の状況とクリティカルな IBM WorkloadScheduler プロセスを判別するための、サブマップとシンボルのセットが含まれています。IBM Workload Scheduler 処理を開始および停止し、ネットワーク内の任意のワークステーションで conman を実行するために、メニュー・アクションが提供されます。

IBM Tivoli Monitoring を使用した制御IBM Tivoli Monitoring は、事前に構成されたベスト・プラクティスを、必要不可欠なシステム・リソースの自動モニターに適用する製品です。この製品は、ボトルネックおよびその他の潜在的な問題を検出し、クリティカルな状況から自動的にリカバリーする手段を提供します。このように、この製品は、システム管理者が膨大なパフォーマンス・データを手動でスキャンする必要を除去します。

IBM Workload Scheduler と IBM Tivoli Monitoring との統合は、カスタマイズ可能なエージェントのインストールにより行います。この IBM Tivoli Monitoring エージェントは、データを収集して Tivoli Enterprise Monitoring Server に配布します。

IBM Tivoli Monitoring エージェントのインターフェースであるデータ・プロバイダーを使用することで、データ・ソース、クライアント・プログラム、URL、スクリプト、関連テーブル、または SNMP エージェントからデータを収集し、その収集されたデータを、それをモニターするカスタム IBM Tivoli Monitoring エージェントに転送できます。

IBM Tivoli Monitoring agent では、IBM Workload Scheduler との統合に、以下の異なった 2 つのデータ・プロバイダーが使用されます。

v スクリプト・データ・プロバイダーは、一定の間隔でスクリプトを実行し、エラー、異常、およびしきい値状態を見つけるためにスクリプト出力を構文解析することで、IBM Workload Scheduler データを収集します。以下のリソースがモニターされます。

– ホスト可用性

– アプリケーションの状況

第 5 章 IBM Workload Scheduler 53

– IBM Workload Scheduler の使用スペース

– IBM Workload Scheduler の使用可能ディスク・スペース

– ページアウト

– 使用可能なスワップ・スペース

– IBM Workload Scheduler メッセージ・ファイルのサイズ

v 順次テキスト・ファイルのデータをモニターするエージェント・ログ・ファイル・データ・ソース。それぞれの新規計画が生成されてからは、IBM WorkloadScheduler がすべてのモニター対象オブジェクト (例えば、ジョブ、ジョブ・ストリームなど) のイベントを IBM Workload Scheduler の Tivoli MonitoringAgentがアクセスするイベント・ファイルに書き込みます。収集されたデータは、Tivoli Enterprise Portal によって取得され、表示されます。

報告実動前プロセスおよび実動後プロセスの一部として、前回の実動日または次回の実動日に関する要約または詳細情報を示す報告書が生成されます。これらの報告書は、随時生成することもできます。以下の報告書が使用可能です。

v ジョブの詳細リスト

v プロンプト・リスト

v カレンダー・リスト

v パラメーター・リスト

v リソース・リスト

v ジョブ・ヒストリーのリスト

v ジョブのヒストグラム

v 計画された実動スケジュール

v 計画された実動の要約

v 計画された実動の詳細

v 実際の実動の要約

v 実際の実動の詳細

v 相互参照報告書

さらに、実動中には、IBM Workload Scheduler によって起動されたジョブ・インスタンスごとに、標準リスト・ファイル (STDLIST) が作成されます。標準リスト・ファイルには、ヘッダーおよびトレーラーのバナー、エコーされたコマンド、およびエラーと警告が入っています。これらのファイルは、ジョブ実行における問題のトラブルシューティングに使用できます。

監査監査オプションは、データベースおよび計画に対する変更の追跡に役立ちます。

データベースの場合には、変更の差分を除くすべてのユーザー変更がログに記録されます。オブジェクトがオープンされ保管された場合には、変更が行われていなくてもそのアクションがログに記録されます。

54 IBM Workload Automation: 概要

計画の場合には、計画に対するすべてのユーザー変更がログに記録されます。アクションは、成功したかどうかに関わらずログに記録されます。

監査ファイルは、IBM Workload Scheduler ネットワーク内の個々のマシン上のフラット・テキスト・ファイルにログ記録されます。これにより、ネットワークの問題に起因した監査障害のリスクは最小限に抑えられ、ログの書き込みの直接的なアプローチが可能になります。ログの形式は、基本的には計画とデータベースの両方の場合で同じです。ログは、すべてのレコードに共通のヘッダー部分、「アクション ID」、およびアクションのタイプに応じて変わるデータのセクションから構成されます。すべてのデータは、VI またはメモ帳などのテキスト・エディターから読み取りと編集ができるようにフォーマットされ、平文として保管されます。

イベント・ドリブン・ワークロード自動化の使用このオプション機能を使用して、エージェントで発生する特定のイベントに応じて、定義済みアクションを実行するルールをセットアップおよび実行します。組織でこの機能を使用すると、計画ベースのジョブ・スケジュールにオンデマンドのワークロード自動化が追加されるため、時間とリソースを節約できます。

イベント・ドリブン・ワークロード自動化は、イベント・ルールの概念に基づいています。IBM Workload Scheduler では、イベント・ルールはスケジューリング・オブジェクトであり、イベント、イベント関連付け条件、およびアクションによって構成されます。イベント・ルールを定義する場合、1 つ以上のイベント、相関ルール、およびそれらのイベントによってトリガーされる 1 つ以上のアクションを指定します。さらに、有効日付、アクティビティーの日次時間間隔、および設定されるすべての時間制限の共通時間帯を指定することもできます。

イベント・ルールをセットアップして、以下のことを実行できます。

v リアルタイム・イベントの発生または組み合わせに基づいて、バッチ・ジョブおよびジョブ・ストリームの実行をトリガーする。

v プロンプトに応答する。

v 異例の条件が IBM Workload Scheduler スケジューリング環境またはバッチ・スケジューリング・アクティビティーで発生した場合にユーザーに通知する。

v 特定のイベント条件が発生した場合、外部製品を呼び出す。

IBM Workload Scheduler は、定義済みイベント・セットとアクション・プラグインを含んでいます。また、アプリケーション・プログラマーが独自のプラグインを開発するためのサンプルとテンプレートを備えたソフトウェア開発キットも提供します。

オプションおよびセキュリティーIBM Workload Scheduler オプション・ファイルは、ユーザーのシステムでの IBMWorkload Scheduler の実行方法を決定します。いくつかのパフォーマンス、調整、セキュリティー、ロギング、およびその他の構成オプションが使用可能です。

IBM Workload Scheduler オプションの設定2 つのタイプのプロパティーを設定して IBM Workload Scheduler ランタイム環境を構成できます。すなわち、マスター・ドメイン・マネージャーで設定し、IBM

第 5 章 IBM Workload Scheduler 55

Workload Scheduler ネットワーク内のすべてのワークステーションでの処理に影響を与えるプロパティーと、ワークステーションでローカルに設定し、そのワークステーションでの処理にのみ影響を与えるプロパティーです。前者は、optman という名前の IBM Workload Scheduler コマンド行プログラムを使用して管理します。後者は、構成ファイル useropts、localopts、および jobmanrc をカスタマイズしてワークステーションでローカルに定義します。

グローバル・オプションは、以下に挙げることのために使用されます。

v ネットワーク内のすべてのワークステーションのセキュリティー・ファイルをマスター・ドメイン・マネージャーからのみ作成および管理できるようにするか、または各ワークステーション独自のセキュリティー・ファイルをそのワークステーションの root ユーザーまたは管理者が作成および管理できるようにするかを定義します。

v データベース監査を使用可能にするか、使用不可にするかを選択します。

v 照会の実行時に、計画内のどのオブジェクトのリストをユーザーに許可するかを制御します。

v 計画監査を使用可能にするかどうかを選択します。

v 強い暗号化を使用可能にするかどうかを選択します。

v フォールト・トレラント・スイッチ・マネージャーを使用可能にするか、使用不可にするかを選択します。

v 時間帯オプションを使用可能にするか、使用不可にするかを選択します。

v ジョブ統計を保管する日数を入力します。

v 実動前計画の最小および最大の長さを日数単位で設定します。

v 未完了のジョブ・ストリームを旧実動制御ファイルから新規実動制御ファイルへ繰り越すかどうかを決定します。

v エラーで終了した計画からジョブ・ストリーム・インスタンスを除去またはクリーンアップします。

v IBM Workload Scheduler 処理日の開始時刻を定義します。

ローカル・オプションは、以下のことのために使用されます。

v ローカル・ワークステーションの名前を指定します

v UNIX で root により実行されるジョブの起動を防止します

v システムへの不明のクライアントの接続を防止します

v いくつかのパフォーマンス・オプションを指定します

v いくつかのロギングの設定を指定します

v SSL セキュリティー・オプションを設定します。

セキュリティーの設定セキュリティーは、1 つ以上のユーザー定義が入っているセキュリティー・ファイルを使用して達成されます。それぞれのユーザー定義は、ユーザーのセット、そのユーザーがアクセスを許可されたオブジェクト、およびユーザーが実行できるアクションのタイプを識別します。

製品とともにテンプレート・ファイルがインストールされます。このテンプレートを編集してユーザー定義を作成し、これをユーティリティー・プログラムを使用し

56 IBM Workload Automation: 概要

|

|

てコンパイルおよびインストールして、新規操作可能セキュリティー・ファイルを作成します。それがインストールされた後に、別のユーティリティーを使用して編集可能コピーを作成することによって、さらに変更します。

個々のファイルを各ワークステーションで維持することもできれば、あるいは単一のセキュリティー・ファイルをマスター・ドメイン・マネージャーに作成して、ドメイン・マネージャー、フォールト・トレラント・エージェント、および標準エージェントのそれぞれにコピーすることもできます。

セキュアな認証および暗号化Secure Sockets Layer (SSL) プロトコルに基づいて認証および暗号化メカニズムを適用することにより、保護ドメインと無保護ドメイン間の接続のセキュリティーが拡張されています。 SSL は、デジタル証明書を使用してワークステーションの IDを認証します。

IBM Workload Scheduler 管理者は、ネットワーク内での認証の使用方法を計画する必要があります。

v IBM Workload Scheduler ネットワーク全体に対して 1 つの証明書を使用する。

v 各ドメインごとに別々の証明書を使用する。

v 各ワークステーションごとに別々の証明書を使用する。

IBM Workload Scheduler では、SSL サポートが自動的にインストールされます。

ファイアウォールを介した作業これまでのバージョンの IBM Workload Scheduler では、ワークステーションを開始または停止するコマンド、または標準リストを入手するためのコマンドを実行するには、発信元ノードと宛先ノード間の直接の TCP/IP 接続を開く必要がありました。ファイアウォール環境では、この理由で、ファイアウォールを強制的に中断してネットワーク上のマスターと各フォールト・トレラント・エージェント間の直接通信パスを開かなければなりません。

IBM Workload Scheduler では、データベースのワークステーション定義に、behindfirewall と呼ばれる構成可能な属性があります。この属性をオンに設定して、その特定のワークステーションとそのドメイン・マネージャー間にファイアウォールが存在していること、およびドメイン・マネージャーとワークステーション (場合によっては、別のドメイン・マネージャー) 間のリンクが、ドメイン間で許可された唯一のリンクであることを示すことができます。

また、この属性がオンに設定されたすべてのワークステーションでは、ワークステーションを開始または停止するためのコマンド、または標準リストを入手するためのコマンドが、マスター (またはドメイン・マネージャー) とワークステーション間の直接接続を開くのではなしに、ドメイン階層を介して送信されます。

集中化セキュリティー・メカニズム新規のグローバル・オプションにより、IBM Workload Scheduler ネットワークのセキュリティー・モデルを変更することが可能になります。このオプションを使用すると、ネットワークのフォールト・トレラント・エージェント用のセキュリティー・ファイルをマスター・ドメイン・マネージャーでのみ作成または変更できま

第 5 章 IBM Workload Scheduler 57

す。IBM Workload Scheduler 管理者は、ユーザー・アクセスが必要なすべてのエージェントのセキュリティー・ファイルの作成、更新、および配布を担当します。このグローバル・オプションを設定すると、そのマスター・ドメイン・マネージャーに対応する IBM Workload Scheduler ネットワークを識別および信任するセキュリティー・メカニズムが起動します。

従来のセキュリティー・モデルを使用したい場合は、グローバル変数を活動化しなければ、引き続き使用することができます。

時間帯の使用IBM Workload Scheduler は、異なる時間帯をサポートします。時間帯を使用可能にすると、ワークロードを 1 つの複数時間帯環境全体にわたって管理できるようになります。 IBM Workload Scheduler の現行バージョンでは、3 文字表記と可変長表記の両方がサポートされています。可変長表記のフォーマットは、ECT (ヨーロッパ中央時間) の場合と同様で、「地域/都市」です (例えば、Europe/Paris)。 3 文字表記は、以前のバージョンの製品の機能を使用する目的でサポートされています。

時間帯は、いったん構成されると、ジョブおよびジョブ・ストリーム内の開始時刻と締切時刻に対して指定することができます。

IBM Workload Scheduler のアクセス方式の使用アクセス方式を使用して、IBM Workload Scheduler のジョブ・スケジューリング機能を他のシステムやアプリケーションに拡張します。アクセス方式は、以下のように動作します。

v 拡張エージェント

v 動的エージェントおよび IBM Workload Scheduler for z/OS エージェント

詳細については、 59 ページの『サポートされているエージェント』を参照してください。

アクセス方式は、コマンド行または Dynamic Workload Console を使用して外部システムと対話する必要があります。IBM Workload Scheduler には、以下のアクセス方式が組み込まれています。

v PeopleSoft (psagent)

v SAP R/3 (r3batch)

v z/OS (mvsjes および mvsopc)

拡張エージェントと動的エージェントの標準的な構成を 59 ページの図 5 に示します。

58 IBM Workload Automation: 概要

サポートされているエージェントIBM Workload Scheduler のアクセス方式は、拡張エージェントと動的エージェント (IBM Workload Scheduler for z/OS エージェントを含む) で実行できます。

1 つ以上の外部アプリケーション (PeopleSoft、SAP R/3) に IBM WorkloadScheduler のスケジューリング機能を拡張できます。IBM Workload Scheduler を使用してそれらの外部アプリケーションでスケジューリング機能を拡張するために必要なエージェントは、以下のとおりです。

拡張エージェント

拡張エージェントは、静的スケジューリング機能を拡張します。IBMWorkload Scheduler の物理ワークステーション (別の拡張エージェントではない) をホストとするアクセス方式に関連した論理ワークステーションです。複数の拡張エージェント・ワークステーションは、同一の IBMWorkload Scheduler ワークステーションでホストされることが可能で、その場合、それらのワークステーションは同一アクセス方式に依存します。拡張エージェントは標準の IBM Workload Scheduler ワークステーション定義に定義されます。このワークステーション定義は、拡張エージェントに名前を与え、アクセス方式を識別します。アクセス方式は、IBM WorkloadScheduler が外部システムにジョブを実行依頼するたびに、ホスティング・ワークステーションで実行されるプログラムです。

図 5. サポートされているエージェント構成

第 5 章 IBM Workload Scheduler 59

拡張エージェントでジョブを定義する方法は、基本的に他の IBMWorkload Scheduler ワークステーションの場合と同じですが、ジョブ属性は、外部システムまたは外部アプリケーションによって異なります。

拡張エージェント上でジョブを起動しモニターするために、ホストはアクセス方式を実行して、それにコマンド行オプションとしてジョブ詳細を渡します。アクセス方式は、外部システムと通信してジョブを起動し、ジョブの状況を戻します。外部環境でジョブを起動するために、IBM WorkloadScheduler は、拡張エージェント・アクセス方式を実行し、拡張エージェント・ワークステーション名と、ジョブに関する情報を提供します。この方式では、XANAME_accessmethod.opts (XANAME は拡張エージェントのワークステーションの名前) という名前の対応するファイルを調べて、接続先の外部環境インスタンスを判別します。これでアクセス方式ではそのインスタンスでジョブを起動して完了するまでモニターでき、ジョブの標準リスト・ファイルにジョブ進行および状況情報を書き込みます。

物理ワークステーションは、最大 255 の拡張エージェントをホスティングできます。

拡張エージェントは、エンドツーエンド環境でジョブを実行するためにも使用できます。この場合、スケジューリング・タスクとモニター・タスクは、IBM Workload Scheduler for z/OS のコントローラーによって実行されます。

動的エージェントと IBM Workload Scheduler for z/OS エージェント (z-セントリック)

動的エージェントを使用して外部アプリケーションでアクセス方式を実行するには、アクセス方式タイプのジョブを定義します。アクセス方式は、外部システムと通信してジョブを起動し、ジョブの状況を戻します。この方式は、optionsfile_accessmethod.opts (optionsfile は、選択したアクセス方式に応じた構成ファイル) という名前の対応するファイルを参照します。動的エージェントと IBM Workload Scheduler for z/OS エージェントには、接続先の外部環境インスタンスを決定するための .opts ファイルが複数関連付けられていることもあります。アクセス方式は、そのインスタンスでジョブを起動して完了までモニターし、ジョブの標準リスト・ファイルにジョブの進行情報と状況情報を書き込むことができます。

60 IBM Workload Automation: 概要

第 6 章 IBM Workload Scheduler for z/OS

IBM Workload Scheduler for z/OS は、データ処理 (DP) 操作の自動化の有効範囲を拡張します。これは、実動ワークロードを計画し、自動的にスケジュールします。単一の制御点から、ローカル・サイトとリモート・サイトの両方のサイトでワークロード処理を実行し制御します。 IBM Workload Scheduler for z/OS を使用して自動化を進めることによって、ユーザーは、DP リソースをより効率的に使用し、DP 資産をより効果的に制御し、また、実動ワークロード処理をより適切に管理します。

実動ワークロードを管理する方法IBM Workload Scheduler for z/OS は、これらのすべてをどのようにして実現させるのでしょうか。ここでは、情報システム (IS) 操作をより効率的に実行する機能について説明します。しかし、その前に製品の構造といくつかの概念について簡単に紹介します。

構造IBM Workload Scheduler for z/OS は、基本製品であるエージェント と、いくつかの機能から構成されます。複合システム内の各 z/OS システムには、この基本製品が必要です。複合システム内の 1 つの z/OS システムが制御 システムに指定され、エンジン 機能を実行します。シスプレックス内の他の z/OS システムで複数のスタンバイ・エンジンを開始したい場合であっても、必要とされるエンジン機能は 1 つだけです。

IBM Workload Scheduler をもつ IBM Workload Scheduler for z/OS は、分散環境内の実動ワークロードを対象にします。ユーザーは、IBM Workload Scheduler内のジョブを IBM Workload Scheduler for z/OS からスケジュール、制御、およびモニターすることができます。例えば、最新計画内で、IBM Workload Schedulerのワークステーションで実行するためのジョブを指定することができます。

IBM Workload Scheduler for z/OS に備わっているオープン・インターフェースにより、他の操作環境におけるワークロードも同様に制御することができます。TCP/IP または NJE/RSCS (ネットワーク・ジョブ入力/リモート・スプーリング通信サブシステム) の組み合わせを使用するサンプル・プログラムが、現在スケジューリング機能を持っていない環境で、ユーザーがワークロードをどのように制御できるかを示しています。

さらに、各国語機能を使用すると、選択した言語でダイアログとメッセージを表示することができます。以下の言語が現在使用できます。v 英語v ドイツ語v 日本語v 韓国語v スペイン語

61

また、企業固有の指示とヘルプを組み込むようにパネルとメッセージ・テキストも変更することができます。

概念用語の定義。本章では、同じ概念を以下の同義語で言い換えて表します。

概念ワークロード・スケジューリ

ングでの用語IBM Workload Scheduler

for z/OS の用語

ジョブおよびジョブを実行するために使用する情報のリスト。製品データベースに定義されているスケジューリング・オブジェクト。

ジョブ・ストリーム アプリケーション

IBM Workload Schedulerfor z/OS 計画に入力されたときの特定のジョブ・ストリーム (アプリケーション)。これは、特定の実行日時によっても定義されます。

ジョブ・ストリーム・インスタンス (job stream instance)

オカレンス

タスク、コマンド、または複数のタスク。

ジョブ 操作

計画内のジョブ。 ジョブ・インスタンス 操作

実動ワークロードの管理に関し、IBM Workload Scheduler for z/OS はいくつかの重要な概念に基づいて構築されています。

計画。 IBM Workload Scheduler for z/OS は、DP 運用部門のユーザー提供の記述と実動ワークロードに基づいて、操作計画 を構成します。これらの計画は、ユーザーのサービス・レベル・アグリーメントの基礎を提供し、任意の時点で、その時点の実動ワークロードの状況をユーザーに示します。 試行計画を生成することによって、実動ワークロード、カレンダー、およびインストール・システムに対する変更の影響をシミュレートすることができます。

アプリケーション。 ジョブ・ストリーム とも呼ばれます。アプリケーションとは、実動作業単位の記述です。ジョブ・ストリームには以下のものを含めることができます。

v 一連の操作 (別名 ジョブ) のリスト。これは、作業単位に関連付けられた以下のようなタスクです。– データ入力– ジョブ準備– ジョブ実行依頼または開始タスクの開始– NetView プログラムとの通信– 他の操作環境へのファイル転送– 出力の印刷– 品質制御またはディスパッチなどの後処理活動– スケジュール、制御、および追跡を行いたい、作業単位に関連する他のタス

ク

62 IBM Workload Automation: 概要

v ジョブ・ストリーム内のジョブ間および他のジョブ・ストリームのジョブ間の依存関係の記述

v データ・セットの専用使用などのリソース要件についての情報

v ジョブと関連付けられる特殊な操作員指示

v 各ジョブを処理する方法と処理する場所

v その作業単位の実行方針、すなわち、いつスケジュールする必要があるか、あるいはこれに代えて、実行方針を記録するグループ定義の名前

IBM Workload Scheduler for z/OS は、アプリケーション (ジョブ・ストリーム)記述に指定された情報に基づいて作業をスケジュールします。

ワークステーション。 作業のスケジュールおよび処理時に、IBM WorkloadScheduler for z/OS は、各ジョブの処理要件を考慮します。以下に標準的な処理の考慮事項をいくつか挙げます。

v 作業の処理に必要な人的リソースまたはマシン・リソース。例えば、オペレーター、プロセッサー、印刷装置など。

v これらのリソースがいつ使用可能か。

v どのようにこれらのジョブを追跡するか。

v リソースが使用不能になった場合に、他の場所でこの作業を処理できるか。

IBM Workload Scheduler for z/OS は、実動ワークロード内のすべてのタスクの処理要件をマップするワークステーション と呼ばれる一定範囲の作業プロセス・タイプをサポートします。それぞれのワークステーションが、1 つのタイプの活動をサポートします。これにより、以下に挙げるものを含めて、任意のタイプの DP 活動のスケジュール、モニター、および制御での柔軟性が得られます。v ジョブのセットアップ (手動と自動の両方)v ジョブ実行依頼v 開始タスク・アクションv NetView プログラムとの通信v 印刷ジョブv 手動の前処理または後処理活動

ユーザーのハードウェア環境とソフトウェア環境で保守時間枠を計画することができます。 IBM Workload Scheduler for z/OS は、ユーザーが制御された、問題のない環境のシャットダウンを実行するのを助け、アクティブ・タスクが最終段階で取り消されることを防止します。計画または計画外のすべての停止の間、自動的にワークロードを転送するように選択することができます。

IBM Workload Scheduler for z/OS は、ワークステーションで処理されるときにジョブを追跡し、ジョブの状況についてのリアルタイム情報で計画を動的に更新します。ダイアログでのワークステーション用の作動可能リストを使用して、この状況情報をオンラインで表示または変更することができます。

仮想ワークステーション。仮想ワークステーションを使用すると、システム可用性のワークロード・バランシングおよびモニタリングが改善されます。この機能によって、ワークロードの実行依頼が異なる宛先に自動的に送信されるため、ワークステーションを特定の宛先に関連付ける必要がなくなります。ワークロードの実行依

第 6 章 IBM Workload Scheduler for z/OS 63

頼用宛先リストを定義できるため、スケジューラーは、周期的スケジューリング方式に従って、自動的に選択されたアクティブな宛先にワークロードを分散します。

ワークステーション定義レベルで新規仮想オプションを指定することによって、この機能を活動化できます。このオプションは、自動レポート作成属性を持ったコンピューター・ワークステーションで許可され、ワークステーションの定義、変更、モニターに使用できるすべてのインターフェースによってサポートされます。

スケジューラーは、仮想ワークステーションを使用して、ワークロードをトラッカーに均等に分散することによって、ジョブの実行依頼または実行の際のボトルネックを回避します。実際に、スケジューラーはワークロードを使用可能な宛先に分割するため、Job Entry System (JES) と Workload Manager (WLM) がアクション用にジョブを選択するときに、過負荷の入力キューは検出されません。

依存関係。 一般に、すべての DP 関連活動は特定の順序で起こる必要があります。誤った順序で活動が実行されると、無効な出力が作成される場合があり、企業データが破壊される場合さえあります。この結果、再実行に費用がかかり、締切期限を守ることができず、顧客を満足させることができません。

特定の処理順序で実行する必要がある場合は、操作 (ジョブ) の依存関係 を定義することができます。ユーザーに代わって IBM Workload Scheduler for z/OS で依存関係を管理すれば、ジョブは、必ず、スケジュールされるたびに正しい順序で開始されます。依存関係が同じジョブ・ストリーム内の 2 つのジョブの間にある場合は、その依存関係は内部依存関係 と呼ばれ、相異なるジョブ・ストリーム内の 2つのジョブの間にある場合は外部依存関係 と呼ばれます。先行操作が完了してからでないと後続操作を開始できない場合、その先行 操作と後続 操作の間に依存関係が生まれます。

依存関係の解決は、先行操作および後続操作が含まれるアプリケーションの入力到着時間 (特定のアプリケーション・オカレンスの定義に役立つ、理論上の起動時間)に基づいて行われます。その依存関係に定義された基準に従って最適一致する先行操作が検出されると、依存関係が解決されます。基準として、後続操作に対して最も近い先行するオカレンス内、あるいは同じ日または特定の日数または時間間隔内に実行されるオカレンス内で最適一致を検出できることを指定できます。また、さまざまな程度で依存関係を必須として定義することもできます。

さらに、条件付き依存関係 を指定することもできます。条件付き依存関係では、操作の戻りコードと状況を使用して、別の操作の開始を決定します。状況値や戻りコード値の検査を定義するための標準的な論理演算子がサポートされています。これにより、条件論理 を使って依存関係の定義を実装できます。先行操作が、ステップの異なるジョブに関連付けられている場合、個々のステップ戻りコードに対して、条件付きのステップ・レベル依存関係 を指定できます。

IBM Workload Scheduler for z/OS を使用すれば、作業を任意の DP リソースの状況に基づいて逐次化することができます。典型的な例は、入力としてデータ・セットを使用するが、そのデータ・セットが有効なデータで正しく作成されロードされるまで開始できないジョブです。リソース逐次化 サポートを使用すれば、DP リソースに関する可用性情報を IBM Workload Scheduler for z/OS に送信することができます。

64 IBM Workload Automation: 概要

特殊リソース。 特殊リソースは、典型的な例では、ジョブが使用する物理または論理オブジェクトを表すために定義されます。特殊リソースは、データ・セットへのアクセスを逐次化するために、あるいは特定のネットワーク・リンクのファイル転送の数を制限したりするために使用できます。リソースは、しばしばユーザーの構成内の物理オブジェクトを表しますが、必ずしも構成の物理オブジェクトを表す必要はありません。

IBM Workload Scheduler for z/OS は、各リソースの状態とその現在の割り振り状況の記録を行います。リソースを割り振るジョブが異常終了した場合には、リソースを保持することを選択できます。また、リソース・オブジェクト・データ・マネージャー (RODM) との IBM Workload Scheduler for z/OS インターフェースを使用して、ジョブを実 リソースの可用性に従ってスケジュールすることができます。ローカル・ドメインとリモート・ドメインの両方で RODM 更新にサブスクライブすることができます。

IBM Workload Scheduler for z/OS によって、ユーザーは、z/OS システム上のデータ・セット活動にサブスクライブ することができます。データ・セットがクローズされたときには、IBM Workload Scheduler for z/OS のデータ・セット起動機能が、自動的に特殊リソースの可用性を更新します。この通知を使用して、計画された活動を調整するか、またはスケジュールに計画外の作業を追加することができます。

カレンダー。 IBM Workload Scheduler for z/OS は、処理リソースが使用できない日 (例えば、日曜日や祝祭日) にジョブ・ストリームの実行をスケジュールしないように、いつジョブ部門が作業するかについての情報を使用します。この情報は、カレンダー に保管されます。 IBM Workload Scheduler for z/OS は、就業日と非就業日が異なる複数の部門のある企業向けに複数のカレンダー をサポートします。1 つの業務内の複数の異なるグループは、複数の異なるカレンダーに従って運用されます。

地理的に複数の場所 (たとえば、別の地方の祝祭日または国民の祝日を持つ) にインストール・システムがある企業では、複数のカレンダー機能は重要です。

業務の処理周期。 IBM Workload Scheduler for z/OS は、業務の処理周期、すなわち、期間 を使用して、ジョブ・ストリームをいつ実行するか (例えば、週ごと、または 10 就業日ごと) を計算します。期間は、顧客の業務周期に基づいています。 IBM Workload Scheduler for z/OS は、実動ワークロード内の種々のジョブ・ストリームを処理するために、ある一定範囲の期間をサポートします。

ジョブ・ストリームを定義する場合には、それを実行する予定の時点を実行サイクル を使用して指定します。実行サイクルとしては、以下のものが可能です。

v 以下のような形式の規則。

ONLY the SECOND TUESDAY of every MONTH

EVERY FRIDAY in the user-defined period SEMESTER1

ここで、大文字の語は序数、曜日、および共通カレンダー間隔または期間名のリストから選択されます。

v 期間とオフセット の組み合わせ。たとえば、月期間のオフセットが 10 であれば、毎月 10 日目を指定します。

第 6 章 IBM Workload Scheduler for z/OS 65

実行サイクル・グループ。アプリケーションの定義を構成する要素の 1 つは、実行サイクルです。実行サイクルには、時間、日、週、月、または期間によりアプリケーション実行に関する時間的な詳細 (および、その他の詳細) を指定します。アプリケーションには、複数の実行サイクルを定義でき、それらはそのアプリケーションの定義の一部になります。実行サイクルのタイプには、定期、除外、ルール・ベース、期間などがあります。

さらに一歩進めて、実行サイクル・グループを定義することもできます。実行サイクル・グループは独立したデータベース・オブジェクトであり、アプリケーションの定義の一部ではありませんが、同じ実行サイクル・グループを複数のアプリケーションに使用できます。実行サイクル・グループは、実行サイクルのリストです。これらの実行サイクルが結合されて、一連の実行日付が生成されます。

実行サイクル・グループは、サブセットに構造化できます。サブセット内で、除外実行サイクルを正の実行サイクルに突き合わせることで、負のオカレンスを生成できます。負のオカレンスは、通常は実行されるようにスケジュールされているアプリケーションが迂回される日を識別します。

グループ内の 2 つの実行サイクルの間に、論理 AND を使用することができます。これにより、複雑な実行日付に作業をスケジュールするルールを容易に定義できます。

IBM Workload Scheduler for z/OS での計画の使用IBM Workload Scheduler for z/OS は、実動ワークロード・スケジュールを計画します。上位の計画および詳細な計画が作成されます。これらの計画はどちらも実動ワークロードを駆動し、指定した任意の時刻におけるシステムの実動ワークロードの状況をユーザーに示します。また、将来のワークロードを予測するための試行計画を作成することができます。

長期計画長期計画 は、ユーザーの予測した実動ワークロードの上位スケジュールです。これは、計画の期間中に実行すべきジョブ・ストリームのインスタンスを日別にリストします。ジョブ・ストリームの各インスタンスはオカレンス と呼ばれます。長期計画は、ジョブ・ストリーム間に存在する依存関係だけでなく、オカレンスをいつ実行すべきかを示します。これらの依存関係を、ユーザーのワークステーションでネットワークとして図示して、作業が正しく定義されているかどうかを調べることができます。この計画を使用すると、処理の負荷が大きい日についての予測と計画を行うのに役立ちます。長期計画機能は、計画期間中の個々のワークステーションについての、計画されたリソース使用を示すヒストグラムも作成することもできます。

サービス・レベル・アグリーメントを文書化する際の基礎として長期計画を使用することができます。顧客が彼らの作業がいつどのように処理されるかを知ることができるように、長期計画により、ユーザーはサービス・レベル・アグリーメントを実動ワークロード・スケジュールに直接関連付けます。

長期計画は、将来の時間枠を提供します。どの程度先にするかは、ユーザーが 1 日から 4 年まで自由に決められます。また、将来の任意の 日について長期計画シミュレーション報告書を作成することもできます。 IBM Workload Scheduler for

66 IBM Workload Automation: 概要

z/OS は、長期計画を定期的に自動的に延長することができます。長期計画を報告書として印刷することができ、あるいはダイアログを使用してオンラインでそれを表示、変更、および延長することができます。

詳細計画最新計画 は、IBM Workload Scheduler for z/OS 処理の中心となります。これは、実動ワークロードを自動的に実行し、その状況を検査する方法を提供します。最新計画は、指定した期間内に起こるオカレンスを長期計画から抽出するバッチ・ジョブを実行することによって、ジョブの詳細から作成されます。最新計画は、長期計画からある時間枠を選択し、ジョブを実行できる状態にします。ジョブは、決定された制限 (例えば、依存関係、リソース可用性、または時間依存ジョブ) に応じて開始されます。

最新計画は、数日をカバーするローリング型の計画です。共通方式は、各勤務時間について通常の延長がある 1 日から 2 日をカバーします。実動ワークロード処理活動は分ごとにリストされます。

最新計画を報告書として印刷するか、あるいはダイアログを使用して、オンラインでそれを表示、変更、および延長することができます。

実動ワークロードの自動制御IBM Workload Scheduler for z/OS は、ワークフローをモニターし、ジョブの処理が計画で確立されている業務の優先順位に従うように指示することによって、実動ワークロードを自動的に実行します。

IBM Workload Scheduler for z/OS は、NetView プログラムに対するインターフェースまたはその例外管理の ISPF ダイアログを使用して、実動ワークロード処理の問題に関するアラートを実動制御の担当者に対して出力できます。さらに、NetView プログラムは、IBM Workload Scheduler for z/OS を自動的に起動して、これらの問題に対応した修正アクションを実行することができます。

IBM Workload Scheduler for z/OS は、以下のことを自動的に行います。

v 開始タスクの開始と停止

v JOB ステートメント (実行依頼前の z/OS JCL またはその他の操作環境での同等の JOB ステートメント) の編集。

v 指定した順でターゲット操作環境にジョブを毎回実行依頼する

v 計画内の各スケジュール済みジョブを追跡する

v ジョブの成功または失敗を判別する

v ワークステーション・オペレーターをガイドするために状況情報と指示を表示する

v ジョブがエラーで終了したときに、操作環境が何であるかには関係なく、自動リカバリーを提供する

v 以下のような規則を使用して、ジョブ・ストリーム実行サイクルのための処理の日付を生成する– 月の第 2 火曜日– 6 月、7 月、および 8 月の最後の土曜日のみ– ユーザー定義の PAYROLL 期間内のすべての第 3 就業日

第 6 章 IBM Workload Scheduler for z/OS 67

v 実リソース可用性に基づいてジョブを開始する

v z/OS ワークロードに対して、エラーおよび再実行の状況で、データ・セット・クリーンアップを実行する

v z/OS ジョブと開始タスクのステップ再始動用に JCL を調整する

v 計画できない活動への対応として、追加の処理を動的にスケジュールする

v 更新されたデータ・セットがクローズされたときに、自動通知を出す。これは、順次処理を起動するために使用できます。

v ワークロード内で異常な状況が検出されたときにアラートを生成する

また、IBM Workload Scheduler for z/OS は、 73 ページの『手動での制御と介入』で説明されている手動制御機能も提供します。

自動ワークロード実行依頼IBM Workload Scheduler for z/OS は、システムを通じて、手動またはプログラムにより記録される完了を必要とする作業を考慮に入れて、作業を自動的に実行します。プログラムにより記録される完了とは、スケジューラーにより制御されるジョブの状況が、ユーザー作成プログラムによって「完了」に設定された状況を指します。これは、リソースの最適な使用を促進し、システム可用性を改良し、複雑で繰り返されるオペレーター・タスクを自動化します。 IBM Workload Schedulerfor z/OS は、以下のものに従って、作業の実行依頼を自動的に制御します。v ジョブ間の依存関係v ワークロード優先順位v 特定作業の実行依頼のために指定された時刻v リソースの可用性

計画内の特定ジョブのそれぞれ別個の実行またはオカレンスに対する JCL のコピーを保管することによって、IBM Workload Scheduler for z/OS は、指定変更などの一時的な JCL の変更の意図しない再使用を防止します。

ジョブの調整。 IBM Workload Scheduler for z/OS は、ジョブを自動的に編集するジョブの自動調整機能を提供します。これによって、長時間を要しエラーが発生しがちな手作業によるジョブの編集への依存度を少なくすることができます。 IBMWorkload Scheduler for z/OS のジョブの調整は、以下のことが行われます。v 自動変数置換v インライン JOB ステートメントの動的組み込みと除外v 他のライブラリーまたは出口からの JOB ステートメントの動的組み込み

z/OS システムで実行依頼されるジョブの場合、これらのジョブ・ステートメントは z/OS JCL です。スケジューラー JCL 調整ディレクティブを、AIX®/6000 などの他のオペレーティング・システムで実行依頼されるジョブに組み込むことができます。

変数は特定の列を置換することができ、無効なストリングで置換されないように検証基準を定義することができます。ジョブ・ストリーム・プログラムで使用される各種の日付形式をサポートする特殊なディレクティブを使用すると、必要な形式を動的に定義し、同じジョブ内で何回も変更することができます。算術式を定義し

68 IBM Workload Automation: 概要

て、現在日付に 4 就業日を加えるといった値を計算できるようにすることができます。そして、特定の値または、他の一時変数で構成される式への、一時変数の設定を行うことができます。

システム自動化コマンドの調整。 IBM Workload Scheduler for z/OS は、システム自動化コマンドを自動的に編集する機能を提供します。これは時間の節約と、エラー編集の可能性の削減に役立ちます。IBM Workload Scheduler for z/OS コマンド調整機能は、自動変数置換を行います。

自動リカバリーと再始動IBM Workload Scheduler for z/OS は、実動作業のための自動再始動機能を提供します。IBM Workload Scheduler for z/OS によって開始された作業がエラーで終了したときに実行する、再始動アクションを指定することができます (図 6を参照してください)。これらの機能を使用して、ジョブと開始タスクに対して自動エラー・リカバリーと再始動のアクションを事前定義することができます。 スケジューラーを NetView プログラムと統合することにより、エラー状況にある場合に、NetView プログラムにアラートを自動的に渡すことができます。 z/OS のシステム間カップリング・ファシリティー (XCF) を使用することにより、IBM WorkloadScheduler for z/OS は、システム障害が起こった場合に実動ワークロード処理を維持することができます。

ジョブと開始タスクのリカバリー。 失敗したジョブに対する自動リカバリー・アクションは、ユーザー定義の制御ステートメントに指定されます。これらのステートメントのパラメーターは、ジョブまたは開始タスクがエラーで終了したときに実行するリカバリー・アクションを決定します。

再始動およびクリーンアップ。 再始動およびクリーンアップを使用して、ジョブがエラーになった場合、あるいはジョブの再実行が必要な場合に、データ・セットを

図 6. 自動リカバリーと再始動

第 6 章 IBM Workload Scheduler for z/OS 69

カタログ、アンカタログ、または削除することができます。データ・セット・クリーンアップは、ローカル・システムとリモート・システムの両方で、ストリーム内JCL、ストリーム内プロシージャー、およびカタログ式プロシージャーの形式のJCL を処理します。この機能は、IBM Workload Scheduler for z/OS が自動的に開始するか、あるいはパネルを使用してユーザーが手動で開始することができます。IBM Workload Scheduler for z/OS は、JCL に含まれる世代別データ・セット・グループ (GDG) と DD 割り振り済みデータ・セットの両方に対して、ジョブが実行される前の状況にカタログをリセットします。 さらに、再始動およびクリーンアップは、ユーザー環境での Removable Media Manager の使用をサポートします。

IBM Workload Scheduler for z/OS パネルでは、ステップとジョブの両方のレベルの再始動も提供されます。これは、世代別データ・グループ (GDG) の名前、ネストされた INCLUDE または PROC、および IF-THEN-ELSE ステートメントが入っている JCL の解決を管理します。 IBM Workload Scheduler for z/OS は、また、正常な再始動を妨げる可能性がある問題を自動的に識別し、「最良の再始動ステップ」のロジックを提供します。

カタログに変更がない場合であっても、ジョブ・ログをブラウズするか、あるいは任意の z/OS ジョブまたは開始タスクのステップ・レベル再始動を要求することができます。ジョブ・ログ・ブラウズ機能は、他のオペレーティング・プラットフォームのワークロードでも使用できます。これは、SDSF のような機能をサポートしない環境で特に役立ちます。例えば、RMDS などの SYSOUT アーカイバーを使用する場合には、IBM Workload Scheduler for z/OS からそのアーカイバーにインターフェースを取ることができるので、ジョブ・ログ情報の重複を防ぐことができます。

これらの機能は、ユーザーの現行 JCL を変更する必要なしに使用することができます。

IBM Workload Scheduler for z/OS は、リモート・エージェント・システム上で、企業規模のデータ・セット・クリーンアップ機能を提供します。

実動ワークロード再始動。 IBM Workload Scheduler for z/OS は、実動ワークロード再始動を提供しており、これによって、システムまたは接続に障害があっても、作業の処理を自動的に維持することができます。正常に作動しないシステムにおけるスケジューラー制御の実動作業は、別のシステムに転送されます。 IBMWorkload Scheduler for z/OS は実動ワークロードを再始動して管理することができるので、処理スケジュールの保全性は維持され、顧客に対するサービスも継続されます。

IBM Workload Scheduler for z/OS は、VTAM® モデル・アプリケーション・プログラム定義機能および z/OS 定義済みシンボルを使用してシスプレックス環境での構成とジョブを容易にし、ユーザーにシスプレックスの単一のシステム視点を提供します。

エンジンおよびエージェントの開始、停止、および管理には、ユーザーはどのシスプレックス z/OS イメージが実際に実行されているかを認識している必要はありません。

70 IBM Workload Automation: 概要

ホット・スタンバイ。 IBM Workload Scheduler for z/OS は、ユーザーの z/OS実動ワークロード用の単一制御点を提供します。この制御システムに障害が発生すると、IBM Workload Scheduler for z/OS は、制御機能を Parallel Sysplex® 内のバックアップ・システムに自動的に転送することができます。図 7を参照してください。IBM Workload Scheduler for z/OS は、XCF を介して、システムまたは接続の障害時に実動ワークロード処理を自動的に維持できます。

z/OS 自動再始動マネージャーのサポートプログラム障害の場合に、すべてのスケジューラー・コンポーネントは z/OS オペレーティング・システムの自動再始動マネージャー (ARM) によって再始動できるようになっています。

ワークロード・マネージャー (WLM) のサポートワークロード・マネージャー (WLM) を使用すれば、ユーザーのスケジュール済みジョブによってアクセスされるリソースを最適に活用することができます。さらに、ユーザーのジョブは、WLM および IBM Workload Scheduler for z/OS を使用することにより、最高のスループットを維持することができます。WLM とともに使用した場合、スケジューラーは可能な最高のシステム応答時間を達成することができます。

自動状況検査ワークフローを追跡するために、IBM Workload Scheduler for z/OS は、オペレーティング・システムと直接インターフェースをとり、現在システムでアクティブな実動作業に関する状況情報を収集して、分析します。IBM Workload Schedulerfor z/OS は、ローカル・プロセッサーとリモート・プロセッサーの両方のプロセッサーから状況情報を記録することができます。状況情報が異なる時間帯のリモート・サイトから報告される場合には、IBM Workload Scheduler for z/OS は時差を考慮します。

図 7. 実動ワークロードの再始動とホット・スタンバイ

第 6 章 IBM Workload Scheduler for z/OS 71

異機種環境からの状況報告他の操作環境の処理も、IBM Workload Scheduler for z/OS によって追跡することができます。提供されているプログラムを使用して、z/OS システムとの通信を確立できる任意の環境から、エンジンと通信することができます。

ユーザー・プログラムからの状況報告実動ワークロード処理に関する状況情報は、標準で提供されるルーチンを通じて、ユーザー独自のユーザー・プログラムから IBM Workload Scheduler for z/OS へ渡すことができます。

ジョブ完了の追加検査処理の成功または失敗が完了コードでは判別できない場合に、必要であれば、IBMWorkload Scheduler for z/OS は、その処理からの SYSOUT およびその他の印刷データ・セットをスキャンすることによって、さらに状況検査を行います。例えば、IBM Workload Scheduler for z/OS は、システム・メッセージ、またはユーザー・プログラムから出されたメッセージのテキストを検査することができます。IBM Workload Scheduler for z/OS は、ジョブ完了チェッカー (JCC) テーブルに入っている情報を使用して、それが特定のテキスト・ストリングを検出したときに実行するアクションを決定します。これらのアクションには、以下のものを組み込むことができます。v エラーの報告v SYSOUT の再キューイングv 問題データ・セットへの問題レコードの書き込み

計画できない作業の管理IBM Workload Scheduler for z/OS は、あらかじめ計画できない作業についての情報で最新計画を更新するために、自動的に起動することができます。これによって、IBM Workload Scheduler for z/OS は予期しない作業を制御することができます。IBM Workload Scheduler for z/OS はこの作業の処理状況を検査するので、自動リカバリー機能も使用可能です。

IBM Tivoli Monitoring との統合IBM Tivoli Monitoring は、各種のプラットフォーム上のシステムやネットワーク・アプリケーションをモニターおよび管理して、エンタープライズ全体の可用性とパフォーマンスの状況を追跡することができます。IBM Tivoli Monitoring によって提供されるレポートは、トレンドの追跡や問題のトラブルシューティングに使用できます。

IBM Workload Scheduler for z/OS と IBM Tivoli Monitoring の統合では、カスタマイズ可能なエージェントである IBM Tivoli Monitoring Agent for IBMWorkload Scheduler for z/OS のインストールが必要となります。このエージェントは、モニターするシステムにインストールされ、データを収集して TivoliEnterprise Monitoring Server に配信します。

IBM Tivoli Monitoring Agent for IBM Workload Scheduler for z/OS (これ以降は Tivoli Monitoring Agent と呼びます) は、IBM Tivoli Monitoring (ITM) にイベントおよびアラートを送信します。IBM Workload Scheduler for z/OS は、リスナー・タスクのように機能する Tivoli Monitoring Agent のソケット・データ・

72 IBM Workload Automation: 概要

ソースとの IP 接続を確立します。モニター対象操作の状況が変化するたびに、あるいはアラートが発行されるたびに、関連イベントが Tivoli Monitoring Agent に送信されます。

IBM Workload Scheduler for z/OS から送信されるデータは、Tivoli MonitoringAgent によって解釈されます。エージェントはそのキャッシュにイベント情報を保管し、この情報は後で Tivoli Enterprise Monitoring Server によって統合されます。収集されたデータはその後、Tivoli Enterprise Portal という名前のコンポーネントによって取得され、表示されます。

Tivoli Enterprise Portal は、企業ネットワークの表示およびモニターに使用される対話式インターフェースです。Tivoli Enterprise Portal クライアントは TivoliEnterprise Portal サーバーに接続します。このサーバーは、企業内のすべての既存IBM Tivoli Monitoring エージェントによって収集されたデータの検索、操作、および分析を可能にします。

Tivoli Enterprise Portal を使用すると、IBM Workload Scheduler for z/OS 操作に関連したイベント (操作の開始時刻および終了時刻など) を表示および管理することができます。同様に、モニターされる操作およびサブタスクの自動選択を構成することにより、企業の全リソースを単一ポイントで管理および制御することができます。

他のプログラムとのインターフェースIBM Workload Scheduler for z/OS は、1 つのプログラム・インターフェース(PIF) を提供します。このインターフェースを使用すれば、ダイアログを介してオンラインで実行できるほとんどのアクションを自動化することができます。このインターフェースは、CLIST から、ユーザー・プログラムから、また TSO コマンドを使用して呼び出すことができます。

アプリケーション・プログラミング・インターフェース (API) によって、ユーザー・プログラムは、任意の対応プラットフォームから IBM Workload Schedulerfor z/OS と通信することができます。 共通プログラミング・インターフェース通信 (CPI-C)、拡張プログラム間通信 (APPC)、またはユーザー独自の論理装置 (LU)6.2 verb を使用し、API を通じて IBM Workload Scheduler for z/OS と会話することができます。このインターフェースを使用して、最新計画を照会し、更新することができます。エンジンが実行されている z/OS システムとローカルに、またはネットワークを通じてリモートから接続された任意のプラットフォームで、プログラムを実行することができます。

手動での制御と介入IBM Workload Scheduler for z/OS を使用すれば、優先順位が変更されているとき、または計画外の作業を実行したいときには、作業の状況を調べ、手作業で介入することができます。実動ワークロードの状況を照会し、その後、必要に応じてスケジュールを変更することができます。

第 6 章 IBM Workload Scheduler for z/OS 73

状況の照会ISPF ダイアログまたは Dynamic Workload Console を使用することにより、オンラインで照会を実行したり、実動作業負荷の状況についてタイムリーな情報を受け取ったりすることができます。

ダイアログによって表示される時刻情報は、ダイアログ・ユーザーの現地時間です。ダイアログを使用すると、全体としての実動ワークロードに関する要約情報だけでなく、個々のジョブ・ストリーム、ジョブ、およびワークステーションに関する詳細または要約情報を要求することができます。また、依存関係をジョブ・ストリームとジョブ・レベルの両方で、ネットワークとして図示することもできます。状況の照会は、以下のことを行います。

v ワークステーションの処理能力の変更を考慮する場合、または追加のシフトまたは時間外勤務を調整する場合に使用できる全体的な状況情報を提供します。

v 例えば、各ワークステーションで作業の状況を表示することにより、インストール・システムでのワークフローを監視することに役立ちます。

v 特定のジョブ・ストリームの処理を速くするために、介入が必要かどうかの決定に役立ちます。どのジョブ・ストリームが最も重要であるかを見分けることができます。また、各ジョブの計画および実際の時間だけでなく、任意のジョブ・ストリームの状況を調べることができます。

v 計画に変更を加える前に、情報を調べるのを助けます。たとえば、削除するか、あるいはその入力到着時間または締切を変更する前に、ジョブ・ストリームの状況とその依存関係を調べることができます。詳しくは、『最新計画の変更』を参照してください。

v 特定のワークステーションでの処理状況についての情報を提供します。ワークステーションに到着しているはずの作業が到着していない場合があります。状況の照会は、ユーザーがその作業を特定し、何が起こっているかを見つけ出す助けとなることがあります。

最新計画の変更IBM Workload Scheduler for z/OS は、そのトラッキング機能を使用して、計画への状況更新を自動的に行います。ただし、勤務時間中にしばしば生じる計画外の変更をワークロードまたは操作環境に反映させるために、手作業で変更することが可能です。たとえば、ジョブ・ストリームの優先順位を変更したり、計画外の作業を追加したり、あるいは 1 つのワークステーションから別のワークステーションへ作業を転送したりすることができます。また、操作上のエラーを手作業で訂正することもできます。最新計画を変更することが、これらの状況を処理する最良の方法です。

最新計画をオンラインで変更することができます。たとえば、以下のことができます。

v 予測外のジョブまたは最終段階での変更を計画に組み込みます。 IBM WorkloadScheduler for z/OS は、次に、この作業についての依存関係を自動的に作成します。

v 手作業でジョブの状況を変更します。

v ジョブ・ストリームのオカレンスを削除します。

v 変更する前にジョブの依存関係をグラフィック表示します。

74 IBM Workload Automation: 概要

v JCL も含めて、ジョブ・ストリーム内のデータを変更します。

v 以下のようにして、エラー状況に対応します。– ジョブの転送– ジョブまたはオカレンスの再実行– ジョブまたはオカレンスの完了– ジョブまたはオカレンスの変更

v 以下のようにして、ワークステーションの状況を変更します。– あるワークステーションから他のワークステーションへ作業を転送する– ワークステーション報告属性を変更する– リソースの可用性を更新する– リソースの処理方法を変更する

v 最新計画を再計画または拡張します。

ダイアログを使用するほかに、プログラム・インターフェースまたはアプリケーション・プログラミング・インターフェースを使用することによっても、独自のジョブ・ストリームから最新計画を変更することができます。また、IBM WorkloadScheduler for z/OS を起動して、TSO コマンドまたはバッチ・プログラムを使用して計画を動的に変更することもできます。これにより、予測外の作業が自動的に計画に追加されます。

クリティカル・ジョブの管理IBM Workload Scheduler for z/OS は、z/OS のワークロード・マネージャー・コンポーネントの機能を使用して、クリティカル・ジョブが確実に時間どおりに完了するようにします。クリティカル・ジョブが遅延している場合は、IBMWorkload Scheduler for z/OS はワークロード・マネージャー・インターフェースを使用して、それを優先処理します。

クリティカル・パスの管理Workload Manager に基づいたクリティカル・ジョブの処理に加え、IBMWorkload Scheduler for z/OS は、日次計画バッチ・ジョブ・プロセスによって計算されるクリティカル・パスを動的に処理します。

クリティカル・パスは、最小の遊び時間を持った、ジョブのネットワーク内のパスです。

先行ジョブのクリティカル・パスの遊び時間とは、先行ジョブの処理が遅延してもクリティカル・ジョブの締め切りを超えず、差し支えない時間の長さのことです。これは、先行ジョブの締め切り、入力の到着時刻、および所要時間の設定を使用して計算される予備の時間です。

この機能には、以下が含まれます。

v 遅延しているか、長く実行されているか、あるいはエラーで終了したクリティカル・ジョブの先行ジョブのモニター。このプロセスは、アラート条件をモニターするためにスケジューラーが適用するのと同じ内部ロジックを使用します。

v 遊び時間を消費し、計画生成時に計算されたパスよりクリティカルになっているパスのモニター。

v ISPF ダイアログ・フローを使用した、機能拡張されたクリティカル・ジョブ・モニター機能。

第 6 章 IBM Workload Scheduler for z/OS 75

v Dynamic Workload Console を使用して使用可能になる新規ビューに対するバックエンド・サポート。

セキュリティー今日、DP の運用の範囲が拡張され、また企業内のより多くの人が関与するようになったため、DP の運用には高水準のデータ・セキュリティーがますます必要になっています。 IBM Workload Scheduler for z/OS は、その機能の範囲内で完全なセキュリティーとデータ保全性を提供します。ユーザーが異なる企業または他の国にいる場合でも、その異なるユーザー部門に対して、共用される中央サービスを提供します。 IBM Workload Scheduler for z/OS は、無許可アクセスからスケジューラー・データとリソースを保護する高水準のセキュリティーを提供します。IBMWorkload Scheduler for z/OS を使用すれば、ユーザー・アプリケーションの保全性を保護するために、ユーザー・データを容易に編成、分離、および保護することができます (図 8を参照してください)。IBM Workload Scheduler for z/OS は、多くのユーザー・グループの作業を計画および制御し、データとサービスへのアクセスの完全な制御を維持することができます。

監査証跡監査証跡を使用すれば、スケジューラー・リソースへのアクセス (読み取りと更新の両方) を IBM Workload Scheduler for z/OS に記録させる方法を定義することができます。監査証跡は、データベースへの変更のヒストリーを提供するので、デバッグと問題判別に携わる要員にとって特に役立ちます。

監査証跡レコードを読み取るためのサンプル・プログラムが提供されています。そのプログラムは、ユーザーが指定した期間のログを読み取り、スケジューラー・リソースに対して行われた変更を詳しく示す報告書を作成します。

図 8. セキュリティー

76 IBM Workload Automation: 概要

システム許可機能IBM Workload Scheduler for z/OS は、z/OS の機能であるシステム許可機能(SAF) を使用して、許可検査要求を、例えば RACF といったセキュリティー・システムに渡します。これは、SAF インターフェースを使用する任意のセキュリティー・システムでスケジューラー・データ・オブジェクトを保護できることを意味します。

データとリソースの保護:各ユーザーの、機能へアクセスする要求またはデータへアクセスする要求が、SAFによって検証されます。以下に保護できる情報のいくつかを示します。v カレンダーと期間v ジョブ・ストリーム名またはジョブ・ストリーム所有者 (名前)v ワークステーション (名前)v 計画内のジョブ・ストリーム固有のデータv オペレーター指示v JCL

分散された、マルチユーザーの処理をサポートするために、IBM WorkloadScheduler for z/OS は、インプリメントするセキュリティーのレベルを、まさに個々のレコードのレベルにまで、ユーザーが制御するようにします。汎用または特定の RACF リソース名を定義して、セキュリティー検査のレベルを拡張することができます。

RACF バージョン 2 リリース 1 がインストールされている場合には、IBMWorkload Scheduler for z/OS 予約済みリソース・クラスを使用して、IBMWorkload Scheduler for z/OS のセキュリティー環境を管理することができます。これは、RACF を変更しシステムを再始動して、独自のリソース・クラスを定義する必要がないということを意味します。

実行依頼中のデータ保全性:IBM Workload Scheduler for z/OS は、ジョブがローカル・システムまたはリモート・システムのどちらのシステムで実行されるかには関係なく、実行依頼するジョブごとに正しいセキュリティー環境を確保することができます。IBM WorkloadScheduler for z/OS によって、個々のジョブまたはジョブのグループに対して、調整済みのセキュリティー・プロファイルを作成することができます。

連邦情報処理標準 (FIPS) への準拠SSL セキュア接続を介して連邦情報処理標準 (FIPS) に準拠するように IBMWorkload Scheduler for z/OS を構成することができます。

コントローラーと各種インターフェース (トラッカー、サーバー、データ・ストア、リモート ISPF ダイアログ、プログラム・インターフェース (PIF)) 間の通信で、z-セントリック・エージェントまたはフォールト・トレラント・エージェントを使用するエンドツーエンドをスケジューリングする際に、FIPS 140-2 準拠を有効にするように IBM Workload Scheduler for z/OS を構成できます。そのためには、IBM Workload Scheduler for z/OS コントローラーの TCPOPTS 初期化ステートメントまたは HTTPOPTS 初期化ステートメント (あるいはその両方) でENABLEFIPS というパラメーターを構成する必要があります。

第 6 章 IBM Workload Scheduler for z/OS 77

互換性、アップグレード、および共存クラスター環境で動作するように構成されている IBM Workload Scheduler エージェントは、IBM Workload Scheduler の旧バージョンとの互換性には影響を与えないため、構成もデータ・マイグレーションも必要ありません。

Windows のクラスター環境で動作するように構成されている IBM WorkloadScheduler エージェントは、分散ネットワーク構成とエンドツーエンド・ネットワーク構成の両方に接続することができます。

Windows Cluster Administration プログラムを拡張する DLL は、フィックスパックや IBM Workload Scheduler の新規リリースで更新されることがあります。そのため、Windows Cluster Enabler をインストールするプログラムには、マイナー(フィックスパック) またはメジャー (新規リリースの IBM Workload Scheduler)の新規バージョンを使用した DLL の更新に使用する更新オプションがあります。

IBM Workload Scheduler for z/OS の構成IBM Workload Scheduler for z/OS は、以下のようにさまざまな通信方式を使用して、多くの構成オプションをサポートします。

v 『制御システム』

v 79 ページの『制御される z/OS システム』

v 80 ページの『リモート・パネルおよびプログラム・インターフェース・アプリケーション』

v 80 ページの『IBM Workload Scheduler 内のジョブのスケジューリング』

制御システム制御システムには、エージェントとエンジンの両方が必要です。 1 つの制御システムが、すべての操作環境にわたる実動ワークロードを管理することができます。

エンジンは、制御および情報の中心拠点です。これには、制御機能、ダイアログ、およびスケジューラー自体のバッチ・プログラムが含まれます。ローカル・システムとリモート・システムを含めて ( 79 ページの図 9 を参照) インストール・システム全体を制御するために必要なエンジンは 1 つだけです。

78 IBM Workload Automation: 概要

制御される z/OS システムエージェントは、構成内で制御されるすべての z/OS システムに必要です。たとえば、これには共用 DASD またはシスプレックス構成内のローカルの制御されるシステムが含まれます。

エージェントは、1 つの z/OS サブシステムとして実行され、サブシステム・インターフェースとオペレーティング・システム出口を使用して、オペレーティング・システムと (JES2 または JES3、および SMF を通じて) インターフェースをとりま

図 9. IBM Workload Scheduler for z/OS の構成

第 6 章 IBM Workload Scheduler for z/OS 79

す。エージェントは、作業の状況をモニターしてログに記録し、その状況情報を共用 DASD、XCF、または ACF/VTAM を介してエンジンに渡します。

ユーザーは、z/OS およびシステム間カップリング・ファシリティー (XCF) を使用して、ローカル z/OS システムに接続することができます。作業状況情報は、共用DASD を使用して制御システムに渡される代わりに、XCF 接続によって直接渡されます。XCF を使用すれば、実動ワークロード再始動機能とホット・スタンバイ機能のすべてを使用することができます。 69 ページの『自動リカバリーと再始動』を参照してください。

リモート・システムリモート z/OS システム上のエージェントは、進行中の実動作業についての状況情報を制御システム上のエンジンに渡します。制御システム上とリモート・システム上の IBM Workload Scheduler for z/OS サブシステム間のすべての通信は、ACF/VTAM を介して行われます。

IBM Workload Scheduler for z/OS により、ユーザーは、ACF/VTAM ネットワークを使用してリモート・システムをリンクすることができます。リモート・システムは、データ処理 (DP) インストール済み環境の複雑さを軽減するために「オンプレミス」においてローカルで頻繁に使用されます。

リモート・パネルおよびプログラム・インターフェース・アプリケーション

ISPF パネルおよびプログラム・インターフェース (PIF) アプリケーションは、エンジンが実行されているシステムとは別の z/OS システムで実行することができます。ダイアログおよび PIF アプリケーションは、ターゲット・エンジンが拡張プログラム間通信機能 (APPC) を使用して実行中である z/OS システムと同一のシステムで実行されている IBM Workload Scheduler for z/OS サーバーとの間で要求を送信し、データを受信します。サーバーは、エンジンと通信して、要求されたアクションを実行します。

サーバーは独立したアドレス・スペースであり、エンジンが自動的に、あるいはユーザーが z/OS コマンドを使用して開始および停止します。1 つのエンジンに複数のサーバーを使用することができます。

ダイアログまたは PIF アプリケーションが、ターゲット・エンジンが実行されている z/OS システムと同じシステムで実行されている場合には、サーバーは組み込めないことがあります。

IBM Workload Scheduler 内のジョブのスケジューリングIBM Workload Scheduler for z/OS は、ジョブ・ストリーム (IBM WorkloadScheduler でのスケジュール) にアクセスし、それらを IBM Workload Schedulerfor z/OS の最新計画に追加することもできるようにします。さらに、IBMWorkload Scheduler for z/OS ジョブ・ストリームと IBM Workload Schedulerジョブの間に依存関係を構築することもできます。 IBM Workload Scheduler forz/OS から、分散エージェントをモニターおよび制御することができます。

フォールト・トレラント・ワークステーションの使用IBM Workload Scheduler for z/OS の最新計画では、 IBM Workload

80 IBM Workload Automation: 概要

Scheduler のフォールト・トレラント・エージェントで実行するジョブを指定することができます。IBM Workload Scheduler for z/OS は、ジョブ情報を IBM Workload Scheduler の Symphony ファイルに渡し、次に、最新計画内のジョブが配布および処理のために IBM Workload Scheduler に渡されます。IBM Workload Scheduler は、次に、IBM WorkloadScheduler for z/OS でモニターするために、実行中または完了したジョブの状況を最新計画に報告して戻します。

z-セントリック・ワークステーションの使用z-セントリック・ワークステーションは IBM Workload Scheduler ネットワークにインストールされたエージェントで、HTTP または HTTPS でIBM Workload Scheduler for z/OSに接続することができます。z-セントリック・ワークステーションは、分散プラットフォーム(UNIX、Linux、Windows) で実行する必要のある IBM WorkloadScheduler for z/OS ジョブからスケジュールする手段を提供します。 z-セントリック・ワークステーションは IBM Workload Scheduler for z/OSのコンピューター自動ワークステーションと同等で、フォールト・トレラント・ワークステーションよりも少ない構成と少ない支援インフラストラクチャーで使用できます。

第 6 章 IBM Workload Scheduler for z/OS 81

82 IBM Workload Automation: 概要

第 7 章 Dynamic Workload Console

Dynamic Workload Console は、Web ベースのユーザー・インターフェースであり、以下に使用できます。

v IBM Workload Scheduler

v IBM Workload Scheduler for z/OS

これは、IBM Workload Automation 製品スイートの戦略的ユーザー・インターフェースになっています。ここには、スケジューリング・エンジンで使用できる最新の機能と機能拡張に対するサポートが含まれます。

Dynamic Workload Console は、スケジューリング・ネットワーク全体に対する、軽量で強力な、使いやすいシングル・ポイントの操作コントロールです。シングル・サインオン (SSO) と 1 つ以上のスケジューラーに対する認証が可能であり、拡張が非常に容易です。さらに、エンタープライズ・ワークロードのリアルタイムのモニター、管理、レポート作成を行うことができます。また、レポートの作成とカスタマイズが大幅に単純化されています。

Dynamic Workload Console を使用すると、以下のことが可能です。

v データベース内のオブジェクトの設計、計画の処理、ジョブまたはジョブ・ストリームの実行依頼、および計画内のオブジェクトのモニターのための、ワークロードの管理。

v スケジューリング環境 (ワークステーションとドメイン) のトポロジーの設計と制御。

v 計画のヒストリカル・データまたは詳細を収集するレポートの定義と実行。カスタマイズ済み SQL レポートの生成と実行を行うこともできます。

v 動的なスケジューリングで使用する論理リソースまたは論理リソースのグループの定義と管理。

ワークロードの処理において制御と自律性は求められるが、複雑なワークロード自動化の概念への対応は求められていないアプリケーション開発者は、より単純化された Web ベースのユーザー・インターフェースを使用できます。Application Labは、共用されているかまたはシングル・サインオンで構成されている既存のDynamic Workload Console 分散エンジンに接続します。アプリケーション開発者は、実際のビジネス・ニーズに対処するシンプルなプロセスを作成および管理できます。詳しくは、「Application Lab ユーザーズ・ガイド」を参照してください。

Dynamic Workload Console には、環境内の任意のコンピューターから、セキュアな HTTPS プロトコルまたは HTTP プロトコルにより、Web ブラウザーを使用してアクセスできます。

Dynamic Workload Console に接続したときに最初に実行する操作で主要な操作は、以下のとおりです。

83

|

|

|

|

|

|

|

スケジューリング・エンジン (IBM Workload Scheduler または IBM WorkloadScheduler for z/OS) への接続を作成する

詳細 (IP アドレス、ユーザー名、およびパスワード) を入力してスケジューリング・エンジンにアクセスするか、オプションとしてデータベースにアクセスし、計画で定義されたオブジェクトか、またはデータベースに保管されたオブジェクトを処理します。データベース内に新規のスケジューリング・オブジェクトを定義することもできます。

Dynamic Workload Console から、分散環境の場合は、最新計画、試行計画、予測計画、またはアーカイブ計画にアクセスでき、z/OS 環境の場合は、最新計画にアクセスできます。

データベースにアクセスして、そこに保管されているオブジェクトに対するアクションの実行や、ヒストリカル・データまたは統計データを示すレポートの生成を行うことができます。

さらに、データベースと計画の両方の処理により、イベント・ルールを作成して実行することで、IBM Workload Scheduler ノードで発生するイベントに対する応答として実行するアクションを定義して起動することができます。

タスクを作成して、計画内のスケジューリング・オブジェクトを管理する特定のフィルター条件を指定し、その条件を満たす属性を持つスケジューリング・オブジェクトのリストを照会します。このリストから始めて、計画の内容のナビゲートと変更、オブジェクト間の切り替え、別のリストのオープン、他の計画や他の IBM Workload Scheduler または IBM WorkloadScheduler for z/OS 環境へのアクセスを行うことができます。

コンソールには、ワークロードを管理するための以下のグラフィカル・ビュー・ツールもあります。

グラフィカル・ビュー (モデリング用)Workload Designer に対するグラフィカルな拡張機能で、データベース内のジョブ・ストリーム定義をグラフィカルに表示します。これにより、ジョブ・ストリーム定義を直感的に作成したり保守したりすることができます。

計画ビュー (モニター用)あらゆるタイプの計画の概要を表示するビューで、ジョブ・ストリームおよびその相互依存関係のフィルタリングされたセットを表示します。

ジョブ・ストリーム・ビュー (モニター、トラブルシューティング、影響分析用)計画内のジョブ・ストリームおよびジョブの展開表示可能なグラフィカル表現。ジョブとジョブ・ストリームの完了が計画の進行状況にどのように影響するかについて、マルチレベルの分かりやすい分析結果が表示され、ジョブ、ジョブ・ストリーム、およびそれらの依存関係を直接操作することができます。

実動前計画ビュー (ワークロード計画用)計画の対象となる指定の時間間隔内に実行されるジョブ・ストリーム・インスタンスとジョブ・ストリーム依存関係が表示されます。

各ビューでは、オブジェクトに対してアクションを実行したり、プロパティーを参照したり、ビューを簡単に切り替えたりすることができます。グラフィックスは、PNG ファイルと SVG ファイルにエクスポートすることができます。

84 IBM Workload Automation: 概要

第 8 章 エンドツーエンド・スケジューリング

エンドツーエンド・スケジューリングを使用して、真の分散スケジューリングのために、メインフレーム、Windows、および UNIX 環境でジョブをスケジュールおよび制御することができます。エンドツーエンド構成では、IBM WorkloadScheduler for z/OS がジョブ・スケジューリング環境のための計画機能として使用されます。IBM Workload Scheduler ドメイン・マネージャー、標準エージェント、フォールト・トレラント・エージェント、および z-セントリック・エージェントは、分散プラットフォームでスケジュールを行うために使用されます。これらのエージェントがトラッカー・エージェントに代わって使用されます。

IBM Workload Scheduler for z/OS は、ジョブ・ストリーム (IBM WorkloadScheduler でのスケジュール) にアクセスし、それらを IBM Workload Schedulerfor z/OS の最新計画に追加することもできるようにします。さらに、IBMWorkload Scheduler for z/OS ジョブ・ストリームと IBM Workload Schedulerジョブの間に依存関係を構築することもできます。 IBM Workload Scheduler forz/OS から、分散エージェントをモニターおよび制御することができます。

分散スケジューリングは、以下の機能のいずれかを活動化することによって管理できます。

v 『フォールト・トレランス機能付きのエンドツーエンド・スケジューリング』

v 87 ページの『z-セントリック機能付きのエンドツーエンド・スケジューリング』

フォールト・トレランス機能付きのエンドツーエンド・スケジューリングフォールト・トレランス機能付きのエンドツーエンド・スケジューリングについて説明します。

フォールト・トレランス機能付きのエンドツーエンド・スケジューリングは、IBMWorkload Scheduler 標準エージェント、フォールト・トレラント・エージェント、およびドメイン・マネージャー (基礎となるエージェントとドメインと共に) をIBM Workload Scheduler for z/OS に直接接続します。IBM Workload Schedulerfor z/OS は、分散ネットワークによりマスター・ドメイン・マネージャーとして認識されます。

IBM Workload Scheduler for z/OS は、実動計画を分散ネットワーク用にも作成し、それをドメイン・マネージャーならびに直接接続されたエージェントに送信します。ドメイン・マネージャーは、実行するために、計画のコピーをエージェントと従属ドメイン・マネージャーに送信します。

IBM Workload Scheduler ドメイン・マネージャーは、従属マネージャーとエージェントに関するすべての依存関係を解決することにより、分散ネットワークのブローカー・システムとして機能します。ドメイン・マネージャーは、計画を適切に更新できるように、更新を IBM Workload Scheduler for z/OS に送ります (イベントの形式で)。 IBM Workload Scheduler for z/OS は、自身のジョブを処理し、

85

IBM Workload Scheduler 計画に関係する IBM Workload Scheduler for z/OS ジョブの状況変更すべてをドメイン・マネージャーに通知します。この構成では、ドメイン・マネージャーおよびすべての分散エージェントが IBM WorkloadScheduler for z/OS をマスター・ドメイン・マネージャーとして認識し、それに対して、ドメイン・マネージャーおよびすべての分散エージェント自身の計画で行われたすべての変更を通知します。同時に、エージェントは IBM WorkloadScheduler for z/OS ジョブに干渉することはできません。これは、エージェントが、それらを管理する唯一のノードであるマスター上で実行されているものと見なされるためです。

IBM Workload Scheduler for z/OS の最新計画では、IBM Workload Schedulerネットワークのワークステーションで実行するジョブを指定することができます。IBM Workload Scheduler for z/OS は、ジョブ情報を IBM Workload Schedulerfor z/OSサーバーの Symphony ファイルに渡します。次に、このサーバーはSymphony ファイルの配布と処理のために、それを IBM Workload Scheduler ドメイン・マネージャー (DMZ) に渡します。IBM Workload Scheduler は、次に、IBM Workload Scheduler for z/OS エンジンでモニターするために、実行中または完了したジョブの状況を最新計画に報告して戻します。

87 ページの図 10 は、IBM Workload Scheduler for z/OS によって管理されるIBM Workload Scheduler ネットワークとデータのフローを示しています。

86 IBM Workload Automation: 概要

z-セントリック機能付きのエンドツーエンド・スケジューリングz-セントリック機能付きのエンドツーエンド・スケジューリングについて説明します。

図 10. フォールト・トレランス機能付きのエンドツーエンド構成

第 8 章 エンドツーエンド・スケジューリング 87

z-セントリック機能付きのエンドツーエンド・スケジューリングは、IBM WorkloadScheduler z-セントリック・エージェントを、分散ネットワークのためのマスター・ドメイン・マネージャーである IBM Workload Scheduler for z/OS に直接接続します。

標準変数置換、自動復旧ステートメント、そして代替ワークステーションなど、強力なメインフレーム機能がサポートされており、それによって分散ワークロードを管理できます。

z-セントリック・エージェントと IBM Workload Scheduler for z/OS コントローラーの間の通信は、HTTP または HTTPS プロトコルによる直接通信です。

図 11 は、この構成のネットワークを表しています。

分散エージェント分散エージェントは、ジョブを IBM Workload Scheduler からスケジュールできる、IBM Workload Scheduler for z/OS を実行するコンピューターです。分散エージェントの例としては、標準エージェント、拡張エージェント、フォールト・トレラント・エージェント、およびドメイン・マネージャーがあります。

以下は、分散エージェントのタイプの説明です。

図 11. z-セントリック機能付きのエンドツーエンド構成

88 IBM Workload Automation: 概要

ドメイン・マネージャードメイン内の管理ハブ。ドメイン内のエージェントとのすべての通信は、ドメイン・マネージャーを介して経路指定されます。

バックアップ・ドメイン・マネージャー自動ワークロード・リカバリーの場合に、そのドメイン・マネージャーの役割を果たせるフォールト・トレラント・エージェントまたはドメイン・マネージャー。

フォールト・トレラント・エージェント (FTA)ドメイン・マネージャーが存在しない場合にローカル依存関係を解決し、そのジョブを起動することができるワークステーション。

標準エージェントドメイン・マネージャーの指示によってのみジョブを起動するワークステーション。

拡張エージェント他のシステムおよびアプリケーション (PeopleSoft、SAP、z/OS JES2 および JES3 など) 上のジョブを起動し、制御するのに役立つ論理ワークステーション定義。

z-セントリック・エージェントIBM Workload Scheduler for z/OS からスケジューリングされたジョブを実行するワークステーション。コントローラーは、このタイプのエージェントとの通信を直接に処理します。

プールプールは、ジョブの要件に従って、特定の動的エージェント・ワークステーションが追加されるグループです。ジョブは、実行するジョブの量がより少ないエージェントを選択してロード・バランシング・ポリシーを適用する、使用可能な最善の動的エージェントに、動的に割り当てられます。

動的プール動的プールは、要件が指定されるグループです。また、ジョブは、この要件を満たし最善のエージェントを識別するための最適化ポリシーを適用する、使用可能な最善の動的エージェントに動的に割り当てられます。

分散エージェントは、IBM Workload Scheduler for z/OS においてトラッカー・エージェントを置き換えたものです。分散エージェントは、非 z/OS システム上で、より信頼性がありスケーラブルなエージェントを使用してスケジュールするのに役立ちます。

IBM Workload Scheduler for z/OS 計画においては、分散エージェントの論理表現がフォールト・トレラント・ワークステーションまたは z-セントリック・ワークステーションと呼ばれます。

エンドツーエンド・スケジューリングの利点エンドツーエンド・スケジューリングを使用することによって得られる利点は、以下のとおりです。

v フォールト・トレラントまたは z-セントリック IBM Workload Scheduler エージェントのいずれかと、IBM Workload Scheduler for z/OS との接続。

第 8 章 エンドツーエンド・スケジューリング 89

|

|

|

|

|

v 追加のオペレーティング・システムでのスケジュール。

v メインフレームおよび分散環境内の作業の同期化。

v ドメイン・マネージャーで複数層アーキテクチャーを使用できる IBM WorkloadScheduler for z/OS の機能。

90 IBM Workload Automation: 概要

第 9 章 ハイブリッド・スケジューリング環境

ハイブリッド・ワークロード・オートメーションでは、共通のユーザー・インターフェースを使用して、オンプレミスとオンクラウドの両方のエンジンを管理できます。ワークロード・オートメーションをクラウドまたはオンプレミスで管理するか、両方の組み合わせを選択できます。オブジェクト (ジョブ、クリティカル・ジョブ、ワークステーション、リソース、プロンプト、ジョブ・ストリーム、ファイル、およびドメイン) について、計画内でモニターし、アクションを実行できます。

お客様のためのソリューションオンプレミス環境で効率的に管理されていたのと同じワークロードをクラウド環境で実行するようにスケジュールできます。Workload Automation onCloud は、IT インフラストラクチャーのコストを削減し、ワークロードを実行するビジネス・ニーズがあるときにのみ、リソースを使用するためのソリューションです。単純なインポート手順を使用して、オンプレミス環境から Workload Automation on Cloud にワークロードを転送できます。ワークロードはすぐに複製され、エージェントで使用できる状態になります。クラウド環境でワークロードを処理すると、オンプレミス・インフラストラクチャーに依存することなく、必要なときにのみ、クラウド内のリソースを費用対効果の高い方法で使用できます。

ハイブリッド・スケジューリング環境での操作方法オンプレミス環境からオンクラウド・エンジンを操作するには、ポート 443を使用して、Dynamic Workload Console でエンジン接続を定義します。この設定により、ハイブリッド・ワークロード・オートメーションの管理に必要な REST API を操作できるようになります。

オンプレミス・ワークロードを Workload Automation on Cloud 環境に転送するには、次の手順を実行します。

v ワークロード・アプリケーション・テンプレートを作成します。

v ワークロード・アプリケーション・テンプレートをエクスポートします。

v ワークロード・アプリケーション・テンプレートを WorkloadAutomation on Cloud 環境にインポートします。

転送するジョブ・ストリームを含むワークロード・アプリケーション・テンプレートを作成し、そのテンプレートに関する一般情報 (名前、説明など)をいくつか定義します。テンプレートに追加するジョブ・ストリーム (それぞれが 1 つ以上のジョブを含む) を選択します。エクスポート・アクションを選択し、テンプレートを圧縮ファイル形式で保存します。圧縮ファイルには、ワークロードをクラウド環境に適合させるための最小限のカスタマイズにより、新しいクラウド環境でワークロードを実行できるようにするために必要なすべてのファイルと情報が含まれています。Workload Automation on Cloud ダッシュボードで、「カスタム・アプリケーションのインポート」アクセス・ポイントを選択し、自分の IBM IDを使用してサインインすることで、ご使用のオンクラウド環境にテンプレー

91

トを追加します。圧縮したワークロード・アプリケーション・テンプレート・ファイルをアップロードし、そのインポート対象のエージェントを選択します。このワークロードをクラウド環境に適合させるために調整する必要があるのは、プロンプト定義と変数テーブルの 2 つのオブジェクトのみです。これらのオブジェクトの名前は両方とも、ご使用の WorkloadAutomation のサブスクリプション環境 ID を名前の前に付加することで変更する必要があります。インポート・プロセスが完了したら、ワークロード・アプリケーションをクラウド環境で使用する準備が整います。

92 IBM Workload Automation: 概要

特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。この資料は、IBM から他の言語でも提供されている可能性があります。ただし、これを入手するには、本製品または当該言語版製品を所有している必要がある場合があります。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBMの営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

　本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

93

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Director of LicensingIBM CorporationNorth Castle Drive, MD-NC119Armonk, NY 10504-1785US

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

本書に含まれるパフォーマンス・データは、特定の動作および環境条件下で得られたものです。実際の結果は、異なる可能性があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場合があります。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、類似する個人や企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。これらのサンプル・プログラムは特定物として現存するままの状態で提供されるも

94 IBM Workload Automation: 概要

のであり、いかなる保証も提供されません。 IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。

© (お客様の会社名) (西暦年).このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。© Copyright IBM Corp. _年を入れる_.

商標IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された InternationalBusiness Machines Corporation の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml をご覧ください。

Adobe、Adobe ロゴ、PostScript、PostScript ロゴは、Adobe SystemsIncorporated の米国およびその他の国における登録商標または商標です。

IT Infrastructure Library は AXELOS Limited の登録商標です。

Linear Tape-Open、LTO、LTO ロゴ、Ultrium および Ultrium ロゴは、HP、IBM Corp. および Quantum の米国およびその他の国における商標です。

インテル、Intel、Intel ロゴ、Intel Inside、Intel Inside ロゴ、Centrino、IntelCentrino ロゴ、Celeron、Xeon、Intel SpeedStep、Itanium、および Pentium は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における登録商標です。

Microsoft、Windows、Windows NT および Windows ロゴは、MicrosoftCorporation の米国およびその他の国における商標です。

Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Cell Broadband Engine は、Sony Computer Entertainment, Inc. の米国およびその他の国における商標であり、同社の許諾を受けて使用しています。

ITIL は AXELOS Limited の登録商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

製品資料に関するご使用条件これらの資料は、以下の条件に同意していただける場合に限りご使用いただけます。

特記事項 95

適用可能性

IBM Web サイトの「ご利用条件」に加えて、以下のご使用条件が適用されます。

個人使用

これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、非商業的な個人による使用目的に限り複製することができます。ただし、IBM の明示的な承諾をえずに、これらの資料またはその一部について、二次的著作物を作成したり、配布 (頒布、送信を含む) または表示 (上映を含む) することはできません。

商業的使用

これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、お客様の企業内に限り、複製、配布、および表示することができます。ただし、IBM の明示的な承諾をえずにこれらの資料の二次的著作物を作成したり、お客様の企業外で資料またはその一部を複製、配布、または表示することはできません。

権利

ここで明示的に許可されているもの以外に、資料や資料内に含まれる情報、データ、ソフトウェア、またはその他の知的所有権に対するいかなる許可、ライセンス、または権利を明示的にも黙示的にも付与するものではありません。

資料の使用が IBM の利益を損なうと判断された場合や、上記の条件が適切に守られていないと判断された場合、IBM はいつでも自らの判断により、ここで与えた許可を撤回できるものとさせていただきます。

お客様がこの情報をダウンロード、輸出、または再輸出する際には、米国のすべての輸出入 関連法規を含む、すべての関連法規を遵守するものとします。

IBM は、これらの資料の内容についていかなる保証もしません。これらの資料は、特定物として現存するままの状態で提供され、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任なしで提供されます。

96 IBM Workload Automation: 概要

索引

日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アクセシビリティー ixアクセス方式 58新しい向上したインターフェース xxxixアップグレード

v8.6 インスタンス xxivアップグレード、エージェント xxviii,

xxix, xxxiアプリケーション

定義 62アプリケーションのデプロイメント

デプロイメント xxviアプリケーション・プログラマー 10アプリケーション・プログラミング・イン

ターフェース (API) 73アラート、NetView に渡す 69依存関係

条件 xliii定義 64

エージェント

更新 xxviii, xxix, xxxi, livエンド・ユーザーからの照会 11オートコンプリート

ワークステーション名とユーザー

ID xlオカレンス 66, 67オペレーター、ワークステーション 10

［カ行］拡張エージェント 39, 58拡張再実行オプション xx拡張プログラム間通信 (APPC) 73拡張リカバリー・オプション xx仮想ワークステーション

定義 63各国語機能 61仮定

z/OS 環境 xviii仮定分析 xlv

拡張機能 xxiii仮定分析、

拡張機能 xxiii

仮定分析、 (続き)

クリティカル・ジョブへの影響を表示

xviii可用性 7カレンダー 43

定義 65監査証跡機能 76期間 65技術研修 x機能拡張要求 xv, xxvi, xxxiv共通プログラミング・インターフェース通

信 (CPI-C) 73業務の処理周期 65クラウド & スマーター・インフラストラ

クチャー技術研修 xグラフィカル・ビュー xxxiii

拡張 xvii, xlグラフィカル・ビューのスタイル

エクスポート xl幅広モニター xl変更 xl

グローバル・オプション 55計画

現在 67試行 62試行計画 62詳細 67タイプ 62長期間 66定義 66変更 74

計画できない作業 72計画ビュー

コンテキスト起動 xl計画ビュー、

改善 xvii権限検査 77研修 x

技術 x更新、エージェント xxviii, xxix, xxxi,

liv構成 78高度な統計 lv構文図の見方 x互換性

旧バージョンとの 78顧客からの照会 11コンソール・オペレーター 10コンテキストに合わせて計画ビュー xl

［サ行］再実行における柔軟性の向上 xx再始動 xli, 69, 71再始動管理 69, 71最新計画 67サイレント・インストール xxxvii作業実行依頼、自動 68サポート

エージェント xxviii, xxix, xxxi, liv動的エージェント liii

試行計画 62試行計画を使用したシミュレーション 62システム間カップリング・ファシリティー

(XCF) 69, 71, 80システム許可機能 (SAF) 77システム自動化コマンドの調整 69システム障害 69システム・アプリケーション体系共通プロ

グラミング・インターフェース通信 73実行サイクル 44実行サイクル・グループ 66実動期間 46実動制御ファイル 36実動ワークロード再始動 69, 71自動

状況検査 71状況報告 72ジョブ実行依頼 68

自動化 6自動ジョブおよび開始タスクのリカバリー

69, 71シフト・スーパーバイザー 10手動状況制御 75障害

Informatica PowerCenter ジョブの再

始動 xli障害点から Informatica PowerCenter ジ

ョブ xli状況検査、自動 71状況制御

手動 73, 74状況の照会 73状況報告

異機種環境から 72自動 72ユーザー・プログラムから 72

条件依存関係 xliii条件による自動化 xxi条件によるスケジューリング xxi

97

条件ベースのワークロード・オートメーシ

ョン xxi状態

IBM Tivoli Monitoring xliv初期化 xxxviiジョブ li, lii, lvi, lvii

IBM Sterling Connect:Direct xlixジョブ依存関係 64ジョブ間での変数の引き渡し xxxiiジョブ管理

プラグイン xixジョブ完了チェッカー (JCC) 72ジョブ管理,

プラグイン xixジョブ実行依頼

自動 68手動 74

ジョブ所要時間 lvジョブの完了時のスクリプトの実行 xxxixジョブの調整 68ジョブ・ストリーム 80ジョブ・ストリームの実行依頼

プラグイン xxiジョブ・ストリームの実行依頼,

プラグイン xxiジョブ・リカバリー

自動 69手動 74

新規グラフィカル・ビュー xxxiiiスクリプトの実行 xxxixスケジューリング・マネージャー 9スケジュール 66ステップ・レベル再始動 70正確な予測 lv制御されるシステム 79制御システム

説明 78リカバリー 70

セキュリティー 77セキュリティー設定の管理

Dynamic Workload Console xl前提条件検査

サイレント・インストール xxxviiマスター・ドメイン・マネージャー

前提条件の検査 xxxvii前提条件の検査 xxxvii操作依存関係 64操作マネージャー 9

［タ行］待機メッセージに対する自動応答 xxxix長期計画 66データ機能階層記憶管理プログラム

(DFSHM) 4

データベース・スキーマ

アップグレード xxxv更新 xxxv

データベース・スキーマのアップグレード

xxxvデータベース・スキーマの更新 xxxv定義と管理 xxxviii統合 2動的エージェント

ファイル依存関係 liiiDocker を使用したインストール xxiv

動的ドメイン・マネージャー 37特殊リソース

定義 65ドメイン・マネージャー 37トラッカー・エージェント 85

［ナ行］ネットワーク・エージェント 39

［ハ行］バージョン

制御 xxxiバージョン 8.6

アップグレード xxivバージョン管理 xxxiハイブリッド xxxviハイブリッド・ワークロード・オートメー

ション xxxviバックアップ、tws_env xxxiiバックアップ動的ドメイン・マネージャー

37バックアップ・システム 70バックアップ・ドメイン・マネージャー

(backup domain manager) 37バックアップ・マスター 37パラメーター (parameter) 45反復ワークフローの自動化、

反復ワークフロー xix標準エージェント 38標準リスト・ファイル 54ファイル依存関係 53ファイル依存関係、動的エージェント liiiフォールト・トレラント・エージェント

37複数層アーキテクチャー 90プラグイン

ジョブ xlixプログラム・インターフェース (PIF) 73プロンプト 44プロンプト依存関係 53ヘルプ・デスク 11

変更

制御 xxxi変数 44変数テーブル 44変数の引き渡し xxxii

ジョブ xxxii

［マ行］マスター・ドメイン 35マスター・ドメイン・マネージャー 37メッセージへの応答 xxxviiiモニター、ワークロードの 7

［ヤ行］役割ベース

IBM Workload Scheduler の役割ベー

スのセキュリティー・モデル xxxviiiユーザー権限検査 77ユーティリティー・コマンド、

filemonitor xxii要求

機能拡張 xv, xxvi, xxxiv

［ラ行］リカバリー 69, 71リカバリー・ジョブ 48リカバリー・プロンプト 48リソース 44リソース・アクセス管理機能 (RACF) 3,

77リソース・オブジェクト・データ・マネー

ジャー (RODM) 3利点 1, 12リモート・ダイアログ

ダイアログ 80ローカル・オプション 55

［ワ行］ワークステーション

オペレーター 10状況の変更 75定義 63

ワークステーション名とユーザー IDオートコンプリート xl

ワークステーション・クラス 43ワークロード再始動 69, 71ワークロードのモニター 7ワークロード・アプリケーション

新しいオプション xxvワークロード・セキュリティーの管理

Dynamic Workload Console xl

98 IBM Workload Automation: 概要

ワークロード・マネージャー (WLM) 3,71

AAPI

rest xxxiiiAPI (アプリケーション・プログラミン

グ・インターフェース) 73APPC (拡張プログラム間通信) 73

Bbatchman 41

CCICS 4Cloudant xxix

データベース (database) xxixCloudant 用のプラグイン xxixComposer 42Conman 42CPI-C (共通プログラミング・インターフ

ェース通信) 73

Ddeadline キーワード xxiiiDecision Support 3DFHSM (データ機能階層記憶管理プログ

ラム) 4Docker コンテナー、

動的エージェントのインストール xxivDynamic Workload Console

アクセシビリティー ix前提条件の検査 xxxvii

Dynamic Workload Console から IBM iジョブ xxxviii

EENABLEFIPS

FIPS のデータ暗号化 77

Ffilemonitor

ファイル変更のモニター xxii

HHadoop

Oozie xxxix

IIBM i ジョブ xxxix

IBM i メッセージに対する自動応答

xxxixIBM i メッセージへの応答 xxxviii

IBM SmartCloud Control Desk(SCCD) 3

IBM Sterling Connect:Direct、ジョブ

xlixIBM Tivoli Monitoring

デフォルトの状態 xlivIBM Tivoli Monitoring (ITM) 3IBM UrbanCode Deploy

統合 xxviIBM Workload Scheduler 58, 61, 80

互換性

旧バージョンとの 78サポートされているエージェント 59Windows Cluster Enabler

前提条件 78IBM Workload Scheduler インスタンス

xxxviiIBM Workload Scheduler エージェント

59IBM Workload Scheduler セキュリティ

ー xxxviiiIBM Workload Scheduler でサポートさ

れているエージェント 59IBM Workload Scheduler/NetView 53IBMi xxxii

ジョブ xxxiiIBMi ジョブ定義 xxxiiIMS 4ISPF (Interactive System Productivity

Facility)ダイアログ 67

ITM (IBM Tivoli Monitoring) 3

Jjobman 41jsuntil キーワード xxii

Mmailman 41

Nnetman 41NetView

アラート 69記述 2RODM 3

Oonlate キーワード xxiiiOozie ワークフロー xxxixOpenIncident

ServiceNow との統合 xxxiiOutput Manager for z/OS 3

PPIF アプリケーション

アプリケーション 80PIF (プログラム・インターフェース) 73plug-in for Apache Oozie xxxix

RRACF (リソース・アクセス管理機能) 3,

77REST API xxxiiiRFE xv, xxvi, xxxivRODM (リソース・オブジェクト・デー

タ・マネージャー) 3

SSA for z/OS Automation Feature 4SAF (システム許可機能) 77SCCD (IBM SmartCloud Control

Desk) 3ServiceNow インシデント管理 xxxiiSingle Entry Point xliSymphony 36, 46SYSOUT の検査 72System Automation for z/OS 4System Automation z/OS (SA/zOS) 4systemd

IBM Workload Scheduler の初期化

xxxvii

TTivoli Business Systems Manager 53Tivoli Information Management for

z/OS 3tws_env、バックアップ xxxii

Uuntil キーワード xxiiURL の作成 xluser 45

索引 99

Wwriter 41

XXCF (システム間カップリング・ファシリ

ティー) 69, 71, 80

Zz-セントリック・エージェント 39

100 IBM Workload Automation: 概要

IBM®

プログラム番号: 5698-WSH、5698-T08

Printed in Japan