C ++でのIBMアセンブラー+ COBOLの書き換え

私は1972年に書かれたレンタルシステムで実行されているレンタカー会社のレンタルエージェント/マネージャーとして働いています。ちょっとした背景として、このプログラムから毎日対処しなければならない狂気の短い例を以下に示します。

レンタルエージェントは、1つの画面での印刷がACTフィールドで「MXC」を使用することを覚えておく必要があります（すべてが短いコードに基づいています）。これは「MaXimum display on a Contract」を意味し、別の画面ではPR（PRint） ACTIONフィールドですが、いくつかの画面はPT（PrinTの場合）フィールドでYを使用し、さらに別の画面はPRT（PRinTの場合）フィールドでYを使用しますが、さらに別の画面ではユーザーがEnterキーを押す必要があります（ただし、文字、それは改行文字であるため、数字パッドで入力する必要があります）、F8、異なるが関連する画面には単にF8が必要です、一部の画面にはPRinT用のフィールドがありますが、実際にはフィールド何もせず、いくつかのプロンプトを通過した後、印刷が自動的に行われ、さらに多くの画面にPRINT Y / Nというラベルのフィールドがあります。これは、別の場所が既に書類を提出している業務ではデフォルトでYになり、別のディーラーが書類を必要とする業務ではNになります。

私はこれよりも良い仕事をすることができると決めたので、これを更新する決定を下す会社の人に連絡することにしました。最終的に、このプログラムを担当するITのVPに連絡します。私は彼から少し情報を入手し、私のレンタカー会社がIBMメインフレームアセンブラーで書かれたCOBOLを少し混ぜたレンタルプログラムを持っていることを知りました。とにかく彼に私の履歴書をメールしてください（何かが開いた場合）。

これは私の質問につながります。

最初は技術的です。将来、保守性を向上させるという考えで、アセンブリ言語よりも高いレベルの言語で書き直すことを考えています。私の経験分野はC ++なので、それは私にとって明らかな選択です。私は最近、私が話した人がチームが一生懸命働いたと言われているという記事を読んだので、プログラムを更新する簡単な方法を切に必要としています。 -桁のロケーションコード（4ではなく）と8桁の車番号（7ではなく）。更新に関する私の哲学は、このような悲惨な状況であっても、Joelの方針に沿っています：http : //www.joelonsoftware.com/articles/fog0000000069.html要するに、再書き込みは以前のすべてを捨てるのではなく、増分する必要があります新鮮に始めます。

IBMアセンブリをC ++と統合する簡単な方法はありますか？ある場合、どうすればよいですか？私はasmキーワードを漠然と認識していますが、それを使用するのが最適なのか、それとも何か他のことをするのが最適なのかわかりません。そのような計画はお勧めしませんか？私はg ++とGNU makeを使用してLinuxでほとんどの作業を行っているので、それに固有の回答は歓迎されますが、絶対に必要ではありません（どのようなビルドシステムがないのかわからないので、ほとんど何もありません）。

2番目の質問はより政治的です。切り替えを行う必要があることをこの会社に説得するにはどうすればよいですか？理論上のコスト削減は莫大です（私の見積もりによれば、会社はプログラムとやり取りする方法を学ぶためのトレーニングコストの増加だけで年間余分に数百万ドルを無駄にしています）が、私の提案された変更はおそらくすべての現在のプログラマーは、仮に彼らが制定されたとしても仕事を終えているので、変化に対する大きな構造的抵抗があります。

編集：会社が既に持っているものを変更する理由が、私にとって最良の解決策のように思える理由を説明しなければなりません。ただし、これはプログラムの怪物であるため、他の提案を受け入れています。プログラミングの仕事をしたことがないので、間違った分析を修正してください。

まず、既製のソリューションがあります。

この種のことについてのいくつかの中間レベルのマネージャーとの私の話から、新しいシステムに切り替えることの主な懸念の1つは、何十年も会社にいて、今までシステムに慣れている忠実な従業員の大多数です。持っているものを変更できる場合は、現在のインターフェイスを一種の「互換モード」に維持できます。ユーザーは既に現在のシステムを使用するためにログインする必要があるため、ユーザーが（この変更を行った後）初めてログインするときに設定をアクティブ化する機能を追加できます。 「クラシック」インターフェースまたは「新しい」インターフェース。それを可能にする既成のソリューションを見つける方法はありません。

私の会社も私たちが使用するソフトウェアを所有しています。私たちはそれをライセンスしません。これは、私が現在話している経営陣は、実際に私に変更を許可することができる人と同じであることを意味します。サードパーティのソリューションでは、使用する製品を開発した会社から必要な権利を確保することに加えて、会社から承認を得なければならないため、ハードルが追加されます。また、これは会社に「彼らの」製品をあきらめて他の製品を使用するよう説得することを必要とします。これは、私たちが持っているものを更新しようとするよりも大きなハードルのようです。

最後に、将来を見据えて、ユーザーインターフェイスを改善し、いくつかのバグを修正したいだけではありません。これらの「緊急」問題を更新した後、テクノロジーに関連する会社の基本的な方法を更新したいと考えていました。この種の問題に1〜2年費やした後、私の計画は経営陣に戻り、より劇的な変化を提案することでした。会社が運営している多くの方法がありますが、それらは現在使用していない技術によって根本的に改善される可能性があります。たとえば、各リージョンはほぼ同じように動作します。地元の主要空港は、自動車を配送する中心的なハブです。これらは主に必要に応じて送信されます。ただし、空港はすべての操作のホームベースとして使用されます。彼らは1台の車で2人を私の場所に送り、必要のない1台の車を私たちから受け取ります。その後、彼らが入った車と、彼らが取り戻しているもの（空港から32マイル）を持って空港に戻ります。その後、2台の車で5マイル離れた場所に到着し、1台を降ろしてから、もう1台の車で空港に戻ります。たとえ私たちが送り返した車が私たちの近くで必要な同じ種類の車であっても、彼らはこれを行います。私は約2年前から会社に勤めていますが、自動車不足の最も極端な緊急事態（これまで約3回）で、彼らがこれから逸脱しているように見えます。すべての地域で働く4人を、どの車がどこに行くかを決定する自動スケジューリングシステムに置き換え、必要な場所にすべての車を届けるために最短時間+マイル+ドライバーを必要とする経路を見つけようとしますより高いレベルの修正の例は、いつか追加したいと思っています。

ただし、これらすべてを提案することに不安を感じる前に、インターフェイスの更新などの小さなタスクを実行することで、会社とコードベースの足掛かりをつかむことが役立つと思います。アウトソーシングなどのソリューションは、この可能性を排除します。

技術面で自分を閉じ込める...

アプリケーションを実行する環境を決定することから始めることをお勧めします。「メインフレーム」は、アプリケーションの年齢がCICSまたはIMSである可能性があるため、いくつかの異なるものを意味する場合があります。元の作者が独自の開始タスクを作成した可能性もあります。

アプリケーションの実行場所に応じて、その環境のAPIを使用する可能性が高いため、CICSは初期とは著しく異なるインターフェースを使用するようになりました。IMSについて話すことはできません。アプリケーションが独自の開始タスクである場合、独自の内部APIを持っている可能性が非常に高くなります。同じ時代に書かれたこのような獣をサポートするのに7年ほど費やしています。

アプリケーションの時代を考えると、他に考慮すべきことは、C ++を統合したいアセンブラーが言語環境（LE）の存在よりも前であることです。そのため、アセンブラーがLEに準拠するように更新されていない限り、CとC ++はLEに準拠し、呼び出し元と呼び出し先も準拠する必要があるため、多少の困難が生じます。

考慮すべきもう1つのポイントは、このアプリケーションがmo死のメインフレームで実行されている場合、サポートされていないハードウェアおよびソフトウェアで実行されるアプリケーションと統合しようとしていることです。これは、1989年に作成された、元のハードウェア上のDOS 4.01で実行されるアプリケーションと統合しようとするのと似ています。

あなたは銃をジャンプしています。あなたの説明から、現在の技術環境を完全に理解していないように見えます（OSの正確性、データの保存場所と保存方法、他のシステムへのインターフェースの存在など）。しかし、さらに重要なのは、深刻な計画では、ソフトウェアの部分的または完全な社内書き換えの代替手段、すなわち市販のソフトウェア、書き換えのアウトソーシング、サービスとしてのソフトウェアなどを検討することです。

会社が最終的にどのように進むにせよ、まず、現在のソフトウェアの機能と新しいソリューションの要件をしっかりと分析する必要があります。

では、なぜこの分析を行うことを申し出ませんか？

私はあなたがそのような丁寧な反応を得たことに驚いています！

これを彼らの視点から見てみましょう。

おそらく数十万行のコードを持つ30年前のシステムの管理に成功し、40年にわたって進化したビジネスプロセスを具現化するおそらく他の20のシステムへのインターフェースとなります。

彼らはおそらく/彼らの分野の専門家であり、C ++をIBMの「High Level Assembler Language」から完全なタイトルを得るためのステップダウンと見なすでしょう。IBMのアセンブラー言語は非常に強力であり、「MACRO」言語は前処理/テンプレート言語の最高の実装です。

システムが最初に実装されてから約5年ごとにシステムを置き換える提案があります。実行可能性の調査後に拒否された人もいれば、予算を失う前に設計段階まで進んだ人もいれば、パフォーマンスの問題に遭遇して缶詰になる前にコードやテスト段階にさえ入った人もいました。

C ++はまったく役に立ちません。アプリケーションが実行される環境にはグラフィックライブラリはありません。（3270グラフィックライブラリがありますが、C ++では誰も使用しないためサポートされそうにありません。また、完全な "X"クライアントライブラリがありますが、使用するには別の環境にいる必要があります。）

それらは、完璧とはほど遠いがよく知られた高速のユーザーインターフェースを持っています。経験豊富なオペレーターは、同等のGUIではなく緑色の画面を使用して約3倍速くフォームに入力します。さらに、タイプに触れる間、顧客に注意を払うことができます。

スクリーンオペレータは、使用するインターフェイスをトレーニングする必要があります。そこで、新しい不慣れなGUIを使用するようにすべての従業員を再トレーニングすることは、旧従業員のシステムで新しい従業員をトレーニングするだけの場合と比較して、膨大な予算項目になります。

私は数年前にベルサウスで同様の問題を抱えていました。アセンブラー言語プログラムをバイト単位でスキャンし、オペコードとオペランドを分離し、分岐命令をtosに変換し、比較命令をIFに変換するCOBOLコードを作成しました。このプログラムは、DC命令を同等のCOBOLデータ部コードに変換し、必要に応じて移動、ザップなどを変換しました。

それが完了したら、IFとGOTOをIF-THENに変換する2番目のプログラムを作成しました。これらのクラスター間の行に移動などがあります（これは本当に難しいことではありませんでした。秘密はIFとELSEは、第1フェーズの「ピジン」コボルを後から前に読み直します）。

IF-THEN-ELSERは、安全に削除できる（参照の数を1減らす）ラベルに近接したGOTO参照を見つけた状況を探しました。このIF-THEN-ELSERプログラムを繰り返し実行します（つまり、最後のパスがそれ以上変更を加える方法を見つけられないときにのみ停止します）。重要な作業の大部分は、このif-then-elserによって行われます。COBOL製品は、経験豊富で有能なアセンブラー言語のプログラマー（つまり、私）によって慎重にレビューおよび吟味される必要があります。私の経験では、「if-then-elser」は、元の分岐命令に起因するGO TOの90％以上を排除できました。

C（またはC ++）に直接変換することで、この時点から先に進むことができると思います-私も精通している言語です。ただし、BellSouthでは、ターゲット言語としてCOBOL / IIを選択しました。残りのラベルに複数のGO TO参照がある状況から生じる少しの複雑さが常にあります（多くの場合、これらの状況はCOBOL PERFORMによって処理されますが、ORおよびAND構造によって単純に表すこともできます）。

EVALUATE（ケース構文）と88レベルの条件名を使用して、エレガントにブロック構造化されたCOBOL / IIでコードを生成するのは良いことだと思います。これらの仕上げ作業を追加すると、別のプログラムのペアが作成され、アセンブラーから変換されたプログラムを起源としないCOBOLプログラムで便利であることが証明されました。

これが役立つかどうかはわかりません。

上記の他の人がコメントしているように、このプロセスは慎重に行わなければなりません。10〜12年のアセンブラーコーディングの経験があると、意思決定プロセスを通知できます。その経験がある私たちは、これ以上見つけるのが難しいです。

最後の注意として：当時はアセンブラーでしか書いていませんでした。なぜなら、高水準言語用のコンパイラーは面倒で非効率的なオブジェクトコードを作成したからです。今日の「最適化」COBOLコンパイラには、同じような悪い習慣はありません。----------

ジョエルのアドバイスは一般的に健全ですが、この場合、完全な書き換えが遅れています。理想的には、ここで扱っているのはモンスターなので、バトルアックスで書き直してください。

あなたはすでにこの書き換えについてかなり良い議論を自分で行っているので、正確に何を追加するのか分かりません。私が唯一お勧めするのは、C ++を完全にスキップして、レンタルシステムのWebインターフェイスに直接移動することです。これにより、労働者のトレーニングがさらに容易になり、UIでの作業が大幅に節約されます。プロジェクトで新しい血を手に入れるのがはるかに簡単になります。あるいは、すべてを外部委託することさえできます。

既存のCOBOLプログラマについては、おそらく既存のシステムの文書化と移行プロセスを支援できます。

技術的な側面に関しては、多くはアセンブラコードの品質（モジュール性）に依存します。一部のプログラマーは、標準のIBMサブルーチンリンケージ規約を使用して、特定の制限された機能と明確でシンプルなパラメーター化されたインターフェイスを備えたモジュールを作成することの重要性を理解しました。しかし、大多数はモノリシックな怪物を生み出す傾向がありました。

前者では、再利用が可能です。アセンブラーモジュールが標準（または少なくとも一貫性のある）呼び出しシーケンスを使用していると仮定すると、C ++とアセンブラーの間の「接着剤」を解決するのは難しくありません。ただし、ほとんどの場合、アセンブラコードは混乱します。構造化アセンブラを作成することはできましたが、作成した人は非常に少なく、書き直しを開始する「デザイン」を見分けることはほぼ不可能です。

一方、360/370アセンブラは、今日のマイクロプロセッサに比べてかなり高レベルであり、はるかに単純であり、Cは「高レベルアセンブラ」と見なされることもあります。私は、製品が完全に370アセンブラーであるDBMS会社で働いていましたが、主なアーキテクトは（将来の移植性のために）アセンブラーコードをCに機械翻訳できると考えていました。私は懐疑的ですが、ポイントはあなたが思うほど距離が大きくないということです。

これが役に立つかどうかはわかりません。私が言うように、それは元のコードの品質とサイズに大きく依存していると思います。

これが冗談かどうかはわかりません-あなたの会社は39年前に書かれたコードを真剣に実行していますか？System / 360で実行している場合、ソースからg ++をコンパイルする必要があります...

正直なところ、古いコードを使用することすら考えていません。新鮮なアプローチをとり、座ってデザインに何を入れる必要があるかを考え、最初からやり直す必要があります。はい、かなりの計画が必要になりますが、Joelでさえ、これが漸進的な変更の場合だとは思わないでしょう。

切り替える必要がある会社を説得するためには、効率を改善し、コストを削減し、そして/または現在使用しているものが収益に何らかの損害を与えていることを示す特定の理由を指摘する必要があります。

もう1つのコメント-他のレンタカー会社が21世紀に私たちの仲間に加わったと思います。私は彼らがそれをどのように行っているかを見るために少しの偵察を行い（ウェブベース、私は想像します）、おそらくそれらのシステムの1つをモデルにします（つまり、車輪を再発明しないでください）。

幸運を！

理論的には、メガバックを節約できることを示すことができれば、上級管理職に古いシステムを置き換えるよう説得することは難しくありません。そしてそれは。このシステムを保守するプログラマを見つけるのはますます難しくなり、それらのプログラマはますます高価になります。「if」の問題ではなく、「when」の問題です。本当に更新する必要があります。

ただし、問題は、更新が必要である（とにかく彼らはおそらくそれを知っている）だけでなく、社内プロジェクトであるべきだと納得させることができるかどうかです。特にチームがあなただけである場合。多くの場合、そのような主要な代替品は外部委託されています。検討のために利用可能な市販のソフトウェアが存在する場合もあります。これらのオプションは調査する必要があり、上司が賢明な場合に起こることをマネージャーが主張します。

タスクに関しては、もしあなたがそれをやるとしたら、私は実際にブルドーズ書き換えがこの場合に適切かもしれないと信じています。ジョエルの議論はすべての場合に当てはまるわけではありません。しかし、私はそれを見ずに本当に知ることができませんでした。

1. 漸進的な変更は問題外です。

2. 市販のソリューションが利用できる可能性があります。多くのレンタカー会社があります。

3. 最後の手段として、書き換える必要がある場合は、まず新しいシステムがどのように機能するかを考えるのに時間をかけます。
   機能とインターフェイスを特定したら、ニーズ（およびスキル）に最適な開発ツールを選択できます。

エンドユーザーへのストレスを最小限に抑える1つの戦略は、ユーザーが知っている古いugいインターフェイスをエミュレートし、いニーモニックのドロップダウンリストなどのいくつかの機能を追加し、UI機能を徐々に追加して、それらを最新のUIに引き離すことです。

おそらく、同じデータファイル形式を維持したくないので、切り替えた後に戻ることはありません。