vse vs mvs比較
TRANSCRIPT
All Rights Reserved ,Copyrights Hirofumi Nakata
VSE/ESA vs
z/OS(MVS) 概要比較説明資料
平成16年4月26日Hirofumi Nakata
All Rights Reserved ,Copyrights Hirofumi Nakata
VSE/ESA 中小規模向けIBMメインフレームOSであることは周知のとおり。 小回りの利く、OSである。 VSEの制約により、業務量の増大によるオンラインCICS区画SOSの多発への対応が難しい。 OSが持つセキュリティー機能の不足。マルチジョブのスループットの問題。
近のzSeriesテクノロジーや 新技術の享受をすぐに受けられない。 VSEを理解しているエンジニアの不足
1)OS概要
z/OS(MVS) 大規模向けIBMメインフレームOSであることは周知のとおり。 小回りはあまり利かないが、RASISに非常に優れたOSである。 OSが64bit化されたことにより、DFSORTのWorkエリアとして2GByte以上のメモリーエリア についても利用が可能となった(z/OS V1.5より) VSEで問題となる、CICSのSOSの多発やマルチジョブのスループットについても z/OSにおいてはすべて解決することが可能である。RegionSizeにも相当の余裕があり、 JOBの多重度においても飛躍的に上がる。OSのSecurity機能も標準で実装。 I/Oの性能においてもVSE/ESAを上回る性能を持つ。 SW料金についても以前程の格差はない。
近のzSeriesテクノロジーや 新技術はすべてz/OSから実装される。
All Rights Reserved ,Copyrights Hirofumi Nakata
2)VSE vs z/OS 主なプロダクトファンクション比較
All Rights Reserved ,Copyrights Hirofumi Nakata
3)区画とアドレス空間
区画とアドレス空間 VSEとz/OSにおいてもっとも違うのが、区画とアドレス空間(Region)である。 VSEにおいては 区画(静的区画・動的区画)をあらかじめ用意する。用意する際にあらかじめ与えられるメモリー 量などを決める。 その区画の中でCICS/VTAM/バッチJOBなどは稼動することになる。 おのずと、オンライン処理、バッチ処理の並行度が限られることになる。 z/OSにおいては STARTコマンド及びジョブがSUBMIT時点でアドレス空間(Region)が生成されその中でCICS/ VTAM/バッチJOBが稼動することになる。それぞれのアドレス空間は約2GByte程度仮想 記憶域を使用することが出来る。(共通域を除く) 使用する仮想記憶域量を制限することも可能。 設定によっては 大32767のアドレス空間での実行が可能である。
All Rights Reserved ,Copyrights Hirofumi Nakata
3)区画とアドレス空間 ①現行勘定系本番環境
静的区画においては、区画メモリーが不足した場合に、動的に増分させることが出来ない。 そのため、勘定系CICSなどでSOSが発生した場合に問題となる。 動的区画を用いて、バッチの並行度をある程度高めることは可能である。
All Rights Reserved ,Copyrights Hirofumi Nakata
3)区画とアドレス空間 ②z/OSへ移行後の勘定系
基本的にSTARTコマンド及びJOBSubmitにてVSEの区画に相当する、アドレス空間(Region)が生成される。 (MAX32767まで、サイズは 大2GB以内) アドレス空間同士のプロセッサー使用量などの優先度をWLM(WorkLoadManager)にて制御が出来る。 各アドレス空間はJOBが終了すると消滅する。
All Rights Reserved ,Copyrights Hirofumi Nakata
4)コンソール及びオペレーション ①コンソール及びコンソールオペレーション
z/OS化した際に、変わるコンソールオペレーション ①コマンド体系が変わることはもちろんのこと。 ②システムコンソールを複数台もてる。(複数のシステムコンソールというのが一般的) ③コンソールからのPGMへの日付応答が行えない。 (不可能ではないがMVSの世界では一般的ではない) ④システムコンソールからのJCLの修正・入力が不可能
z/OS
Master Console
Sub Console Sub
Console
VSE/ESA
System Console
CICS/ICCF IUI CICS/ICCF
IUI
z/OSではMasterConsole以外にSub-Console(Alternate Console)を複数台持てる。 Master ConsoleがI/O障害となった場合でもSub-ConsoleをMaster Consoleに切り替えることで運用が続行可能。
All Rights Reserved ,Copyrights Hirofumi Nakata
4)コンソール及びオペレーション ②システムコンソールイメージ
どちらも VSE z/OSともに現在稼動している、稼動区画及び稼動アドレス空間(Job)を表示するコマンドを入力し、結果表示されたものである。
VSE/ESA z/OS
All Rights Reserved ,Copyrights Hirofumi Nakata
4)コンソール及びオペレーション ③テープオペレーション
Job Submit
//PAUSE ステートメントにより
JOBが一時停止
該当Driveに Tape Mount
Consoleより EnterKey投入により
JOBが再開
Job End
一般的なVSE/ESAの場合
Job Submit
Master/Sub Console にテープマウント
要求Message出力される。 JOB Waitの状態
該当Driveに Tape Mount
テープマウント完了後 JOB再開
Job End
一般的なz/OSの場合
z/OSでは、SUBMITされて、マウント要求が来てからマウントを行えばよい。 マウントが完了すれば、自動的にJOBは再開され終了する。
All Rights Reserved ,Copyrights Hirofumi Nakata
5)開発環境 ①現行開発環境との違い
z/OSでは、TSO/ISPFのもとでPGMの開発、メンテナンス、コンパイル、LINK/EDITを行うことが可能である。
VSE/ESA VM/ESA (CMS)
CICS/VSE ICCF
PGMソース 定義体
オブジェクト及び 実行モジュール
ICCFライブラリー
z/OS
TSO ISPF
PGMソース 定義体
実行モジュール
現行開発環境 z/OSにおける開発環境
区分データセット
All Rights Reserved ,Copyrights Hirofumi Nakata
5)開発環境 ②開発画面イメージ
CMSに比べTSO/ISPFのほうがEditerとしての機能も高機能である。
VM (CMS)
TSO/ISPF
All Rights Reserved ,Copyrights Hirofumi Nakata
5)開発環境 ③開発管理対象
PGMソース A
コンパイル
Object A 共通Object B
LINK/EDIT
フェーズ A
共通オブジェクト
PGMソース A
コンパイル
Object A
共通ロードモジュール
共通ロードモジュール B
LINK/EDIT
ロードモジュール A
たとえば共通プログラムBをCALLするPGM Aをコンパイル/LINK/EDITする場合、 VSEの場合、プログラムBのObjectが必要となるが、z/OSの場合は、LINK/EDITの際には、Objectではなく生成されたロードモジュールをIncludeして LINK/EDITしてくれるので、Objectは単なる中間ファイルに過ぎない。 そのため、z/OSにおいては、OBJECTを管理する必要はなく、ソースとロードモジュール(VSEではフェーズ)のみを管理するのが一般的。
VSEの場合 z/OSの場合
管理対象
All Rights Reserved ,Copyrights Hirofumi Nakata
6)言語 ①シーケンシャルI/O記述部分の簡略化
したがって、もともとテープに書き出すことを想定したPGMであっても、JCLの変更において、PGMの修正を行うことなくディスクへ書き出すことも可能
シーケンシャルファイルの場合、テープ、ディスクなどの装置形式に依存しないコーディングが可能。(PL/I COBOL アセンブラ)
All Rights Reserved ,Copyrights Hirofumi Nakata
6)言語 ②JCL
JCLについては、VSEとz/OSにおいてはまったく互換性はない。 特にIF文については、z/OSには存在しない機能もある。 変更点については、次ページ参照。
All Rights Reserved ,Copyrights Hirofumi Nakata