Top　＞　PRC（プログラムレスキューセンター）

ＰＲＣ事例－COBOL－

ＰＲＣ（プログラムレスキューセンター）のCOBOL言語版　の取り組み事例です。

システム運用上の課題（COBOLソリューション編）

お客様及び開発企業の課題は運用しているCOBOLソリューションにおける課題を解消することです。

お客様のシステム運用管理の課題：解決できないか？

１：運用上、システム変更のコスト高を認識し、将来性のある仕組を構築

　① 事業変化への柔軟なシステム対応を短期間で実現

　② 適正コストでの維持管理体制を確立

　③ 経営者やシステム管理者が、運用システムの内容を把握できる透明性

２：システムの維持管理コストを削減

　① 年間保守や追加修正コストを低減する具体策の提示

　② 長年運用しているシステムが抱えるコスト高の原因を特定

　③ システム要員確保の困難に対処する方法を提案

３：既存COBOLアプリケーションの再利用を促進

　① 新規投資を行いつつ、既存アプリを低コストで移行

　② システム担当者が既存アプリを継承できる仕組を構築

　③ 維持管理を最小限の要員で対応可能にする

開発企業（開発者）の課題：どう解決する？

１：COBOL要員確保の困難に対応

　① 開発者が既存アプリを理解できる環境を整備

　② 現行要員で効率的に顧客対応を行える方法を確立

　③ 言語知識不足を補完する仕組を構築

２：受託運用・新規開発コストへの適正な対応

　① 委託企業との運用内容の共有化

　② ドキュメントを活用し、システム共有を可能にする

　③ 言語移行時に既存アプリ状況を正確に把握し、適切な移行計画を立案

COBOLソリューションにおける技術的課題

１：COBOLアプリケーションの課題は、仕様の複雑さと依存性にある

　① 開発時のCOBOLバージョンやプラットフォームの識別が必要

　　　FujitsuCOBOL、IBMCOBOL等

　② 仕様書やプログラム構造の理解が保守の鍵

　　　ファイル記述、データ記述、手続き記述、環境記述（各セクションごとの設計思想の把握）

　③ 業務フローを反映したドキュメント作成の重要性

　　　業務内容を示すフローチャート図やデータフロー図の活用が不可欠

２：プログラム保守の効率化

　① 改修時に依存関係を確認するための仕組が必要

　② プログラムサイズの大規模化による影響を最小化

　③ COBOL特有の固定フォーマット（Column 1～80）に基づいた正確なコーディングが求められる

-PRCを実践してみると-

COBOLのPRCでは、

プログラムソースコードの「見える化」・「共有化」に焦点を当て、

１：ルールソースコード作成（Analysis－解析）

　　プログラム構造と制御フローの把握

２：比較（Comparison）

　　修正内容と影響範囲の特定

３：データフロー図（Data Exploration－データ連携）

　　データ項目を中心としたフローの解析

を実践します。

これらの仕組みにより、開発効率の向上、エラーの早期発見、保守性の強化といった大きなメリットを提供します。また、解析結果はドキュメント資料として活用可能で、チーム全体での理解共有を促進します。

表：機能、内容、メリット

１：ルールソースコード作成（Analysis－解析）

図：ルールソースコードのアウトプット例

※クリックすると拡大表示します。

　上記はUPD-RTNセクションのルールソースコード事例です。

こちらのソースは、入力した社員名（WRKNAME）によってWHEN文により分岐が起こります。WRKNAMEがDの場合、IF文がネストされており、このIF文は、IF～（THEN）～END-IFがオリジナルのソースコードであったので、ELSE　CONTINUE　を追加することにより分岐をより際立たせ、コードの可読性を向上させてます。また、THENも省略されているので、ルールソースコードでは追加表示してます。

ルールソースコードがつくられると、その解析結果および解析データの組合せなどを活用して、以下のようなサブ資料を自動生成することが可能となります。

１ー１：制御命令文サマリー生成

　ルールソースコードを作成すると、その解析結果を活用して、サブ資料を自動生成することが可能です。その一つがサマリー資料です。

サマリー資料には、ソースコード内のセクション別に開始行～終了行、ステップ数、最大ネストレベル、制御に関する命令文（入出力文、条件文、呼出文など）の使用数など、数値化して自動生成して表示します。

図１－１：サマリー

※クリックすると拡大表示します。

　今回の事例では、セクションは全部で５つあります。ステップ数で大きいものは見当たりません（ステップ100以上の場合は、着色といった設定も可能です）、ネスト深度は深いものは見当たりません。（ステップ数と同様に５以上などの設定で着色といったことも可能です）

１ー２：Section関係表生成

　ルールソースコードを作成すると、その解析結果を活用して、サブ資料を自動生成することが可能です。その二つめが　Sectiion関係表です。

関係表は、セクションからの呼出、呼出先の関係をテーブルにしてます。どのセクションからどのセクションが呼び出されているのか、または　他のサブプログラムが実行されているのかがこのテーブルからわかります。

図１－２：関係表

※クリックすると拡大表示します。

　今回の事例では、セクションは全部で５つあります。呼出（PERFORM）は、MAINから３つ、MAIN-RTNから１つの状況がこの表からわかります。他の３つのINIT-RTN、END-RTN、UPD-RTNはそのセクションから呼出がないセクションにつき、呼出なし　が「なし」となり、色が黄色で表示されます。

１ー３：CALLリスト生成

　ルールソースコードを作成すると、その解析結果を活用して、サブ資料を自動生成することが可能です。その三つめが　CALLリストです。

CALLリストは、外部プログラムへの呼出の関係を一覧にしたものです。

呼出元セクション、呼出先プログラム、引数　といった内容が確認できます。

また、DBIO関連と思われる単語が判明している場合は、以下の図のように色分けすることも可能であり、どのセクションがどのサブプログラムを呼出、DBと関連付けているかといったこともわかるようになります。

図１－３：CALLリスト

※クリックすると拡大表示します。

　今回の事例では、１－２セクション関係表をみると、CALL文がありませんので、CALLリストは存在しません。

上記の表は、CALL文が存在する場合の事例の表示形式です。

引数の色が着色されているのは、DBIOに絡んだワードです。色があるものが引数にある場合は、DBIOに絡んだCALL文のサブプログラム実行、色がないものは、DBIOがない　といった識別ができるようにしてます。

１－４：階層図生成

　階層図とは、ファイル内の各セクション同士の呼出元、呼出先関係を可視化したものです。呼出には外部プログラムが含まれることがあり、その場合も可視化対象です。

※緑色はプログラム本体、水色はセクションです。

　今回の事例では、階層図をみると、MAINセクションが実行され、3つの呼出が実行されていることがわかります。そしてMAIN-RTNからUPD-RTNのセクションを呼び出していることがわかります。

階層図は　Left To Rightの方式をとっており、左が親階層となり、右へ行くにつれ、子階層、孫階層へとつながっていきます。

また、今回の事例ではファイル単位でしたが、プロジェクト単位など、あるひとまとまりのルールソースコードのCALLリストを集めることにより、以下のような、ファイル間のつながりを階層図表示させることも技術的に可能です。

１－５：日本語フローチャート図生成

　ルールソースコードを作成すると、その解析結果を元に作成した可視化図の一つがフローチャート図です。ソースコードの「見える化」「共有化」を実現します。

　フローチャート図は　ルールソースコードのソースコード列をベースとし、表示は、日本語注釈した内容を使います。

フローチャート図の特長として、

フローチャート図では、条件文　や　選択文などが、可視化して表示されることにより、分岐点、分岐後の処理の流れがわかりやすくなります。

※クリックすると拡大表示します。

　今回の事例では、フローチャート図は、EVALUATE文のパターンとIF文のパターンが見られます。

EVALUATE文のパターンはEVALUATE文（黄色のひし形）から３つに線が分かれ、それぞれのWHEN文（黄色の長方形）につながります。さらにWHEN文内の処理へとつながり、END－EVALUATEへとつながります。

日本語注釈の74～87の箇所です。

また、真ん中のWHEN文は内部にIF文のネストがあります。日本語注釈の80～83の箇所です。

IF文はEVALUATE文のWHEN文のネストとして見つかります。黄色のひし形のIF文から2つに分かれます。

弊社のフローチャート図はIF文の場合、省略を追加するため、必ず　真　と　偽の２方向に線が分岐します。

条件を満たす場合のTHEN　と　そうでない場合のELSE）それぞれの処理へとつながり、END-IF（条件文を終了する）へとつながります。

２：比較（Comparison）

フローチャート図の活用例として

修正前　のソースコード　と　修正後　のソースコードを比較する際、

可視化することで、素早くに修正箇所をみつけることが可能になります。

以下の例は、ソースコードでは修正前と修正後のソースコードです。行が異なるので、一見すると違いがあることはわかりますが、どこに違いがあるかとなると　目検が必要となります。

フローチャート図であらわすと　どこを修正したかが一目瞭然です。

※クリックすると拡大表示します。

　今回の事例では、１ルールソースコードは、修正後のものでした。

別途、修正前のソースコードを用意して、同様にルールソースコードを生成します。

生成して並べた　フローチャート図が上記の図です。

修正箇所は、EVALUATE文の中のWHEN文にて、出力文、入力文が追加され、入力文判定により、処理が分岐するIF文が追加されていることが特定できます。

このように、短いソースコードの場合は、目検で特定できますが、ソースコード量が長くなってくると、目検も難しくなり、フローチャート図に表すことにより、視覚化され、より素早く特定につながります。

３：データフロー図（Data Exploration－データ連携）

　フローチャート図とは逆手順でデータの繋がり確認を行うのがデータフロー図です。

　ルールソースコードで解析されたそれぞれのソースコード行の主要データ（主語）

　およびその主語の生成に関連するデータ（変数主語）との関係を可視化させます。

　データフロー図からはデータのつながり確認に加え、不要なデータ抽出（浮島となって表れる）、または、繰返し文、条件文、などのデータルールを確認できます。

図①データフロー図生成

※クリックすると拡大表示します。

今回の事例は、５つのセクションからなり、データフロー図は５つの囲いが確認できます。条件文は黄色、出力文は緑色、代入力文はピンク、代入文は肌色といったように特定の機能ごとに色分けで表示してます。また、特定のデータに着目していない場合、線の色は、黒色で表示します。

②修正（トラブル）箇所データ特定

③特定データ使用命令文を抽出

以下の図では、赤色の線が　WRKNAME（入力従業員名）に関連したデータの線を表示することで、他のつながり（実行経路順など）とは区別されます。

また、全体ではなく、そのデータに関連したセクション（COBOLを例として）に図の表示範囲が限定されることにより、関連したデータにフォーカスされて図が可視化されます。

　こちらの事例は、UPD-RTNセクションの79行目にある WRKNAME というデータに着目したものです。WRKNAME は、セクション５番目のUPD-RTNセクションにしかデータがないため、全体図ではなく、セクション５の図となっています（複数のセクションにみられる場合は、複数のセクションが図に表示されます。また、その複数のセクションから、更にユーザー設定でセクション名を特定して表示させることも可能です（例：セクション１，２，３，５で使われており、５だけで表示させたい場合など）。

　また、設定したデータ WRKNAME に関連する流れは赤色で表示、データ同士の流れは黒色、実行経路の流れは灰色と線の色を分けることで、より対象データの流れを視覚化しやすいようにしてます。

　また、データフロー図を作成する際、サブ資料として、このWRKNAMEがどこで使われているかを対象セクション内から特定した資料を自動生成します。

　こちらの表は、データフロー図を作成する際に使用するツールから一緒にアウトプットされます。WRKNAMEが DATA DIVISIONのどの場所に記載されているか、およびどのセクションのどの行に生成されているのか（代入文）、参照されているか　の情報を一元管理した表になってます。赤い色が選択データ、黄色は、そのデータの元になる領域文を示してます。

COBOLについて、解析、比較、データ連携の３つの観点から実践したPRC例です。

ここで掲載した内容を活用することにより、システム全体の解析、修正、対応といったお客様のプログラムをレスキューする（PRC）を実践致します。

"PRC in Practice – See the Difference"