レガシー・マイグレーションのノウハウ＆ドゥハウ。 計画時サービスからメインサービスまでシステムズの業務をご案内。

　COBOLは仕様が厳密に定義されており、どの計算機でも動作や精度が保障されています。また拡張も世界的な委員会で検討されているため、将来性も充分と考えられます。これらの点から、ＡＰに関しては移行先も現行と同じＣＯＢＯＬを使用する事をお勧めします。また、製作・メンテナンス要員のスキルの観点、性能の観点からもＣＯＢＯＬは有利と考えられます。

　①従来のメインフレームと移行先のオープン機とでは、稼働環境が大きく異なり、実行するユーティリティ等も大きく異なります。このため、事前に運用規則の異なる点を明確にし、変更しておく事が重要です。 　もしまだオープン系の運用規則が出来ていない場合、その製作のお手伝いも弊社がさせて頂きます。 　②言語としてのＪＣＬのマイグレーションは左程複雑では無いのですが、それにより起動するユーティリティは多数存在し、それらのパラメータは各々異なるため、ＪＣＬのマイグレーションは非常に複雑かつ煩雑となります。その解決策として、弊社は先に述べたようにマイグレーションに関する特許を有しており、 そのパターン化技術により現状使用しているユーティリティを明確化する事により、お客様にフィットした　ＪＣＬコンバータを適用する事が可能となっています。

　残念な事に分散機では構造型のＤＢＭＳは使用出来ず、リレーショナル型（ＲＤＢ）に移行しなくてはなりません。このため、ＤＢ構造、アクセス命令、制御エリア、制御コード等、関連する総ての命令のマイグレーションが必要となります。 弊社は今迄のマイグレーションの経験を生かして、高効率、高品質にＲＤＢ移行を実現します。更に弊社のＲＤＢへの移行方策では、最も懸念される性能劣化も防ぐ事が可能となっています。

　従来のホスト機はＥＢＣＩＤＩＣ（数字＞英字）で、オープン機はＡＳＣＩＩ（その逆の数字＜英字）の文字コードを使い、その順に出力されます。
　 帳票を出力するためのソート処理では、文字の大小をパラメータにより変更する事が出来るため従来のホスト機と同じ出力順とする事が可能となっています。
　しかしながら、移行先のオープン機環境の中では、ＡＳＣＩＩの順が一般的で普通であるため、将来方向を考えると今回の移行のタイミングで、ＡＳＣＩＩの順にし、慣れておく事が良いと思われます。

　①オープン機側には色々のオンライン制御システムが存在するため、それに見合ったマイグレーションが必要になります。弊社は豊富なマイグレーション経験により、お客様の選択した制御システムに最適なマイグレーションを実施する事が出来ます。
　 ②画面定義Ｔｏｏｌが現行機と異なるため、画面定義により生成された論理マップ（ＣＯＰＹ）のネーミングルールが異なります。このため、オンラインＡＰプログラムの画面インターフェースアリアのデータ名が異なる事になり、殆どの処理命令の書き換えが必要になります。弊社のマイグレーションＴｏｏｌではこれらのデータ名変換を自動化する事により、高効率・高品質を実現しています。