先日、Z/OSの並列実行機能について掲載されました。
私が関わったVOS3のジョブステップ並列実行機能(JSPEC)について、記憶を辿って順次掲載していきます

日立のジョブステップ並列実行機能(JSPEC)とは

VOS3で動作するJSPECは基本的に先日掲載された、Z/OSのジョブ並列実行と同じです。一つのジョブの流れの一部(ジョブステップ)を並列実行させることで、ジョブの終了時間を早める事を目的としています。
JSPECを使う場合、ユーザ側は並列実行させたいジョブステップのEXEC文に”JSPEC=YES”を追加するだけです
VOS3の場合、JSPEC=YESで指定された(先行ジョブステップと並列実行する)ジョブステップを”サブジョブ“と呼びます

#以下のジョブがあった場合、STEP3にJSPEC=YESの指定により、STEP3とSTEP4が並列実行されます。この場合STEP3がサブジョブとなります
//AAAAAAAA JOB CLASS=A・・・
//STEP1 EXEC PGM=PGM01
:
:
//STEP2 EXEC PGM=PGM02
:
:
//STEP3 EXEC PGM=PGM03,JSPEC=YES
:
:
//STEP4 EXEC PGM=PGM04
:
:


しかし、EXEC文でJSPEC=YESを指定しても、システム側でJSPECが使える環境になっていないとオペランドが無視若しくはJCLエラーになります
ジョブステップを並列に実行する事は、並列実行している時間にCPU(演算装置)に今まで以上の能力が求められる事になります。

詳細は「JSPECを実行するためのシステム側の設定」で説明します

日立のジョブステップ並列実行機能(JSPEC)のはじまり

VOS3でジョブステップ並列実行機能(JSPEC)はVOS3/FSからリリースされました。
VOS3/FSではCPUを並列に接続し、負荷の軽いCPUでバッチジョブや通信・TSS(TSO)などに実行を振り分ける「高速結合機構(HCCF)」がリリースされるなど、”並列(パラレル)”がキーワードでした。
HCCFのような高額なハードウェアを使えないサイトでも”並列”の恩恵を受けるための機能としてJSPECがあったと思っています。

JSPECを支援するツール、環境

ジョブステップが並列に実行される事は、今まで並列実行(別ジョブとして同時に実行)できなかった事が環境の整備などによって並列実行できるようになる事です。VOS3が用意しているツール、環境を紹介します

ジョブステップ並列実行支援機能「JSPEC/AID」

VOS3/FSでJSPECが初めてリリースされた時、JSPECを適用できるか否かを判断するツールがありました。それがJSPEC/AIDです。
JSPEC/AIDの入力データにJSPECを適用したいJCLを入れると、適用の可否などを判定結果としてリスト出力してくれました。
(VOS3/USではJSPEC/AIDは別の手段として提供されている可能性があります)

並列実行ジョブステップ間データ転送機能「PREST」(プレスト)

ジョブステップを並列実行する事で一番の問題になるのが先行ステップで得られたデータの受け渡しです。
先行ジョブステップで得られたデータを中間ワークに一時保管しておき、後続のジョブステップ、サブジョブでデータを入力します
ここで問題になるのが、中間ワークへの出力が完了するまで後続のジョブステップ、サブジョブを実行できない事です

そこで、用いられるのがPREST(Pararell REference and Synchronous Transfer facility)です

PRESTは元々VOS3/FSの前のOSであるVOS3/ASでリリースされた機能です。
VOS3/ASでのPRESTは「ジョブ間、ジョブステップ間でのデータ逐次渡し機能」だけでした。

VOS3/FSではさらに以下の機能をリリースし、JSPECへの適用範囲を拡大しました
1)データ多重転送機能
先行ジョブ・ジョブステップがPRESTに出力したデータを複数の後続ジョブ・ジョブステップ・サブジョブに同時転送する機能。これにより同じデータを利用する複数のジョブ・ジョブステップ・サブジョブの同時実行が可能になりました
2)データ分割転送機能
先行ジョブ・ジョブステップの出力を分割し、複数の後続ジョブ・ジョブステップ・サブジョブに転送する機能です。


3)転送データバックアップ機能
PRESTによるデータ転送中、同時にバックアップを採取する機能
4)システム間データ転送機能
PRESTをシステム間で利用が可能になりました。これによりCPUの負荷分散が図れるようになりました

PRESTの仕組み

　PRESTは仮想メモリ上に確保される領域です。1レコードが入る程度の大きさしか確保されないため、PREST領域を使う時、SPACE情報は不要です。

　データセット名とUNIT=PRESTの記述だけで利用できたと記憶しています

　PRESTは一時領域のため、PRESTにデータを書き込むジョブ・ジョブステップ・サブジョブとデータを読み込むジョブ・ジョブステップ・サブジョブが同時に必要になります。
　UNIT=PRESTの指定があるジョブが実行された場合、OSはPREST領域にデータセット名が存在するかを探します
　あれば、データを読み込む側、なければデータを書き込む側と判断できます。
　（データセットをOPENする際のオプションREAD・WRITE・UPDATEとの組み合わせが合わない場合、エラーにしていたと思います）

　あとはPRESTにデータを書き込むジョブ・ジョブステップ・サブジョブから1レコードが書かれたら、データを読み込むジョブ・ジョブステップ・サブジョブにデータが渡されます。これの繰り返しです。
　PREST領域を同時に使えるジョブの数に制限は無かったと思いますが、ISMルールなどを用いてUNIT=PRESTの指定ができるジョブを制限する事は可能です。

JSPECを実行するためのシステム側の設定

　ここからはジョブステップ並列実行機能(JSPEC)を使えるようにするためのシステム側の設定についての説明です。
　JSPECだけを使えるようにする場合、システムパラメタ(JSS3PARM等)だけ設定する事で動作しますが、PRESTを使う場合はさらに入出力(IO)ゼネレーションパラメタの設定が必要になります。
　また、サブジョブが先行ジョブステップと同時実行することにより設定前よりCPUが高負荷となることから、ストーレジ設計の見直しが不可欠です

システムパラメタ(JSS3PARM等)、入出力(IO)ゼネレーションパラメタの設定
ストーレジ設計 等

システムパラメタ(JSS3PARM等)の設定

　システムパラメタ(JAASYS00など)でJSPEC=YESの指定が必要か否か記憶が定かではありませんが、JSS3PARMで記述するサブジョブ専用イニシエータの設定により、パフォーマンス・実行多重度(ジョブ)の設定を行うJAAIPS00に影響を与える可能性が考えられます。詳細は「VOS3　センタ運営」で確認して下さい

　JSS3初期設定パラメタ(JSS3PARM)では以下の設定が必要になります
　・ジョブクラス毎にJSPECの実行を許可するか否かの設定
　　　JSPECの実行を許可するか否かをジョブクラス毎に設定します。省略値はJSPEC=NOのため、JSPECの実行を許可する場合、JSPEC=YESを明示指定します

　　　冒頭に記述したジョブの例は実行クラス”A”のため、JSS3PARMのジョブクラス”A”の設定にJSPEC=YESを指定しておく必要があります

　・サブジョブ専用イニシエータの設定　
　　　通常のイニシエータ設定とは別に、サブジョブ専用のイニシエータを設定します。
　　　イニシエータ名称の後、CLASS=*（アスタリスク）を記述し、どこのジョブクラスにも属さないサブジョブ専用のイニシエータが出来ます

　　　ここで記述したサブジョブ専用イニシエータ(CLASS=*)の数が必然的にJSPEC(並列実行)多重度の上限となります

入出力(IO)ゼネレーションパラメタの設定

　PREST領域を使う場合、入出力(IO)ゼネレーションに設定が必要です。
　UNITNAMEマクロでUNIT=PRESTの一行を書くだけだったと記憶しています

ストーレジ設計

JSPECを適用する際、サブジョブを動作させるための専用イニシエータクラスを設定するなど、必要とするリソースが増加する可能性があるためストーレジ設計値に影響があります

詳細は「VOS3　ストーレジ設計」を参照してください

JSPECを適用する場合、もう一つ注意しなければならない点をお伝えします。
メインフレームコンピュータのシステム構成を検討するとき、担当部署はシステムに求められている業務を遂行するため、システムが必要とするリソース(CPU MIPS、メモリ量、DISK容量等)を算出し、金額に見合うハード構成を選定します

しかし、JSPECを使う事でハード構成選定時に検討したリソースを超過する可能性があります
それは、JSPECがジョブの終了時間を短縮する事が目的であり、サブジョブを同じ時間帯に実行させるため、実行に必要なリソースを(JSPEC適用前より)高く必要とするからです

したがって見積もり時に用いたリソースを超えるようなシステム稼働は想定していません

ところが、JSPECを使う事でハード構成選定時に検討したリソースを超過する可能性があります。JSPECがジョブの終了時間を短縮する事が目的であり、サブジョブを同じ時間帯に実行させるため、実行に必要なリソースを(JSPEC適用前より)高く必要とするからです


JSPECがリリースされる以前にもジョブの時間短縮の方法は検討されていました。
検討理由は多々あるのですが、その一例は中間データセットです。クローズされないと次に渡せないからです
対策方法には中間データセットの出力方法見直し、出力先の変更（仮想メモリ）です

VOS3/FSでJSPECがリリースされた時、ソフトウェア工場は耳にタコができるくらい私たちサイト担当者に、「JSPECを使ってくれ」という言葉を言いました「JSPEC/AIDを実行して、どのくらい改善されるか定量化してくれと、、」

でも、システムを管理している側にしてはリソースの事が前提にあったので、ソフトウェア工場からの言葉はあまり受け入れられないものでした


最後に、、
VOS3の場合、JSPECがもたらした恩恵はそんなに多くなかったというのが私の印象です
時代が遅すぎたという点もあったかもしれません

現在では、COD(キャパシティ・オンデマンド)があるので、お金があるサイトではある程度のリソースアップ(MPIS、メモリ)は出来ますが、、

※記載の内容に一部誤りがありましたので、修正しました