.NET COBOL に移行する際の考慮事項

既存のアプリケーションで .NET COBOL を使用する前に、検討が必要な事項がいくつかあります。現在のアプリケーションの構造およびビルド方法を分析し、どのような変更が必要かを判断する必要があります。

.NET COBOL へのアプリケーションの移行についてサポートが必要な場合は、Micro Focus Professional Services にお問い合わせください。

検討が必要な項目の一部を次に示します。

元のアプリケーションの複雑さ

.NET COBOL に簡単に移行できるかどうかについては、アプリケーションの複雑さ (プログラムの数やプログラム間の相互接続など) とネイティブのコンパイル方法が大きく影響します。次のような要因があります。

  • アプリケーション内のプログラムの数。たとえば、アプリケーションに非常に多く (数万など) の COBOL プログラムが含まれており、それらがすべて .int/.gnt コードとしてコンパイルされている場合があります。このアプリケーションを .NET COBOL に移行する場合、プログラムを .exe または .dll としてコンパイルしてから、アプリケーションを .NET COBOL コード用にパッケージ化する最適な方法を決める必要があります。
  • メインフレームやネイティブ COBOL では、多数の絡み合ったプログラムも正常にコンパイルできます。それらを .NET COBOL として正常にコンパイルして実行するには、書き換えが必要になる場合があります。これは、生成される .NET COBOL コードの基になるモデルはオブジェクト指向であり、クラスおよびメソッドが生成されるためです。.NET では、実行セクションの外部への GO TO 文を使用するアプリケーションでスタック オーバーフローが発生する可能性があります。
  • Micro Focus のネイティブのオブジェクト指向クラス ライブラリを使用するアプリケーションは、.NET COBOL に再コンパイルできません。これらのアプリケーションについては、代わりに .NET Framework を使用するように書き換える必要があります。

元のネイティブ アプリケーションのビルド方法

元のネイティブ COBOL アプリケーションにおいて、コマンド ラインで実行されるバッチ スクリプトをコンパイルに使用している場合があります。そのようなアプリケーションのコンパイル方法を変更する場合、コードをコンパイルするために新しい改善された手順の適用が必要になることがあります。

この変更は、バッチ スクリプトで特定のディレクトリ構造に実行可能ファイルを配置する場合にも必要になる可能性があります。

プログラミングの新しい技術の知識およびスキル

.NET COBOL に移行するにあたり、アプリケーションを適切に保守するのに役立つスキルへの投資が必要になることがあります。次に例を示します。

  • Microsoft Azure のクラウド コンピューティングを利用するには、Visual Studio Azure プロジェクトの構造および Azure へのディプロイ方法に関する知識が必要になります。Visual Studio のチュートリアルを参照してください。
  • COBOL アプリケーションを WCF Web サービスとして公開するには、サービスの作成方法とディプロイ方法、およびクライアントの作成方法に関する知識が必要になります。Visual Studio のチュートリアルを参照してください。
  • .NET Core を使用すると、.NET Core がサポートする任意のオペレーティング システムにアプリケーションをディプロイできます。
  • コンテナーおよび Docker - コンテナー化の知識と Docker でのアプリケーションの開発、ディプロイ、および実行に関する知識が必要になります。「モダン開発プラクティス」を参照してください。
  • 継続的インテグレーションには、自動化のテストを含む、同じアプリケーション ベースで作業するチームのための一連のソフトウェア開発プラクティスが含まれます。「モダン開発プラクティス」を参照してください。

ディプロイおよびライセンス

.NET COBOL コードでは、これらの扱いが異なります。アプリケーションをパッケージ化して .NET でディプロイする方法を理解する必要があります。

データベース サポート

SQL(DBMAN=ADO) 指令で OpenESQL を使用して、.NET COBOL アプリケーションをコンパイルできます。Micro Focus では、OpenESQL ネイティブ コードとマネージ コードのランタイム システム間で可能な限りソース コードの互換性が維持されるよう努めています。各ランタイム システムには、基盤となるデータベース API および実行環境に基づく拡張、制限、および相違がありますが、埋め込み SQL 文 (DECLARE CURSOR、OPEN、FETCH、CLOSE、SELECT、INSERT、UPDATE、DELETE、CONNECT、DISCONNECT、COMMIT、ROLLBACK など) の大部分は完全に互換性があり、変更は必要ありません。

ADO.NET ランタイム システムには、EXEC ADO 文を使用したオフラインの DataSet および DataTable をサポートする拡張機能があります。また、オブジェクト ホスト変数および従来の COBOL ホスト変数をサポートしています。

次の制約事項は、.NET COBOL コードにおけるデータベース サポートに適用されます。

  • Oracle は、Pro*COBOL を使用した .NET COBOL コードはサポートしていません。

    対策として、OpenESQL SQL 指令 (DBMAN=ADO TARGETDB=ORACLE PROCOB) を使用して .NET COBOL コードに移行します。詳細については、「データベース アクセス」で該当する SQL 指令を参照してください。

  • OpenESQL に移行する前に、Pro*COBOL 指令 MODE=ANSI および FIPS でコンパイルして、.NET COBOL コードでサポートされていない非 ANSI 規格の構文がコードに含まれるかどうかを確認する必要があります。また、一部の Oracle 拡張機能は OpenESQL によってサポートされている場合がありますが、その他は修正が必要になることがあります。
  • 一部の PL/SQL 文およびブロックは機能する可能性がありますが、.NET COBOL コードに PL/SQL サポートはありません。
  • ストアド プロシージャ呼び出しから出力パラメーターを使用するアプリケーションは、COBOL 指令 NOILNATIVE を使用する必要があります。オブジェクト ホスト変数は、ストアド プロシージャ呼び出しで出力パラメーターには使用できません。
  • ロックを行うペシミスティック同時実行は、Microsoft SQL Server 以外のデータベースの ADO ではサポートされていません。代わりにランタイム システムが、オプティミスティック同時実行の代替となります。

Dialog System アプリケーション

.NET COBOL コードは、Enterprise Developer for Visual Studio 2017 を通して Dialog System アプリケーションをモダナイズする優れた方法です。最初のステップとして、Enterprise Developer でアプリケーションをインポートし、それを新しい IDE でビルドおよび実行できます。次に、アプリケーションを徐々にモダナイズしていくことができます。たとえば、ある Dialog System スクリーンを Windows Form に置き換えたり、.NET ユーザー コントロールを ActiveX としてラップし、それを Dialog System で使用したりすることができます。一方、残りのコードは変更しないまま保持できます。モダナイゼーションのさまざまな技法の詳細については、「Dialog System アプリケーションのモダナイズ」を参照してください。

ライブラリ ルーチン

特定のライブラリ ルーチンは、ネイティブ コードでのみサポートされています。.NET COBOL コードで使用できるルーチンの詳細については、本ドキュメントの「ライブラリ ルーチン」セクションを参照してください。

ネイティブ コードおよび .NET COBOL コード

ネイティブ コードは .NET COBOL コードから呼び出すことができますが、禁止されている環境もあります。たとえば、.NET ストアド プロシージャおよび特定の Java アプリケーション サービスから、ネイティブ COBOL を呼び出すことはできません

同じアプリケーションでのネイティブ コードと .NET COBOL コードの使用は、特にコードをデバッグして .NET でディプロイする際に、いくつかの点で制限される可能性があります。

ユーザー インターフェイスのモダナイゼーション

Enterprise Developer は、アプリケーションのユーザー インターフェイスをモダナイズするための優れたオプションを提供します。.NET の Windows フォームまたは Windows Presentation Foundation を使用できます。アプリケーション アーキテクチャ、および元のユーザー インターフェイスとバックエンド モジュールの関連付けの強さによっては、問題が発生する可能性がある点に注意してください。

オブジェクト指向プログラミング

.NET フレームワークなどのマネージ環境でコンパイルおよび実行される、手続き型 COBOL を作成して使用できます。ただし、マネージ環境で利用可能なすべての機能を最大限に活用し、コードを他のマネージ言語に公開できるようにするには、.NET COBOL 構文の使用が必要になる場合があります。.NET COBOL コードの作成については、次のリソースを参照してください。

  • Micro Focus SupportLine Documentation Web siteで閲覧可能な『COBOL 開発者向けのオブジェクト指向プログラミング入門』。
  • Enterprise Developer とともにインストールされる [Visual COBOL Samples] サンプル ブラウザーの [Moving to .NET] セクションに含まれるサンプルを確認してください。
  • Microsoft の MSDN の .NET プログラミングに関する大量のリソース、および Java Web サイト上の Java の例も参照できます。

サード パーティ製ソフトウェア

オペレーティング システムを呼び出すサード パーティ API に対する、既存の手続き型 COBOL コードを確認してください。他のソフトウェア ベンダーによって提供される技術は、.NET COBOL コードでの利用向けに書き替える必要がある場合があります。

Win32 API ルーチン

Win32 API ルーチンは、.NET COBOL コードではサポートされていません。手続き型コードを .NET COBOL に移行する場合、意図した結果を得るには、Win32 API ルーチンの呼び出しを削除し、同等の .NET 機能を代わりに使用する必要があります。