レガシーソフトウェア以外に、COBOLを使用する理由はありますか？
COBOLは今でも（頻繁に）金融コンピューティングに使用されています。それは古い言語であり、ほとんどのプログラマーはCOBOLを嫌い、または少なくとも嫌いです。これは疑問をもたらします：COBOLがまだ使用されている唯一の理由は、レガシーソフトウェアがそれを使用するのですか、それとも他のプログラミング言語に比べて本当の利点があるのですか？
ちょっと興味があるんだけど。
現在はほとんどがレガシーです。重要なビジネスシステムの多くは、非常に大きく、統合されているため、書き換えのコストに見合わないというだけの理由で、まだCOBOLのままです。 COBOLで新しいシステムを作成することは、おそらく実現不可能です。ほとんどのCOBOL開発者は非常に乏しく、専門的なスキルのためにかなりの金額を引き込むことができるためです（現在はFoxpro開発者に似ています）。 COBOLアプリを維持する理由はほとんどありませんが、残念なことに、COBOLアプリが既に配置され、信頼されており、他のシステムと密接に結合していて、交換がほぼ不可能である場合が一般的です。その理由が、アプリを実行する唯一のハードウェアが80/90年代のEbayパーツからカスタムビルドされる必要がある状況になる前に、交換する必要がある理由です。
「ほとんどのプログラマ」が何を意味するのか不思議に思います。私は、cobolプログラマーと同じフロアにある大きなITショップで働いています。Javaプログラマー、.NETプログラマー（単数形）、古いスタイルVBプログラマー。そこでcobolは他のプログラミング言語と同じような言語です。cobolでプログラミングする人々は、Javaでのプログラミングやトラックの運転と同じように、彼らにとっての仕事であるため、そうします。米国で人気のある構想では、多くのcobolが作成され続けていますが、そのほとんどはインドでのみ行われ、毎日新しいCobolプログラマーが作業を開始しています。
まったく新しいシステムがCobolで書かれていないのは、cobolに適した種類のシステム（大容量ファイル処理）がすべて既に書かれているためだと思います。最近、新しい大企業はほとんど生まれません。そして、そうするのは、給与計算やレガシーcobolシステムを実行する企業への利益などのアウトソーシングかもしれません。
COBOLは今でも（頻繁に）金融コンピューティングに使用されています。
それは...ですか？
それはあなたが金融コンピューティングと呼ぶものに依存します。金融機関が実行しているすべてのコードを「はい」と呼ぶのであれば、おそらくそうです。ほとんどは60年代と70年代に書かれたビジネスルールを持っています。このようなシステムを新しい環境にアップグレードするリスク+コストは価値がありません。新しいCOBOLコードを書いている人はいないと思います。現在、たとえば.NETスタックに統合するCOBOLコンパイラがあります。多くの場合、レガシーアプリケーションを最新のソフトウェアスタックに統合して活用するためのツールがありますが、これらのツールは、非常にニッチな市場であるため、それらを使用する必要のない人には知られていないことがよくあります。
金融コンピューティングを量的金融のソフトウェアのようなものにすると、誰かがCOBOLを使用しているという話を聞いたことはありません。 C++は、APLの派生物であるkのようないくつかのニッチ言語に沿って、はるかに一般的です。
現在、COBOLは主にレガシー使用を認識しています。新しいアプリケーションは作成されておらず、古いアプリケーションはゆっくりと、しかし確実に段階的に廃止されているため、ユーザーベースは徐々に減少していきます。
迅速かつ安価に交換できるほとんどのCOBOLシステムは、すでに交換済みです。新しいシステムに比べて、修理または交換がますます高価になりつつありますが、維持するのにますます安価になっているものは、安価で時代遅れのハードウェアで正常に動作し、長年のサービスの後、新しいバグを長く表示します。ほとんどのバグは修正されているか、回避策として適合する長年の伝統があります。通常、メンテナンスは1人または2人の専門の従業員に削減されており、長い間システムに取り組んだ後、想像以上に親密にそれを知っています。
技術的な観点から見ても、通常、古いシステムを維持する理由はいくつかあります。それらは比較的安定しており、主にバグが修正されており、エンドユーザーによく知られています。
ただし、最終的にはシステムが置き換えられるのがわかります。通常、この動きはビジネスの側面から生じます。
- 現在のシステムのユーザーは、古風なインターフェースの使い方を学ぶことに確信が持てない若いユーザーに置き換えられています
- 会社はシステムを維持するために雇う人を見つけることができず、他の従業員の給与と比べて法外な給与ではありません
- 予算が大きい人は、会社のコアシステムがラップトップ上のvmに置き換えることができるハードウェアで実行されていることを知って恥ずかしくなります。
- 新しい商品システムが登場しました。これは使い始めるのが本当に安いです
- 古いシステムを使用している会社が買収され、倒産したか、そうでなければ実際に存在しなくなった
- 新しい、緊急に必要な機能の重要なビットは、レガシーシステムと対話するために安く作ることはできません
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のプログラマーはこれを知っているので、決してアイデアを提供することはないでしょう。一部の人にとっては、それは犠牲になるでしょう。
PeopleSoftのコアコードの大部分はCOBOLで記述されています。