レガシーソフトウェア以外に、COBOLを使用する理由はありますか？

COBOLは今でも（頻繁に）金融コンピューティングに使用されています。それは古い言語であり、ほとんどのプログラマーはCOBOLを嫌い、または少なくとも嫌いです。これは問題をもたらします：COBOLがまだ使用されている唯一の理由は、レガシーソフトウェアがそれを使用するのですか、それとも他のプログラミング言語に比べて実際の利点があるのですか？

ちょっと興味があるんだけど。

現在はほとんどがレガシーです。重要なビジネスシステムの多くは、非常に大きく、統合されているため、書き換えのコストに見合った価値がないように思われるだけの理由で、まだCOBOLのままです。COBOLで新しいシステムを作成することは、おそらく実現不可能です。ほとんどのCOBOL開発者は非常に乏しく、専門的なスキルのためにかなりの金額を引き込むことができるためです（現在はFoxpro開発者に似ています）。COBOLアプリを保持する理由はほとんどありませんが、残念なことに、COBOLアプリが既に配置され、信頼されており、他のシステムと緊密に結合されており、交換がほぼ不可能である場合が一般的です。その理由が、アプリを実行する唯一のハードウェアが80/90年代のEbayパーツからカスタムビルドされる必要がある状況に至る前に、交換する必要がある理由です。

COBOLは今でも（頻繁に）金融コンピューティングに使用されています。

それは...ですか？

それはあなたが金融コンピューティングと呼ぶものに依存します。金融機関が実行しているすべてのコードを「はい」と呼ぶのであれば、おそらくそうです。ほとんどは60年代と70年代に書かれたビジネスルールを持っています。このようなシステムを新しい環境にアップグレードするリスク+コストは価値がありません。新しいCOBOLコードを書いている人はいないと思います。現在、たとえば.NETスタックに統合するCOBOLコンパイラがあります。多くの場合、レガシーアプリケーションを最新のソフトウェアスタックに統合して活用するためのツールがありますが、これらのツールは、非常にニッチな市場であるため、使用する必要のない人には知られていないことがよくあります。

金融コンピューティングを量的金融のソフトウェアのようなものにすると、誰かがCOBOLを使用しているという話を聞いたことがありません。C ++は、APLの派生物であるkのようないくつかのニッチ言語に沿って、より一般的です。

COBOLは主にレガシー使用を現在見ています。新しいアプリケーションは作成されておらず、古いアプリケーションはゆっくりですが、確実に段階的に廃止されているため、ユーザーベースは徐々に減少していきます。

迅速かつ安価に交換できるほとんどのCOBOLシステムは、すでに交換済みです。新しいシステムに比べて、修理または交換がますます高価になりつつありますが、維持するのにますます安価になっているものは、安価で時代遅れのハードウェアで正常に動作し、長年のサービスの後、新しいバグを長く表示します。ほとんどのバグは修正されているか、回避策として適合する長年の伝統があります。メンテナンスは通常、1人または2人の専門の従業員に減らされており、長い間システムで作業した後、想像以上に親密にそれを知っています。

技術的な観点から見ても、通常、古いシステムを維持する理由はいくつかあります。それらは比較的安定しており、主にバグが修正されており、エンドユーザーによく知られています。

ただし、最終的にはシステムが置き換えられるのがわかります。通常、この動きは物事のビジネス側から生じます。

• 現在のシステムのユーザーは、古風なインターフェースの使用方法を学ぶことに確信が持てない若いユーザーに置き換えられています
• 会社はシステムを維持するために雇う人を見つけることができず、他の従業員の給与と比較して法外な給与ではありません
• 予算が大きい人は、会社のコアシステムがラップトップ上のvmに置き換えることができるハードウェアで実行されていることを知って恥ずかしくなります。
• 新しい商品システムが登場しました。これは使い始めるのが本当に安いです
• 古いシステムを使用している会社が買収された、倒産した、またはそうでなければ実際に存在しなくなった
• 新しい、緊急に必要な機能の重要なビットは、レガシーシステムと対話するために安く作ることはできません

「ほとんどのプログラマー」が何を意味しているのだろう。私は、cobolプログラマー、Javaプログラマー、.NETプログラマー（単数形）、古いスタイルのVBプログラマーと同じフロアにある大きなITショップで働いています。憎しみや嫌いはありません。cobolは、他のプログラミング言語と同様の言語です。cobolでプログラミングする人々は、Javaでプログラミングしたりトラックを運転したりするのと同じように仕事をするので、そうします。米国での一般的な概念に反して、多くのコボルが執筆され続けていますが、そのほとんどはインドでのみ行われ、毎日新しいコボルプログラマーが仕事を始めています。

Cobolで書かれたネットの新しいシステムが多すぎない理由は、cobolに適した種類のシステム（大容量ファイル処理）がすべて既に書き込まれているためだと思います。最近、新しい大企業はほとんど生まれません。そして、そうするのは、給与計算やレガシーcobolシステムを実行する企業への利益などのアウトソーシングかもしれません。

PeopleSoftのコアコードの大部分はCOBOLで記述されています。

20年にわたるCOBOLの経験があり、3つの異なるメインフレームで、真のCOBOLプログラマはほとんどおらず、代わりにIBMプログラマ、Sperry（Unisys 2200）プログラマ、Burroughs（Unisys MCP）プログラマ、およびTandem（HP NonStop）がいるプログラマー。それらへの敬意を示すために、HP 3000プログラマー、BULLプログラマー、およびDECプログラマーの存在についても言及する必要があります。

COBOLは、ほとんどの場合、大きな鉄の箱で実行されます。おそらく、私自身の基準によると、唯一の真のCOBOLプログラマーは、UNIXボックスでCOBOLを作成しているプログラマーでしょう。うわー、これについて聞いてみます。

ハードウェアが中心的な部分であるため、COBOLを作成するほとんどのプログラマーは、自分が作成するコードが実行されるハードウェアによって自分自身を識別します。長年にわたり、他のプログラマーがスペリー、バロウズ、またはタンデムのメリットについて語るのを聞いて、私はそれらを切り上げて、彼らが一緒になるまで離れることができない部屋に一緒に配置した場合、どのような戦争が続いて起こるのだろうかとよく思っていました。すべてのCOBOLの1つのハードウェアプラットフォームについて合意しました。他のプラットフォームには触れたことがないので、言及しませんでした。

私は多くのIBMプログラマーと会って話し合いましたが、彼らは自分たちをCOBOLプログラマーと呼んでいます。ただし、会話に参加すると、すぐにIBM固有の手順とツールについて言及し始めます。COBOLのハードウェア中心の性質を考えると、これはすべてのハードウェアプラットフォームで非常に理解できます。

COBOLは通常、非常に高価なハードウェアに関連付けられているため、そのハードウェアがコンパイルされたCOBOLプログラムを実行している限り、移行のためにCOBOLから移行する強い欲求はありません。ただし、COBOLプログラマーの高齢化に伴い、移行は避けられません。

COBOLを実行するすべての大きな鉄の箱もJavaを実行するため、JavaはCOBOLからの移行の自然な道です。コードは、特に現在のダウンエコノミーでは、かなり経済的な価格で変換できます。そのCOBOLがなく、Javaだけがその高価なハードウェア部分にある場合、組織の上位にいる誰かが、Javaコードを他のはるかに安価なハードウェア部分に移動できるかどうか疑問に思い始めます。

IBM、Sperry、Burroughs、Tandemのプログラマーはこれを知っているので、アイデアを決して提供しないでしょう。一部の人にとっては、それは生贄になるでしょう。