①弊社はマイグレーションに関し特許を有しております。その特許とは、お客様の現状のソース類（ＣＯＢＯＬ、　ＪＣＬ等）を解析工程でパターン化し、その抽出したパターンについてＴｏｏｌ等を製作して行くと言う物です。これにより、Ｔｏｏｌもお客様にフィットした物になりますし、テストにおいても漏れが無くなり、効率が上がると共に品質も向上します。

②マイグレーション品質の向上にはＴｏｏｌの整備が特に重要です。弊社は豊富なマイグレーション経験から総合的にＴｏｏｌ整備を進め、①ソースプログラム変換（オン・バッチ）、②ＪＣＬ変換、③画面定義変換、④ソフト書式変換、⑤ＤＢ定義変換と、お客様の総ての定義体の自動変換を行う事が可能となっています。

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

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

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

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

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

移行前の環境によってシフトコードの意味合いが違います。

• 日立、富士通の場合はデータの前後に２バイトずつ
• IBMは1バイトずつ
• NEC、東芝はシフトコード自体がありません

また、フィールド属性を日本語（2バイト文字）とすることにより、シフトコードがない場合もあります。このケースはデータ移行ツールなどを使用しアスキーへ変換後IBM漢字へ変換する必要があります。
いずれにしても、プログラム中で使用されている2バイト文字とデータにて使用されている場合とでは移行方法が変わり、当然結果も変わってきます。

いずれの場合もどこに外字が使用されているのかまず調査を行う必要があります。

• 使用しない場合でも、常用漢字に変更する必要があります。
• 新規に作成する場合でも、メーカーによっては第二水準に存在する可能性があり、その時は新規に作成する必要はありません。その上で前項の作業を実施する必要があります。
• 移行ツールを作成する場合は、移行前後の動作環境に依存します。外字のビットマップの分析が可能なのか、どこにマップを持つのか、どこの領域を使用するのかを検討の上、前2項の作業後、移行ツールの機能を判断し作成する必要があります。

基本的に現在のフィールド属性と互換があれば、レイアウトの変更は行いません。 ただし、階層の深さにより親キーが付加される場合があります。あらかじめご了承ください。
また、項番1のシフトコードの影響でシフトコード分フィールド長が長くなる可能性があります。

外部I/Oモジュールを使用している場合は、同等機能を持つモジュールを新規に作成して対応します。
可能な限りお客様のご希望に応じますので、お気軽にご相談ください。

UDB/400（Universal Database 400）に移行します。
このDBへは通常のREAD/WRITEの他、SQLでもアクセすることが可能です。

基本的には、データ移行ツールをファイルごとに作成し移行することになります。
また、2バイト文字のデータの移行については「1. 文字コード（2バイト文字）の移行方法」も参考にしてください。 作業に取り組む前に緻密な調査・分析を行い、移行設計を行うことで隠れているリスクを明確にし、さらに精度の高いマイグレーションを行うことができます。より具体的な内容については直接お問い合わせください。

CL（Control Language）というコンパイル言語へ移行します。
分析ツールを使用して命令語ごとにJCLコードをパターン化し、さらに各パターンとその出現回数を分析します。この分析結果を基に未対応パターンを変換ツールへカスタマイズすることにより、高い変換率を実現します。

次の方法が考えられます。

• サブルーチンとして移行する方法
• 展開した形で移行する方法

ユーティリティの機能を確認の上、必要と判断したものに関してはコマンドへの変換または代替モジュールを作成し移行します。その都度、最適と考えられるご提案をさせていただきます。どうぞご安心ください。

通常、マイグレーションはストレートコンバージョンを基本としています。
従いまして、JCL中に存在するソート機能は同等の機能を有するソートへ移行します。そのため二次インデックスなどを作成した論理ファイルやビューなどへの変換はマイグレーション時には行いません。
マイグレーション実施後、改めて環境の整理などを行い改善をすることをお勧めします。

メインフレーム上のAdabasで構築されたシステムの対象資産の調査や利用状況の把握、資産棚卸、資産可視化の実施、移行対象の明確化を図り、移行計画の策定から実施・テスト支援を行います。

現在稼働中のメインフレーム上で、Adabasを他のRDBに移行する、旧システムからAdabasだけを新システムに移行する、Adabasを含むシステム全体のオープン化へのマイグレーションを実施する、など、あらゆる移行方式に対応します。お客様のご要望や方針に沿った移行案と実施計画を策定しています。

現行のAdabas資産の調査結果と移行の留意点を勘案し、最適に移行方式(案)をご提案します。

システム全体の資産の見える化の視点から、移行対象資産、課題、移行方針、見積資産を明確化するための、「マイグレーション移行性検証」の実施をお奨めしています。

Adabasは、繰返し項目の設定を可能にしていますが、一般的なRDBは不可能、すなわち、ネストを許しません。そのため、移行にあたっては、該当する項目を別テーブルに分割することでこの問題を解決しています。ただし、繰返し項目の繰返し数が少ない場合は1つのテーブル内で実現することもあり、テーブル分析・検証結果に基づいて対応を判断しています。このほかにも、ハードウェア環境では、ディスクの使用量やパフォーマンス、RDB定義の面ではハイパーディスクリプタやサブディスクリプタ、サブ・スーパーフィールドなどの差異に留意して移行を進める必要があります。システムズのマイグレーションサービスは、こうした非互換問題やデータ移行の際の技術課題に対応した移行を行います。

以前はそういう話も聞かれましたが、ハードウェア性能の進歩やメモリ容量の増大、マイグレーション技術自体の進化などにより、問題点は解消され、そうした心配なく移行いただけます。

DBアプリケーションの非互換問題などの問題も考慮せねばなないNaturalマイグレーションには、信頼性が高く効率的な移行技術が求められます。システムズでは、長年のマイグレーションの現場で経験した異言語マイグレーションのノウハウをもとに、Naturalで開発されたプログラム資産も確実にオープンCOBOLへ移行します。