汎用機の移行 - tsucchi’s diary(元はてなダイアリー)

以前リホストやってたオレが来ましたよ、と。
# まあオイラはハードベンダーだったから、COBOL のコード書いてたわけじゃないけど

闘うマネジャー：複雑・怪異と思えた汎用機を丸裸に (1/2) - ITmedia エンタープライズ

　前回までの話で、情報の登録処理および出力処理はリライトとし、業務処理部分は後でと決まった。ダウンサイジングを一気に進めるのではなく、まずは図1の構成にしてしまう。つまり、長崎県庁では、ダウンサイジングを2期構成とし、第1期の目標を下図とし、業務処理部分のオープン系移行を第2期とした。

基本的な考え方はきっと間違ってないし、気合も感じられて、頑張ってほしいなぁと思う。でもなんでだろうなぁ、すごく不安を感じるんだよ。基本スタンスはきっと正しいし、すごく立派に感じるんだけど、技術的に間違ってることが多いからかなぁ。

たとえばコレ。

ところで、COBOLはどれくらいの期間で習得できるだろうか。どうも、他の言語をすでに知っている場合、一週間も勉強すれば即戦力として仕事ができるというのが一般的であるらしい。

自分の経験で言うと、C# を使い始めたときは確かに1週間くらいで一応使い物になるようになったけど、オイラ昔は Java 使いだったからね。。。 Perl なんていつの間にかそこそこ使えるようになっていたけど、いまだに勉強中だし、ましてや1週間じゃ使い物にならなかったなぁ。。。

つーか、COBOL を1週間でマスターできるぐらいのウデがあるなら、逆に COBOL 使うの嫌がるだろうなぁ。

次。

検討当時、国内で最も実績があったCOBOLはACUCOBOLである。

Micro Focus のほうが実績多いと思う。Micro Focus はメインフレームの COBOL に対する互換オプションが豊富で、うまくオプションを選べば汎用機のコードがそのままコンパイル通って動作したりする(CICS のユーティリティーとか使ってたらもちろんアウトだから、そこは何かしらの書き換えが必要)。

Acu は、ミニコンでは結構実績があったみたいでオプションも豊富だったけど、メインフレームの COBOL オプションはちょっと不足気味で書き換えが多少必要だった。

で、一番ないわー、と思ったのが、

COBOLをCに変換しているわけだから、OPEN系で速度と実績で信頼のあるCへリライトを行っていることと同じだ。不具合があり、「OpenCOBOLのせいではないか」と疑われたときは、変換されたCを見れば良いということになる。

をいをい、トランスレータが自動生成するコードなんて読めるわけねーだろ。

たとえばコレを、

IDENTIFICATION DIVISION.
PROGRAM-ID. hello.
PROCEDURE DIVISION.
DISPLAY "Hello World!".
STOP RUN.

こんな感じで

% cobc -C -x -free hello.cbl

OpenCOBOL でコンパイルして、生成された C のコードを見たら普通に 100行超えてたよ。。。100行の COBOL をトランスレートしたら、どれほどのカオスが広がるか楽しみだぜ。。。(冗談)

本当は「せいぜい数十行だろ、こんなに複雑なコードになっちゃうぜー。」って載せようと思ったのに、100行超えてたから載せるのやめたのはマジ。

トランスレートした C を読むくらいなら最初から C で書いたほうが 100倍マシなわけですよ。

メインフレームをずっと持っているのは多分良くないだろうから、長崎の職員さんと地元のベンダーさんたちには頑張って欲しいなぁ。でも心配です。