オブジェクトの配布 (マネージメント・セントラル パッケージ機能)

マネージメント・セントラルには「パッケージ」という機能があります。

単純に言うと、セントラル・システムに接続されたシステム(= エンドポイント・システム)にオブジェクトを配信する、という仕組みを実現する機能です。
複数の iSeries がネットワークで接続された環境にあり、その間でたとえばセンターのシステムからアプリケーションの配信を行いたい、というような場合に有用な機能でしょう。

「パッケージ」とは配信するオブジェクト(復元時のオプションも含みます)と配信後に実行するコマンド、およびそれらに付随するオプションをセットにした定義になります。

それでは実行例を通してどんなものかを見ていきましょう。


今回は QEOL というライブラリーでできているアプリケーションを配信する、ということを例として行ってみたいと思います。

要は EOL/400 なのですが、具体的な内容としては QEOL というライブラリーと QEOL ライブラリーの中にある SETUP というプログラムを起動するとセットアップされるユーザープロフィールとそのユーザープロフィールの持つオブジェクトへの各種権限で構成されるアプリケーションになっています。

このアプリケーションをあるセンターのシステムにマスターとしておいておき、ネットワークでつながっている iSeries に配信して導入する、ということを行いたいと考えています。

前提/準備

準備としてまず最初に QEOL ライブラリーを QGPL/QEOLSAVF という保管ファイルに SAVLIB します。
保管ファイルの名前や置く場所(ライブラリー)に特に制限はありません。

次にこの保管ファイルからアプリケーション(EOL/400)をセットアップするためのプログラムを作成します。

ちなみに、今回はテストのためエラーリカバリーはいっさい入れていません(問題があった場合はどこでエラーになるか等の確認のためにそうしてあります)が、実際には必ず必要です。
というのは、このプログラムはマネージメント・セントラルのシステムジョブ (QYPSPRC) の一部として実行されるので、エラーで落ちた場合、何が起きたかの確認や対処がわかりにくくなっているからです。
プログラムの進行に応じて適宜メッセージを QSYSOPR に送る、など状況を把握しやすくするのもいいと思いますし、最悪、CL プログラムのあたまの MONMSG CPF0000 だけでも入れておいてください。

このプログラムを実行するのは QSYSWRK サブシステムの中の QYPSPRC になりますので、なんとなればこのプログラムの中で ENDSBS QINTER とか ENDSBS QBATCH などを実行することが可能です。つまり、このプログラムを実行する際に対話型のジョブをすべて終了させた状態で行いたい、といったようなことが可能です。
スケジュール機能(後述)と組み合わせるとけっこういろいろなことができそうですね。

パッケージ定義の作成

マネージメント・セントラルの「定義」から「パッケージ」を選び、右クリックメニューで「新しい定義」を選択してください。

「新規パッケージ定義」画面になります。

名前やテキスト(記述)を入力し、ソース・システム(= マスターのアプリケーションが存在するシステム)を選択します。
今回はマネージメント・セントラル・サーバー(この例では Domino400)と異なるシステム(この例では Asdomino2)をソース・システムに指定しています。

右側の「追加」ボタンで送信したオブジェクトを指定します。
マネージメント・セントラル・サーバー(この例では Domino400)と異なるシステム(この例では Asdomino2)をソース・システムに指定しているため、「iSeries へのサインオン」を要求されます。(この時点ですでにマネージメント・セントラル・サーバーにはサインオン済みです。こうやっていろいろ定義できているので当たり前ではありますが)

送信するオブジェクトは準備のところで見た保管ファイルとセットアッププログラムの 2つです。
ここの「ソース・システム」は「追加」ボタンを押した時に PC からの接続に使用されるホスト名になります。
実際に送信する時には、送信先のシステムからこのソース・システムに接続に来るのですが、ファイヤーウォールなどがある場合やネットワークの構成によっては同じ名前であるとは限りませんね。そうした場合は、実際の送信前にパッケージのプロパティでこの「ソース・システム」を変更してやれば OK です。

ターゲット・パスは同じものが自動的に入りますが、別のものとして復元するように指定することもできます。

復元時のオプションを見て見ましょう。
下はデフォルトの画面そのままですが、今回は「既存のファイルを送信中のファイルで置き換える」の方にチェックをつけています。

「拡張」ボタンを押した後に出てくる画面です。
下はデフォルトのままですが、今回は最後の「復元でオブジェクトの相違を認める」に「はい」を指定しました。

「アクション」タブで、送信したオブジェクトが復元され終わった後に実行することのできるコマンドを指定できます。

ここで指定できるコマンドは 1つだけのようなので、今回の例のようにプログラムにしてしまって CALL した方がいいように思います。

ちなみに、上の画面はプロンプトも使えます。

また、この「アクション」で指定したコマンドは特別文法チェック等がされるわけではありませんので、確認のために一度プロンプトを出してみるのもいいかもしれません。

ということで作成されると、以下のように「定義」-「パッケージ」のところにリストされます。

上の画面で、定義を右クリックして「送信」します。

「送信」を実行するとすぐに送信先のシステムの選択画面になります。

送信先のシステムを指定します。
「システム・グループ」も指定できるので、多数のシステム(パーティションの場合でも同じ)がある場合は同報で送れるのでけっこうよいのではないでしょうか。

また、「スケジュール」ボタンでスケジュールを指定できます。
定期的に送るのであれば、指定しておくといいでしょう。
「パッケージ」の定義はあくまで定義なので、たとえば今回の例でも保管ファイルの内容を毎週入れ替えて、セットアッププログラムも同名のまま内容を変更しておけば毎週自動的にリリースアップが行われる、という仕組みにすることができます。

パッケージ送信の実行

ソース・システムでの状況

パッケージの送信を行うとソース側ではサブシステム QSYSWRK のもとで QYPSPRC というジョブが起動されます。実際にはマネージメント・セントラル・サーバー(今回の例ではターゲット側 (Domino400) になります)からのリクエストでソース側 (今回は Asdomino2) に QYPSPRC ジョブを起動させる、というようになっていると思います。
このジョブがターゲット側にソースからの送信をリクエストしターゲット側での QYPSPRC ジョブを起動させます。
(このことからこのシステムからマネージメント・セントラルでエンドポイントとして定義された名前で TCP/IP の名前解決ができなくてはいけないことがわかりますね)

しばらくするとこの QYPSPRC ジョブは EOJ (End Of Job) になり、QYPSBDTSVR というジョブが動き始めます。

ターゲット側の状況

ソース側からの要求に応じて QYPSPRC ジョブが起動されます。

このジョブログを見るとソース側 (Asdomino2) のリクエストを受けて一回ターゲット側 (Domino400) でこの QYPSPRC が起動され、そこからあらためてまたソース側 (Asdomino2) に QYPSBDTSVR ジョブを起動させて転送を行っていることがわかります。
(このことから今度はこのシステムからマネージメント・セントラルでエンドポイントとして定義された名前で TCP/IP の名前解決ができなくてはいけないことがわかります)

先のセットアッププログラムがこの QYPSPRC ジョブの中で動いていることも、このジョブログからわかります。
このセットアッププログラムが異常終了した場合、この QYPSPRC というジョブがメッセージ待ちになります。お馴染みの "C" とか "I" とかをこのジョブに対して答えてやらなくてはなりません。
応答しない限りずっとこのジョブは待っていますので、いつまでたっても送信が終わらないけどなんでかなあ、ということになってしまいますのでご注意ください。

すべて完了すると以下のような状態になります。

オブジェクトの送信のみが成功して、その後のコマンドの実行に問題があったような場合は、以下のように「状況」のところにちゃんとその旨がわかるようなメッセージが表示されます。

その他

この他、単純にオブジェクト(プログラムやファイルなど)を入れ替えたいだけ、なんていう場合にも (実際にはそちらの方が多いのかもしれませんが) 有用です。
入れ替えたいオブジェクトを単純に指定し、必要な場合はターゲット・パスを指定するだけでシステムが入れ替えてくれます。アクションの指定は必要ありません。

[Top Pageに戻る]

Ads by TOK2