はじめに
メインフレームは長期にわたって基幹システムを支え続けているプラットフォームですが、今後も効果的に活用していくためには様々な観点でのモダナイゼーションを検討していく必要があると考えます。
例えば開発環境をモダナイズしていくことで、IBM Bobなど最近注目のAIエージェントをベースとした開発支援ツールなども活用できるようになると思います。
一方で、新しい技術を取り入れて長年続けてきたやり方を変える、ということには課題も多くあります。
参考:
VS Code - z/OS連携 (7)AIエージェントの活用:概要
メインフレーム開発環境モダナイゼーションにおける課題
メインフレームのモダナイゼーションを検討する上で出てくるこのような課題に対応するため、IBM Bobを活用できる部分が結構あるのではないかと考えています。
例えば、メインフレーム上のソース(EBCDIC)をGitで管理しようと思うと(UTF-8)、文字コードの違いやコード変換を意識する必要があり、バイナリー・データを直接扱っているソースはなんらかの対応が必要になってきます。
そこで今回、メインフレーム上のソースをGit管理に移行する際、対応が必要な情報(制御コードやバイナリーなど)を含むソースが無いか調査しながらEBCDIC→UTF-8変換を行うツールを、IBM Bobで作ってみました。
当記事ではIBM Bobを使ったツール開発の流れを追ってみていきたいと思います。
なお、今回の成果物は以下のGitHubにアップしています。
GitHub - E2UConverter
ちなみに、このツールさえあれば単純にGit移行できますよ、という類のものではないので誤解なきよう...
背景/課題のおさらい
まず、前提としてメインフレーム開発環境のモダナイゼーションをすすめたいという要件があるとします。具体的にはz/OS上で管理されているソースをGit管理に移行し、UIはVS Codeを使って開発するスタイルを基本に考えたい、すなわち、オープン系でのアプリ開発と同じような開発スタイルを取り入れたい、という想定です。
この時、これまでは意識していなかった課題が生じることがありますが、その中でも文字コードに関する課題というのは共通的に発生しうるものだと思います。
参考: メインフレーム開発環境モダナイゼーションにおける課題 - 1. オープン系とメインフレームの差異に関する課題
他の記事でも触れていますが、今回のツールに関連する部分について改めて整理しておきます。
文字コードについての課題
まず、z/OSに閉じた世界でソース管理を行っている場合は、基本的に文字コードはEBCDICという一つの文字コード体系しか使われません。
一方で、GitやVS Codeなどオープンな世界のツールを併用する場合、オープン系の世界ではUTF-8で扱うことが標準ですので、EBCDIC - UTF-8間での文字コード変換が発生することになります。
また、Gitで管理したソースをVS Codeで編集するという際には、UTF-8のファイルを扱うということになります。z/OS上のソースをPCOMのエディタで操作する際には、HEXのコードを直接編集することもできるので、一部バイナリーや制御コードをソース中に含む場合でも取り扱いができていましたが、Git/VS Codeで管理する場合にはそのようなオペレーションは基本的に無理です。
つまり、開発プロセスにおいて以下の点に考慮が必要になります。
- EBCDIC <=> UTF-8 の文字コード変換が発生する
- 制御コードやバイナリー情報など"文字"として認識できない情報がソース中に含まれる場合は扱えない
EBCDIC文字コード
EBCDIC文字コードについて少し補足しておきます。
EBCDICという文字コード体系は、SBCS(Single Byte Character Set): 英数字などのいわゆる半角文字、DBCS(Double Byte Character Set): 日本語などのいわゆる全角文字 を制御コードで区切って管理されるという特徴があります。
これは、SBCSで使われるコードポイントとDBCSで使われるコードポイントに重複があるため、明確にここからここまではDBCSとして解釈しますよ、という区切りをつけてあげないと意図した文字として解釈できないためです。
分かりやすいところだと、EBCDICでは...
半角ブランクは x'40' で表されます。
全角ブランクは x'40 40' で表されます。
DBCSの開始を意味する制御コードは Shift-Out(SO)とよばれ x'0E' で表されます。
SBCSの開始を意味する制御コードは Shift-In(SI)とよばれ x'0F' で表されます。
すなわち、
半角ブランク 全角ブランク 半角ブランク
という並びの文字列をHEXコードで表すと、
x'40 0E 40 40 0F 40'
となります。
※同じx'40'というコードでもSO/SIに括られた位置にある場合は解釈が変わるということです。
z/OS上ではプログラミング言語としてCOBOL, PL/Iがよく使われますが、これらの言語の特性として、"桁数"を意識する必要がある、という点が話をさらにややこしくしています。
例えば、COBOLであれば、
- 1～6桁目はシーケンス番号
- 7桁目は特殊な指示文字(コメント行やデバッグコードなど)
- 8～11桁目がA領域 (DIVISION, SECTIONなど)
- 12～72桁目がB領域 (命令文など)
- 73桁目以降が管理情報
といったように、どの範囲に何を書かなければいけないか、ということが厳密に決まっています。
文字数としては1文字であっても、半角文字と全角文字では内部的に使われるコードは1バイト, 2バイトでそれがソースコード中の桁数に影響しますし、区切り文字やその他の制御コードなども、そのバイト数分だけ桁数に影響します。
例えば、DBCSの前後にあるSO/SIコードはPCOMのテキストエディター上では半角ブランクのように表示されます。その他文字として表示できないバイナリーのコードが含まれている場合、エディター上は"."(どっと)のように表示される場合があります。
つまり、z/OSのソースコードをPCOMで開発する際は、SBCS、DBCS、制御コードなど、内部的にそれらが何バイト使われているかをある程度意識しながらコーディングする、というのはある意味暗黙の了解となっています。
ところがオープン系の世界では、テキストエディターでソースを編集しているときに桁数とかその文字が何バイト使われるか、というようなことは普通意識しません。制御コードやバイナリを埋め込むという発想も基本的には無いわけです。
そのため、Git/VS Codeなどオープン系ベースの仕組みに乗っかっていくには、その辺の文化に合わせていく必要がある、ということになります。
SBCS補足
英小文字系 / 半角カタカナ系に大別されます。使用するコードページによって、英小文字、半角カタカナ、一部の記号のコードポイントが入れ替わっています。
いずれにしても、基本的に文字としてコードがマッピングされる範囲は、0x'40'以降ということになります。
(上の表のとおり、その範囲の中でも文字が割り当てられていないコードポイントが多数あります。)
DBCS補足
DBCS部分は大量の文字を扱うことになりますしCCSIDによって対応するCharacter Setの範囲も変わってきますが、使用されるコードポイントの範囲はルールとして決まっています。
以下IBM iの資料ですがこちらが分かりやすいと思います。
参考: DBCS code scheme
上の通り、DBCSのコードポイントとして割り当てられる値は、1st byte, 2nd byteともに、x'40'～x'FE'の範囲ということになります。
改行コード補足
改行コードとして認識されるコードは以下の通りです。
| EBCDIC HEX値 | UTF-8 HEX値 | 意味 |
|---|---|---|
| x'0D' | x'0D' | Carriage Return |
| x'15' | x'C285' | New Line |
| x'25' | x'0A' | Line Feed |
PDSメンバーは一般的に80バイト固定長レコード(RECFM=FB,LRECL=80)として管理されます。z/OS上でPCOMのエディターやISPF Editでソースを扱う際は、行の区切りは改行コードではなくレコード境界によって管理されるため、レコード内に EBCDIC の制御文字(X'0D'、X'15'、X'25' など)が存在してもエディター上で改行として解釈されることはありません。
このようなデータをUTF-8へ変換する際に、レコード境界を保持せず X'15' (NL) などの制御文字を改行文字として扱ってしまうと、本来のレコード構造が失われ、1行の認識が変化する可能性があります。
IBM Bobによるツール開発
さて、ここからようやく本題ですが、IBM Bobを使用して文字コード変換に関するツールを作成してみたいと思います。要件定義、設計、実装、テストの流れを、IBM Bobの支援を受けながら進めていきます。
0.事前準備
関連S/W
まず、事前に環境の整備をしておきます。今回のツールの実装としては、EBCDIC/UTF-8間の文字コード変換をPC上のJavaで行うことを想定しています。そのため、EBCDICコンバーターを含むJDKとしてIBM Semeru Runtime、Javaのビルド管理ツールとしてMavenを使用することを想定します。
今回使用する環境としてはこちらです。
- Windows11
- IBM Bob 2.0
- IBM Semeru 21.0.10
- Apache Maven 3.9.16
こちらは使えるようにセットアップ済の前提です。
参考:
IBM Bob
IBM Semeru Runtimes Downloads
Downloading Apache Maven and Maven Daemon
IBM Bobワークスペース
IBM Bobのワークスペースとして使用するフォルダを作成しておきます。このフォルダ配下は最終的にはGitのリポジトリとして管理する想定です。
また、Bobのワークスペース全体に有効な共通ルールをAGENTS.mdファイルに定義しておきます。
参考: AGENTS.mdファイルの使用
# 概要
- 当プロジェクトは、EBCDICで記述されているz/OS上のソースコードをUTF-8に変換するプログラムを作成するためのものです。
- 成果物はJavaで実装し、PC上で稼働させる想定です。
- 要件定義、設計、実装、テストに必要な一連の成果物を生成、管理します。
- ドキュメントは基本的にMarkdown形式、図はMermaid表記で生成してください。
- 各フェーズの成果物は以下のフォルダに管理します。
- 要件定義: 01_requirements
- 設計: 02_design
- 実装: 03_implementation
- テスト: 04_test
- READMEはテストが完了して成果物が出そろったあとに、最後に作成します。
これに合わせてフォルダも作成しておきます。構造としてはこんな感じ
E2UConverter\
├─00_prompt\
├─01_requirements\
├─02_design\
├─03_implementation\
├─04_test\
└─AGENTS.md
1.要件定義
以下のようなプロンプトを準備して投入します。
プロンプト
# 要件定義
以下のような要件をベースとしたプログラムを作成したい。
設計、実装、テストを進めるにあたり必要な要件を明確化したい。
不足している情報があれば指摘してください。
最終的に01_requirementsフォルダ以下に要件定義書を作成してください。
# 要件概要
EBCDICで記述されているz/OS上のソースコードをUTF-8に変換するプログラムを作成したい。
このツールは、現在z/OS上で管理されているソース(EBCDICベース)を、Git管理(UTF-8)に移行する際に利用することを目的とする。
ソースコードは複数あり、EBCDICコードのままPC上に保持されている前提とする(PDSメンバーをバイナリーモードでPC上に転送済みの想定)。
作成する変換プログラムはJavaで実装し、PC上で稼働させることを想定している。
単純な変換機能だけでなく、制御コードなど文字として認識できない文字コード、正しく変換できない文字コードが含まれている場合は、それを検知し、レポートする機能も提供する。
変換およびレポート生成は複数のファイルをまとめて処理できるようにする。
文字コード変換後のファイル出力先のディレクトリはオプション指定できるようにし、出力先のファイル名やフォルダ構造は変換元のファイル名、フォルダ構造と同一とする。
レポートはMarkdown形式とし、出力先のファイル名(パスを含む)はオプションで指定可能とする。
# 提供機能詳細
## アプリケーション実行形態
アプリケーションはjavaコマンドでCLIで実行できるようにする。
ビルドツールにはMavenを使用し、実行可能JARとしてビルドする。
プロジェクトのトップのディレクトリから実行しやすいように、バッチファイルを用意する。
## 入力ファイル(変換元EBCDICファイル)関連
変換元のEBCDICコードページは日本語を含むものを想定し、オプションで明示指定できるようにする。
オプションで指定するコードページは、Javaコンバーター名をそのまま使用する(IBM-930, IBM-939, IBM-1390, IBM-1399など)。
入力ファイルは、固定長レコード(デフォルトLRECL:80バイト)として扱う場合と、単なるバイトストリームとして扱う場合(改行コードとして x'0D' or x'15' or x'25'を含む場合)とを、オプションで切り替え可能とする。
変換対象の入力ファイルは、単一ファイル、またはディレクトリのどちらも指定可能とする。
入力ファイルとしてディレクトリを指定した場合、再帰処理オプションで、サブディレクトリ下のファイルも処理するか指定できるようにする。
## 不正文字検知について
EBCDICでの x'0D', x'15', x'25' は改行コードと判断する。
EBCDICでの x'0E'はShift-Out(SO)、x'0F'はShift-In(SI) のコードと判断する。
指定したコンバーターで文字として変換できなかったコードは不正検知の対象とする。
### 入力ファイルが固定長レコードの場合
x'00' ～ x'0D' および x'10' ～ x'3F' および x'FF' は制御文字、もしくは文字として認識できないコードとして不正検知の対象とする。
x'0E' と x'0F' は1レコードにDBCSコードの前後に1つずつ現れる必要がある。1レコードにx'0E' と x'0F'のペアが正しく順序性を保って現れていない場合、それらは不正検知の対象とする。
x'0E' と x'0F'のペアがレコードをまたがる場合不正検知の対象とする。
1レコード内にx'0E' x'0F' が連続して現れる場合 (中身のDBCSコードが無くx'0E'の直後にx'0F'が現れる場合)、不正検知の対象とする。
### 入力ファイルが単なるバイトストリームの場合(改行コードを含む)
x'00' ～ x'0C' および x'10' ～ x'14' および x'16' ～ x'24' および x'26'～ x'3F' および x'FF' は制御文字、もしくは文字として認識できないコードとして不正検知の対象とする。
x'0E' と x'0F' は1行にDBCSコードの前後に1つずつ現れる必要がある。1行にx'0E' と x'0F'のペアが正しく順序性を保って現れていない場合、それらは不正検知の対象とする。
x'0E' と x'0F'のペアが行をまたがる場合不正検知の対象とする。
1行内にx'0E' x'0F' が連続して現れる場合 (中身のDBCSコードが無くx'0E'の直後にx'0F'が現れる場合)、不正検知の対象とする。
## 出力ファイル1(変換後UTF-8ファイル)関連
出力先フォルダをオプションで指定できるようにする。
出力ファイルの階層構造は変換元ファイルと同等とする。
拡張子はデフォルトでtxtとし、オプションで明示指定できるようにする。
変換不能文字があっても変換ファイルを出力する（問題箇所は代替文字「?」に置換）
同じファイル名が存在する場合は上書きする。
## 出力ファイル2(変換処理結果のレポート)
出力ファイル名(相対パス または 絶対パス)をオプションで指定できるようにする。
Markdownのレポートには、サマリー情報に加え、以下の不正文字検知の情報を含めるようにする。
- ファイル名
- 行番号
- 行頭からの位置(オフセット)
- 文字コード値(返還前、および、変換後のHEXコード値)
- 変換後の文字
1ファイル/1レコードに複数の不正文字を検知した場合でも、それぞれ全てレポートに出力する。
EBCDICのSBCSのコード x'00' ～ x'FF' 全てにおいて、各コードが指定したコンバーターによってUTF-8の何のコード(HEX値)に置き換わるか、また、再度EBCDICに変換した場合の結果を一覧表にしてレポートに出力する。
- EBCDICのHEXコード値
- コンバーターにより変換されたUTF-8のHEXコード値
- UTF-8変換後の文字(文字として認識できる場合)
- 再度EBCDICに変換した時のHEXコード値
※実はこれは一度Bobに投げてブラッシュアップしたものです。最初はもっとラフな要件記述でした。
簡単に実装したいツールのポイントをあげておくと...
- バイナリでPC上に転送したEBCDICのソースをまとめてUTF-8にコード変換する
- PC上のJavaで稼働させる想定
- コード変換時に制御コードなど文字として扱えないものを含む場合はレポートで報告
- 全SBCSコードについて、EBCDIC → UTF-8 → EBCDIC 変換結果も付録としてレポートに付与
ここからさらにBobに要件定義として明確化してもらいます。
「不足している情報があれば指摘してください。最終的に01_requirementsフォルダ以下に要件定義書を作成してください。」という指示をしているので、不足している情報についてはBobが聞いてくれます。
例えば以下のような追加のやり取りをしています。
Bobとのやりとり
Agent asked: 要件の明確化のために以下の点を確認させてください。
【質問1】固定長レコードモードの不正文字検知範囲について
要件では「x'0E'(SO) と x'0F'(SI)」を除いた制御文字を検知対象としていますが、x'0E' と x'0F' は正常なDBCSシフトコードとして使われる場合に検知から外れます。ただし、改行コード x'0D', x'15', x'25' については固定長レコードモードでも不正扱いするか、それとも許容しますか？
User replied: 固定長レコードモードでは x'0D', x'15', x'25' は制御文字として不正検知の対象とする（レコードが固定長なので改行コードは不要）
Agent asked: 【質問2】出力ファイルの拡張子について
入力ファイルに元々拡張子がある場合（例: COBOL.cbl, PROGRAM.jcl など）の出力ファイルの拡張子はどうしますか？
User replied: 元の拡張子はそのまま保持し、オプション指定がある場合のみ置き換える（例: PROGRAM.cbl → PROGRAM.cbl のまま）
Agent asked: 【質問3】入力ファイルに拡張子が無い場合（z/OS PDSメンバーはデフォルト拡張子なし）の出力ファイルの拡張子はどうしますか？
User replied: 拡張子がない場合は、デフォルトで .txt を付与する（オプションで変更可能）
Agent asked: 【質問4】レポートのサマリー情報について
Markdownレポートのサマリーセクションには具体的にどの情報を含めたいですか？（複数選択可）
User replied: 処理日時、処理対象ディレクトリ/ファイル、使用コードページ、入力モード（固定長/ストリーム）などの実行パラメータ, 処理ファイル総数、成功ファイル数、不正文字検知ファイル数、不正文字検知総件数などの統計情報, 処理したファイルの一覧（ファイル名、検知件数）, エラー（処理できなかったファイルとその理由）の一覧
Agent asked: 【質問5】バッチファイルについて
プロジェクトトップから実行するバッチファイルはどのOS向けを想定しますか？
User replied: Windows向けのみ（.batファイル）
Agent asked: 【質問6】DBCSコードの変換について
EBCDICのDBCS（2バイト文字）コード変換において、SO(x'0E')とSI(x'0F')自体はUTF-8出力ファイルに含めますか？それとも除去しますか？
SO/SIを含めたDBCSコードをそのままUTF-8に変換すれば、UTF-8での文字コードに変換されるはずなので(UTF-8ではSO/SIに相当するコードは無いので結果として除去される)、それをそのまま出力すればよいです。
"了解です。JavaのEBCDIC→UTF-8コンバーター（IBM-930等）はSO/SIを含めてDBCS文字を正しくUnicode文字に変換するので、変換結果をそのまま出力すればSO/SIは自然に除去されます。
残りの確認事項をまとめて聞きます。"
Agent asked: 【質問7】レポートの不正文字検知セクションのレイアウトについて
不正文字を検知した場合の詳細情報（ファイル名、行番号、オフセット、HEXコード値、変換後文字）はどのような形式で出力したいですか？
User replied: 全ファイルをまとめた1つの大きな表形式（ファイル名・行番号・オフセット・HEXコード・変換後文字）で出力する
Agent asked: 【質問8】レポートのSBCSコード変換対応表について
EBCDICのSBCSコード x'00'～x'FF' の変換対応表は、レポートの最後に固定の付録として出力する想定でよいですか？また、この表はSBCSコードのみ（256エントリ）でDBCSコードは含まない認識で正しいですか？
User replied: はい、SBCSコードのみ256エントリの対応表をレポート末尾に付録として出力する
Agent asked: 【質問9】レポートが未指定の場合の動作について
レポートの出力先ファイルがオプション未指定の場合、どうしますか？
User replied: デフォルトのファイル名（例: report.md）で出力先ディレクトリ（-oオプションと同じ場所）に出力する
Agent asked: 【質問10】出力先ディレクトリが未指定の場合の動作について
変換後ファイルの出力先ディレクトリ（-oオプション相当）が未指定の場合、どこに出力しますか？
User replied: 出力先未指定の場合はエラーとして処理を中止する（必須オプションとする）
詳細は省略していますが、多くは選択肢が提示されてそこから選択して回答するイメージです。
このようなやりとりをして、要件定義書が生成されました。
成果物: 要件定義書 — EBCDIC → UTF-8 変換ツール (E2UConverter)
※上のドキュメントは、後続の操作を行った結果の最終形なので、この時点で生成されたものからアップデートが入っています。大枠は変わらないですが。
2.設計
要件定義書がある程度固まったので、これを基に設計書を作らせてみます。
プロンプト:
01_requirements\requirements.md ファイルに記載されている要件を満たすプログラムを作成したいです。
実装、テストを進めるにあたり必要な設計書を作成してください。
不足している情報があれば指摘してください。
成果物は02_designフォルダ以下に作成してください。
ここは要件定義書に従ってひたすら設計書を作ってくれます。
こんな感じの設計書が出来上がりました。
成果物: 設計書
※上のドキュメントは、後続の操作を行った結果の最終形なので、この時点で生成されたものからアップデートが入っています。大枠は変わらないですが。
3.実装
上の設計書からツール本体を実装させます。
プロンプト:
01_requirements\フォルダ以下の要件を満たすプログラムを、02_design\ フォルダ以下に記述されている設計書に従って実装してください。
成果物は、03_implementation\フォルダ以下に作成してください。
コンバーター IBM-1390, IBM-1399 を使用できるように、以下を参考にビルド時にはpom.xmlにicu4j関連のライブラリを追加してください。
https://mvnrepository.com/artifact/com.ibm.icu/icu4j
https://mvnrepository.com/artifact/com.ibm.icu/icu4j-charset
```
<dependency>
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
<version>78.3</version>
</dependency>
<dependency>
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j-charset</artifactId>
<version>78.3</version>
</dependency>
```
ここで、IBM-1390/IBM-1399のコンバーター用に、依存関係の情報を付与しています。
というのも、IBM Semeru Runtime V11以降ではこれらのコンバーターが削除されてしまうという謎の仕様変更が入っているからです。
Unicode Consorsium が管理しているICU(International Components of Unicode)というプロジェクトがあり、多言語対応のためのライブラリ群を公開してくれています。そこで提供されている日本語用のライブラリを取り込むことで、IBM-1390/IBM-1399のコンバーターが利用できるようになります。
参考: GitHub - The home of the ICU project source code
※後から思いましたが、こういう情報は設計書のどこかに記載すべきだったのかも...
これで、設計書に従って実装が行われます。
プロジェクトのトップにバッチファイルを作成するような指示にしていたはずなのですが、場所が違ったので修正するよう指示を出します。
プロンプト:
e2u.batはプロジェクトのトップのフォルダに配置し、そのフォルダで実行できるように修正してください。
成果物: Javaのソースコード等
※上のドキュメントは、後続の操作を行った結果の最終形なので、この時点で生成されたものからアップデートが入っています。大枠は変わらないですが。
このステップで、ビルド、および、簡易的なテスト実行まで実施してくれました。
4.テスト
上で簡易的に実行できることは自律的に実施してくれましたが、もう少しきちんとしたテストも実施したいと思います。
とはいえ、単なる補助ツールのサンプル的な位置づけなので、ここではがっつりきっちりテストするつもりはありません。ブラックボックステストを流すにとどめたいと思います。
4-1. テスト計画作成
まず、テスト計画を立てさせます。
プロンプト:
# テスト計画作成
01_requirements\フォルダ以下の要件を満たすプログラムを、02_design\ フォルダ以下に記述されている設計書に従って、03_implementation\フォルダ以下に実装しています。
このプログラムのテスト計画を立ててください。
不足している情報があれば指摘してください。
最終的に04_testフォルダ以下にテスト計画書を作成してください。
## 基本方針
- ブラックボックステストを実施する
- 固定長レコードモードとバイトストリームモードでテストケースを分けて作成する
- 固定長レコードモードはLRECL=80バイトをベースにテストケースを作成する
- DBCSとSBCSを含むソースをベースとする
- できるだけ網羅的にテストパターンを作成する
追加で以下のような情報をインプットしています。
Agent asked: テスト実行方法について確認させてください。テスト計画書では「テスト手順」をどのレベルで記述すべきでしょうか？
User replied: 両方記述する（テストケース仕様 + 代表的なテストの実行コマンド例）
Agent asked: テスト用EBCDICバイナリファイルは、どのように用意する想定でしょうか？
User replied: テスト計画書と合わせて、テストデータ生成用のスクリプト（例：Pythonやバッチ）も04_testフォルダに作成する
Agent asked: このテスト計画プランで問題ありませんか？
User replied: 追加・修正の要望がある（具体的にコメントします）
IBM-1399もテストケースに追加してほしい
Agent asked: このプランで確定してよいですか？確認後、agentモードに切り替えてテスト計画書とテストデータ生成スクリプトを作成します。
User replied: 問題ない。agentモードに切り替えて実装を開始してください
これでテスト計画書が作成されることになりますが、テスト計画を立てるためのプランを作成し、そこから実際のテスト計画書を作る、という流れになってしまいました。少し冗長な感じもしますが、指示の仕方がよくなかったのかも？
成果物:
※上のドキュメントは、後続の操作を行った結果の最終形なので、この時点で生成されたものからアップデートが入っています。大枠は変わらないですが。
4-2. テスト実施
テスト計画ができたので、これを基にテスト実行させます。
プロンプト:
01_requirements\フォルダ以下の要件を満たすプログラムを、02_design\ フォルダ以下に記述されている設計書に従って、03_implementation\フォルダ以下に実装しています。
このプログラムをテスト計画 04_test\test_plan.md に従ってテストしてください。
結果、テストケースが実行され、テストレポートが生成されました。
途中、意図した結果と違う結果を返すテストケース(つまりバグ)がありましたが、それに対して修正、再テスト、というのを自律的に実施し、最終的に全テストケースがOKとなりました。
すばらしい！
成果物:
※上のドキュメントは、後続の操作を行った結果の最終形なので、この時点で生成されたものからアップデートが入っています。大枠は変わらないですが。
5.改修
色々動きを見ていると、指定したコードページでの変換がうまくいかなかった場合、具体的にはx'40'～x'FE'の範囲でも文字が割り当てられていないコードポイントがいくつかあるので、そのコードが含まれている場合は不正検知の対象として欲しかったのですが、そこがレポートされない仕様になっていました。要件定義が甘かったですが、まぁ、アジャイルにいきましょう。
SBCS文字については、文字にマッピングされていないコードがあったら不正検知の対象としてレポートされるよう仕様変更します。
(DBCS部分はややこしくなりそうなのでここでは対象外とします。)
以下の仕様変更の指示を出します。
プロンプト:
コードページ上で未定義の文字があった場合も、不正文字検知の対象としてレポートするよう、仕様、実装を変更してください。
変更されましたが、SO～SIの範囲もチェック対象にしてしまっていたので、DBCS文字の一部のコードポイントもチェックして不正と報告してしまっていました。これはちょっと予想した上で敢えてゆるい指示を出してみたのですが、案の定、安易な修正をしてくれてました。Bobくん、まだまだですね。
個別にテストケース作った結果を示して、追加修正指示を出します。
プロンプト:
report.mdにTSUB02の結果がレポートされています。TSUB02の20行目に報告されている0xCA, 0x6A は、DBCS文字の一部のコードであり、正しく変換できています。不正文字検知の対象からは外すべきです。修正を検討してください。
これで一通り期待する動作をするツールができたっぽいです。
その他細かい修正は個別に実施しています。
最後に、仕様変更に合わせて、要件定義、設計書、README等も修正させておきます。
ツール実行イメージ
当ツールの利用イメージとしては以下のような感じでコマンド実行するイメージです。
.\e2u.bat -i .\91_testdata\ -o .\92_testoutput\ -e txt -c IBM-1399
バイナリーでPC上にFTP転送したファイルが保持されているフォルダと、出力先フォルダを指定してツールを実行すると一括でコード変換&レポート作成してくれます。
レポートのサンプルはこちら: report.md
まとめ
メインフレームのアプリケーション開発そのものにBobを活用する、というのは最終的に目指したい方向性だと思いますが、そこに行きつく前に、もっと色々とやっておくことがある気がしています。今回のツールのように補助ツールみたいなものを作ってあげればハードルを越えやすいことも多いように思います。まずは、そういうところに生成AIを活用していくとよいのではないでしょうか。
ちなみに...
実はDBB(Dependency Based Build)という製品でも類似の機能が提供されていますが、残念ながらバイナリを扱っているかどうかという幅広いチェックはできなさそうなので、今回のようなツールを作ってみています。
参考: Migrating source files from z/OS to Git
最後に、今回IBM Bobを使用して実施した上の一連の処理で消費したBob Coin等の情報を参考までに挙げておきます。
| 作業 | Mode | コンテキスト長 | APIコスト(Bob Coin) |
|---|---|---|---|
| 0 AGENTS.md 作成 | Plan | 19.5k / 270.0k (7%) | 0.316 |
| 1 要件定義 | Plan | 27.1k / 270.0k (10%) | 0.711 |
| 2 設計 | Agent | 39.9k / 270.0k (15%) | 1.05 |
| 3 実装 | Agent | 69.6k / 270.0k (26%) | 4.95 |
| 4-1 テスト計画 | Plan | 121.8k / 270.0k (45%) | 10.3 |
| 4-2 テスト実施 | Agent | 167.7k / 270.0k (62%) | 16.6 |
| 5 改修 | Agent | 122.7k / 270.0k (45%) | 13.7 |
※実際にはこれ以外にも細かい修正をさせたりしてますが、まぁ誤差の範囲だと思います。