ソースコードの互換性

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のマクロでアセンブルされたオブジェクトで実行できる。
なお同じマクロ名、パラメーターでサポートされていても、生成される機械命令列が異なるものもある。

展開される命令の順序が異なるもの

         LA    0,1(0,0)
         LA    1,ECBAREA
         SVC   1
と
         LA    1,ECBAREA
         LA    0,1(0,0)
         SVC   1

インデックスとベースレジスタが逆になっているもの

         ST    0,0(1,0)
と
         ST    0,0(0,1)

ワード・フィールドの参照方法が違うもの

         SLR   15,15
         ICM   15,7,21(1)
と
         L     15,20(0,1)

レジスターへの値のローディング方法が違うもの

         LA    0,111(0,0)
         LA    1,0(0,10)
         SVC   2
と
         B     *+8
         DC    A(111)
         L     0,*-4
         LA    1,0(10)
         SVC   2

その他にも、FREEPOOLマクロのように中に展開される命令列が大きく異なるものもある。違いの大小はあれど、結果が一緒になるものであれば、移植そのものに関しては気にすることはない。ただしメンテナンスにおいて、ロードモジュールを直接修正するSPZAPユーティリティーを使い、マクロの展開内に修正パッチを作る場合、OS毎に分けて作成することになる。知っておくべき事は、マクロ名とパラメーターが同じだからと言って、中の展開まで同じとは限らない、と言うことである。そしてそのことは、作るときではなく、直すときに対応しなければならない非互換になる。実際にMVS用のSPZAP入力データを、このような（つまらない）理由でMSPやVOS3用に直すことは多々あって、そう言うことをしなくても済むようなポーティング方法を考えるきっかけになった。（普通はOSマクロの展開内を修正する必要はないが、例えばマクロで指定する入力パラメーター領域のアドレスを変更するような場合は、あり得る）

マッピングマクロ

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