java - レガシー COBOL のモダナイゼーション

Question

私は常に、Cobol コードがまだどれくらい生産されているかについて読んでいます。また、より現代的な言語に更新されていない主な理由は、時間がかかりすぎたり、コストがかかりすぎたりすることです。

私の質問は次のとおりです。Cobol を Java などに変換するツールがあった場合、どの組織でもそれが役立つと思いますか? それとも、すでに機能していることがわかっているものを維持し続けますか?

score 7 · Accepted Answer

現在、大量の COBOL コード (90% をはるかに超えると見積もっています) はテストできません。

それが実際に何をするのかは誰にもわかりません。

彼らは、最小限のことですが、ほとんどの場合、期待どおりの仕事をすることを知っています。そうでない場合は、バグが知られています。

さらに悪いことに、COBOL の一部は、COBOL の他の部分のバグの回避策にすぎません。

したがって、それを精査すると、実際に何が起こっているのかわからないことがわかります。テストケースを作成することはできません。

実際、ほとんどの組織は、何が「正しい」かについて合意さえできていないことがわかります。しかし、彼らは利用できるものについては喜んで妥協します。

中核となる業務処理を検討するコストとリスクは考えられません。

score 4 · Accepted Answer

ある言語を別の言語に変換するツールを常に見つけることができます。通常、それらは「コンパイラ」という用語で使用されます。

言語 X のコードを言語 Y に変換するタスクを実行しなければならないコンパイラには、常に欠点があります。特に、そのコードが人によって書かれた場合はなおさらです。その欠点は、翻訳の過程で可読性が失われることが多いという事実です。COBOL から Java にコンパイルされたコードがすべてのプログラマーに理解されるという保証はないため、事実上、翻訳のコストは実際に増加しています。実際、そのような文脈で可読性を定義することは困難です。

読みやすさとわかりやすさの欠如は、翻訳されたコードの実行時の動作に関する知識の欠如につながります。さらに、人々が元のコードを完全に理解しているという保証はありません。確かに彼らはそれを少しずつ理解しています。

score 4 · Accepted Answer

どのような変換ツールにもリスクが伴い、結果のコードは多くのテストを受ける必要があります。

これらのシステムの多くがビジネスを運営するために毎日使用されていることを考えると、継続的な運用に多くがかかっています。つまり、「期間」や「費用」だけではなく、100%同じように機能することを信頼できるかということです。

score 3 · Accepted Answer

おそらく両方の少し。自動化と手動の両方の手法を使用して変換するためのツールとサービスを提供する企業があります。

しかし、多くの企業は「壊れていない」という哲学に従っています。特に、多くの変換が既存のシステムを「改善」しようとしたり、最新のソフトウェア設計/構築哲学を導入しようとしたりして、混乱を招く結果になるためです。

score 3 · Accepted Answer

COBOL で作成された多くのシステムでは、多数のトランザクションが実行されます。それらは、それらが実行されるメインフレームプラットフォームで適切に機能します。変化のためだけにそれらを変更するのは危険です。

score 2 · Accepted Answer

一部の組織、特にレガシーコードとのインターフェイス/周辺の設計が、コードを Java (または別の言語) に変換するよりもコストがかかり、問題になっている組織では、それが役立つと思うと思います。

while ( (CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork() )
{
 StayWithLegacyCode();
}

PortCodeToJava();

score 1 · Accepted Answer

ここにはいくつかの要因があります。

Cobolプログラムファイルは非常に長く、ほぼ常に非常に安全なメインフレーム上にあります。通常、Java開発者はそれらにアクセスできません。
大学は、20年以上Cobolを苦しめていません。その結果、本当に一流のCobol開発者全員が会社に昇進し、多くのハイテク学校の卒業生に取って代わられました。これらの人々は、ハッカーになるのに十分なプログラミング（またはC、Python、C ++などを実行し、コースを受講しなかった）や学校に通うのに十分なプログラミング（およびJava、.Net、Pythonなど）を愛していませんでした。。
Java開発者は、通常、50,000行の栄光の中でCobolプログラムを見ると気が狂うので、何の助けにもなりません。
実際にはドキュメントはありません。これらのプログラムのロジックは非常にタイトなので、実際に読んで変換する必要があります。
これらの企業のほとんどは金融会社であり、業界に参入せずに爆発する最善の方法は、何かを台無しにすることです。何かを台無しにする良い方法は、重要なタスクをCobolからJavaに変換するようなものに取り組むことです。

長い時間がかかります。プログラムの一部が機能しなくなったり、何かを実行できなくなったりして、置き換えられることがよくあります。これらのプロジェクトの1つで、すべてのFUDに腹を立てている上級管理職はあまり見かけません。また、費やしたお金の見返りという点では、時間枠はかなり長いです。

score 1 · Accepted Answer

実際、COBOL は優れた DSL (ドメイン固有言語) です。

そのドメインは、(主に) バックエンドアプリケーションに組み込まれているビジネスルールです。

他の言語を見つけてください....

その特定のドメインで機能が豊富です
その背後には数年間の実際の適用された経験があるため、すべての問題が解決されるか、公開されます
既存の COBOL レガシーマウンテンよりも TCO (総所有コスト) が低い
に変換する費用対効果が高い

....そして、バックエンドビジネスアプリケーションのキラーアプリケーションが完成します。

score 0 · Accepted Answer

古い COBOL アプリケーションについて認識すべきことは、言語の相違点に加えて、これらのアプリケーションで構築された多くのデータ構造が後の RDBMS 構造に準拠していないことです。言語の構文を変更するだけでなく、それを置き換えることは、たとえQAが十分に行われたとしても、実際の負荷に達すると多くのパフォーマンス上のリスクが発生します.

要するに、最新の言語に新しい機能を追加する方が、書き直すよりも経済的であるということです。それが続く限り、COBOLは生き続けます。

score 0 · Accepted Answer

Cobol には、データの移動が高速であるという利点があります。これは、その種のアプリケーションが多くのことを行う傾向があることです。また、マシンは処理速度ではなく、I/O 用に設計されています。したがって、別の言語への翻訳は、同一または類似のハードウェア上での COBOL の翻訳よりも遅くなる可能性が高く、そうする理由はありません。

反対の質問をさせてください。機能するものがあれば、なぜそれを変換するのですか?

(10 年ごとに橋を取り壊し、その後すぐに再建するのと同じように、通常は、現在持っているものを維持するためだけに安くなります)。

score 0 · Accepted Answer

特定のマシンまたはオペレーティングシステムで実行できるように、わずかなコストで変更できるトランスレータが存在します。一部はイギリスから入手でき、その場所またはオンサイトで実行できます。主要なモデルには標準バージョンが存在します (それらについては誰でも私に連絡できます)。別の言語のソースコードまたはスクリプトへの Cobol は、自動的に行うのが比較的簡単で、95% 以上のコード互換性を備えたターゲットマシン上のソースファイルにインポートするためのテキストファイルを生成します。コンパイラーまたは JIT ソフトウェアを実行して新しいプログラムを作成する前に必要なのは、単純な手動の修正だけです。テスト時または稼働時にメインフレームジョブのジョブコマンド言語またはマクロを修正することを忘れないでください。

java - レガシー COBOL のモダナイゼーション

11 に答える 11

Related

Reference