昔々、チームが座ってCでアプリケーションを作成し、VAX上のVMSで実行していました。これはかなり重要な作業であり、LargeCoでかなり重要なバックエンド操作を実行します。この全体のシバンは非常にうまく機能するので、25年後もまだ動き続けてそれをやっています。
時が経ち、人々は引退します。そして、たまたま、本物の男が新しい世代の鍵を引き渡したのです。彼らは、弟になるのに十分な年齢のシステムの世話人を見つけることにそれほど興奮していません。それでも、Ultra Legacy Systemsを扱うという考えに圧倒されているように、由緒あるアプリケーションを交換するコストを正当化することはできません。
LMSは、私がUNIXを使用していることを発見し、この質問をしました。そして、私はUNIXを持っていますが、話さないので、CIはそれを要約してあなたに渡します。ロングストーリーショート：
LMSは、Cで記述されたLegacyAppをVMSからUNIXに移植したいと考えています。資力？彼が読める本はありますか？彼が話すことができる人？
最初に質問する必要があるのはその理由です。「VMS から移植する必要は本当にありますか」という方向で会話を進めます。VMS について言及する価値のあることがいくつかあります。
-> VMS は現在も HP によって積極的に開発および保守されています。先週、フィールド テスト用に V8.4 をリリースしたばかりです ( http://h71000.www7.hp.com/openvmsft/を参照)。
-> VMS は新しいハードウェアで利用可能です。具体的には、Itanium プロセッサに基づく HP の Integrity サーバーです。
-> VMS は、Charon Emulation 製品を介して仮想プラットフォームでも利用できます。
-> 一般的な見積もりによると、今日でも約 300,000 の VMS システムがアクティブに使用されています。LMS は LargeCo の最後の人物かもしれませんが、彼が世界で最後に残った人物とは言えません。
-> 多くの情報が公開されています。たとえば openvms.org を参照してください。現在のユーザーからの VMS に関する多くの最新情報を確認できます。
OK - あなたはまだ VMS から移植したいと思っています。どのようにしますか？まあ、それは多くのものに依存します。
-> 他の人が言ったように、コードはどのくらい標準ですか? チャンスはあまりありません。VMS 主義が多ければ多いほど、仕事は難しくなります。'言っ途切れる。
→データベースとは？Oracle の場合、他のプラットフォームで Oracle に移行するのはおそらくそれほど難しくありません。RMS インデックス ファイルに基づくカスタム DB のようなものである場合は、さらに多くの作業を行う必要があります。疑似 DB を再作成するか、リレーショナル DB に置き換えるために十分に理解する必要があります。
-> C 以外に、アプリケーションを作成するために他に何が使用されますか? フロントエンドには何がありますか？DECフォーム? FMS? ACMS などのトランザクション エンジンはありますか? RTR? これらのことは、UNIX への移植に必要な実現可能性と労力に大きな影響を与えます。
-> 他にどのような製品が関係していますか? 使用されているサードパーティのライブラリはありますか? アプリケーションまたは機能にとって重要なサードパーティ製品が使用されていますか?
-> このシステムはクラスタ化されていますか? もしそうなら、なぜですか？UNIX ボックスでも同じ目標を達成する必要があります。
-> それを支援し、簡単にするためのツールがあると主張する企業がありますが、私の経験では、これらの企業は製品よりも多くのサービスを販売している傾向があります (つまり、費用がかかります）。
『UNIX for OpenVMS Users』という本は、VMS の初心者が VMS を理解するのにいくらか助けになりますが、タイトルが示すように、この本は実際には反対の目的を意図しています。
VMS で書かれたものはすべて、とても便利な VMS 固有のものをたくさん使用しています。
移植を容易にする互換ライブラリを販売している会社がいくつかありますが、安価ではありませんが、VMS はコストよりも信頼性が重要な場合に使用される傾向がありました。
もう 1 つのオプションは、最新のハードウェア (VM など) で openVMS を実行することです。
いくつかの選択肢があります。
OpenVMS ソースを入手し、Open VMS を Linux ディストリビューションであるかのように維持し続けます。Linux ディストリビューションや OpenVMS ディストリビューションについていくことを気にしない人もいます。それはできます。
VMS C を Linux に再コンパイルしてみてください。C が標準ライブラリのみを使用している場合、これは些細なことです。C が多くの VMS ライブラリを使用している場合、これは非常に困難な場合があります。
事実をすぐに把握できたら、この一連の行動を再評価できます。このプログラムが使用する一連の VMS ライブラリ メソッドをリストしていないため、OS とどのように絡み合っているかを判断することは不可能です。
これは些細なことか不可能かもしれません。ソースを分析しないと判断するのは困難です。
ブリッジ ライブラリを VMS から Linux に書き込みます。あなたのプログラムがいくつかの VMS 処理を行うだけであれば、これはそれほど難しくありません。あなたのプログラムが広範囲にわたる VMS 処理を行う場合、これは狂気の沙汰です。
長い目で見れば、橋はひどい考えです。ただし、マネージャーはそれを気に入っています。
別の方法は、VMS ライブラリ呼び出しを、ブリッジを記述するのではなく、適切で移植可能な Linux 呼び出しに置き換えることです。これは、プログラムの移植性のない機能を削除するため、長期的には優れています。
Python でゼロから書き直します。これは通常、C コードを移植するよりも簡単です。より短く、よりクリーンで、よりシンプルで、ポータブルになります。
VM で VMS を実行し続ける場合は、CHARON-VAX ( http://www.charon-vax.com/ ) を調べることができます。前に述べたように、移植の容易さは、VMS 拡張機能がどれだけ使用されたかに大きく依存します。文字列に埋め込まれた $ 文字 (通常は、lib$gettime、dsc$descriptor、sys$foobar などの 3 文字の先頭の部分文字列) をソース コードで検索すると、少なくともどの VMS システム関数が呼び出されているかについての基本的なアイデアが得られます。名前がかなり明白な場合、それらが移植可能である可能性はどれくらいですか。
If it ain't broke, don't fix it! Why port it or migrate the app if you don't have to? Why not run it on a current install of OpenVMS running on an HP Itanium server; that is assuming you wish to upgrade the hardware, which may not even be necessary if your VAX hardware is still running strong.
C を学ぶには、それを馬の口から引きずり出すこともできます。その発明者である Kernighan と Ritchie による「C プログラミング言語」です。
(再び) Brian Kernighan による「UNIX プログラミング環境」をお勧めします。より権威のある情報源はほとんど見つけられず、Unix/C のイディオムと C プログラミングのビットを同時に教えてくれます。
C の深みと詳細については、Peter van der Linden の本「Expert C Programming - Deep C Secrets」を心から楽しみました。
また、VMS 固有の C 関数のライブラリ ドキュメントについて LMS と格闘することもできます。(もちろん) アプリで実際に使用される関数に特に重点を置いています。それがあなたの移植作業が行われる場所です。
マシン固有の巧妙さとビット操作がどの程度行われるか、および VMS 固有のシステム コールがどれだけ使用されるかに応じて、この作業は簡単または困難になる可能性があります。ワード サイズが同じであれば非常に良いでしょう (つまり、VMS ボックスのワード サイズが 32 ビットの場合、Unix の 64 ビット バージョンでコードを実行しないでください!)
ブライアン、LMS が C コードまたはプロセス全体を移植することを指定/気遣ったかどうかはわかりません。多くの場合、人々は言語をシステムの範囲外と考えています。
VMS 上に構築されたプロセスがあった場合、少なくともスケジューリング/バッチ機能を使用した可能性が高く、これらは多くの場合 DCL でスクリプト化されています (シェルや perl スクリプトとは異なり、単純で明確な言語です)。
そのため、プロセス全体を移植するコストは、LMS が最初に認識したよりも高くなる可能性があります。ここに信頼性の側面を追加してください。C を使用している場合は、もちろん、熱意と決意があれば不可能なことではありません。
以前に投稿されたように、単に C コードを試してみたい場合は、「$」ヒットを検索してください。または、すべてのヘッダーが存在する状態でccするだけで、コンパイルリンクコマンドの基本で十分です。
あるいは、これはコンサルタントの呼び出しのように見えます。実際、そのような仕事は「エクソダス」の時代に豊富にあったからです。ハードウェアが壊れない限り、VMS は非常に堅牢なプラットフォームであり続けます (24 時間 365 日が標準です!)。幸運を！
約1年半後、あなたはすでに何をすべきかを理解しているかもしれません. 私の組織は、古い警備員が最近去ったにもかかわらず、Linux に切り替える代わりに OpenVMS に固執することを最近決定しました。非常に安定した信頼性の高いシステムであると感じたことについては、議論の余地がありませんでした。現在、サポート終了の理由により、Alpha サーバーから Integrity サーバーに切り替えています。HP は移行に非常に役立ちました。
さらに言えば、移行を支援できる Linux ベンダーが存在する可能性があります。推奨事項があるかどうか、新しいハードウェア ベンダーに問い合わせてください。
すでに知っている言語にもよりますが、C を学ぶのはそれほど難しくありません。私はC++を学ぶ過程でCを独学し、最終的にPascalから自分自身をこじ開けました。(VAX Pascal と Rdb/VMS と DCL の組み合わせは、非常に優れたものでした。)
ソフトウェアが典型的な C の場合、言語の学習よりもライブラリ関数の学習に多くの時間を費やすことになります。
これはかなり軽量なものですが、Microsoft が Visual Studio for C++ のエクスプレス エディションと組み合わせて利用できる C++ のオンライン チュートリアルを調べました。
初心者向けチュートリアルは次のとおりです。
なぜLMS がアプリケーションを Unix に移植したいのかを尋ねる努力をする価値はあるでしょう。答えは明白に思えるかもしれませんが、その理由を適切に調査することには利点があります。私は仮定します：
私たちにも同様の課題がありますが、私たちの場合、問題のアプリケーションは OpenVMS で実行されるだけでなく、COBOL で書かれています。あなたのアプリケーションがクロスプラットフォーム言語で書かれていることを考えると、あなたの状況は楽観的であると言わざるを得ません。
いずれにせよ、OpenVMS から Unix への移行などの大きな決断を下そうとしている場合は、ある程度のデューデリジェンスを行うのが賢明だと思います。あなたのケースでは、コードの移植性を評価してみてください。そうして初めて、作業の規模がわかります (最悪の場合は、簡単に最良の場合の倍数になる可能性があります)。C では、コードの移植性は主に依存関係の関数です。依存関係は「標準」ですか、それとも VMS 固有ですか?
私たちの調査によると、HP は少なくとも 2022 年まで Itanium 上の OpenVMS をサポートする予定でした。必ずしも別のプラットフォームに急いで移行する必要はありません。おそらく、アプリケーションを移植するための準備作業に着手しながら、OpenVMS にあるものを維持することができます (作成する)。 OpenVMS の仕様にあまり依存しません)。
VMS には驚くほど健全なコミュニティがあり、問題が Unix の欠如である場合、GNVがそのギャップを埋めるのに役立つのではないでしょうか?
さて、uにはいくつかのオプションがあります。このコードをかなり迅速に移植する必要がある場合は、vmsライブラリをエミュレートするためのブリッジライブラリを作成します。* nixでバックアップして実行する場合は、vmsライブラリ呼び出しを*nixのネイティブ/ポータブル呼び出しに置き換えます。
また、コードに多くの最適化がある場合、つまりインラインアセンブリとビットの調整があります。次に、このコードを書き直す必要があります。これにより、VAXアーチを理解できるようになります。また。単語サイズの違いとエンディアンの違いを必ず確認してください