COBOLを1年やって想ったこと

設計技法

この記事では、オブジェクト思考のプログラムを10年くらいやった後に、業務で1年間COBOLを書いて想ったことを書きます。COBOLなんてと思っている方や今COBOLをメインに使っている方にも読んでいただきたいものです。

COBOLってどんなもの?

COBOLの一般的な説明は検索するとすぐに出てきますね。

COBOL(Common Business-Oriented Language)は、事務処理用に設計されたプログラミング言語として1959年に誕生した。COBOL製のさまざまなレガシーシステムが現在も稼働している。最近のモダンプログラミング言語に次第に取って代わられつつあるとはいえ、レガシーシステムを保守する必要性は今もある。

301 Moved Permanently

クラウドだAIだと言っている今、COBOL開発が行われている現場があります。金融系のシステムや市区町村のシステムもCOBOLで動いていて、今も盛んにシステム保守をしている現場があります。私が携わった事があるのは、金融系と市区町村のシステムです。

COBOLをやって辛かったこと

ここには、COBOLをやって辛かったことを書きます。

エディタがしょぼい

現役のIBMメインフレームのコボラーは、ROSCOEというエディターを使っている。これがまた、慣れるまでものすごく大変なものです。

雰囲気は、この動画がわかりやすいですね。私が思っているダメな点。

  • Ctrl+ZやCtrl+Sが使えない
  • スクロールができず、PageDownかPageUpしかできない。
  • スペースか空白かを判断できない。
  • シンタックスハイライトができない

COBOLを動かすにはJCLを理解する必要がある

COBOLは、メインフレーム上では単体で実行することができない。JCLと呼ばれるジョブ制御スクリプト言語で実行する必要がある。このJCLは、現在メジャーな言語のJavaScriptやC#やPythonとは全く異なるコーディング体型をしているため、慣れるまでに時間を要する。JCLは、コンパイルやPGMの実行をする際に利用する。

Z/OSの縛り

1年なので、あまり深いところまでは行けていませんが、次の縛りが個人的に辛かったです。

  • ファイル名に8文字しか利用できない
  • ディレクトリは1階層までしか作れない
  • 個人で作成できるPGMの行数に限りがある

COBOLをやってびっくりしたこと

Eclipseを拡張したTopazという開発環境がある

CobolもWindows上で開発が可能になっています。Eclipseを商用に拡張したTopazというIDE環境で開発をしていました。ここでは、Ctrl+ZとかJCL実行ログがかなり見やすい。

BMC AMI DevX - BMC Software
Empower next-gen developers with a mainframe-inclusive DevOps toolchain that accelerates innovation and resiliency

秘蔵のツールがある

会社独自のGREPツールや本番リリースツールは、既存のJAVAやUNIXを超える性能や使い勝手を誇るツールが以心伝心されている。COBOLの仕様を知らないと作れないツールもあるため、こういうツールが出てくるとびっくりさせられる。

めちゃくちゃキレイなソースがある

COBOL単体では、とても表現力が低いが、見やすいソースはとてつもなく見やすい。半角カナだけでここまできれいにコメントが書かれていたり、オブジェクト思考の力を借りなくても、恐ろしく読みやすいコードには、読まされるし、お手本にしたいと思う。

JSON APIをCallできる

Cobolもプログラム言語として、JSON APIを利用できる模様。JSONをCALLできれば、スマートスピーカーやAIのAPI、FaaSとも連携できますね。また、メインフレーム環境下では、MQも使えるし最近はJAVAも動くらしい。でも、私の入った開発の現場ではJSON APIやJAVAは開発環境で制限をかけられていました。

https://www-01.ibm.com/support/docview.wss?uid=swg27050207

UTツールが揃っている

COBOLも考え方1つで、単体テストプログラムを作成可能。アサーション機能は自作する必要があるんですが、単体テストの自動化が可能。やろうと思えば、いくらでも自動化ができます。プロジェクトリーダーや現場の雰囲気次第というところが大きいですが運用部門と調整ができれば、JCLでCI環境も構成可能。

COBOLをやって特に大切だと思ったこと

仕様書の整備は必須

メインフレームの謎の仕様で作られた機能があると、社内の人が誰も知らない時がある。COBOLは、スパゲッティソースになりやすい言語仕様があるため、仕様書の整備が必須です。(システム導入以來、仕様書を刷新していないところも多く、全体的にわかりにくい仕様書が多い)

新しい技術の取り込みが必要

Cobolは、新しいことがやりづらい文化にある。開発環境が独自なところが多く、技術者の養成に経験者でも半年。新卒なら2年程度かかる。その間に、上の人の意見が絶対になってしまい、新しい技術の取り込みなくなってしまうところがある。

しかし、WinMergeとかGitとか利用すれば作業が格段に楽になるのにそれを試しもしない環境は如何なものかと思う。メインフレームの良いところとWindowsやUNIXの開発環境の良いところを組み合わせて、効率や品質を上げれるようにコミュニケーションと調整ができる人が欲しい。

COBOLも大切な資産

これは、タイトル通りです。COBOLシステムを一度にリプレイスしようとすると、とてつもなく途方もない予算が必要になり、それができない企業も多いです。COBOLの特性を活かして、適材適所の処理を組むことが重要になってくると思います。

COBOLの優れている点

ここでは、COBOLが他の開発環境と比べて優れている点を書きます。COBOLにも利点はあります。

  • 汎用機OS、専用ハードウェアの組み合わせによりI/Oやメモリの最適化が行われ、バッチ処理の高並列処理が可能で、オンプレミスのUNIXやJavaVMより優れている。クラウドで最適化すればそろそろ優劣の差が無くなりそう。
  • 基本情報処理試験などで出て来る、COBOL独特のデータ表現(ゾーン10進、パック10進)、『誤差がない』固定小数点の大桁数計算が可能。
  • とても管理とマネジメントがし易い。COBOLでは、新しい技術を用いた開発というより、変更になった事務処理をプログラムで実現させるという考え方が多いため、開発の工数や進捗管理がし易い。

まとめ

この記事では、COBOLを1年間やって思ったことを書きました。COBOLなんてもう枯れている技術だと思っていましたが、そうではないことがわかりました。でも、やっぱり開発現場の思想が影響します。どんな言語を使っていても新しい技術の取り込みや改善が上手く回っていれば、多分どんな言語でも楽しい開発ができると思います。

コメント

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