メインフレームのオープン化～アセンブラ☞COBOL変換編③～
はじめに
メインフレームのオープン化対応において、アセンブラからCOBOLへの変換作業は避けて通れないテーマです。 単に「文法を置き換える」だけで済めばよいのですが、実際の現場ではそう簡単にはいきません。
今回の変換作業で特に強く感じたのは、アセンブラ特有の「レジスタ思考」から、 COBOLの「変数（レコード）思考」へ切り替えることが最大の難所であるという点でした。 この記事では、構造化データ（レコード配列）のアクセス処理を例に、 ASM→COBOL変換で直面した“思考の転換”についてまとめます。アセンブラにおけるデータアクセスの考え方
アセンブラでは、構造化されたデータであっても最終的にはメモリ上の並びとして扱います。 今回の変換対象では、以下のような実装が多く見られました。
構造体（レコード相当）の配列
構造体サイズは256バイト固定
レジスタに配列先頭アドレスを設定
項目アクセスは「レジスタ + オフセット」
次の要素へは「レジスタに256を加算」
概念的な ASM の例を示すと、次のようになります。* ASM（概念例）
LA R1,AREA ; 先頭アドレス
L R2,0(R1) ; 項目A
L R3,4(R1) ; 項目B
LA R1,256 ; 次のレコードへこのように、アセンブラでは常に「このレジスタはいまどこを指しているのか」「次の要素に行くには何バイト足せばよいか」という、 アドレス演算中心の“機械寄りの思考”が求められます。COBOLにおけるデータアクセスの考え方
一方、COBOLではアドレス計算を意識する必要はほとんどありません。 デ
0
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
%20(2).png)
.png)
.jpg)
.png)
.jpg)
.png)
.png)
.png)
.png)
%20(23).png)
%E3%81%AE%E3%82%B3%E3%83%94%E3%83%BC%20(3).png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
