1. 導入：なぜGRAPHIC属性が重要なのか
メインフレームで日本語データを扱う際、避けて通れないのが「文字コード」の管理です。特にPL/Iなどの言語で日本語を扱う際、通常の文字型（CHARACTER）とGRAPHIC属性を混同すると、データの切り出しミスや文字化けといった重大なバグにつながります。本記事では、日本語処理の基本であるGRAPHIC属性の仕組みと、安全な扱い方を解説します。
2. 基礎知識：GRAPHIC属性とは？
GRAPHIC属性とは、1文字を2バイトで表現する「DBCS（Double-Byte Character Set）」専用のデータ型です。
一般的なCHARACTER型（英数字）が1バイト単位で管理されるのに対し、GRAPHIC型は「1文字＝2バイト」が固定されています。
ここで注意が必要なのが、メインフレーム特有の「シフトコード（SO/SI）」との違いです。
CHARACTER型で日本語を扱う場合、データの前後をシフトコード（SO: 0x0E, SI: 0x0F）で囲む必要がありますが、GRAPHIC型はデータ自体が純粋な2バイトコードの連続であるため、シフトコードを含みません。この違いを理解することが、データ変換や比較処理を成功させる鍵となります。
3. 実装と解決策
GRAPHIC属性を定義する際、最も注意すべきは「長さの指定」です。
GRAPHIC(n) と宣言した場合、メモリ上では n × 2バイトが確保されます。
例えば、10文字の日本語を格納したい場合は GRAPHIC(10) と記述しますが、実際のメモリ消費量は20バイトとなります。CHARACTER型と混同してバイト数で指定しないよう注意しましょう。
4. サンプルプログラム
以下は、GRAPHIC型を定義し、データを代入してそのバイト数を確認するPL/Iのサンプルコードです。
/ サンプルプログラム：GRAPHIC属性の定義と操作 /
DCL JPN_NAME GRAPHIC(5) INIT(‘あいうえお’); / 5文字分(10バイト)を確保 /
DCL BYTE_LEN FIXED BIN(31);
/ 内部的には2バイト単位で処理されるため、シフトコードは不要 /
/ JPN_NAMEの値を処理する際は、文字単位の長さがそのままバイト単位の計算に直結します /
BYTE_LEN = STG(JPN_NAME); / ストレージ（メモリサイズ）を取得 /
PUT SKIP LIST(‘確保されたメモリサイズは: ‘ || BYTE_LEN || ‘ バイトです’);
/ 注意：GRAPHICデータをCHARACTERデータへ代入する際は、 /
/ 変換関数（GTOCHARなど）を使用して明示的に変換を行うのが安全です /
5. 応用・注意点：現場で陥りやすい罠
現場でよくあるミスは、CHARACTER型（シフトコード付き）とGRAPHIC型（シフトコードなし）を直接比較しようとすることです。これらは内部コード体系が異なるため、必ず変換を行う必要があります。
また、サブストリング（SUBSTR）を使用する際も注意が必要です。
CHARACTER型であれば1バイト単位で切り出せますが、GRAPHIC型では1文字が2バイトで構成されているため、中途半端な位置（奇数バイト目）で切り出そうとするとデータが破壊されます。必ず「文字単位」で位置を指定することを徹底してください。
まずは、自分の扱っているデータが「シフトコード付きのCHARACTER型」なのか「純粋な2バイトのGRAPHIC型」なのか、設計書と定義体を見直すことから始めてみましょう。
コメント