金融機関は、COBOLなどの古いプログラミング言語の機能低下をどのように計画していますか？
一部の金融機関はまだCOBOLなどの「死んだ」言語を使用しています。これらの言語でプログラミングを行う人がほとんどいない将来、何が起こるのだろうと思います。リソースがなくなるため、システムのメンテナンスは悪夢になります。 （これは私が起こると私が思うことです）。
これらの企業は現在、システムの最新バージョンを構築していますか？そうでない場合、彼らはこれをどのように扱いますか？
プログラマーは限定的なリソースではありません。新しい言語を学ぶことは、新しい会社を始めるときに学ぶ必要があるすべてのドメインやプログラム固有のものに比べて簡単であり、人々は常に新しい会社に移動します。あなたは300のキーワードを持つ言語を話しているのに対して、何十万もの関数を持つプログラムを話しているのです。それも近くありません。
ハードウェアは最終的に使い古され、新しいハードウェアのコンパイラサポートを取得できない場合は、新しい言語に移行します。これらのタイプのハードウェアの移行は、通常、数年前に計画されています。私はかつて、ドットマトリックスリボンサプライヤーが廃業することをきっかけに、大規模な書き換えに取り組みました。私の会社は、移行のための十分な時間を購入するために、たくさんのリボン在庫を買いました。 「幸いなことに」当時の古い言語は新しいハードウェアに移行するのに十分なサポートがありましたが、書き換えは広範囲に及ぶため、新しい言語に移行した可能性もあります。
おかしい、あなたはそれを尋ねるべきです。
私の父はCOBOLプログラマーです。大学卒業後、大手保険会社に就職。彼のキャリア全体で同じアプリに取り組んでいました（その30奇年の間同じ物理メインフレーム）。過去4年間を費やして、インドの新卒チームにCOBOLの書き方をリモートで教えました。彼は去年引退した。
私はそれを「計画」として、あるいは長期的には良いビジネス決定として数えません。しかし、企業は長期的な技術的決定を下すことで有名ではありません。
与えられた問題ドメインについて、より現代の言語が古い言語よりも何らかの形で好ましいと仮定するのは簡単です。
そのような近代化に伴うリスクと莫大なコストの問題を超えて、多くのレガシー環境には独自のエコシステムがあり、それと共生的に進化してきたという事実があります。これらのソリューションは、実際に原因となった問題に最適なエリクサーです。
IBMはすぐにDB2/RPGをあきらめることはありません。 COBOLフラットファイルは、私たちの存続期間中に絶滅することはありません。これは事実です。また、削除できたとしても（ここに悪意のあるテクノロジーを挿入）、適切なツールがない可能性がある問題ドメインに対処する必要があります。
私たちが完全に理解していない可能性のある動作するシステムまたはリエンジニアリングするシステムで、少量のメンテナンスを行う方が簡単ですか？
良くも悪くもCOBOLにとって、VB6、RPGなどは死んでいるところではありません。
COBOLなどの言語は、エキゾチックなハードウェアを必要としません。不足する可能性がある唯一のリソースはスタッフです。しかし、稼ぐお金がある限り、人々は必要なスキルを学びます。
今日、一部の企業はシステムをよりファッショナブルな言語に書き換えていますが、ねえ、昨年C++からJavaに書き換えているように思われる銀行からの申し出がありました。 考えられるあらゆるアプローチに対して、少なくとも1つの会社がそれを実行に移しているだと思います。プログラマー考古学者の新しいランクのトレーニングから、すべてを何度も何度も書き換えるまで。
組織は死んだ言語を置き換えることをどのように計画していますか？ビジネスの秘密と思われる方法で。
私が最後に銀行で働いていたとき、彼らは3つの問題に直面していました：
- 彼らは過去20年間に1回、新しいコアシステムプログラマーを雇いました。
- 言語はCobolよりも死んでいました。
- コアシステムはメインフレーム上にあり、数十台のコモディティマシンのクラスターと比較すると、実行に非常にコストがかかります。
私は現在、それを処理するための実際のビジネス計画に精通していました（そのため、前述のビジネスの秘密を破ることはできません）。私のチームはそれを解決するための計画を考え出し、ほとんどを実装しました。
前述の死んだ言語からJavaに変換するツールを作成しました。作成したツールはかなりひどいJavaを生成しました。主に、GOTOがないための回避策、および再入可能関数の存在と、それを現代の言語に取り入れていない他のいくつかの癖のためです。 Java作成されたのはひどいものでしたが、新機能や変更された機能が必要なため、モジュールごとに置き換えることができました。翻訳ツールはC＃で記述され、ANTLRを利用しています。
ツールのもう一方はJavaにあり、ほとんどの演算子とデータ型は無効な言語から実装されています。ユニオンとポインタが使用されることがあったため、仮想メモリ層を実装する必要がありました。
ほとんど作業が終わった後、Javaに変換するのではなく、C++に変換した方がよいだろうという結論に達しました。C++には、最新の言語に組み込まれていない機能がまだたくさんあるためです。 Javaは、Java特定のクラスタ製品/アーキテクチャのVMが安価であるために、もともと選択されました。
私が去ったとき、これはほとんど行われました。それはあなたが死んだ言語のために見つけることができるあらゆるサンプルコードをコンパイル/翻訳します。それができなかったのはデータベース層でした。これは、死んだ言語のソースコードで3層の前処理で処理され、メインフレームでデータベースにアクセスするために使用するインターフェイスではなく、リモートdb接続で置き換える必要がありました。
私はそれがうまくいくと確信しました。しかし、作業をやめてからバージョン管理からチェックアウトされたかどうかはわかりません。彼らは今日それを使用している可能性があります。
長期的には（多くは過去になりました）、私が開始する6か月前にそれらを購入した大規模な銀行グループ会社はITシステムを完全に消化し、親会社のシステムの前で薄いシェルを使用することを強制するだろうと思います。