COBOL資産をオープン環境へ移行するための方法論

WHITE PAPER
COBOL資産をオープン環境へ
移行するための方法論
COBOL 資産のオープン環境移行の方法論
はじめに
企業情報システム再構築の必要性が高まる中、汎用機・オフコンから UNIX・
PC サーバーなどのオープンシステムへのダウンサイジング事例が増えていま
す。このホワイトペーパーでは、ダウンサイジングを進めて行く上での留意
点と現在利用可能な技術について概観します。まず、再構築によって何が得
られるのか、進めて行く上での方法論・工程にはどのようなものがあるのか
を述べ、次いで、再構築の第 1 段階である既存システムの理解と分析をどの
ように行うかを、リエンジニアルングツールの実際例を通して解説します。
ダウンサイジングを効率的に進めるためには、既存コードをいかに再利用で
きるかがポイントとなります。続く章では、コード再利用に伴う問題点を分
類・整理し、そのそれぞれについての解決方法を述べます。最後に、IBM メ
インフレームから UNIX へ基幹業務をダウンサイジングした生命保険会社の
事例をとりあげ、そこから学ぶべき事柄を述べます。
2002 年
1 月 10 日
Ver 1.00
© 2001 Micro Focus International. All rights reserved. その他の商標は、所有各社の登録商標また
は商標です。
COBOL 資産のオープン環境移行の方法論
目次
情報システム再構築の背景と方法論
なぜ再構築が必要か
システム再構築の方法論
既存システムの理解と分析
何を理解・分析するか
ツールの活用事例 - M ICRO FOCUS REVOLVE
既存システム再利用のポイント
再利用方法の概要
COBOL プログラム移植での問題点
COBOL コンパイラの互換性オプション
ソースコードの自動変換
COBOL 以外の問題点の対応
環境に依存する移行上の問題点
COBOL 以外の言語
データベースアクセス
バッチジョブ
ダウンサイジング事例
まとめ
MI C R O
FO C U S
COBOL 資産のオープン環境移行の方法論
企業情報システム再構築の必要性が高まる中、汎用機・オフコンから UNIX・
PC サーバーなどのオープンシステムへのダウンサイジング事例が増えてい
ます。このホワイトペーパーでは、ダウンサイジングを進めて行く上での留
意点と現在利用可能な技術について概観します。まず、再構築によって何が
得られるのか、進めて行く上での方法論・工程にはどのようなものがあるの
かを述べ、次いで、再構築の第 1 段階である既存システムの理解と分析をど
のように行うかを、リエンジニアルングツールの実際例を通して解説します。
ダウンサイジングを効率的に進めるためには、既存コードをいかに再利用で
きるかがポイントとなります。続く章では、コード再利用に伴う問題点を分
類・整理し、そのそれぞれについての解決方法を述べます。最後に、IBM メ
インフレームから UNIX へ基幹業務をダウンサイジングした生命保険会社の
事例をとりあげ、そこから学ぶべき事柄を述べます。
情報システム再構築の背景と方法論
本ホワイトペーパーの冒頭に当たって、既存 COBOL 資産をオープン環境へ
移行することの必要性を概観し、そのための方法論・工程についてハイレベ
ルなポイントを整理します。
なぜシステム再構築が必要か
ここではなぜ企業はシステム再構築を行わなければならないのか、システム
再構築をした結果えられるメリットは何なのかを概説します。
(1) システムの保守性を高める
昨今の社会・産業構造の急激な変化に伴い、ビジネスのやり方を絶え間無く
変えて行くことが、企業にとって競合に勝ち抜き存続して行くための必須条
件となっています。これに伴い、企業情報システムも、堅固さを保ちながら
同時に変化にすばやく対応できる柔軟性を求められるようになってきました。
大企業では、20 年、30 年前に開発されたシステムが現在も稼動していること
があり、このようなシステムは長年の保守による変更の積み重ねのために、
きわめて柔軟性の低いものになっている場合があります。企業が多大なコス
トを費やして、抜本的なシステム再構築を行わなければならないと決断する
理由の第一はここにあります。
このような理由によるシステム再構築では、ERP の導入が多く見られます。
パッケージ導入によるシステム再構築では、以下の点が達成されるのかを十
分に確認する必要があります：
ú
他社との競合力を実現するような特殊性のあるカスタム化ができるのか
ú
一旦カスタム化して導入したものを、導入後に容易に再カスタム化でき
るのか
3
COBOL 資産のオープン環境移行の方法論
(2) ダウンサイジングによるコスト削減
システム再構築を行う第 2 の理由はコスト削減です。
汎用機の開発・保守コスト、運用コストが、努力して削減することが非常に
難しいのに対して、オープンシステムの世界でのハードウェアの価格性能比
の向上スピードはめざましいものがあります。一旦初期コストを費やしてオ
ープンシステムへダウンサイジングしてしまえば、以後 10 年のレンジでのコ
スト削減効果はきわめて大きなものになると期待されています。
この場合の付帯効果として、次のようなことも良く挙げられます：
ú
基幹系と情報系を統合できる
ú
OA 環境と連携できる
ú
アウトソーシングしている運用をインハウス化できる
このほか、ターゲット環境としての汎用機はそのまま存続させるが、システ
ムの開発・保守を PC を使って効率化して行こうという試みも多く見られま
す。
Micro Focus COBOL および Micro Focus Revolve は、
Windows 上で稼動し、
IBM メインフレームの COBOL ソースプログラムや JCL などを対象として、
クロス開発・保守を可能にするツールとして大きな実績を持っています。こ
れについては、後の章でより詳しく解説します。
(3) 旧環境がサポートされなくなる
汎用機のメーカーが、機種や OS のバージョンのサポートを停止するのに伴
って、オープン環境へ移行するという例も多くあります。このような消極的
なダウンサイジングの場合は、情報システムの機能に付加価値を与えること
よりも、低コストで移行できることのほうが重要になります。
一時期、システムの西暦 2000 年対応に伴って、ダウンサイジングの計画を推
進した企業も多くありました。これも、このような消極的ダウンサイジング
の一形態と考えられます。
システム再構築の方法論
システム再構築は、基本的には次のステップで実行されます：
MI C R O
FO C U S
1.
既存システムを物理レベルから論理レベルへリバースエンジニアリング
する
2.
論理レベルで再設計する
3.
新しい論理レベルを物理レベルへ再実装する。
4
COBOL 資産のオープン環境移行の方法論
対象システムが巨大な場合には、各ステップにおいて詳細な計画・チェック
ポイントの立案・ツールによる自動化が必要になってきます。
コンサルティングファームが提供しているシステム開発方法論の中には、再
構築に特化した機能をもっているものがあり、システム再構築のための細分
化された工程と、各工程における良く定義された入出力情報とチェックリス
トを提供しています。
l
James Martin & Co. 社の TSRM
James Martin & Co.社のシステム再構築方法論「 TSRM 」は、さまざまなリエ
ンジニアリング技術を適用することによって、メンテナンス・最新技術への
移行・既存システムの置換作業を合理的に行うための手段を提供することを
目的としています。
具体的には、情報システム部門内でのシステム再構築の運営、評価、メトリ
クスのガイドラインを企業の実情に合わせてカスタム化して提供する形をと
ります。基本的な工程は、以下の４つのステージからなっています：
MI C R O
FO C U S
1.
エンタープライズ再構築計画 - エンタープライズ・レベルでのシステム
再構築計画を立案する。
2.
情報資産の分析／評価 - システム再構築にかかるコスト・時間・リスク
をつかみ意思決定するための既存システム資産の分析／評価を行う。
3.
ポジショニング - 現行の機能やアーキテクチャに影響を与えずに、既存
システムの品質を改善する。
4.
移行のためのモデリング - 現行と目標のアプリケーションをトップダ
ウンとボトムアップの両アプローチを使用して分析し、目標のビジネ
ス・モデルを作成する。
5
COBOL 資産のオープン環境移行の方法論
既存システムの理解と分析
本章では、システム再構築の第 1 ステップである、既存システムの理解・分
析の目的と進め方を概説します。特にこのフェーズで活用できるツールにつ
いてやや詳しく述べます。
何を理解・分析するか
このフェーズで行われる作業は、具体的には以下のことを目的としています：
(1) システム資産の要約分析
棚卸し分析、ポートフォリオ分析などとも呼ばれます。再構築の対象である
システム全体の、規模、複雑度を把握し、同時に不要な資産を切り分けてお
くことにより、再構築プロジェクト全体の工数見積もりや要員計画の基礎資
料を得ます。
また、再構築を行ったことによる効果を定量化するためにも、再構築前のシ
ステムのメトリクスを得ておく必要があります。
具体的には以下のようなものを抽出します：
•
サブシステムへの分割、共通 COPY、サブルーチンの切り分け
•
ステップ数カウント
•
McClure 法、McCabe 法などによる複雑度メトリクスの計数
•
ファンクションポイント法による計数
(2) データ設計の再文書化
資産の要約分析は計画フェーズで利用されるハイレベルな情報を得るための
ものです。これに対して、実際の作り変え作業で必要となる情報は、データ
ベース設計とビジネスロジックを論理レベルへ抽象化することです。
VSAM、階層型 DB、関係 DB のそれぞれについて、 DDL（データ定義言語）
のソースから論理構造を抽出する、リバースエンジニアリングツールが各種
存在します。
また、特定のデータベースフィールドの使用箇所をシステム全体から漏れな
く抽出するクロス参照機能も、ツールの効果が発揮されるものです。
(3) ロジックの再文書化
データ構造の把握と並んで必要な解析は、ソースコードやジョブ管理言語か
ら、モジュール・バッチジョブの論理構造を抽出する作業です。
ここでも、さまざまなリバースエンジニアリングツールが市場に存在し、そ
れぞれ特徴を持っています。出力できる情報には以下のようなものがありま
す：
MI C R O
FO C U S
6
COBOL 資産のオープン環境移行の方法論
•
ジョブフロー図
•
プログラムの呼び出し関係
•
特定サブルーチンのクロス参照
•
１プログラム内の手続き関連図
(4) 移行での問題個所の抽出
情報システムへの付加価値の追加を主目的としない、ストレートなダウンサ
イジングの場合は、既存システムを理解することよりも、以下に理解するこ
となくコンバージョンを行うかが重要になってきます。
このような場合、ソースプログラム中で、移行に伴って修正が必要な個所の
分布・一覧を得ておくことが有益です。このような個所には例えば、以下の
ものがあります：
•
移行元環境に特有なミドルウェアの使用個所
•
アセンブラサブルーチンの呼び出し個所
•
特殊なマクロの使用個所
リバースエンジニアリングツールの提供するクロス参照機能を使用して、こ
のような情報を取得することができます。
ツールの活用事例 - Micro Focus Revolve
前節では、既存システムから抽出する情報で、システム再構築で必要となる
ものを挙げました。この工程ではツールによる自動化が大きな効果を発揮し
ます。
ここでは一例として、Micro Focus Revolve をとりあげ、どのような情報を自
動生成できるかを解説します。
Revolve は、保守作業を支援する目的で開発されたリエンジニアリングツール
であり、以下のような作業の流れの全てに渡って、使いやすく強力な機能を
提供しています。
Revolve がサポートする環境は IBM メインフレームが中心で、CICS、IMS の
DB/DC をフルサポートしています。しかし、その他の汎用機でも、 COBOL
MI C R O
FO C U S
7
COBOL 資産のオープン環境移行の方法論
言語の方言はかなりの部分をサポートしており、JCL も IBM と互換性のある、
富士通・日立環境であれば同様に利用できます。
(1) 棚卸し分析
Revolve は PC にダウンロードしたソースを読み込んで解析し、リポジトリを
構築します。この過程で、自動的に不足している COPY メンバーを洗い出し、
プログラム中の未定義の変数を示し、プログラムと COPY メンバーのバージ
ョン不整合を指摘します。
Revolve を使用してソース資産の棚卸しを行う場合、まず、汎用機上にあるソ
ースライブラリ内の全メンバーを PC へダウンロードしておき、ここから出
発して不要資産や不足メンバーの調査を行うことが推奨されます。例えば、
一群の JCL だけを指定して、そこから Revolve にリポジトリ構築をさせる
ことによって、指定されたバッチジョブから呼び出されているプログラム、
そのプログラムが使用している COPY メンバー、サブルーチンなどを自動的
に探索し、プロジェクトを完成させようとします。自動探索の結果見つから
なかったソースメンバーは、不足しているファイルとして報告します。
このように、Revolve を使用して時間をかけずに正確な資産の棚卸しを得るこ
とができます。
(2) 統計情報の取得
一旦 Revolve のリポジトリを作製すると、そこから以下のような統計情報を
取得することができます。これらは、移行工数の試算に利用できる指標を提
供します。
•
行数カウント
COPY 展開前の物理行数と、 COPY 展開後の論理行数の両方を一括し
て計算します。
•
McClure 法、McCabe 法などによる複雑度メトリクスの計数
ソフトウェア工学によって提唱されている、各種のメトリクスを自動
算出します。これによって、単なる行数カウントより精密な工数試算
が可能になると言われています。
•
ファンクションポイント法による計数
Revolve は International Function Point Users Group (IFPUG) の 3.4 フ
ァンクションポイント分析定義に準拠した方法で、リポジトリ中の
COBOL プログラムから、ポイントを計算します。なお、 IFPUG 自身
が表明しているように、厳密にはプログラムのソースプログラムだけ
から得られる情報ではポイントの計算は不可能ですので、ここで取得
される値は参考値になります。
MI C R O
FO C U S
8
COBOL 資産のオープン環境移行の方法論
Description
Low Average
High
Total
External Inputs
5
3
1
33
External Outputs
6
2
1
41
External Inquiries
0
0
0
Internal Logical Files
0
5
0
0
35
External Interface Files 4
1
0
27
Total Degree of Influence = 0
Adjustment Factor = 0.65 + (0.01 * 0) = 0.65
Final Function Point Count = 136 * 0.65 = 88.40
Revolve によるファンクションポイント算出例
(3) データ設計のリバース
Revolve には、データ設計の論理構造を逆生成して文書化する機能はありま
せんが、データアクセスに関するクロス参照を大域的に取得する機能が提供
されています。
VSAM に関しては、特定のデータファイルを使用しているプログラムとその
行位置を一覧することができ、移行に伴うデータファイル変更の影響個所を
把握することができます。同時に JCL を解析し、DD 文の定義から物理デー
タセット名に関連付けてクロス参照を行うため、COBOL プログラム内に書か
れた論理ファイル名だけからは取得することができないような、大域の解析
を行うことができます。また、CICS コマンドによる VSAM アクセスもバッ
チと同様にサポートされています。従って、同一の物理データセットが、バ
ッチとオンラインとの両方からアクセスされている場合でも、ひとつのクロ
ス参照でまとめて把握することができます。
VSAM のクロス参照
MI C R O
FO C U S
9
COBOL 資産のオープン環境移行の方法論
また、データファイル毎に、それを更新するプログラム個所のみの抽出、デ
ータファイルのレコードを定義している COPY メンバーの一覧など、きめ細
かいオプション設定が用意されています。
Revolve データファイルブラウザのオプション
埋め込み SQL 文によるリレーショナルデータベースアクセスについては、テ
ーブル単位、カラム単位の大域クロス参照を取得することができます。
IMS データベースへのアクセスは、DLI コマンドと CALL “CBLTDLI” の両
方をサポートしており、データベース単位での大域クロス参照を取得できま
す。
IMS データベースのクロス参照
MI C R O
FO C U S
10
COBOL 資産のオープン環境移行の方法論
その他、日立 XDM などの階層型データベースに関しては、Revolve 固有のサ
ポートはありませんが、CALL 文での利用であれば、サブルーチンのクロス
参照機能で代替することもできます。Revolve のスクリプティング機能を使用
して、CALL 文のパラメタを解析して、より高度なクロス参照を生成するこ
とも可能です。
(4) ロジックの最文書化
Revolve の提供する各種のビューは、ソースコードからモジュールやバッチジ
ョブの論理構造を逆生成します。以下に Revolve が生成する文書の例を示し
ます：
ジョブフロー図
MI C R O
FO C U S
11
COBOL 資産のオープン環境移行の方法論
モジュール関連図
MI C R O
FO C U S
12
COBOL 資産のオープン環境移行の方法論
既存システム再利用のポイント
システム再構築において、論理レベルの設計変更があまりに多いと、既存の
ソースコードはまったく再利用できず最初から作り直しとなってしまうこと
があります。しかし、パッケージ導入などの場合を除き、多くの場合はある
程度の再利用が可能です。本章では、ソースコード再利用の問題点を整理し、
その解決方法について整理します。移行元環境と移行先環境に関する各論に
ついては、引き続く章で個別に解説します。
再利用方法の概要
再利用ベースのダウンサイジングでは、典型的にはメインフレームで稼動し
ていた COBOL プログラムをオープン系 COBOL コンパイラで再コンパイル
することによってオープンシステム上で稼動させることになります。しかし、
同じメインフレームどうしの間の移植であっても、例えば COBOL コンパイ
ラのバージョンを上げるだけでも、さまざまな互換性問題が発生することが
多いことは良く知られています。ましてやマシンアーキテクチャもオペレー
ティングシステムも異なる環境への移植となれば、容易ではないことが予測
されます。
たしかに互換性への過度の期待はするべきではありません。しかし、ロジッ
クを再利用することに割り切って考えるならば、一からの作り直しに比べて
大きな工数削減、品質の安定を獲得できる場合が多くあります。
COBOL プログラム移植での問題点
この項では COBOL プログラムの再利用に着目して、問題点を整理します。
一般に、COBOL プログラムの移植で発生する問題は以下のように分類されま
す。
(1) シンタクスの相違
コンパイラのサポートする COBOL 構文の相違により、新しい環境ではコン
パイルエラーになってしまうもの。これをさらに細分すると、以下のような
ものがあります：
MI C R O
FO C U S
•
準拠する COBOL 規格の相違 (ANSI74、ANSI85 など)
•
COBOL の規格で「処理系作成者が定める」としているもの
•
利用者語が追加された予約語と衝突する
•
旧環境の COBOL コンパイラの方言
13
COBOL 資産のオープン環境移行の方法論
•
本来不正なプログラムだが、旧環境の COBOL コンパイラがたまたまエ
ラーとしなかった
(2) セマンティクスの相違
文法的に同じプログラムで、コンパイルエラーにもならないが、実行すると
異なる動作をするもの。大抵は COBOL の規格で「動作は規定しない」とし
ているものであり、以下のようなものがあります：
•
算術式で桁あふれ条件が発生し、ON SIZE ERROR 句によるエラー処理
が記述されていないとき
•
ファイル節のデータ項目に VALUE が書かれている
•
数字データ項目に数字で無い内容が含まれているとき
(3) 正しくないプログラムの動作
本来不正なプログラムだが、旧環境の COBOL コンパイラがたまたまエラー
としなかった、もしくはコンパイル時にチェックすることが理論的に不可能
なもの。初期化されていないデータを参照する時の動作などがこれにあたり
ます。
COBOL コンパイラの互換性オプション
これらの問題点に対して取りうる対策は、以下の二つに大別されます：
•
COBOL コンパイラをカスタム化して旧環境のコンパイラの動作に合わ
せる
•
プログラムを書きかえる (自動変換・手作業)
ここでは、Micro Focus の COBOL 製品を例にとり、どのようなカスタム化
が可能かをやや詳細に説明します。
Micro Focus Net Express、Micro Focus Server Express の場合、以下のようなカ
スタム化のインタフェースを提供しています。
(1) コンパイル時の指令によるカスタム化
200 に及ぶコンパイル指令がサポートされています。このうち、移行に伴う
互換性に関連する代表的なものとして、以下のものがあります。
l
MI C R O
FO C U S
算術式の中間結果評価方式
14
COBOL 資産のオープン環境移行の方法論
COBOL プログラム中に複合的な算術式を書くと、これを計算する方式によっ
ては、プログラムの実行結果に相違が出てきます。これは、コンパイラが演
算の中間結果にどれだけの精度を与えるかによって生じる相違です。
汎用機では十進演算など高機能なハードウェア命令がサポートされており、
COBOL コンパイラもこれを活用するようなコード生成を行っています。これ
に対して、マイクロプロセッサを使用するオープンシステムでは、十進演算
はほとんどの場合ソフトウェアによって実行されます。コンパイラの作成者
は、常にもっとも高速に計算が実行されることを念頭におきますので、マシ
ンアーキテクチャが異なれば最適な実装方式も自ずと異なってきます。
例として、Micro Focus の COBOL コンパイラはデフォルトでは、整数部 19
桁、小数部 19 桁の演算レジスタを内部的に使用しています。これは、メイン
フレームのコンパイラの処理よりも高い精度を保証します。
以下のようなプログラムの場合、Micro Focus では結果は 7 になりますが、
メインフレームでは 4 になります。
WORKING-STORAGE
01 ITEM-1
01 ITEM-2
01 ITEM-3
01 ITEM-4
COMPUTE
SECTION.
PIC 9.
PIC 9
VALUE 7.
PIC 9
VALUE 4.
PIC 9
VALUE 4.
ITEM-1 = ITEM-2 / ITEM-3 * ITEM-4.
このように、一般には Micro Focus のほうが汎用機より正しい結果を返してい
るのですが、これも非互換です。この互換性のために ARITHMETIC(VSC2)
指令がサポートされており、IBM VS COBOL II の中間結果評価方式をシミュ
レートします。
l
廃要素構文のサポート
COBOL 言語の規格は、ANSI66、ANSI74 、ANSI85 と進化してきており、そ
の間に消えてしまった構文もいくつかあります。新しい COBOL コンパイラ
はそのような構文の使用を抑止するためにサポートを取りやめていることが
あります。Micro Focus でも、このような廃要素構文はデフォルトで許さない
ようにしています。しかし、OSVS などの指令によって使用可能にすること
も可能です。以下のような構文がこれに当たります。
•
EXAMINE 文
•
EXHIBIT 文
•
ON 文
l
特殊構文のサポート
COBOL 規格とは無関係に、
汎用機上で独自にサポートされてきた構文があり
ます。Micro Focus では、 IBM メインフレームとの互換性を重視しており、
OSVS などの指令を指定することによって以下のような独自構文をメインフ
レームと同様にサポートしています。
MI C R O
FO C U S
15
COBOL 資産のオープン環境移行の方法論
•
PANVALET の ++INCLUDE 文
•
CA Librarian の＋INC 文
•
EJECT、SKIP、TITLE などのリスティング制御コマンド
•
= TO、> THAN などの比較条件
l
予約語の制御
Micro Focus は常に最新の COBOL 言語機能を取り込んできており、以前の
COBOL コンパイラがサポートしていなかったような言語機能をデフォルト
でサポートすることがあります。通常はこのような場合でも、機能が追加さ
れているだけなので、互換性上の問題になることはありません。しかし、
COBOL の予約語が新たに追加された場合、既存プログラムがたまたまそれと
同じ名前のデータ項目名を使用していれば、コンパイルエラーとなってしま
います。
このような問題を簡単に解決するために、指定された予約語を予約語扱いと
させないような指令 REMOVE が用意されています。この指令を使用すると、
当然その予約語を使用する言語機能は使用できなくなります。
なお、Micro Focus が最近になって予約語として追加したものには、以下のよ
うなものがあります：
ABSTRACT
B-AND
B-EXOR
B-LEFT
B-NOT
B-OR
B-RIGHT
B-XOR
BROWSING
CALLED
CLASS-ID
COERCION
DEFAULT
DEFINITION
END-WAIT
EVENT-POINTER
IDENTIFIED
INHERITS
METHOD
METHOD -ID
MONITOR-POINTER
MUTEX-POINTER
READING
REDEFINITION RESTRICTED
SEMAPHORE-POINTER
SHARING
THREAD-POINTER
THREAD-LOCAL
さらに、ある予約語を別の予約語に読み変えさせることを指令する、
OVERRIDE 指令、MAKESYN 指令もあります。
l
実行時例外の制御
COBOL プログラムの実行時に論理エラーが発生したときの動作は、 COBOL
コンパイラの実装方式によって変わってきます。一般には、このようなエラ
ー系の動作にまで互換性を期待するのは間違っており、エラーはなくすのが
正しい方法です。
Micro Focus では、コンパイル指令によって実行時例外の動作をある程度制御
することができます。以下のような場合が対象になります：
•
MI C R O
FO C U S
添え字範囲チェックをする・しない
16
COBOL 資産のオープン環境移行の方法論
•
10 進データ例外時のアベンドする・しない
•
ゼロ除算時のアベンドする・しない
(2) 実行時オプションの指定によるカスタム化
コンパイル指令はプログラム単位に個別に設定しますが、実行時オプション
は実行時システム全体のカスタム化を行います。Micro Focus では、環境変数
COBSW で設定するオプションと、コンフィグファイル中にコマンド形式で
記述するランタイムチューナーの 2 種類の設定方法をサポートしています。
さまざまな指定が用意されていますが、移行に伴う互換性に関するものとし
ては、以下のものがあります：
•
10 進データ例外時のアベンドする・しない
•
ゼロ除算時のアベンドする・しない
•
レコードロック時のリトライ・エラーリターン
•
ファイルロック時のリトライ・エラーリターン
•
ISAM ファイルオープン時のキー属性チェックをする・しない
•
ファイル更新のディスクフラッシュのタイミング
ソースコードの自動変換
コンパイラのカスタム化で対応できないような問題点は、COBOL プログラム
を新環境に適合するように書きかえることで対応します。これを自動的に行
う方法としては、以下の 2 つの方式があります。
(1) プリコンパイル方式
Micro Focus は、統合化プリプロセッサと呼ばれるインタフェースを提供して
おり、ユーザやサードベンダーが作成したプリコンパイラを、COBOL コンパ
イラ中に組み込むことができます。このインタフェースを使用すると、プロ
グラマは明示的にソースのコンバートを行う必要が無く、COBOL コンパイラ
が自然に言語拡張されたように見えます。また、COBOL デバッガで、変換す
る前のソースコードのままでデバッグできるというメリットもあります。
以下のサンプルプログラムは、この機能を利用して作成された、日立 COBOL
独自の NC’漢字’ 定数を自動変換するプリコンパイラのソースです。アプリ
ケーションのコンパイル時に、コンパイル指令でこのプリコンパイラを指定
するだけで、NC’漢字’ 定数をエラー無くコンパイルすることができるように
なります。ユーザプログラムのソースコードに対する修正は不要です。この
コンパイル指令をコンパイラのデフォルト指令に設定しておけば、プログラ
マは意識することなくこの文法を使用できるようになります。
MI C R O
FO C U S
17
COBOL 資産のオープン環境移行の方法論
select main-file assign to buffer
organization line sequential.
file section.
fd main-file.
01 main-rec.
02 filler pic x(80).
linkage section.
01 mode-flag
pic 9(2)
01 buffer
01 response.
pic x(80).
03 response-status
03 response-code
comp-x.
pic 9(2)
pic 9(4)
comp-x.
comp-x.
03 filler redefines response-code.
05
filler
pic x.
05 resp-main
03 response-code-2
pic 9(2)
comp-x.
pic 9(4)
comp-x.
03 filler redefines response-code-2.
05 filler
05 resp-more
pic x.
pic 9(2)
comp-x.
procedure division using mode-flag, buffer, response.
1. move 0 to response-status
if mode-flag = 0 *> initial calls
open input main-file
else *> mode-flag = 1 *> the following calls
read main-file at end
move spaces to buffer
move 0 to resp-main move 032 to resp-more
close main-file
exit program
end-read
inspect main-rec replacing all " NC'" by "
inspect main-rec replacing all " NC""" by "
N'"
N"""
move main-rec to buffer
end-if.
exit program.
(2) 自動変換方式
ソースコンバータを作成して、事前に一括して変換をしてしまう方式です。
SED 、A W K などのテキスト操作用スクリプト言語は、使いこなせばかなりの
レベルの変換処理を記述することができます。
例として以下の SED スクリプトは、NC'漢字'、NX'16 進漢字' をそれぞれ N'
漢字'、X'16 進漢字' に置換し、 DISPLAY UPON DISP 文を DISPLAY UPON
CONSOLE に置換し、CONSOLE IS DISPLAY を CONSOLE IS CRT に置換し
ます。
MI C R O
FO C U S
18
COBOL 資産のオープン環境移行の方法論
s/ NC'/ N'/
s/ NX'/ X'/
/ UPON *DISP/ {
s/ UPON *DISP/&¥^¥^¥^/
s/ DISP¥^¥^¥^/ CONSOLE/
}
/ CONSOLE .* DISP/ {
s/ DISP/ CRT/
}
このようなスクリプトでは処理しきれないような複雑な変換は、変換プログ
ラムを COBOL で記述して、バッチ処理で一括変換します。
COBOL 言語以外の問題点の対応
ここまでは、COBOL 言語に焦点を絞って、プログラムのオープン環境への移
行について説明しました。しかし、COBOL 言語以外の部分で現れる移行の問
題点が多くあります。例えば以下のようなものです：
•
簡易言語
•
データベースアクセス
•
トランザクション処理
•
画面制御
•
ジョブ制御
これらについては、次章で各論として触れます。
MI C R O
FO C U S
19
COBOL 資産のオープン環境移行の方法論
環境に依存する移行上の問題点
旧システムを撤廃し、新たにオープンシステムへダウンサイジングする場合、
旧システムで利用されていたさまざまな言語、ツール、ユーティリティ、ミ
ドルウェア、データベースを、新環境でどのように代替するかが、非常に重
要なポイントとなります。
本章では、このような COBOL 言語以外の問題点について、移行元環境と移
行先環境に関する各論として個別に解説します。
COBOL 以外の言語
汎用機の世界では、COBOL はもっとも普及したプログラミング言語ですが、
それ以外の言語も頻繁に使用されています。ここでは、そのようなものに対
して提供されているソリューションについてまとめます。
(1) PL/I
PL/I アプリケーションのダウンサイジングに当たって、オープンシステム上
で稼動する PL/I コンパイラ製品も存在しますが、ほとんど使用実績がありま
せん。ダウンサイジングに当たっては、別の言語に書き換えてしまう事例が
見受けられます。
PL/I を COBOL に変換するツール・サービスを提供するベンダーもあります。
一例として、株式会社ソフトプレックスでは、メインフレーム上またはオー
プンシステムをターゲットとして、PL/I プログラムを COBOL に変換するコ
ンバージョンサービスを用意しています。
http://www.softplexinc.com/products.htm
(2) アセンブラ
メインフレーム上の大規模なシステムでは、多くの場合部分的にアセンブラ
が使用されており、ダウンサイジングでの障壁になります。通常、アセンブ
ラが使用されるのは以下の場合に限られます：
•
日付計算など頻繁に実行される処理を高速化するため
このようなケースでは、一般にそれほど膨大な量のプログラムが書かれ
てはいません。一旦工数を費やして、COBOL や C に書き換えておくこ
とが推奨されます。
•
ミドルウェアの機能の呼び出しや SVC が必要であるため、特殊なマクロ
を使用するため
このようなケースでは、オープンシステムではサポートされていない機
能を使用するためにアセンブラが使われています。従って、いずれにし
ても何らかの代替機能に書き直す必要があります。
MI C R O
FO C U S
20
COBOL 資産のオープン環境移行の方法論
(3) RPG/400
AS/400 では、アプリケーションの多くは RPG で記述されています。オープ
ンシステム上で動作する RPG 言語はありませんので、何らかの言語に書き換
える必要があります。
こういったコンバージョンサービスを提供するベンダーもあります。株式会
社アイ・アンド・シーでは、独 PKS Software 社の AX/ware の総代理店とし
て、AS/400 からの自動コンバージョンツールを販売しています。
http://www.iandc.co.jp/iac_main04.html
(4) Easytrieve, CSP, Mantis などの 4GL
PL/I 変換サービスを提供している株式会社ソフトプレックスでは、このよう
な 4GL の変換メニューも用意しています。
データベースアクセス
通常、ダウンサイジングではデータベースアクセスはオープン系のデータベ
ースに置き換わります。従って COBOL プログラムからデータベースアクセ
スを行っている部分は、一般には書き換えなければなりません。この項では、
必要とされる変換作業を分類・整理します。
(1) VSAM などの COBOL ファイル
l
COBOL READ/WRITE 文の場合
通常は、ANSI 標準に準拠する文法で実現されているので移植上の問題はあり
ません。以下の点に注意する必要があります：
•
古いアクセスメソッド
古いオフコンの直接編成や、IBM の BDAM のような、COBOL 規格範囲外の
アクセスメソッドは、対応する ISAM に書きかえる必要があります。
•
ファイル状態コード
I/O 文の実行後に返される状態コードで 1 桁目が 9 であるものは、コンパイ
ラ作成者がさだめることになっており、相違があります。Micro Focus の場合
は、IBM メインフレームのファイル状態コードをシミュレートするコンパイ
ル指令が用意されています。しかし、状態コードは通常ログファイルへの書
き出しなどのためにしか使用されませんので問題はありません。
MI C R O
FO C U S
21
COBOL 資産のオープン環境移行の方法論
l
CICS コマンドなどの場合
VSAM アクセスであっても、オンラインプログラムからの EXEC CICS READ
などの埋め込みコマンドの場合は、書き換えが必要となります。
(2) 階層型データベース
IMS などの階層型データベースで、オープン系のオペレーティングシステム
でも稼動しているものはありません。従って、単なるプログラムの書き換え
だけでなく、データベース設計自体の変換も必要になってきます。
l
データベース設計の移行
階層型データベースの設計をリレーショナルデータベースの設計に設計変更
するには、論理的には各セグメント（レコード）を１テーブルに単純変換す
ることで可能です。
親子関係は、リレーショナルデータベースのテーブルに参照キーを付加する
ことで実現されます。
このような方式で、論理的には機能を実現することはできても、照会のパタ
ーンによっては性能が出ない場合もあるので、そのような場合だけをチュー
ニングしてやれば良いことが知られています。
MI C R O
FO C U S
22
COBOL 資産のオープン環境移行の方法論
l
CALL インタフェースの場合
IMS の CALL 'CBLTDLI' や、日立 XDM の CALL ‘XDATBAS’ のように、
CALL インタフェースのプログラムの場合は、変換が必要な箇所の洗い出し
も、変換自体も機械的であり、比較的容易に変換できます。
このような場合、あらかじめ移行元の CALL 文のパラメタ仕様を明確にして
おき、変換規則を良く定義しておくことが重要です。例として XDM の場合、
移行元では以下のような CALL 文でアクセスしています：
CALL 'XDATBAS' USING READM NFPADIA NFPA PAS-KEY.
CALL 'XDATBAS' USING RDNXT NFPADIA NFPA PAF-KEY.
CALL 'XDATBAS' USING READM NFPADIA NFPA PAF-KEY.
CALL 'XDATBAS' USING DEL-M NFPADIA NFPA PAF-KEY.
CALL 'XDATBAS' USING ADD-M NFPADIA NFPA PAF-KEY.
CALL 'XDATBAS' USING WRITM NFPADIA NFPA PAF-KEY.
これらはそれぞれ、READM は SELECT へ、RDNXT は FETCH へ、DEL-M
は DELETE へ、ADD-M は INSERT へ、WRITM は UPDATE に書き換える必
要があります。実際に、変換方法をうまく定義し、この XDATBAS という
サブルーチン自体を COBOL で書き直すことによって、呼び出し側の COBOL
プログラムを修正することなしに、XDM から Microsoft SQL Server へ変換し
たユーザ事例もあります。
l
親言語方式の場合
IMS の EXEC DLI 文のような親言語埋め込み方式の場合も、CALL インタフ
ェースと同様に、系統立てた変換規則を定めておくことによって、機械的な
手作業で変換が可能です。
l
モジュール言語方式の場合
モジュール言語方式とは、CODASYL で定められたプログラミング方式で、
照会パターンをプログラムとは別に定義して名づけておき、プログラムから
はその名前で照会を起動する方式のことを言います。ユーザ作成ミドルウェ
アの多くはこの方式を取っています。
モジュール言語方式で作成されたプログラムは、プログラムとデータベース
照会の D M L とが独立に定義されているため、周到に準備しておけば変換は
機械的に行うことができます。
(3) 関係データベース
ダウンサイジング対象システムが、DB2 などの関係データベースを使用して
いる場合、データ設計をそのまま流用してオープン系の関係データベースに
移行できます。ただし、流用できるのはテーブルとカラムおよびその参照関
係だけであり、実装に特有な設定は使用できません。
MI C R O
FO C U S
23
COBOL 資産のオープン環境移行の方法論
l
埋め込み SQL の場合
SQL 文を COBOL に埋め込む方式は、ANSI で規格化されており、どの実装も
基本的にその方式を採用しています。
しかし、各データベースがサポートする SQL 文法には方言もかなりあり注意
を要します。
l
その他の親言語方式の場合
ADABAS など一部の関係データベースには、モジュール言語方式のプログラ
ミングを提供しているものもあります。やはり、プログラムとデータベース
照会の D M L とが独立に定義されているため、周到に準備しておけば変換は
一般に難しくありません。
(4) データの変換
ここまでは、アプリケーションプログラムの移行の問題を扱ってきましたが、
ダウサイジングにおいては、これまで汎用機上で運用してきたデータ資産を
オープン環境のデータベースに移行することも重要なタスクです。
汎用機のシステムが操作するデータは、 VSAM や独自のデータベース管理シ
ステムに保管されています。これを、オープン環境のデータベースエンジン
へ移行しなければなりません。
Micro Focus Net Express が提供するデータツールは、IBM メインフレーム形式
のデータファイルを Net Express 形式のデータファイルへ変換します。しかし、
これは各種国産汎用機のコード形式をサポートしていませんので、サードベ
ンダーのツールが必要になります。そのようなツールの一例として、富士通
ビー・エス・シーの F*TRAN+ があります。
F*TRAN+シリーズは、汎用機上の COBOL データ中の、日付データや BCD
形式データの変換、EBCDIC←→JIS8 変換はもちろん、各種漢字コード（拡張
漢字を含む）の変換をサポートしています。COBOL のゾーン形式、パック形
式などの数値項目の変換も可能です。
各汎用機に対応した拡張漢字テーブルを提供しており、拡張漢字テーブルは
ユーザがカスタマイズ可能になっています。
実際のデータ移行は、次のような手順で行われます：
1) 索引ファイル、データベースのダウンロード
汎用機上のデータ管理ユーティリティを使用して、索引ファイルやデータベ
ースを一旦固定長順編成ファイルへアンロードします。このときに、順ファ
イルのレコードレイアウトを明確にしておきます。これは通常 COBOL の
COPY 登録集などで定義されているものです。その上で、アンロードされた
順ファイルをオープンシステムへバイナリファイル転送します。
2) F*TRAN+ によるデータベースへの変換
各順ファイルは、個別にオープンシステム上のデータベースのテーブルに変
換されます。このため、変換後の収納先として事前にデータベース定義を行
い、必要なテーブルを切っておきます。
MI C R O
FO C U S
24
COBOL 資産のオープン環境移行の方法論
COBOL レコード定義：
01
従業員レコード.
05
従業員番号
PIC X(6).
05
従業員名
PIC N(10).
05
生年月日
PIC 9(8).
05
性別
PIC N.
05
住所
PIC N(20).
05
入社年月日
PIC 9(8) USAGE COMP-3.
05
所属部署
PIC X(4).
F*TRAN+による変換指定：
インポートされた Access テーブル：
MI C R O
FO C U S
25
COBOL 資産のオープン環境移行の方法論
画面処理
汎用機上のプログラムでの画面処理には以下のようなものがあります：
•
CICS などのトランザクションシステムがサポートする画面マップ処理
•
COBOL の SEND/RECEIVE 文による論理端末の入出力
•
富士通の表示ファイルに代表される READ/WRITE 文による処理
•
NEC オフコンに代表される SCREEN SECTION 構文
これに対し、オープンシステムでの COBOL で一般的に使用される画面処理
は、以下のようなものです：
•
COBOLコンパイラがサポートする SCREEN SECTION によるキャラクタ
画面処理
•
Micro Focus の Dialog System に代表される、COBOL コンパイラに組み
込まれた GUI ビルダー
•
クライアント側で Visual Basic などを使用した 3 層 C/S 形式
•
HTML や ASP による Web 画面
•
トランザクションシステムによる画面マップ処理
以下、これらを使用した変換方式の概要を説明します。
(1) COBOLの SCREEN SECTION 構文
汎用機からのダウンサイジングの場合、業務の種類によっては、マウスを使
用する GUI アプリケーションより、キー操作ベースのキャラクタ画面の方が
歓迎される場合があります。このような場合に有効な方式です。
画面レイアウトを COBOL の画面節で定義し、手続き部中の
ACCEPT/DISPLAY 文で入出力操作を行います。
この構文は、従来オフコンの COBOL を中心に広く採用されてきています。
しかし、COBOL 言語の国際標準で定義されていないものであるため、細かな
構文の相違がかなり存在します。Micro Focus では、 X/Open 標準に準拠した
構文をサポートしていますが、一般にオフコンの SCREEN SECTION からの
移行では手直しが必要となります。
移行元COBOL がSCREEN SECTION では無い画面マップ定義機能を使用して
いる場合には、文法の変換が必要となります。例として、日立メインフレー
ムのマップ定義の場合、以下のように変換します：
MI C R O
FO C U S
26
COBOL 資産のオープン環境移行の方法論
移行元画面マップ定義：
CNSFLD POS=(003,015),
VAL=(C,'ｻｷﾞﾖｳ
ﾋﾞ:['),
ATTR=(GREEN,PRINT)
VARFLD LOGFLD=MPDATE,
CTLFLD=MPDATE,
POS=(003,028),
ATTR=(WHITE,TRANS,PRINT)
相当する SCREEN SECTION 定義：
05 LINE 003 COL 015 VALUE 'ｻｷﾞﾖｳ
05
ﾋﾞ:['.
PIC X(6) LINE 003 COL 028 USING MPDATEI
UNDERLINE BACKGROUND-COLOR 2.
SCREEN SECTION によって Net Express で作製された Windows 画面の例を以
下に示します。
(2) Dialog System
Micro Focus Net Express は、
専用の GUI ビルダーである Dialog System を標準
装備しています。VB ライクな画面ペインターと COBOL インタフェースの
自動生成機能を備えており、Windows GUI を簡単に作製することができます。
Dialog System は、
一般の GUI ビルダーと異なりイベント駆動型でない COBOL
プログラミングを許容しています。画面とプログラムのインタフェースは
MI C R O
FO C U S
27
COBOL 資産のオープン環境移行の方法論
CALL 文となるため、汎用機上のプログラムと類似した制御フローで処理で
きます。
(3) 3 層 C/S 形式
COBOL のロジックをサーバー側で稼動させ、クライアント側で Visual Basic
などで作製した GUI から呼び出す形式です。
この形式への変換は、移行元の COBOL プログラムに大幅な改変が必要にな
ります。
(4) Web 形態
Web アプリケーションでは、HTML で記述されたユーザインタフェースによ
ってブラウザから入力されたフォームデータが、何等かの方法でサーバー側
におかれたプログラムに手渡され、アプリケーションに固有のビジネスロジ
ックによって処理され、その処理結果が再び何等かの方法によってブラウザ
に返されます。
これは、メインフレームのオンラインプログラムが、端末からあがったデー
タをホスト側で処理して再び端末に返すのに類似しています。オンラインプ
ログラムを COBOL で書くように、Web アプリケーションでもサーバー側の
ビジネスロジックを COBOL プログラムで書くことができます。
この形態については、Micro Focus のホワイトペーパー「Micro Focus Net
Express による COBOL アプリケーションの Web 化」に詳しく解説されていま
す。
(5) CICS
CICS アプリケーションは IBM の TX Series がオープン環境での利用可能に
なっており、Micro Focus の COBOL を使用することによって、ほぼそのまま
ダウンサイジング可能です。
MI C R O
FO C U S
28
COBOL 資産のオープン環境移行の方法論
バッチジョブ
バッチジョブ制御を記述する JCL は、オープンシステムでは OS そのものは
サポートしていないため、対応する何らかの機能に変換する必要があります。
UNIX のコマンド言語であるシェルスクリプトでも、JCL の多くの機能を記述
できます。以下に、IBM 形式の JCL と、それに相当するシェルスクリプトの
例を挙げます：
JCL：
//STEP1 EXEC PGM=BATCH1
//VBTYPEIN DD DSN=PROD.VIDEO.BONDS.MASTER,DISP=SHR
//GAMEMSIO DD DSN=PROD.GAME.MASTER,DISP=OLD
//PLAYMSIO DD DSN=PROD.PLAY.MASTER,DISP=SHR
対応するシェル：
export VBTYPEIN=/usr/data/prod/video/bonds/master.dat
export GAMEMSIO=/usr/data/prod/game/master.dat
export PLAYMSIO=/usr/data/prod/play/master.dat
BATCH1
メインフレームでは、ソートやファイル生成、コピーなどを行うユーティリ
ティが各種用意されており、ジョブステップでこのようなユーティリティが
多用されています。ファイルコピーなどは OS コマンドで置き換え、ソート
は例えば Micro Focus COBOL の Mfsort ユーティリティなどで代替します。
MI C R O
FO C U S
29
COBOL 資産のオープン環境移行の方法論
ダウンサイジング事例
大手保険業 D 社ではメインフレームで 2 年以上かけて開発された約 290 万
ステップの COBOL によるホスト集中型基幹システムを、稼動後 6 年たって
業務ニーズの変化と、技術的可能性の高まりを理由に、UNIX 環境のクライ
アント／サーバー形式でのダウンサイジングを開始しました。開発を外部の
会社に依存していた D 社では、ダウンサイジングの開始に当たり次のような
目標を設定しました。
•
コスト削減
分散機開発で開発生産性を向上させる
•
先端開発技術、ノウハウの吸収
ＳＩベンダー、関連会社との共同開発
•
保守開発、運用ノウハウの移転
ＳＩベンダー、関連会社との共同運用
•
安全、確実性の重視
D 社ではトータルな生産性向上のため、次のような手法を検討し実施しまし
た。
•
事前に幅広いフィージビリティ・スタディを実施、実現可能な生産性向
上策を検討
•
変換、テスト、運用支援のためのツールを自作し、自動化による工数削
減を図る
•
SI ベンダー、関連会社まかせでなく設計、開発の早い段階から参画
既存資産であるバッチ・プログラムについては自動変換ツールと手作業によ
り、主に以下の項目の変更を行い、Micro Focus COBOL でコンパイルして実
行モジュールを生成。
MI C R O
FO C U S
•
DB I/O 処理
•
DB I/O のリターンコード（エラー判定）
•
帳表出力
•
ABEND サブルーチン
•
半角カナの定数（全角文字に）
30
COBOL 資産のオープン環境移行の方法論
既に移行が完了したシステムについてはハードウェア、データベースのチュ
ーニング、COBOL からの最適化されたコード生成等の総合的結果として、処
理パフォーマンスの向上が報告されています。又、画面まわりや SQL 文、プ
ログラムを部品化して、作業文書の整備も向上させたことにより将来のメン
テナンスも容易にしています。
このプロジェクトでは、環境の載せ変え自体が目的であり、業務の仕様変更
はあまり要求されていませんでした。
実作業に入るまでの準備、フィージビリティスタディに多くの時間を費やし
ており、移行作業自体は非常に短期間で実行しています。この点がもっとも
学ぶべきであると考えられます。
MI C R O
FO C U S
31
COBOL 資産のオープン環境移行の方法論
まとめ
企業情報システムにおける COBOL への過去の投資を無駄にすることなく、
新しいプラットフォーム上でのアプリケーションを開発してゆくために、具
体的な手法を見てきました。
MI C R O
FO C U S
32
マイクロフォーカス株式会社
Tel:0120-209612
www.microfocus.co.jp

Download Report