»

z/OSソフトウェア製品移植のための前提知識(命令やマクロの互換・ソースレベルの互換)

By 神居 - Posted: 2009/10/21 Last updated: 2009/10/21 - Leave a Comment
印刷用ページの表示 印刷用ページの表示

ソースコードの互換性

CPUアーキテクチャが同じなので、命令の形式、機能は同じである。アセンブラー言語としての文法も同じだから、MVSのアセンブラー・コードはそのままアセンブルできる。OSの制御表を参照せず、OSのマクロ(API)命令も使わなければ、そのままMSP、VOS3に持ってくることができる。ソース互換と言うよりはロードモジュールをそのまま動かすことも可能である。これが移植にあたっての基本。

とは言え、近年はソースレベルでの非互換も多くなってきた。この理由は大きく2つ。1つはS/390やz/Archで追加された新しい命令セットが富士通や日立ではサポートされないものがあること。もう1つはアセンブラーの違いである。OS/390以降で提供され、現在のz/OSでも使用されるHLASM(高水準アセンブラー)は、それまでのアセンブラーと異なり、コーディングに非常に大きな柔軟性をもたらした。例えば、2つのDCBにDCBDをマッピングして、データ・フィールドを参照する際、HLASMでは「MVC SYSUT2.DCBLRECL,SYSUT1.DCBLRECL」のように、同じフィールド名に異なるベースアドレスを設定して参照することができる。MSPとVOS3のアセンブラーであれば、「MVC DCBLRECL-IHADCB(2,R4),DCBLRECL-IHADCB(R5)」のように修正しなければならない。どちらも同じオブジェクトコードを生成するが、ソースのコーディングには互換がない。そのためz/ArchやHLASMを前提にコーディングされたMVS用プログラムは、大幅な書き換えを強いられることになる。OSの機能と同じで、「昔は同じだったが、新しく追加されたものは非互換が多い」がここにも適用される、と考えてよい。


機械命令

一般に使われるCPU命令には基本的に互換があるが、S/390やz/Archで追加された新しい命令セットはIBMでしか利用できない。(日立ではM/64モードにすれば、互換動作可能なものもあると思われる...)
それらには64ビット命令(例えば命令の末尾にGが付くもの)や即値加算(AHI)、文字列移動(MVST)、圧縮(CMPSC)、ツリー操作(UPT)などがある。またマニュアルには載っていないが、z/ArchではJump命令などintel CPUの命令動作に近いものもあり、海外製のソフトでは利用したものがあるかも知れない。当然これらの命令はサポートされていないと思われる。


マクロ命令

同じAPIがMSPとVOS3にも実装されているかどうかは、マクロ命令の有無で基本的に判定できる。マクロ名とパラメーターがまったく同じもの、パラメーターの一部に非互換があるもの、違うマクロ名で同等機能が提供されるもの、に分かれる。中にはマクロ命令ではサポートされないものの、OS自身には互換機能が実装されているものもある。公開されていないため、ここに具体名を明かせないが、そのようなものはMVSのマクロでアセンブルされたオブジェクトで実行できる。
なお同じマクロ名、パラメーターでサポートされていても、生成される機械命令列が異なるものもある。


マッピングマクロ

システム・プログラムの場合、OSのコントロール・ブロックを参照することは多々ある。この場合、参照するフィールドは先頭からのオフセット値(先頭+○○)ではなく、対象のフィールドを名前で指定するのが一般的である(と言うか鉄則)。この時に使用するのがMACLIBやMODGENに入っている、コントロール・ブロックのマッピングマクロである。例えばデータセットのDCBなどをマッピングするDCBDマクロがある。
実行マクロと違い、マッピングマクロの多くは異なる名前を持つ(と言っても先頭3文字が違って後は同じと言うものが多い、例えばIHAがKAAやJAAなど)。フィールド名には比較的互換があって、マクロ名を変えれば、同じフィールド名で参照できるものが多い。しかし同じフィールド名やフラグ名であっても意味まで同じかどうかは別である。
例えば、ASVTのASVTENTYフィールドにはASVTAVALと言うフラグがあり、MVSではフラグがONの時は対応するアドレス空間はアイドル(どのジョブにもアサインされていない状態)だが、MSPでは逆にアクティブである。VOS3はMVSと同じである。
全く名前が違っていたり、存在しなかったりすれば、対応フィールドを探したり、代替方法を考えるため、そこで調査をすることになるが、名前が同じだとアセンブルでエラーにならず、そのまま通してしまうことになる。そして実行時にエラーになったり、とんでもない動きをしたり、となる。経験的にわかっているなら別であるが、基本としては参照や更新をしているコントロール・ブロックとフィールド、フラグをピックアップして、Diagnosisのマニュアル(例えばData area)やマッピングマクロのコメントなどから、何のためにアクセスしているのかを調べることを奨める。その上で、移植先の関連マニュアルやマッピングマクロを見ることになる。
MSPには「デバッグ手引書」があり、マッピングマクロにもコメントが付いているが、VOS3にはMSPのデバッグ手引書に相当するマニュアルはなく、マッピングマクロにもコメントがないので、事前の調査はむずかしい。名前が同じなら意味も同じと信じて実機で確認するしかない。

Posted in ポーティング、ローカライズ手法 • • Top Of Page