4

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

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

更新:プログラムは、ユーティリティ、データ処理、画面などに対してギャミットを実行します。

4

9 に答える 9

8

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

申し訳ありませんが、抵抗できませんでした。

真面目な話、現在のプラットフォーム用の COBOL コンパイラは存在しますが、コードを移植する必要がある理由をもう少し理解しない限り、助けにならないかもしれません。

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

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

  • C.
  • クラスなしの C++
  • Java、ただし、1 つの大きなホンキン シングルトンがない限り、クラスを避けることはできません。
  • Pascal (1 つの「死んだ」言語を別の言語に交換)。
  • Python、Perl などでさえ動作させることができます。
于 2009-04-21T05:26:50.687 に答える
4

さて、COBOL プログラムが通常取得する入力を検討する必要があります。

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

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

于 2009-04-21T05:23:12.663 に答える
2
  • COBOLを移植すべきではないと言わざるを得ません。
    • rewriteを意味する場合は、はい、言語を選択してください。書き直すには、Web インターフェイス、Java または .Net をお勧めします。
    • コードを現在実行しているのとまったく同じように実行する必要がある場合、「移植」変換は害を及ぼすだけです。
  • 何らかの理由でプラットフォームを変更する必要がある場合は、別のプラットフォームで COBOL を使用できます。
  • 私の経験では、コンポーネントまたはサービスを互いに分離し、小さな部分を個別に変換するか、好みの言語で新しいコードを記述して、COBOL をバックエンドで実行したままにすることが最も効果的でした。
于 2012-04-06T22:08:15.460 に答える
2

私は COBOL のことはあまり知りませんが、COBOL の直接のスーパーセットである現在の言語はないと思います (そのため、COBOL を言語に直接マップするのは簡単ではありません)。いくつかの問題があります。

  1. 10 進演算のビルトイン サポート - これにより、演算子のオーバーロードのない最新の言語が除外されます。

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

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

マッピングが容易でないその他の機能が存在する場合があります。

于 2009-04-21T06:20:15.847 に答える
1

私は COBOL コアを保持しますが、エッジを拡張します。

Microfocusは、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 など) で新しい開発を行うことです。

于 2009-04-21T19:38:14.213 に答える
1

私は、現在の実装ではなく、プログラムの意図した設計に基づいて、個人的にこの決定を行います。ただし、単純な行ごとのポートが必要な場合は、おそらく c/c++ と言うでしょう。

于 2009-04-21T05:26:12.063 に答える
1

おそらく、新しい言語をすぐに検討する代わりに、コードの一部を .Net などの最新のフレームワークに移行することを検討できます。完全に独り占めする準備が整うまでは、それが適切な中間ソリューションであることがわかるかもしれません。

富士通のNetCOBOLなど、利用可能な .NET 用の COBOL コンパイラがいくつかあります。

于 2009-04-21T05:28:12.603 に答える
1

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

于 2009-04-21T05:37:52.470 に答える