VSE vs MVS比較

All Rights Reserved ，Copyrights Hirofumi Nakata　　　　　　　

VSE/ESA vs

z/OS(MVS) 概要比較説明資料

平成16年4月26日Hirofumi Nakata


VSE/ESA 中小規模向けＩＢＭメインフレームＯＳであることは周知のとおり。小回りの利く、ＯＳである。 VSEの制約により、業務量の増大によるオンラインCICS区画SOSの多発への対応が難しい。ＯＳが持つセキュリティー機能の不足。マルチジョブのスループットの問題。

近のzSeriesテクノロジーや新技術の享受をすぐに受けられない。 VSEを理解しているエンジニアの不足

１）OS概要

z/OS(MVS) 大規模向けＩＢＭメインフレームＯＳであることは周知のとおり。小回りはあまり利かないが、RASISに非常に優れたＯＳである。 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から実装される。


２）VSE vs z/OS　主なプロダクトファンクション比較


３）区画とアドレス空間

区画とアドレス空間 VSEとz/OSにおいてもっとも違うのが、区画とアドレス空間(Region)である。 VSEにおいては区画（静的区画・動的区画）をあらかじめ用意する。用意する際にあらかじめ与えられるメモリー量などを決める。その区画の中でCICS／VTAM／バッチJOBなどは稼動することになる。おのずと、オンライン処理、バッチ処理の並行度が限られることになる。 z/OSにおいては STARTコマンド及びジョブがSUBMIT時点でアドレス空間(Region)が生成されその中でCICS／ VTAM／バッチJOBが稼動することになる。それぞれのアドレス空間は約２ＧＢｙｔｅ程度仮想記憶域を使用することが出来る。（共通域を除く）使用する仮想記憶域量を制限することも可能。設定によっては大32767のアドレス空間での実行が可能である。


３）区画とアドレス空間 ①現行勘定系本番環境

静的区画においては、区画メモリーが不足した場合に、動的に増分させることが出来ない。そのため、勘定系ＣＩＣＳなどでＳＯＳが発生した場合に問題となる。動的区画を用いて、バッチの並行度をある程度高めることは可能である。


３）区画とアドレス空間　 ②z/OSへ移行後の勘定系

基本的にＳＴＡＲＴコマンド及びＪＯＢＳｕｂｍｉｔにてＶＳＥの区画に相当する、アドレス空間（Region)が生成される。（ＭＡＸ３２７６７まで、サイズは大２ＧＢ以内）アドレス空間同士のプロセッサー使用量などの優先度をＷＬＭ（WorkLoadManager)にて制御が出来る。各アドレス空間はＪＯＢが終了すると消滅する。


４）コンソール及びオペレーション　 ①コンソール及びコンソールオペレーション

z/OS化した際に、変わるコンソールオペレーション　①コマンド体系が変わることはもちろんのこと。　②システムコンソールを複数台もてる。（複数のシステムコンソールというのが一般的）　③コンソールからのＰＧＭへの日付応答が行えない。　（不可能ではないがＭＶＳの世界では一般的ではない）　④システムコンソールからのＪＣＬの修正・入力が不可能　

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に切り替えることで運用が続行可能。


４）コンソール及びオペレーション　 ②システムコンソールイメージ

どちらも VSE　z/OSともに現在稼動している、稼動区画及び稼動アドレス空間(Job)を表示するコマンドを入力し、結果表示されたものである。

VSE/ESA z/OS


４）コンソール及びオペレーション　 ③テープオペレーション

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は再開され終了する。


５）開発環境　 ①現行開発環境との違い

z/OSでは、TSO/ISPFのもとでPGMの開発、メンテナンス、コンパイル、LINK/EDITを行うことが可能である。

VSE/ESA VM/ESA　(CMS)

CICS/VSE ICCF

ＰＧＭソース定義体

オブジェクト及び実行モジュール

ICCFライブラリー

z/OS

TSO ISPF

ＰＧＭソース定義体

実行モジュール

現行開発環境 z/OSにおける開発環境

区分データセット


５）開発環境　 ②開発画面イメージ

CMSに比べTSO/ISPFのほうがEditerとしての機能も高機能である。

VM (CMS)

TSO/ISPF


５）開発環境　 ③開発管理対象

PGMソース A

コンパイル

Object A 共通Object B

LINK/EDIT

フェーズ A

共通オブジェクト

PGMソース A

コンパイル

Object A

共通ロードモジュール

共通ロードモジュール B

LINK/EDIT

ロードモジュール A

たとえば共通プログラムＢをＣＡＬＬするＰＧＭ　Ａをコンパイル／ＬＩＮＫ／ＥＤＩＴする場合、 VSEの場合、プログラムＢのＯｂｊｅｃｔが必要となるが、z/OSの場合は、ＬＩＮＫ／ＥＤＩＴの際には、Ｏｂｊｅｃｔではなく生成されたロードモジュールをＩｎｃｌｕｄｅしてＬＩＮＫ／ＥＤＩＴしてくれるので、Ｏｂｊｅｃｔは単なる中間ファイルに過ぎない。そのため、z/OSにおいては、OBJECTを管理する必要はなく、ソースとロードモジュール（ＶＳＥではフェーズ）のみを管理するのが一般的。

VSEの場合 z/OSの場合

管理対象


６）言語　 ①シーケンシャルＩ／Ｏ記述部分の簡略化

したがって、もともとテープに書き出すことを想定したＰＧＭであっても、ＪＣＬの変更において、ＰＧＭの修正を行うことなくディスクへ書き出すことも可能

シーケンシャルファイルの場合、テープ、ディスクなどの装置形式に依存しないコーディングが可能。（ＰＬ／Ｉ　ＣＯＢＯＬ　アセンブラ）


６）言語　 ②ＪＣＬ

ＪＣＬについては、VSEとz/OSにおいてはまったく互換性はない。特にＩＦ文については、z/OSには存在しない機能もある。変更点については、次ページ参照。


Software

VSE vs MVS比較