コントロール・ブロックのマッピング
コントロール・ブロックのマッピング
多くのシステム・プログラム製品はOSのコントロール・ブロック（制御表）を参照します。古くからあるメジャーなコントロール・ブロックは、その構造やフィールド名にも互換が多く、比較的移植がしやすいものです。ただしコントロール・ブロックのマッピング・マクロ名については、ほとんどが異なるため、そのままアセンブルできることはまずありません。
マッピング・マクロ名を変更する（ソースメンバーを分ける）
MVS用
IHAPSA , PSA
CVT DSECT=YES CVT
IHAASVT , ASVT
IHAASCB , ASCB
IKJTCB , TCB
IKJRB , RB
MSP用
IHAPSA , PSA(KAAFLC)
CVT DSECT=YES CVT
KAAASVT , ASVT
IHAASCB , ASCB(KAAASCB)
KAATCB , TCB
KAARB , RB
VOS3用
JAEPSA , PSA
CVT DSECT=YES CVT
JAAXASV ASVT
JAAASCB , ASCB
JAAXTCB , TCB
JBCRB , RB
最も単純で簡単な方法です。MVSに対応するMSPとVOS3のマッピング・マクロ名で置き換えます。
マクロの中にはMVSと同じマクロ名でMSP用、VOS3用のマッピング・マクロを呼び出せるものがあります。例えばIHAASCBはKAAASCBを呼び出し直すマクロで、MSPのSYS1.MACLIBまたはMODGENに入っています。OSのマクロライブラリーにMVSと同じ名前のマッピング・マクロが入っている場合、そちらを使うことを奨めます。例えばMSPのIHAPSAマクロは単にKAAFLCを呼び出し直すだけでなく、非互換フィールドであるASCBとTCBのポインターをMVSのフィールド名で参照できるように追加されています。数は少ないですが、メジャーな非互換はマッピング・マクロで吸収されているものもあるのです。
マッピング・マクロ名を変更する（ソースメンバーを共用する）
AIF (&SOSF4).MSPBLKS
AIF (&SOSV3).VOSBLKS
IHAPSA , PSA
CVT DSECT=YES CVT
IHAASVT , ASVT
IHAASCB , ASCB
IKJTCB , TCB
IKJRB , RB
AGO .ENDBLKS
.MSPBLKS ANOP ,
IHAPSA , PSA(KAAFLC)
CVT DSECT=YES CVT
KAAASVT , ASVT
IHAASCB , ASCB(KAAASCB)
KAATCB , TCB
KAARB , RB
AGO .ENDBLKS
.VOSBLKS ANOP ,
JAEPSA , PSA
CVT DSECT=YES CVT
JAAXASV ASVT
JAAASCB , ASCB
JAAXTCB , TCB
JBCRB , RB
.ENDBLKS ANOP ,
ソースの一部が変わる程度の修正量であれば、ソースメンバーを分けると後々のメンテナンスやバージョンアップで苦労します。アセンブラーの機能で展開するソースコードを条件で選択することができますから、それを利用します。サンプルでは、OSを区別するフラグビット（&SOSF4、&SOSV3）を作り、MSPならMSPを示すフラグをONにし（SETBアセンブラー命令）、VOS3ならVOS3を示すフラグをONにするようにコードを作り、マッピング・マクロを展開する箇所では、AIFアセンブラー命令で条件分岐すればいいのです。フラグビットを作る代わりに、アセンブル時のPARMパラメーターでSYSPARM(任意の文字)パラメーターを指定し、そこに指定された内容で判定する方法もあります。例えば、PARM=’SYSPARM(MSP),…’と指定し、ソース中では、AIF (‘&SYSPARM’ EQ ‘MSP’).MSPBLKS、と聞けばよいのです。
AIF ('&SYSPARM' EQ 'MSP').MSPBLKS
AIF ('&SYSPARM' EQ 'VOS3').VOSBLKS
:
MVSと同じ名前のマッピング・マクロを作る（ソースメンバーを共用する）
メーカーがMACLIBやMODGENに用意したものもありますが、それがない場合、あっても移植するプログラムには内容が不十分、などであれば作ってしまうのも手です。作ったマッピング・マクロをOS別の専用マクロライブラリーを作り（例えばPP.MSP.MODGENやPP.VOS3.MODGEN）、そのマクロライブラリーをアセンブル時のSYSLIBに、メーカーのマクロライブラリーより先にコンカチします。
元のソース
IHAASCB , ASCB
IKJTCB , TCB
IKJRB , RB
IKJASCBマクロの内容（MSP用）
MACRO
IHAASCB
KAAASCB
ASCBJBNI EQU ASCJBNI フィールド名の違いを吸収するEQU定義の追加
ASCBTSB EQU ASCTSB
ASCBCSCB EQU ASCCSCB
MEND
IKJTCBマクロの内容（MSP用）
MACRO
IKJTCB &DSECT=YES,&PRINT=OFF
KAATCB DSECT=&DSECT,PRINT=&PRINT
MEND
IKJRBマクロの内容（VOS3用）
MACRO
IKJRB
JBCRB
MEND
この方法の利点は、ソースの独立性を高めるだけでなく、作成したマッピング・マクロは、他の製品やプロジェクトのプログラムでも共通して利用できることにあります（逆にそれが、自ら苦労して調べることをなくしてしまうことにもなり、その場合はデメリットになるとも言えます）。
同じソースの共有なら、AIF命令で展開を分ける方法も紹介しました。単にマッピング・マクロ名だけを変更するならAIFの方が簡単です。しかし使用するフィールド名も異なるものが多かったりすれば、MVSと同名マクロを作って、そこにフィールド名の違いを吸収するEQU定義を追加すれば、命令ロジックもそのまま直さずに使えます。もちろん名前が違うだけで、フィールドの意味は同じであることが前提です。
代替マッピング・マクロを作る（ソースメンバーを共用する）
今後も、MVS以外のOSを継続してサポートし続けるなら、ソース・プログラムで直接OSのマッピング・マクロを指定せずに、コントロール・ブロックをマッピングするための、ユーザー・マクロを作る方法もあります。
元のソース
IHAASCB , ASCB
IKJTCB , TCB
IKJRB , RB
新しいソース
CMOSCB ASCB ASCB
CMOSCB TCB TCB
CMOSCB RB RB
MACRO
CMOSCB &CB
GBLB &SOSF4,&SOSV3
:
:
AIF ('&CB' EQ 'ASCB').ASCBMAP
AIF ('&CB' EQ 'TCB').TCBMAP
AIF ('&CB' EQ 'RB').RBMAP
:
:
.ASCBMAP ANOP ,
AIF (&SOSF4).MSPASCB
AIF (&SOSV3).VOSASCB
IHAASCB , ASCB
AGO .ASCBEND
.MSPASCB ANOP ,
KAAASCB , ASCB
ASCBJBNI EQU ASCJBNI
ASCBTSB EQU ASCTSB
AGO .ASCBEND
.VOSASCB ANOP ,
JAAASCB , ASCB
.ASCBEND ANOP ,
:
:
この方法もソースの独立性を高めます。マクロ自体を製品に依存しないように作れば、共通化も可能です。自社製品なら自由に作れますが、海外のISV製品の場合などでは、開発元の意向もあるので採用できるかはアピール次第です。MVSとVSEの両方をサポートしているような製品であれば、開発元にもメリットはありますが、MVSしかサポートしていない製品だと返って面倒になるからです。もっとも今はMSPやVOS3バージョンも海外の開発元が直接対応する例も多いようです。