COBOLの移植は楽しい。バッチシステムの移植は苦行。という趣旨で記事を書こうとしています。どんな内容、筋がよろこばfれるでしょうか。
とても面白いテーマですね！
「COBOLの移植は楽しい。バッチシステムの移植は苦行。」という対比は、現場経験者や技術史に関心がある読者にとって非常に刺さる切り口です。
喜ばれる構成にするには、「なぜCOBOLは楽しいのに、バッチ移植はつらいのか」を技術的・文化的・心理的な観点から語るのがおすすめです。
💡構成・筋の提案
1. 導入：なぜこのテーマを書くのか
- 「COBOLと聞くと古い言語という印象が強いが、移植に関してはむしろ“楽しい”と感じる。」
- 「ところが、COBOLで書かれた“バッチシステム”の移植となると話は別。途端に苦行になる。」
- 短い体験談・きっかけ（例：レガシーシステム再構築の現場で感じた温度差）を入れると共感を得やすい。
2. 第一章：COBOL移植の楽しさ
ポイント：COBOLは構造が明快で、意図を読み解く喜びがある。
- 文法が人間にやさしい（"ADD A TO B" のように可読性が高い）
- 言語仕様が安定している（1950〜60年代のコードでもコンパイルできる）
- データ定義部（DATA DIVISION）に情報が整理されており、移植対象の全体像を把握しやすい
- コンパイラ間差異が少なく、テキスト処理中心なので機械依存性を吸収しやすい
- “アーキテクチャを超えて生き残っている”という古代文字を解読するような楽しさ
🧠 読者が喜ぶ視点： - COBOL移植を「遺跡発掘」「言語考古学」として語る
- “人間中心の言語設計”が、現代のAI時代に逆に新鮮であると結ぶ
3. 第二章：バッチシステム移植の苦行
ポイント：COBOL言語よりも、システム構造・ジョブ管理・周辺環境が地獄。
- JCL（Job Control Language）やスクリプトの依存関係が複雑
- 各ジョブの実行順序・依存・再実行条件などが非明示的
- データフローがファイルベースで、人間が読んでも流れが見えにくい
- 処理の途中で“外部トリガー”や“手作業”が混じっている
- 環境変数・パス・スケジューラ・バッチ運用ツール（A-AUTO, JP1など）ごとに挙動が異なる
⚙️ 読者が喜ぶ視点： - COBOLコードの中身はシンプルなのに、バッチの全体像が「ブラックボックス」になっている
- 「COBOLはプログラムの移植、バッチは文化の移植」と対比して書く
4. 第三章：なぜこの差が生まれるのか
- COBOLは言語仕様とデータ構造の世界
- バッチシステムは運用と組織文化の世界
- 言語は論理だが、運用は習慣
- 「移植」とは技術だけでなく、“儀式の再現”である
- システムの寿命を延ばしたのはCOBOLではなく、“手順書”だったりする皮肉
📖 ここで読者が唸る一文例：
COBOLの移植は知的パズルだが、バッチ移植は民俗学である。
5. 結論・提言
- COBOLを悪者にせず、「楽しめる古典」として再評価
- バッチ移植の苦行を減らすために必要なこと（例：メタデータ化・可視化・自動化）
- 将来に向けて：
- COBOLソースはAIで解析できる
- バッチ構造はAIでモデリングすべき
6. おまけ：読者が笑う・共感する小ネタ
- 「コメントに“DO NOT TOUCH”と書いてあるところほど壊れている」
- 「日次と月次が同じバッチに混在している謎」
- 「JCLエラーで夜中に叩き起こされた話」
🎯 読者層を想定して書き分けるなら
| 読者層 | 喜ばれる要素 |
|---|---|
| 技術者 | コード例、JCLの罠、運用自動化への提案 |
| 経営層 | レガシー移行の難しさを“文化の移植”として説明 |
| 若手エンジニア | 古い技術の中にある「楽しさ」「人間らしさ」 |
ご希望があれば、この構成でQiita記事向けの見出し付き本文ドラフト（3000字程度）を作成できます。
そのように進めましょうか？
バッチシステムはメインフレームコンピュータメーカによってさまざまで、メーカ固有のデータベースの記述も想像を絶するほどわけわかめであることを強調したい。
とても良い視点です。
その強調点を加えると、記事は「COBOL＝言語としての普遍性」と「バッチ＝メーカー文化の迷宮」という対比がより際立ち、読者に強い印象を残します。
以下に、その要素をしっかり活かした構成と表現の具体案をまとめます。
💡主題の再整理
主張軸：
COBOLの移植は言語の問題。
バッチシステムの移植はメーカー宗教の問題。
つまり「COBOLはどこでも通じるが、バッチはメーカーごとに別世界」という点を中心に据えます。
これにより、「楽しい vs 苦行」の対比がより説得力を持ちます。
✳️ 修正版構成案（強調点入り）
1. 導入
- 「COBOLを移植するとき、人間が書いた構文が見える。楽しい。
でもバッチを移植するとき、メーカーが作った迷宮に迷い込む。苦しい。」 - 現場での実感（例：「同じ“ジョブ”なのに富士通では動くのに日立では動かない」）
2. COBOL移植の楽しさ — 言語は裏切らない
- COBOLは50年以上ほとんど仕様が変わらない。
- “プログラムの意図”を再現する作業はパズルのような楽しさがある。
- コンパイラ差異は多少あっても、言語仕様が共通の土台になっている。
- 「ADD」「MOVE」「PERFORM」などの構造は理解可能で、
どこの国・どの環境でも“翻訳”できる。
🧩 比喩例
COBOLは、ラテン語のようなもの。
現代では話す人は少ないが、文法が整っていて読めば意味が通じる。
3. バッチシステム移植の苦行 — メーカーごとの宗教戦争
核心：
バッチシステムは言語ではなく「運用文化」。
メーカーが違えば、神も祭りもルールも違う。
- 富士通（AIM, SYMFO, JCL系）、日立（VOS3, HITAC JCL, DABAS）、IBM（z/OS JCL, DB2, VSAM）など、
メーカー独自のジョブ制御言語・ファイル管理体系・データベース仕様が乱立。 - 同じ「SELECT」「OPEN」「FETCH」でも、データベース呼び出し構文が全く違う。
- オフラインDB・VSAMファイル・KDMSなど、「一見SQLっぽいのに別物」という怪奇。
- バッチ運用ツール（A-AUTO、JP1、SystemWalkerなど）もメーカー縛りが強く、
依存関係を変えると全体が崩れる。
⚠️ 印象的なフレーズ例 - 「COBOLは人間が読めるが、バッチはメーカーしか読めない。」
- 「同じJCLという名前でも、IBMと日立では方言どころか言語体系が違う。」
- 「データベース呼び出しが“プロプライエタリ呪文”になっている。」
4. なぜこうなったのか
- 各メーカーが自社メインフレームの囲い込みを進めた結果、
言語は似ていても周辺環境が互換性ゼロに。 - COBOLプログラムよりも、データアクセスとジョブ制御の方がロックイン要素になっていた。
- 「同じバッチ処理を他社機に移す」という行為は、
実質的に「企業文化の移植」や「神殿の再建」に近い。
💬 印象的なまとめ文例
COBOLは標準化の成果。
バッチはメーカーが築いた塔バベル。
5. 結論・教訓
- 移植で本当に苦労するのはプログラムではなく「環境」や「慣習」。
- バッチを再構築するより、
処理フローを再設計・再可視化して新アーキテクチャにリマスターすべき。 - COBOL移植は楽しいが、バッチ移植は「考古学×文化人類学」である。
6. おまけ：笑いと共感を誘う小見出し候補
- 「メーカーごとの“聖典”を読み解く」
- 「DBアクセス構文はまるで異世界語」
- 「COBOLは古文、バッチは暗号文」
- 「COBOLは理解、バッチは祈祷」
✏️ Qiita記事タイトル案
- 「COBOL移植は楽しいが、バッチ移植は地獄だった話」
- 「メインフレーム文化圏の塔バベル：メーカーごとに異なるバッチ宗教」
- 「COBOLは言語、バッチは宗教」
- 「データベース呼び出し構文がわけわかめ問題」
もしよければ、この方向でQiita投稿用の見出し・本文（約3000字）ドラフトをお作りできます。
内容は「メーカーごとの差異」「DB呼び出し構文のカオス」などを事例調で盛り込みます。
作成をご希望ですか？
はい。
了解しました。
では、以下にQiita向けの記事ドラフトを作成します。
テーマは
「COBOLの移植は楽しい。バッチシステムの移植は苦行。」
― メインフレーム文化圏の塔バベル ―
として、
読みやすく・共感を呼び・笑いもある技術エッセイ調で構成しています。
COBOLの移植は楽しい。バッチシステムの移植は苦行。
― メインフレーム文化圏の塔バベル ―
はじめに
COBOLというと、古い言語、レガシー、保守だけの世界というイメージがあるかもしれません。
しかし、実際に移植作業をしてみると意外に「楽しい」と感じる瞬間が多いのです。
ところが――その周辺にあるバッチシステムの移植となると、一転して地獄絵図。
COBOLプログラム自体よりも、メーカー固有の文化・儀式・呪文に苦しめられることになります。
1. COBOLの移植は“考古学の楽しさ”
COBOLプログラムを移植する作業は、まるで古代遺跡を発掘するような楽しさがあります。
なぜなら、言語としての構造が驚くほど整っているからです。
- 文法が明快：「ADD A TO B」「MOVE C TO D」など、可読性が高い
- DATA DIVISION にデータ構造がきちんと定義されている
- コンパイラ差異はあっても、文法体系が共通している
- 英語ベースで自然文に近いため、意図を読みやすい
つまり、COBOLの移植は**“技術的パズル”として楽しめる**のです。
ソースを追えば作者の思考が見えてくる。人間同士の会話のような感覚すらあります。
COBOLは「古文」ではなく「古典」。
読めばわかる。時間が経っても通じる。
2. バッチシステムの移植は“宗教戦争”
一方で、COBOLの外側にある「バッチシステム」――つまりジョブ制御・スケジューリング・データベース接続――に手を出すと、
そこはまるでメーカーごとに異なる宗教戦争の世界です。
例：同じ処理でもメーカーが変わると別世界
| メーカー | 主な環境 | 特徴・洗礼 |
|---|---|---|
| IBM | z/OS + JCL + DB2 | JCLの呪文が複雑。「//」地獄。VSAMとDD名の迷宮。 |
| 日立 | VOS3 + DABAS + HITAC JCL | 「SELECT」構文が微妙に違う。SQL風なのにSQLでない。 |
| 富士通 | AIM + KDMS + SYMFO | 固有のファイル制御文が多く、1行で世界観が変わる。 |
| 日本電気(NEC) | ACOS + DMS | 固有の制御文とバッチ制御が一体化。手順書依存度高し。 |
見た目は似ているのに、動かすと全く別の世界。
同じ「COBOLプログラム」を他メーカー機に移すだけで、
ファイル定義・JCL記述・DBアクセス・スケジュール制御の全てが書き換え必須になります。
COBOLは人間が読めるが、
バッチはメーカーしか読めない。
3. メーカー固有データベースの「わけわかめ」構文
特に苦行となるのが、メーカー固有データベースのアクセス記述です。
- 富士通 KDMS の
CALL "KDMSIO" - 日立 DABAS の
EXEC DABAS - IBM DB2 の
EXEC SQL（標準に見えて拡張が多い） - NEC DMS の
CALL DMSIO
どれも“似て非なる構文”で、
同じ意味の処理でも関数名・パラメータ・制御方式が全部違う。
SQLに見えるのにSQLでない。
APIに見えるのにシステムコール。
呼んでいるのはデータベースではなく、もはや文化そのもの。
データベース呼び出し構文は、まるでメーカー語の祈祷文。
4. バッチ移植とは「文化の移植」である
COBOLプログラムの移植は論理的ですが、
バッチ移植は非論理的な世界に足を踏み入れる行為です。
- 手順書の裏にしか書かれていない「運用ノウハウ」
- “夜間バッチでしか動かさない”暗黙の制約
- “月次ジョブはこれを実行後に手動確認”という口伝
- スケジューラ（JP1, A-AUTO, SystemWalker）の設定がブラックボックス
つまり、バッチの移植とは企業文化の翻訳に近いのです。
COBOLは構文を移す。
バッチは儀式を移す。
5. なぜCOBOLは楽しく、バッチは苦しいのか
| 観点 | COBOL | バッチシステム |
|---|---|---|
| 本質 | 言語・ロジック | 運用・文化 |
| 標準化 | 高い | ほぼゼロ |
| 読みやすさ | 明快 | 暗号 |
| 再利用性 | 高い | メーカー依存 |
| 作業感覚 | パズルを解く楽しさ | 沼を渡る苦行 |
6. これからの教訓
COBOLの移植は、AI解析やコード変換でもかなり自動化が進んできています。
しかし、バッチ構造やジョブ依存を理解できるAIはまだ少ない。
今後の課題は、**「バッチ文化を可視化すること」**です。
- ジョブフローの自動抽出
- ファイル依存関係のグラフ化
- メーカー独自DBアクセスをメタ情報として整理
言語は翻訳できる。
文化は可視化しなければ移せない。
7. おわりに
COBOLはよく「古くて面倒」と言われますが、
触ってみると意外に“筋が通っている”。
一方でバッチシステムは、“人間の歴史”がそのまま詰まっている。
だからこそ、理解も再現も一筋縄ではいかない。
COBOL移植は技術。
バッチ移植は人類学。
それでも私たちは今日も、夜間ジョブが通ることを祈りながら、
メーカーごとの“塔バベル”を少しずつ読み解いていくのです。
🏁 まとめ
- COBOLは構文とデータ構造が明快で、移植は「楽しい知的パズル」。
- バッチはメーカー文化の塊で、移植は「苦行」そのもの。
- 真の課題は「技術」ではなく「文化」と「運用習慣」の翻訳にある。
ご希望があれば、このドラフトに - 具体的なJCL記述例やDBアクセス構文例
- 移植支援ツール紹介（例：Micro Focus、Raincode、OpenCobol等）
を加えて技術寄りのQiita完成版として整えることもできます。
👉次のステップとして、
どちらの方向（①エッセイ寄り／②技術実例付き）で完成版に進めましょうか？
オープンソースのCOBOLは、今でも簡単にPCで動くことと、COBOLは英語を書くように書けばよく４０年ぶりでも１時間以内にプログラムがかけたことを追記したい。https://qiita.com/kaizen_nagoya/items/9d9a216ce1b7b05dbb43
了解しました。以下のように追記案を盛り込みます。ご確認ください。
追記案
また、昨今ではオープンソースの COBOL コンパイラ／実行環境も整っており、PC上ですぐに動かせるようになっています（例えば「Docker で COBOL を動かしてみた」記事では、40 年ぶりにCOBOLを触ったとして「座って１時間で導入・コンパイル・実行」できたという報告があります）。 ([Qiita][1])
さらに、COBOLは「英語のように書けばよい」ため、長期間触っていなかった人でも、英語に抵抗がなければ１時間以内にプログラムを書けたという体験例もあります。 ([Qiita][1])
もしよければ、こちらの追記を含めた 本文全文のドラフト（3000字程度） を改めてご用意いたします。どうしますか？
[1]: https://qiita.com/kaizen_nagoya/items/9d9a216ce1b7b05dbb43 "COBOLを40年ぶりにうごかしてみた:dockerでcobol。docker(81)プログラムちょい替え（4） #Docker - Qiita"
はい。
承知しました。
以下に、追記内容（オープンソースCOBOL・英語的記述のしやすさ・40年ぶりに1時間で動かせた体験）を含めた、
Qiita向け最終ドラフト（約3000字）をまとめました。
COBOLの移植は楽しい。バッチシステムの移植は苦行。
― メインフレーム文化圏の塔バベル ―
はじめに
COBOLというと、「古い」「面倒」「消えゆく遺産」というイメージを持つ人も多いでしょう。
しかし、実際にCOBOLの移植をやってみると――これが意外に楽しいのです。
一方で、同じレガシー領域でも「バッチシステムの移植」となると話は別。
これはもう、技術ではなく宗教の領域です。
COBOLの移植がパズルだとすれば、バッチの移植は迷宮探索。
1. COBOLの移植は“考古学の楽しさ”
COBOLのソースコードを読むと、作者の意図や時代の空気が透けて見えます。
なぜなら、COBOLは人間に優しい言語だからです。
- 文法が英語に近い（
ADD A TO B,MOVE X TO Yなど） - データ構造が DATA DIVISION に明示されており、全体像を把握しやすい
- プログラム構造がトップダウンで論理的
- 50年以上前のコードでも構文がほぼそのまま通る
COBOL移植の魅力は、「昔の人の思考をトレースできる」点にあります。
機械語ではなく、設計思想そのものを読み解く作業です。
COBOLは“古文”ではなく“古典”。
読めば通じる。しかも美しく論理的。
2. オープンソースCOBOLは今も現役
驚くべきことに、COBOLは今でも簡単にPC上で動かせます。
オープンソースの「GnuCOBOL」などを使えば、Windows・macOS・Linux いずれでもすぐ動作。
Dockerイメージもあり、現代の開発環境でも問題なくコンパイル・実行できます。
実際、筆者は40年ぶりにCOBOLを触りましたが、
インストールから最初の「Hello, world!」までわずか1時間足らず。
COBOLは英語を書くように書けばよい言語なので、
長年のブランクがあっても驚くほどスムーズにプログラムを再開できました。
“COBOL is written almost like English.”
久しぶりに触っても、身体が思い出す感覚。
参考：
👉 Docker で 40 年ぶりに COBOL を動かしてみた
3. バッチシステムの移植は“宗教戦争”
ここからが本題です。
COBOLの移植が楽しいのは、「言語」として普遍だから。
しかし、バッチシステムの移植となると、メーカーごとの文化衝突が始まります。
メーカーごとの“塔バベル”
| メーカー | 主な環境 | 特徴・洗礼 |
|---|---|---|
| IBM | z/OS + JCL + DB2 | JCL構文の呪文が深く、VSAMファイル操作が独特。 |
| 日立 | VOS3 + DABAS | SQLに似て非なる EXEC DABAS の世界。 |
| 富士通 | AIM + KDMS | ファイル制御が特殊で、パラメータの意味が神秘的。 |
| NEC | ACOS + DMS | データ管理がシステム固有で移植困難。 |
見た目は同じCOBOLでも、動かす環境が違えばまったく別物。
ファイルアクセス、ジョブ制御、データベース構文、スケジューラ設定の全てが再設計レベルです。
COBOLは人間が読めるが、
バッチはメーカーしか読めない。
4. データベース呼び出し構文のカオス
各社メインフレームのデータベース呼び出しは、まさにわけわかめ構文。
- 富士通 KDMS →
CALL "KDMSIO" - 日立 DABAS →
EXEC DABAS - IBM DB2 →
EXEC SQL（だが独自拡張あり） - NEC DMS →
CALL DMSIO
似ているようで、全く互換性がありません。
「SELECT」も「FETCH」も挙動が違い、
意味を保ったまま移植するのはほぼ手作業になります。
データベース呼び出しは文法ではなく呪文。
メーカーごとに祭壇が違う。
5. バッチ移植とは文化の移植である
バッチシステムの本質は、「コード」ではなく「運用文化」です。
- “夜間しか動かさない”
- “手動承認を経て次ジョブへ”
- “月次処理後に再実行禁止”
これらは技術ではなく慣習であり、人間の文化に根ざしています。
JCLやスケジューラ（A-AUTO, JP1, SystemWalkerなど）も、その文化をコード化したものです。
COBOLは構文を移す。
バッチは儀式を移す。
6. なぜCOBOLは楽しく、バッチは苦しいのか
| 観点 | COBOL | バッチシステム |
|---|---|---|
| 本質 | 言語・論理 | 運用・文化 |
| 標準化 | 高い | ほぼゼロ |
| 再利用性 | 高い | 低い |
| 学習曲線 | 緩やか | 急登 |
| 感覚 | パズルを解く | 沼を歩く |
COBOLは「英語で考えれば書ける」。
バッチは「メーカーの神話を理解しなければ動かない」。
この差が、「楽しい vs 苦行」を分けているのです。
7. 今後の方向性 ― バッチ文化の可視化へ
現代では、COBOLコードの解析や変換を行うツールが数多く存在します。
しかし、バッチシステム全体の依存関係やジョブフローを自動的に理解できる仕組みはまだ少ない。
次の課題は、**バッチ文化の“見える化”**です。
- ジョブフローの自動抽出
- ファイル依存の可視化
- DBアクセス構文の共通メタ変換
- 運用スケジュールのモデリング
言語は翻訳できる。
文化は可視化しなければ移せない。
8. おわりに
COBOLの移植は、人間が書いた論理を追う喜びがあります。
それは技術であり、知的なパズルです。
一方で、バッチシステムの移植は、
メーカー文化・組織慣習・手順書という人間の歴史と向き合う作業です。
COBOL移植は技術。
バッチ移植は人類学。
それでも、レガシーを動かし続けてきた人たちの知恵と工夫を尊敬しつつ、
今日も新旧のシステムのあいだを行き来しています。
参考
- Docker で 40 年ぶりに COBOL を動かしてみた
- GnuCOBOL 公式サイト
-
Open Mainframe Project COBOL Working Group
もしご希望があれば、この原稿に - 具体的なJCLやCOBOL構文例を追加して技術寄りにする
-
歴史・文化面を強調したエッセイ調に整える
などの方向調整も可能です。
どちらの方向にブラッシュアップしましょうか？
技術寄り
了解しました。
では「技術者が読むQiita記事」向けに、COBOL移植の楽しさとバッチシステム移植の苦行を対比しながら、実例・環境構築・技術的課題を交えてまとめた技術寄りドラフト（約3000字）をご提案します。
COBOLの移植は楽しい。バッチシステムの移植は苦行。
はじめに
近年、メインフレームからオープン環境への移行・移植案件は再び増えている。クラウド時代になっても、企業の中核業務を担ってきたCOBOLの資産をどう扱うかは、依然として重要なテーマだ。
筆者も久しぶりにCOBOLを触る機会があり、「あれ、COBOLってこんなに楽しかったっけ？」と思った。一方で、その周辺にあるバッチシステムの移植となると、笑っていられなくなる。
1. COBOL移植の楽しさ
COBOLは「英語のように書く」ことを目指して設計された言語だ。
DISPLAY "HELLO WORLD".
と書けば動く。この構文は今でも読みやすく、記述の意図が明確である。
さらに嬉しいのは、今のPCでも簡単に動かせることだ。オープンソースのCOBOLコンパイラ（例：GnuCOBOL）を使えば、macOSでもWindowsでもLinuxでも、数分で実行環境を整えられる。
brew install gnu-cobol
cobc -x hello.cob
./hello
これだけで40年前のCOBOLプログラムが再び息を吹き返す。
実際、筆者も40年ぶりにCOBOLを触ったが、インストールから動作確認まで１時間もかからなかった。書いているうちに、英語の文章を組み立てるような心地よさを思い出した。
COBOL自体は今も変わらず安定しており、移植そのものは意外なほどスムーズで楽しい。
2. バッチシステム移植の苦行
問題はその「周辺」にある。COBOLのソースをコンパイルして実行するだけなら簡単だが、実際の企業システムではバッチ処理の制御、データベース、ジョブ管理、入出力フォーマットなどが密接に絡み合っている。
2.1 メインフレーム依存の多層構造
メインフレーム時代のバッチシステムは、各メーカー（IBM、富士通、日立、NECなど）が独自に設計した環境に強く依存している。
- JCL（Job Control Language）：メーカーごとに文法・機能が異なる。
- データベース：IMS、IDMS、DMSなど、いずれも独自仕様でSQL非対応。
-
ファイル形式：EBCDICコード、固定長、ブロックサイズ指定など。
これらの構造は「ソースをコンバートすれば済む」というレベルではない。メーカー固有の設定ファイル、ステップ管理、ジョブスケジューラの挙動まで、まるで異なる文化圏だ。
2.2 想像を絶する「わけわかめ」仕様
たとえば、あるメインフレーム環境では、日次バッチで100本以上のジョブをJCLで連結し、各ジョブが独自形式のデータベースを操作している。
移行先ではRDBに置き換えるとしても、論理削除や更新履歴、可変長レコードの扱いなどを再現しなければならない。
JCL内の「IF/THEN/ELSE」構造やCONDパラメータの意味を正確に理解しないと、再現性のない結果が出る。
つまり、「動いていた理由」がコード上にはなく、運用ルールや手順書、時にはベテランの記憶に埋もれているのだ。
3. 「COBOL移植が楽しい理由」と「バッチ移植が苦行な理由」
| 項目 | COBOL移植 | バッチシステム移植 |
|---|---|---|
| 言語仕様 | ANSI準拠、文法安定 | メーカ独自仕様が混在 |
| 実行環境 | GnuCOBOLで即動作 | メインフレーム環境依存 |
| 学習コスト | 英語感覚で記述可能 | JCLや独自DB構造の解析が必要 |
| デバッグ | 標準入出力で確認容易 | ジョブ単位・複合依存あり |
| 成功体験 | 小さくても動く喜び | すべて動くまで成果が見えにくい |
COBOL単体では「プログラム言語の原点」を味わえるが、バッチ移行では「アーキテクチャの歴史」を掘り起こすような地道な作業が続く。
4. 今こそ「分離して考える」
移行プロジェクトで重要なのは、「COBOLの論理（業務ロジック）」と「バッチ制御（ジョブ運用）」を明確に分離して考えることだ。
- COBOL：GnuCOBOL等でロジック単体テスト
- バッチ制御：Airflow、Luigi、または独自スクリプトで再構成
COBOLの資産は「業務知識の塊」だ。これを近代的な制御フレームワークと組み合わせることで、移植は現実的なレベルに近づく。
5. おわりに
COBOLは古いが、枯れていない。英語のように書けて、いまでもPCで動く。
問題はCOBOLそのものではなく、その周囲に積み重なった「環境文化」だ。
COBOLを触るのは楽しい。
バッチシステムを触るのは苦行。
それでも両方を理解してこそ、過去の資産を未来へつなぐ本当の移植になる。
もしご希望があれば、Qiita投稿向けに：
- 冒頭サマリ（要約3行）
- タグ候補（例：COBOL, レガシー移行, GnuCOBOL, メインフレーム）
-
図表（バッチ構造のイメージ）
も追記しますか？
図表
了解です。技術寄りの記事に合う図表案を作りましょう。
ここではテキストベースでQiitaに貼れる形と、イメージ化した場合の構成を提案します。1. バッチ依存関係の概念図
┌─────────────┐
│ データベース │
│ （KDMS/DB2） │
└─────┬───────┘
│
┌─────▼───────┐
│ ジョブステップ1 │
│ JCL / バッチ制御 │
└─────┬───────┘
│
┌─────▼───────┐
│ ジョブステップ2 │
│ ファイル出力 │
└─────┬───────┘
│
┌─────▼───────┐
│ ジョブステップ3 │
│ 外部バッチ呼出 │
└─────┘
ポイント
- 各ジョブステップが依存関係でつながっていることを可視化
- データベース・ファイル・外部バッチへの依存を示す
- メーカーごとに構文や処理方法が異なる点も矢印や注釈で示せる
2. COBOL vs バッチ移植比較表（図表形式）
| 項目 | COBOL移植 | バッチ移植 |
|---|---|---|
| 対象 | プログラムロジック | ジョブ・スケジュール・DB依存 |
| 環境依存 | 低（オープンソースでPC上可動） | 高（メインフレーム/メーカー固有） |
| 標準化 | ANSI準拠、文法安定 | JCL/DB独自仕様、運用慣習依存 |
| 作業感覚 | 英語で書くように記述 | 迷宮探索・文化理解 |
| 成果の見えやすさ | 小単位でも動作確認可 | 全体が動かないと検証不可 |
3. 技術寄りイメージ（図表化例）
COBOL移植 バッチ移植
┌─────────────┐ ┌─────────────────┐
│ GnuCOBOL / PC │ │ メインフレーム │
│ ソースコード │ │ JCL + DB + File │
└──────┬───────┘ └─────────┬───────┘
│ │
▼ ▼
小規模テスト ジョブフロー全体確認
│ │
▼ ▼
修正・実行 依存関係調整
解説
- 左側：COBOLは小規模テスト単位で移植・確認可能
- 右側：バッチはジョブ全体の依存関係を理解してから移植作業
もし希望であれば、これをQiita向けにMermaid記法で図として埋め込める形に変換できます。
例：
これを使うとQiita記事内で実際に図として表示されます。
希望に応じて、このMermaid図をCOBOL移植とバッチ移植の比較図も作り、記事内に2〜3枚組み込むことが可能です。
作りますか？
図はplantUMLでお願い
了解です。PlantUMLで描く場合、Qiitaでも貼り付け可能な形式で「バッチ依存関係」と「COBOL vs バッチ比較」の図を作ることができます。以下に例を示します。
1. バッチ依存関係（PlantUML）
解説
- データベースからジョブステップ1 → 2 → 3と順に依存関係を矢印で示す
- 各ステップに処理内容や制御手段を注記
2. COBOL移植 vs バッチ移植の比較（PlantUMLフローチャート風）
解説
- 左側：COBOLは小規模単位でテスト・修正・実行が可能
- 右側：バッチは全体フローを理解し、依存関係を調整しなければ動作確認できない
3. メリット
- PlantUMLなのでQiitaにそのまま貼れる
- コードを変更するだけでステップ名や処理内容を簡単に編集可能
- 図が文字ベースなので、環境に依存せず表示される
希望であれば、これらを1枚の統合図にしてCOBOL移植とバッチ移植の差を一目で示す形にもできます。
作りますか？
PlantUMLからのCobol生成と、CobolからのPlantUML生成のシステムのソースコードを生成してください。
File: README.md
# PlantUML <-> COBOL generation system
This repository contains two Python scripts:
- `plantuml_to_cobol.py` : Convert a restricted subset of PlantUML activity diagrams into a COBOL program skeleton.
- `cobol_to_plantuml.py` : Convert a COBOL program (simple, conventional layout) into a PlantUML activity diagram.
Both scripts target a pragmatic, limited subset useful for documentation and quick prototyping. They are intentionally simple and easy to extend.
---
# File: plantuml_to_cobol.py
#!/usr/bin/env python3
plantuml_to_cobol.py
Simple generator that parses a restricted PlantUML activity diagram and
emits a COBOL program skeleton.
Supported PlantUML input (activity-style):
Rules/Mapping:
- Lines beginning with ":DATA" define working-storage items using a simplified syntax:
:DATA name PIC X(10);- Lines beginning with ":PARAGRAPH " start a procedure paragraph.
- Lines between paragraph markers are copied into the paragraph as comments or simple statements.
This is intended as a starting point — adapt the parser to your PlantUML style if needed.
import re
import sys
from pathlib import Path
def parse_plantuml(text):
"""Parse a limited PlantUML activity text into a structured model."""
lines = []
in_block = False
for raw in text.splitlines():
s = raw.strip()
if s.startswith("@startuml"):
in_block = True
continue
if s.startswith("@enduml"):
in_block = False
continue
if not in_block:
continue
# Skip start/stop or empty
if s in ("start", "stop") or s == "":
continue
# activity line like :DATA ...; or :PARAGRAPH NAME
m = re.match(r'[:]\s*(.+)', s)
if m:
lines.append(m.group(1).rstrip(';'))
model = {
'data_items': [], # tuples (name, pic)
'paragraphs': [] # tuples (name, [statements])
}
current_para = None
for item in lines:
if item.upper().startswith('DATA '):
# DATA name PIC X(10)
rest = item[5:].strip()
# Accept patterns like NAME PIC X(10) or NAME TYPE ...
m = re.match(r"([A-Za-z0-9\-]+)\s+PIC\s+(.+)$", rest, flags=re.IGNORECASE)
if m:
name = m.group(1)
pic = m.group(2).strip()
else:
parts = rest.split(None, 1)
name = parts[0]
pic = parts[1] if len(parts) > 1 else 'X(100)'
model['data_items'].append((name.upper(), pic.upper()))
continue
if item.upper().startswith('PARAGRAPH '):
name = item.split(None, 1)[1].strip()
current_para = (name.upper(), [])
model['paragraphs'].append(current_para)
continue
# Otherwise it's a statement inside a paragraph
if current_para is None:
# If no paragraph defined yet, create one called MAIN
current_para = ('MAIN', [])
model['paragraphs'].append(current_para)
current_para[1].append(item)
return model
def emit_cobol(model, program_name='GENPROG'):
"""Generate a COBOL program text from model."""
out = []
out.append(' IDENTIFICATION DIVISION.')
out.append(f' PROGRAM-ID. {program_name}.')
out.append(' *) Generated by plantuml_to_cobol.py')
out.append('')
if model['data_items']:
out.append(' DATA DIVISION.')
out.append(' WORKING-STORAGE SECTION.')
for name, pic in model['data_items']:
out.append(f' 01 {name} PIC {pic}.')
out.append('')
out.append(' PROCEDURE DIVISION.')
for para_name, stmts in model['paragraphs']:
out.append(f'{para_name}.')
if not stmts:
out.append(' *> no statements')
else:
for s in stmts:
# Try to map some simple statements
s_strip = s.strip()
# Example: MOVE A TO B
if re.match(r'(?i)^MOVE\b', s_strip):
out.append(' ' + s_strip + '.')
elif re.match(r'(?i)^DISPLAY\b', s_strip):
out.append(' ' + s_strip + '.')
else:
# fallback: emit as comment to be manually implemented
out.append(' *> ' + s_strip)
out.append('')
out.append(' STOP RUN.')
return '\n'.join(out)
def main():
if len(sys.argv) < 2:
print('Usage: plantuml_to_cobol.py input.puml [PROGRAM-NAME]')
sys.exit(2)
p = Path(sys.argv[1])
text = p.read_text(encoding='utf-8')
model = parse_plantuml(text)
pname = sys.argv[2] if len(sys.argv) > 2 else p.stem.upper()
cobol_text = emit_cobol(model, program_name=pname)
out_file = p.with_suffix('.cob')
out_file.write_text(cobol_text, encoding='utf-8')
print(f'Wrote {out_file}')
if __name__ == '__main__':
main()
# File: cobol_to_plantuml.py
#!/usr/bin/env python3
cobol_to_plantuml.py
Simple COBOL parser to produce a PlantUML activity diagram.
It extracts WORKING-STORAGE items and PROCEDURE DIVISION paragraphs.
Limitations:
- Expects COBOL in a classical free-format (not strict column-based).
- Detects WORKING-STORAGE SECTION and simple PIC lines, and paragraph labels
by a line that starts at column 1 and ends with a period. - This is for documentation and prototyping; do not rely on it as a full parser.
import re
import sys
from pathlib import Path
def parse_cobol(text):
lines = text.splitlines()
in_ws = False
in_proc = False
data_items = []
paragraphs = []
current_para = None
for raw in lines:
line = raw.rstrip()
# Normalize spaces for parsing
s = line.strip()
up = s.upper()
if up.startswith('DATA DIVISION'):
in_ws = True
continue
if in_ws and up.startswith('PROCEDURE DIVISION'):
in_ws = False
in_proc = True
continue
if in_ws:
# find PIC lines like '01 VAR-NAME PIC X(10).'
m = re.match(r"^(\d{2})\s+([A-Za-z0-9\-]+)\s+PIC\s+([^\.]+)\.?$", s, flags=re.IGNORECASE)
if m:
name = m.group(2).upper()
pic = m.group(3).strip().upper()
data_items.append((name, pic))
else:
# Also allow '01 VAR-NAME PIC X(10).' without level columns
m2 = re.match(r"^([A-Za-z0-9\-]+)\s+PIC\s+([^\.]+)\.?$", s, flags=re.IGNORECASE)
if m2:
data_items.append((m2.group(1).upper(), m2.group(2).strip().upper()))
continue
if in_proc:
# paragraphs are lines that start at beginning and end with a period and have no spaces
# e.g. MAIN-LOOP.
m = re.match(r'^([A-Za-z0-9\-]+)\.$', s)
if m:
if current_para:
paragraphs.append((current_para, para_stmts))
current_para = m.group(1).upper()
para_stmts = []
continue
# collect statements until next paragraph
if current_para:
if s == '':
continue
para_stmts.append(s)
# append last
if in_proc and current_para:
paragraphs.append((current_para, para_stmts))
return {
'data_items': data_items,
'paragraphs': paragraphs
}
def emit_plantuml(model, title='COBOL Flow'):
out = []
out.append('@startuml')
out.append(f'title {title}')
out.append('start')
# Emit data items as first activities
for name, pic in model['data_items']:
out.append(f':DATA {name} PIC {pic};')
# Emit paragraphs as steps
for para_name, stmts in model['paragraphs']:
out.append(f':PARAGRAPH {para_name};')
for s in stmts[:5]: # include up to first 5 statements as comment-like notes
clean = s.replace('"', "'")
out.append(f':{clean};')
out.append('stop')
out.append('@enduml')
return '\n'.join(out)
def main():
if len(sys.argv) < 2:
print('Usage: cobol_to_plantuml.py input.cob [TITLE]')
sys.exit(2)
p = Path(sys.argv[1])
text = p.read_text(encoding='utf-8')
model = parse_cobol(text)
title = sys.argv[2] if len(sys.argv) > 2 else p.stem
plant_text = emit_plantuml(model, title=title)
out_file = p.with_suffix('.puml')
out_file.write_text(plant_text, encoding='utf-8')
print(f'Wrote {out_file}')
if __name__ == '__main__':
main()
File: examples/example.puml
File: examples/example.cob
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 CUSTOMER-NAME PIC X(30).
01 AMOUNT PIC 9(6)V99.
PROCEDURE DIVISION.
MAIN-PARA.
DISPLAY "START".
PROCESS.
MOVE 100 TO AMOUNT.
DISPLAY "DONE".
STOP RUN.
File: USAGE.md
# Usage
## Generate COBOL from PlantUML
python3 plantuml_to_cobol.py examples/example.puml SAMPLE
This writes `examples/example.cob` with a basic COBOL skeleton.
## Generate PlantUML from COBOL
python3 cobol_to_plantuml.py examples/example.cob SAMPLE
This writes `examples/example.puml`.
---
# Notes
- These scripts are intentionally small and use regex-based parsing. For production use, integrate with a proper COBOL parser (e.g., using OpenCobol/GnuCOBOL parser outputs or a COBOL frontend) and extend PlantUML DSL definitions as needed.
- Extend the PlantUML conventions to match your team's diagram style (you may prefer activity boxes, notes, or class diagrams).
# End of bundle