6

現在、COBOL で記述され、OpenVMS (Integrity/Itanium) 上で実行される大規模なビジネス クリティカルなアプリケーションがあります。

月が経つにつれて、Itanium アーキテクチャの寿命についての憶測がますます増えています。もちろん、公には何も語られていませんが、このような記事やこのよう記事は、憂慮すべき状況を描いています。これを裏付ける公式の情報は何も見つかりませんが、当社の廊下では、HP が OpenVMS と HP COBOL を廃止するというつぶやきさえあります。

これで私たちだけだとは信じられません。

私の見方では、いくつかのオプションがあります。

  1. CHARON-VAXCHARON-AXPなどの製品を使用して、いくつかの古いハードウェアをエミュレートし、その上でアプリケーションを実行します。私の見方では、特に 64 ビット (AXP) オプションが使用されている場合、プロセスが比較的簡単であるという利点があります。潜在的な短所は、パフォーマンスの低下です (ただし、これは、より高速なハードウェアによって相殺されるはずです)。
  2. HP COBOL ベースのアプリケーションをVisual COBOLなどの最新の COBOL の方言に移植します。したがって、長所は、移植作業が比較的少ないという事実 (依然として COBOL です) と、Unix または Windows プラットフォームでアプリケーションを実行できるという事実です。短所は、COBOL を移植しているにもかかわらず、別のオペレーティング システムに移植しているという事実が問題を引き起こす可能性があることです (特に、OpenVMS 固有の依存関係がある場合)。
  3. COBOL を Java のような最新の言語に自動的に変換します。これには、ハードウェア サポート、オペレーティング システム サポート、特に管理者とプログラマーの検索など、すべての従来の問題からすぐに解放されるという明らかな利点があります。これが大きな仕事であることを除けば、明白な欠点は、非慣用的な Java (または最終的に選択されたターゲット言語) になってしまうという事実です。おそらく、これは時間の経過とともに改善できるものです。
  4. ゼロからの書き直し(当然、最新のテクノロジーを使用)。これを行ったことのある人なら誰でも、それがどれほど費用と時間がかかるかを知っています。リストを完全にするためにのみ含めました:)

独自の DBMS には依存しないことに注意してください。データベースは ISAM ファイルベースです。

だから...私の質問は:

選択したプラットフォームが OpenVMS と COBOL である場合、Itanium の差し迫った陳腐化に直面している他の企業は、ビジネス継続性を維持するために何をしているのでしょうか?

アップデート:

Integrity/Itanium/OpenVMS は、少なくとも2022 年まではサポートされるということを、現地の HP 担当者から公式に保証されています。これは、この問題全体がプラットフォームに関するものではなく、言語 (COBOL) に関するものであることを意味していると思います。

4

3 に答える 3

1

この作業の主な問題は、OpenVMS 固有のコード部分です。通常、OpenVMS で開発されたほとんどのアプリケーションは、別のプラットフォームに簡単に移植できないルーチンとプロシージャを使用します。特定の言語の互換性について心配するよりも、まず、アプリケーションで使用されるランタイム ルーチンとコマンド プロシージャに焦点を当てます。

別の方法として、現在のアプリケーションを引き続き使用しながら、新しいアプリケーションを開発するか、市販のアプリケーションをニーズに合わせて変更することもできます。Itanium の長期的な地位は疑問視されていますが、過去の歴史は、OpenVMS が今後しばらく存続することを示しています。今日でも、ビジネス クリティカルなアプリケーションに使用されている VAX マシンがあります。OpenVMS とそのハードウェアが安定しているという事実が、その寿命が長い主な理由です。

ダン

于 2012-05-22T16:13:37.657 に答える
0

COBOLが主な依存関係であるように見えます。この写真のItanium+OpenVMSは単なるプラットフォームです。

あなただけがOpenVMSでミッションクリティカルなものを実行しているわけではありません。HPサイトにはOpenVMSロードマップ(AlphaとIntegrityの両方)があり、サポートは現在2015年まで延長されています。Oracleは最近、さまざまなドメインでSUN資産を活用しようとしているようです。

いずれにせよ、あなたの心配がかなりのものであるなら(COMPAQ、次にHP、vax >> alpha >> Itanium遷移について過去に心配していることを確認してください)、COBOLの依存関係を解く時があります。

そこで、COBOLから選択したより移植性の高い言語(プラットフォーム拡張なしのC / C ++ ANSIIなど)への移行パスをグラフ化することを検討します。Oracleの活動を考えると、おそらくJavaは最も賢明な選択ではありません。書き直しは、それがどれほど不快であるか、より進歩的であり、プロセス全体を合理化する可能性があります。開始が早ければ早いほど、完了も早くなります。

また、エミュレーターに加えて、中古のハードウェアがまだたくさんあります。皮肉なことに、私が今知っているある会社は、ミスソンクリティカルなAlphaに取って代わるIntegrityプラットフォームを段階的に導入しています。これは、「企業のテスト要件」だと思います...

何もしないという選択肢もありますが、明らかにリスクが高くなります。OpenVMSプラットフォームは信頼できることが証明されているため、代わりに、信頼できるサードパーティのサポート会社を見つけると、将来のハードウェアの不測の事態が拡大する可能性があります。

于 2012-05-24T19:57:08.403 に答える