C ++でのIBMアセンブラ+ COBOLの書き換え
私は1972年に作成されたレンタルシステムで実行されているレンタカー会社のレンタルエージェント/マネージャーとして働いています。更新の時期だと思いました。背景について少し説明しますが、これは毎日このプログラムで対処しなければならない狂気の短い例です。
レンタルエージェントは、1つの画面での印刷でACTフィールドに「MXC」が使用されることを覚えておく必要があります（すべてが短いコードに基づいています）。これは当惑して「契約のMaXimum表示」を表し、別の画面ではPR（PRintの場合）が必要です。 ACTIONフィールドですが、いくつかの画面ではPT（PrinTの）フィールドでYを使用していますが、別の画面ではPRT（PRinTの）フィールドでYを使用していますが、別の画面ではユーザーがEnterキーを押す必要があります（ただし、文字、それは改行文字なので、それはテンキーのEnterキーである必要があります）、次にF8、異なるが関連する画面は単にF8を必要とし、一部の画面にはPRTというラベルの付いたフィールドがあります。何もせず、いくつかのプロンプトを通過した後、印刷は自動的に行われ、さらに多くの画面にPRINT Y/Nというラベルの付いたフィールドがあります。ディーラーは事務処理が必要になります。
私はこれよりも良い仕事をすることができると決めたので、これを更新することを決定する会社の担当者に連絡することにしました。最終的には、このプログラムを担当するIT担当副社長に連絡します。私は彼から少し情報を得て、私のレンタカー会社がIBMのメインフレームアセンブラーでレンタルプログラムを書いていて、少しのCOBOLが混在していることを知りました。彼は現在空いているポジションはありませんが、とにかく彼に私の履歴書をメールで送ってください（何かが開かれた場合に備えて）。
これは私の質問につながります。
最初は技術的です。将来の保守性を向上させるという考えから、アセンブリ言語よりも高水準の言語で書き直すことを考えています。私の経験分野はC++なので、それは私にとって明らかな選択です。私が最近話し合った男性がチームが懸命に働いたと言っていると述べられている記事を最近読んだので、会社はプログラムを更新する簡単な方法を切実に必要としており、彼らはプログラムが5をサポートしていることを発表できて誇りに思っています桁のロケーションコード（4の代わりに）および8桁の車の番号（7の代わりに）。更新に関する私の哲学は、この悲惨な状況でも、Joelの方針に沿っています： http://www.joelonsoftware.com/articles/fog0000000069.html つまり、書き換えは増分的である必要があります。以前あったすべてのものを捨てて、新鮮に始めるより。
IBM AssemblyをC++と統合する簡単な方法はありますか？その場合、どのようにすればよいですか？私は漠然とasmキーワードを認識していますが、それを使用するのが最適なのか、それとも他のことをするのが最善なのかわかりません。そのような計画は不適切です。私はg ++とGNU makeを使用してLinuxでほとんどの作業を行っているので、それに固有の回答は歓迎されますが、絶対に必要ではありません（どのようなビルドシステムがないかわからないため、しかし、私はほとんど何も疑っていません）。
2番目の質問はより政治的です。この会社を説得して、切り替えを必要とするようにするにはどうすればよいですか？理論的なコスト削減は莫大です（私の見積もりに基づいて、会社はプログラムと対話する方法を学ぶためのトレーニングコストの増加だけで、年間100万ドル以上の無駄遣いをしています）が、提案された変更はおそらくすべての現行のプログラマーは、彼らが制定された場合、失業するため、変化に対する大きな構造的抵抗があります。
編集：私が会社がすでに持っているものを変更することが私にとって最高の解決策のように思われる理由を説明する必要があります。ただし、これはプログラムの怪物なので、私は他の提案を受け入れています。今までプログラミングの仕事をしたことがないので、間違った分析があれば修正してください。
まず、既成のソリューションがあります。
この種のことについての中間管理職数人との話し合いから、新しいシステムへの切り替えに関する主な懸念の1つは、何十年も会社にいて、現在システムに慣れている多くの忠実な従業員です。 。自分が持っているものを変更する能力があれば、現在のインターフェースを一種の「互換モード」に維持できます。ユーザーは既に現在のシステムを使用するためにログインする必要があるため、ユーザーが（この変更を行った後）初めてログインしたときに設定をアクティブにする機能を追加できます。 「クラシック」インターフェースまたは「新しい」インターフェース。それを可能にする既成の解決策を見つける方法はありません。テクノロジーの変更によって上級社員が混乱するのではないかという恐れが、上級管理職がノーと言う主な理由だと思います。
私の会社も私たちが使用するソフトウェアを所有しています。ライセンスはありません。これは、私が現在話している経営陣が、実際に私に変更を加えることを許可できる人と同じであることを意味します。サードパーティのソリューションを使用する場合、使用する製品を開発した会社から必要なすべての権利を確保することに加えて、会社の承認を得る必要があり、さらにハードルが追加されます。これはまた、会社に「彼らの」製品をあきらめて他の製品を採用するよう説得することを必要とします。これは私たちが持っているものを更新しようとするよりも大きなハードルのようですが、私はこの問題について非常に間違っている可能性があります。
最後に、将来を見据えて、ユーザーインターフェイスを改善し、いくつかのバグを修正するだけではありません。これらの「緊急」の問題を更新した後、テクノロジーに関連する会社の基本的な運営方法を更新したいと思っていました。このような問題に1〜2年費やした後、私の計画は経営に戻り、より劇的な変化を提案することでした。現在使用されていないテクノロジーによって根本的に改善できる可能性のある会社の運営方法は数多くあります。たとえば、各リージョンはほとんど同じように動作します。地方の主要空港は、自動車を販売するための中心的なハブです。それらは主に必要に応じて送信されます。ただし、空港はすべての操作の拠点として使用されます。彼らは1台の車で2人の人を私の場所に送り、私たちから不要な1台の車をピックアップし、彼らが来た車と彼らが持っているもの（空港から32マイル）を空港に返します空港）。それから、彼らは私たちから5マイル離れた場所に2台の車で来て、1台を降ろしてから、他の車で空港に戻ります。私たちが返送した車が私たちの近くに必要な同じ種類の車であっても、彼らはこれを行います。私はこの会社に2年ほど在籍しており、自動車不足の最も極端な緊急事態（これまでに約3回）でのみ、これから逸脱しているように見えます。すべての地域で働く4人を自動化されたスケジューリングシステムに置き換え、どの車がどこに行くかを決定し、必要なすべての車を提供するために最短の時間+マイル+ドライバーが必要な経路を見つけて、より高いレベルの修正の例をいつか追加したいと思っています。
ただし、これをすべて提案する前に、インターフェイスの更新など、より小さなタスクを実行することで、会社とコードベースを理解しておくと役に立ちます。アウトソーシングなどのソリューションは、この可能性を排除します。
自分を技術面に閉じ込める...
まず、アプリケーションが実行される環境を決定することをお勧めします。 「メインフレーム」とは、アプリケーションの年齢が [〜＃〜] cics [〜＃〜] または [〜＃〜] ims [〜＃ 〜] 。また、オリジナルの作成者が独自のスターティッドタスクを作成した可能性もあります。
アプリケーションの実行場所に応じて、その環境でAPIを使用する可能性があります。CICSは interface を使用するようになり、初期とは著しく異なります。IMSについて話すことはできません。アプリケーションが独自のスターティッドタスクである場合、独自の内部APIを備えている可能性があります。私は、同じ時代に書かれたそのような獣をサポートするために約7年間を費やしています。
アプリケーションの古さを考えると、他に考慮すべきことは、C++を統合するアセンブラが Language Environment （LE）の存在を前提としていることです。そのため、アセンブラーがLE準拠に更新されていない限り、CおよびC++はLE準拠であり、呼び出し元と呼び出し先も準拠する必要があるため、問題が発生します。
考慮すべきもう1つのポイントは、このアプリケーションが瀕死のメインフレームで実行されている場合、サポートされていないハードウェアおよびソフトウェアで実行されるアプリケーションと統合しようとしていることです。これは、元のハードウェアのDOS 4.01で実行される1989年に作成されたアプリケーションと統合しようとすることと同じです。
あなたは銃をジャンプしています。あなたの説明から、現在の技術環境を完全に理解していないようです（どのOSが正確か、データがどこにどのように保存されているか、他のシステムへのインターフェースが存在するかなど）。しかし、さらに重要なのは、深刻な計画では、ソフトウェアの部分的または完全な社内書き換えの代替案、つまり、既製のソフトウェア、書き換えの外部委託、サービスとしてのソフトウェアなどを検討する必要があることです。
会社が最終的にどのように進むにせよ、まず、ソフトウェアが今日何をしているか、新しいソリューションの要件をしっかりと分析する必要があります。
それでは、なぜこの分析を行うことを提案しないのですか？
こんな丁寧な返事をいただいてびっくり！
これを彼らの視点から見てみましょう。
彼らは、おそらく数十万行のコードを備えた30年前のシステムの管理に成功し、40年以上に渡って進化したビジネスプロセスを具体化するおそらく他の20のシステムへのインターフェイスを提供します。
彼らはおそらく/願わくばその分野の専門家であり、C++をIBMの「高水準アセンブラー言語」から一歩下がったものと見なして、完全なタイトルを付けます。 IBMのアセンブラー言語は非常に強力であり、「MACRO」言語は前処理/テンプレート言語のこれまでで最高の実装です。
システムが最初に実装されてから約5年ごとにシステムを置き換えるという提案が出されます。一部は実現可能性調査後に却下され、一部は予算を失う前に設計段階に達し、一部はコードに行き、おそらくパフォーマンスの問題にぶつかって缶詰になる前にテスト段階に入ったかもしれない。
C++は単に役に立たないでしょう。アプリケーションが実行される環境にグラフィックスライブラリはありません。 （3270グラフィックライブラリがありますが、誰も使用しないためC++でサポートされる可能性は低く、完全な「X」クライアントライブラリはありますが、使用するには別の環境にいる必要があります。）
彼らは完璧からは程遠いが、よく知られていて高速なユーザーインターフェースを持っています。経験豊富なオペレーターは、同等のGUIではなくグリーンスクリーンを使用すると、フォームの入力が約3倍速くなります。さらに、彼らはタイプに触れる間、顧客に注意を払うことができます。
画面のオペレーターは、使用するインターフェイスに関係なくトレーニングを行う必要があります。新しい馴染みのないGUIを使用するようにすべての従業員を再トレーニングすることは、古い世界のシステムで新しい従業員をトレーニングするだけの場合に比べて、膨大な予算項目になります。
数年前にベルサウスで同様の問題がありました。アセンブラー言語プログラムをバイトごとにスキャンし、オペコードとオペランドを分離し、分岐命令をtoに変換し、比較命令をIFに変換するためのCOBOLコードを単に記述しました。このプログラムは、DC命令を同等のCOBOLデータ部コードに変換し、必要に応じて移動、zapsなどを変換しました。
それが完了したら、IFとGOTOをIF-THENに変換する2つ目のプログラムを作成しました。これらのクラスター間の行に移動などを行いました（これは実際にはそれほど難しくありませんでした。秘密はIFを挿入し、 ELSEは、第1フェーズの「ピジン」コボルを後ろから前へと読み直します）。
IF-THEN-ELSERは、ラベルの近くにGOTO参照が見つかり、安全に削除できる（参照の数を1つ減らす）状況を探しました。この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は「ハイレベルアセンブラ」と見なされることがあります。私はDBMS製品会社で働き、その製品は完全に370アセンブラーでした。私たちの主な設計者は、アセンブラーコードをCに機械翻訳することが可能であると信じていました（将来の移植性のため）。私は懐疑的ですが、重要なのは、距離が思ったほど大きくないことです。
このいずれかが役立つかどうかはわかりません。私が言うように、それは元のコードの品質とサイズに大きく依存していると思います。
これが冗談かどうかはわかりませんが、あなたの会社はもともと39年前に書かれたコードを真剣に実行していますか？システム/ 360で実行している場合は、ソースからg ++をコンパイルする必要があります...
正直なところ、古いコードを使用することすら考えていません。あなたは新鮮なアプローチを取り、座って、デザインに何を入れる必要があるかを考え、それを根本から行う必要があります。はい、かなりの計画が必要になりますが、ジョエルでさえ、これが段階的な変更のケースであるとは思わないでしょう。
切り替える必要がある会社を説得するには、効率を向上させ、コストを削減し、現在使用しているものが何らかの害を及ぼすことを示す特定の理由を指摘する必要があります。現在、一番下の行に。
もう1つのコメント-他のレンタカー会社が21世紀に私たちの残りのメンバーに加わったと思います。私は彼らがどのようにしているかを確認するために少し偵察を行い（Webベース、私は想像します）、おそらくそれらのシステムの1つに基づいてモデル化します（つまり、車輪を再発明しないでください）。
幸運を！
理論的には、メガバックを節約できることを示すことができれば、上級管理職に古いシステムを置き換えるよう説得することは難しくありません。そして、そうなるでしょう。このシステムを維持するプログラマーを見つけるのはますます難しくなり、それらのプログラマーはますます高価になるでしょう。それは「if」の問題ではなく、「いつ」の問題です。本当に更新する必要があります。
ただし、問題は、更新が必要であること（そしておそらくとにかくそれを知っている）だけでなく、社内プロジェクトであることを納得させることができるかどうかです。特にチームがあなただけの場合は。多くの場合、そのような主要な代替品は外部委託されています。検討のために利用可能な市販のソフトウェアさえあるかもしれません。これらのオプションは調査する必要があり、あなたのマネージャーはそれらが賢明である場合に起こると主張します。
タスクについて言えば、この場合、ブルドーズの書き換えが適切であると私は実際に考えています。ジョエルの主張はすべての場合に当てはまるわけではありません。でも、それを見ないとわからない。
段階的な変更は問題外です。
市販のソリューションが利用できる可能性があります。多くのレンタカー会社があります。
最後の手段としてそれを書き直す必要がある場合は、まず新しいシステムがどのように機能するかを考えるのに少し時間を費やしてください。
機能とインターフェイスを特定したら、ニーズ（およびスキル）に最適な開発ツールを選択できます。
エンドユーザーへのストレスを最小限に抑える方法の1つは、醜いニーモニックのドロップダウンリストなどのいくつかの優れた機能を備えた、ユーザーが知っている古い醜いインターフェイスのエミュレーションを開始し、UI機能を徐々に追加して、モダンなUIにそれらを追加することです。
おそらく同じデータファイル形式を維持したくないので、切り替え後は元に戻せません。