COBOL プログラムをどの言語に移植しますか?その理由は何ですか?

StackOverflow https://stackoverflow.com/questions/771136

質問

COBOL プログラムを移植する言語を選択する場合、どの言語を選択しますか?またその理由は何ですか?私は「言語 X に精通しているから」という答えを探しているわけではありません。

COBOL の設計によく対応する言語の機能を探しています。

アップデート： プログラムは、ユーティリティ、データ処理、画面などの機能を実行します。

役に立ちましたか？

解決

私はそれらを...に移植します。うーん...コボル。はい、それだけです。コボル。

ごめんなさい、我慢できませんでした。

真面目な話、現在のプラットフォーム用の COBOL コンパイラは存在しますが、そのコードがなぜそうなるのかをもう少し詳しく知らない限り、 もっている 移植される場合、私たちはお手伝いできないかもしれません。

実行されているプラ​​ットフォームは時代遅れですか?経営陣は単に、より「現代的な」ソリューションを推進しているだけなのでしょうか？System z から Windows に何かを移動する必要がありますか (ああ!)。

COBOL (OO-COBOL のゴミではなく、最も純粋な形式) は、ほとんどが単純な手続き型言語 (ReportWriter にもかかわらず) であるため、他の手続き型言語にかなり適切に変換できます。

  • C.
  • クラスのない C++
  • Java ですが、大きなシングルトンがない限りクラスを避けることはできません。
  • パスカル (「死んだ」言語を別の言語に置き換える)。
  • Python、Perl などでも動作させることができます。

他のヒント

COBOL プログラムが通常どのような入力を取得するかを考慮する必要があります。

COBOL は、大量の固定幅形式のテキストを入力として処理し、ほぼ同じ方法で出力するように設計されています。私にとって、これは他の何よりも ETL プロセスのように思えます。

したがって、私は COBOL プログラムを単に別の言語に移植するつもりはありません。これを SQL Server Integration Services (SSIS) や、少なくともその前身である DTS (SQL Data Transformation Services) などの適切な ETL テクノロジに移植すると思います。SSIS は VB.NET (少なくとも SQL Server 2005 では) の使用を意味しますが、それは問題にはなりません。

私は COBOL についてはあまり詳しくありませんが、COBOL の直接のスーパーセットである現在の言語は存在しないと思います (したがって、COBOL を言語に直接マッピングするのは簡単ではありません)。いくつかの問題が見つかりました。

  1. 10 進算術の組み込みサポート - これにより、演算子のオーバーロードを行わない最新の言語が除外されます。

  2. 構造化レコードのサポートの改善 - C のように構造体と共用体の組み合わせを使用することもできますが、識別子が非常に長くなる場合があると思います (少なくとも私が見たプログラムでは)。

  3. Goto ステートメント - これがないと、プログラムを書き直すときにプログラムのロジックを完全に分析する必要があります。

マッピングするのが難しい他のフィーチャがある可能性があります。

私は個人的に、現在の実装ではなく、プログラムの意図された設計に基づいてこの決定を行います。ただし、行ごとに直接移植したい場合は、おそらく c/c++ を使用すると思います。

おそらく、すぐに新しい言語を検討するのではなく、コードの一部を .Net などの最新のフレームワークに移行することを検討してもよいでしょう。本格的に取り組む準備が整うまで、それが優れた中間ソリューションであることがわかるかもしれません。

Fujitsu のような .NET 用の Cobol コンパイラがいくつか利用可能です。 ネットCOBOL.

私はかつて、いくつかの COBOL のものを C に移植することに携わっていました (1989 年頃)。問題の COBOL は、盗難警報器や火災警報器などを監視するためのコードでした。よりリアルタイムな環境に適したプログラムでした。これらの数十億の顧客フィールド デバイスを 1 分あたり何回もポーリングします。「COBOL の設計によく対応する言語の機能を探す」ことは、COBOL の設計を無視する COBOL プログラムが世の中にたくさんあるという事実を無視することになります。

私なら COBOL コアは維持しますが、エッジの周りを拡張します。

マイクロフォーカス COBOL が Web サービスと対話できるようにする Enterprise Server と呼ばれるツールを提供します。

COBOL プログラム A と別の COBOL プログラム B があり、A がインターフェイス セクション経由で B を呼び出す場合、このツールを使用すると、B のインターフェイス セクションを Web サービスとして公開できます。

プログラム A の場合、クライアント プロキシを生成すると、A は Web サービス経由で B を呼び出すことができるようになります。

もちろん、B には Web サービスがあるため、他の種類のプログラム (コマンド ライン、Windows アプリケーション、Java、ASP など) もそれを呼び出すことができます。

また、Visual Studio 内で実行され、COBOL を MSIL に変換する COBOL.NET と呼ばれる製品もあります。これは、任意の .NET コンポーネントにリンクできることを意味します。

したがって、アプローチは、COBOL コアを維持しながら、Web サービス経由でインターフェイスし、CLR 準拠の言語 (C#、VB など) で新しい開発を行うことです。

  • COBOL を移植すべきではないと言わざるを得ません。
    • つまり リライト, 次に、はい、言語を選択します。Web インターフェイス (Java または .Net) を書き換えることをお勧めします。
    • コードを実行する必要がある場合 その通り 現在実行されているように、「移植」変換は害を及ぼすだけです。
  • 何らかの理由でプラットフォームを変更する必要がある場合は、別のプラットフォームで COBOL を使用できます。
  • 私の経験上最もうまくいったのは、コンポーネントやサービスを互いに分離し、小さな部分を個別に変換するか、または単に新しいコードを好みの言語で記述して、バックエンドで COBOL を実行し続けることです。

まず最初に考えなければならないのは、なぜ COBOL を移植する必要があるのか​​ということです。COBOL は古くからある強力な言語であり、給与計算や会計処理などを実行するコード行がまだ残っている可能性が高いです。本番環境では他のどの言語よりも優れています。

最も痛みが少ないポートは Synergy DBL です。これは、DIBOL (Digital Business Oriented Language) の移植性の高い VM スタイルのアップデートです。

http://www.synergex.com/synergy-dbl/

DIBOL は、BASIC、FORTRAN、COBOL の優れた部分をすべて使用し、悪い部分のほとんどを取り除きました。

上記のリンクをたどると、GUI、.NET、その他の拡張ツールがあることがわかります。実行するターゲット OS に応じた VM が存在することを確認してください。

CICS、TCAM、IDMS などを多用する IBM メインフレーム COBOL。他のものへの移植は非常に困難になるでしょう。

DECForms や場合によっては FMS を利用する OpenVMS COBOL は、画面処理パッケージがなければ移植が困難になります。これらのショップの非常に古い COBOL は、他のほとんどのプラットフォームでは利用できない、OS によって提供されるシステム サービスとランタイム ライブラリ ルーチンを多用します。また、論理を読んで、ターゲットにある程度近いものを実装する方法を理解する必要もあります。

ほとんどのメインフレームおよびミッドレンジ COBOL では、COBOL だけを移植しているわけではないことがわかります。古い COBOL が利用していたシステム サービスが大量に存在することになります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top