【入門編】DB2埋め込みSQLにおけるホスト変数とPL/Iデータ型のマッピング – PL/Iの基本構文とデータ制御実践ガイド

こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLというモダンで堅実な言語を経験してきた皆さんにとって、PL/Iは少し「癖のある古き良き職人」のように見えるかもしれませんね。

今日は、DB2アプリケーション開発における最大の関門の一つ、「ホスト変数とPL/Iデータ型のマッピング」についてお話しします。特に「なぜVARCHARなのにそんな宣言が必要なの?」という疑問を、現場の知見を交えて紐解いていきましょう。

1. PL/Iの基本構造:まずは「お作法」を知る

PL/Iのプログラムは、必ずと言っていいほど以下の構造で始まります。

1
/ プログラムの入り口です /
SAMPLE_PROG: PACKAGE OPTIONS(MAIN);

SAMPLE_PROC: PROCEDURE;
/ ここにロジックを書いていきます /
END SAMPLE_PROC;

END SAMPLE_PROG;

COBOLで言うところの `PROGRAM-ID` や `PROCEDURE DIVISION` ですね。PL/Iは「パッケージ」という大きな器の中に「プロシージャ」という処理単位を詰め込む構成になっています。ここまでは、他の言語と大きな違いはありません。

2. 核心:DB2とPL/Iの「言葉の壁」を埋める

DB2のテーブルにある `VARCHAR(10)` 型のデータを、PL/Iで受け取りたいとき、COBOLなら `PIC X(10)` だけで済むことが多いですが、PL/Iでは少し工夫が必要です。

ここが初学者が一番戸惑う「奇妙な宣言」の正体です。

VARCHARの正体は「長さ+文字列」のコンビ

DB2の `VARCHAR` は、実はデータ本体の前に「何文字入っているか」という長さ情報を持っています。PL/Iでこれを受け取るためには、構造体(STRUCTURE)を使って、この「長さ」と「データ本体」をセットで宣言しなければなりません。

1
/ DB2のVARCHAR(20)をマッピングする際のお作法 /
DCL 1 HOST_VAR_NAME,
2 LEN FIXED BIN(15), / 文字列の長さを保持する場所 /
2 STR CHAR(20); / 実際の文字列本体 /

  • `FIXED BIN(15)`: これは2バイト(ハーフワード)の整数です。DB2はここに「現在この変数に何文字入っているか」を自動で書き込みます。
  • `CHAR(20)`: 文字列そのものです。

「なぜわざわざ分けるの?」と思うかもしれませんが、これはPL/Iがメモリを非常に厳密に管理する言語だからです。この「長さ+データ」のセットを作っておけば、DB2のプリコンパイラが「あ、これはVARCHAR型だな」と正しく認識して、内部的に変換処理(SQLDAを介したバインド)を適切に行ってくれるのです。

3. 注意すべき「落とし穴」

現場でよくある失敗が、この長さをうっかり更新し忘れるパターンです。

  • 更新時: データをセットしたら、必ず `LEN` に文字数を代入してください。さもないと、DB2は「長さが0だ」と判断して、空っぽのデータを登録してしまいます。
  • CHAR型の扱い: 固定長である `CHAR(n)` の場合は、構造体にする必要はありません。`DCL MY_CHAR CHAR(10);` と書けばOKです。ただし、PL/Iの `CHAR` は代入時に空白で埋められるという性質があるため、比較時には注意が必要です。

4. 実践コード:SQLでデータを取得してみる

では、実際にデータを取得するイメージを見てみましょう。

1
/ 埋め込みSQLのホスト変数宣言 /
DCL 1 V_NAME_STRUCT,
2 V_LEN FIXED BIN(15),
2 V_DATA CHAR(20);

/ DB2から値を取り出す /
EXEC SQL SELECT EMP_NAME INTO :V_NAME_STRUCT
FROM EMPLOYEE WHERE EMP_ID = ‘100’;

/ 取得後の判定 /
IF V_NAME_STRUCT.V_LEN > 0 THEN
PUT SKIP LIST(‘名前は:’ || V_NAME_STRUCT.V_DATA);

どうでしょう。最初は「面倒くさい構造体だな」と感じるかもしれませんが、この「明示的であること」こそが、数十年稼働し続けるメインフレームシステムの堅牢性を支えているんです。

最後に:怖がらなくて大丈夫です

PL/Iのデータ宣言は、最初は呪文のように見えるかもしれません。しかし、一つひとつが「メモリのどこに、どんな形式でデータがあるか」を明確にするための設計図です。

  • `FIXED BIN` は数字の箱
  • `CHAR` は文字の箱
  • `STRUCTURE` はそれらを束ねるフォルダ

このように整理していけば、必ず手足のように使いこなせるようになります。もしコンパイルエラーが出ても、それはPL/Iが「もう少し正確に教えてくれない?」と優しく教えてくれている証拠です。

皆さんのメインフレーム移行、あるいは開発がスムーズに進むよう、これからも現場の知恵を共有していきますね。また次回の記事でお会いしましょう!

タイトルとURLをコピーしました