Top > PRC事例-RPG-

PRC事例-RPG-


RPG言語(AS/400 IBMiシリーズ)

PRC(プログラムレスキューセンター)のRPG言語(AS/400 IBMiシリーズ)の取り組み事例です。

システム運用上の課題(IBM iのRPGソリューション編)

お客様及び開発企業の課題は運用しているIBM iのRPGソリューションの課題の解消が解決策です。

お客様のシステムを運用管理の課題出来ないか?

1.運用上、システム変更でのコスト高原因を認識

  システムの将来性に柔軟な対応が出来る仕組(要望)

 ①事業変化へのシステム対応が短期間で製品に反映が可能

 ②運用上の適正コストでの維持管理に必要な体制を構築

 ③経営者・システム管理者も運用システムの内容が分かる

2.システムの維持管理コストは下げたい。

  IBMiユーザーの取り巻く環境下でコストを下げる方法

 ①年間保守・追加修正コストを低減させる方法はあるのか

 ②長年使用システムの何が原因でコスト高になるか

 ③システム要員の確保が難しいが対応する方法は

3.開発済アプリケーションの再利用を促進できないか

  開発済みアプリでもそのまま使用するのも多い

 ①新規投資はするが、使用中アプリはコスト安での移行

 ②システム担当者にアプリ継承の仕組み構築

 ③維持管理を最小限要因で対応する方法

開発企業(開発者)の課題出来る方法がない?

1.RPG要員確保が難しい

  言語を学びたがらない環境を補完できる仕組

 ①開発者にアプリを把握できる環境構築

 ②現状要員で効率的なお客様対応が可能な方法

 ③言語知識不足をアプリ把握から補完する仕組

2.受託運用、新規開発コストを適正対応には

  委託企業とシステム運用内容を共有化

 ①システムの共有とはドキュメントがあること

 ②言語知識不足はアプリで補完が出来ること

 ③言語移行はアプリ状況把握で移行方法が決定 

図:出典 Iマガジン掲載特集(2024/3/17)深刻化する要員不足の現状とIBM iユーザーの取り組み ~人材確保に挑戦するユーザーとベンダーの状況

IBM I で利用中の開発言語

IBM I ユーザーを取り巻く環


IBM iのRPGソリューションの課題(IBM iマガジン特集掲載を参照)

 1.IBM iのアプリの課題は言語依存にある

  ①開発されたRPG開発言語種類で識別が必要

   ・RPGⅢ(RPGⅡからの移行も含む:内部記述)

   ・RPGⅢ、RPG400

   ・RPGⅣ(固定、フリー)

  ②RPG言語は3種類毎にルール必要

   ・システム、サブシステムで混在している。

   ・保守はRPG言語種別での対応が必要 

  ③仕様書(F、I、C、O)ごとに確認が必要

   ・業務の流れはプログラム実行順番の反映で

    あるC仕様書(演算)にて業務の流れ確認には

    フローチャート図等のドキュメントが必要

   ・仕様書毎の命令文の桁位置、桁数等の理解が必要

    言語種別、仕様書毎に理解が求められる。

 

IBM i(AS/400)RPGへのPRCの取り組みとは(COBOLを含む):

開発技術者および iBM i のお客様に提供する技術とは、

 

1)RPGソースコードさえ準備ができれば、

2)プログラム実行経路様相解析技術でRPGソースコードからルールソースコードを作成します。

3)そして、RPGソースコードをフローチャート図で表現ができます。

目的:

IBM i (AS/400)上で稼働するRPG資産を:

1)継続使用に必要なドキュメントを準備することでRPG技術者の作業効率の向上を図ります。

2)JAVA等のオープン系言語への移行にRPG言語リノベーションで最適な移行を可能にする技術の提供をいたします。

IBM ⅰ 上で稼働するRPGプログラム課題を解決するとは

■RPG言語の抱える課題

 1)RPG技術者不足が深刻:保守及びオープン系言語移行に難(原因を把握)

 2)RPG保守技術者不足を解消し、継続使用に支障がない体制確立が急務

 3)RPG言語からのオープン系言語移行コストが大の為、コスト軽減策が必要

RPG言語を知らなければ対応はできません。

 

■ IBM i (AS/400)上で稼働するRPGとは:

 1)RPG言語には【 RPGⅢ 】、【 RPG400 】、【 ILERPG 】で、其々に仕様書ルールがあります。

   ・当該ルールで作成されているシステム全体、サブシステムには上記RPG言語が混在しています。

 2)RPG言語ではドキュメントが一般的には必要がないですが上記の課題解決には必須事項になります。

   ・ドキュメントの主体は演算仕様書で、フローチャート図と仕様内容の日本語ドキュメントが必須です。

RPG仕様書とは

1.画面よりSEUで入力準備をいたします。

2.H仕様書からO出力仕様書まで順序列で作成いたします。

3.各仕様書の作成は桁位置が重要です。

仕様書の桁位置での要注意とは、そのソースコードの桁位置の意味合いを理解しないと、保守&移行時に影響を及ぼすことです。

各仕様書について、それぞれソースコードから抽出し、解析し、その全容を把握します。

 

 

F仕様書は、どのようなファイルをプログラムで使用されるかを定義するファイル仕様書です。

 ①16桁目にPの有無:Pが有はプログラムサイクル仕様を示します。

 

 ②19桁目に「E」は、外部記述を示し、「F」は内部記述を示します。 

 

図:F仕様書(クリックで拡大します)

I仕様書は、読み取ったレコードの構成を記述する入力仕様書です。

 ①19桁目にDS(データ構造)がありますが、2重定義をしている可能性が含まれます。

 

図:I仕様書(クリックで拡大します)

O仕様書は、プログラムで使用される出力レコードをプログラム記述する出力仕様書です。

 

 ①印刷出力が多いか。:内部記述の出力 といった点が注意点となってきます。

 

図:O仕様書(クリックで拡大します)

C仕様書は、プログラムの開始から終了までの処理を記述する演算仕様書です。

 ①標識の使い方 や ②条件文(IF文)の使い方 や ③GOTO文のありなしなどが注意点として浮上してきます。

 

C仕様書(演算仕様書)はドキュメントの主体となります。

フローチャート図と仕様内容の日本語ドキュメントが必須です。

RPGソリューションセンターでは、ソースコードをデータ化したプログラム実行経路様相、図示化したフローチャート図、仕様内容の日本ドキュメントを用意、その全容を把握します。

 

C仕様書 -ドキュメント主体ー

 

お預かりしましたソースコードを弊社のプログラム実行経路様相解析技術よりソースコードをデータ化した「ルールソースコード」および図面で表現させた「フローチャート図」があります。

資料イメージ

左:ソースコードを解析したルールソースコードでRPGソースコードの内容を知ります。

真ん中:フローチャート図で、RPGソースコードが図面上で表現されます。

右:ソースコードを 人工知能(AI)へ回答依頼した日本語ドキュメントでソースコードのアウトラインが掴めます。

●ルールソースコードについて

お預かりしたソースコードを解析した資料、ルールソースコードを作成します。RPGでは、各仕様書によって、役割が異なり、その中でもプログラム処理部分である、C仕様書(演算仕様書)を解析、データ資料を出力します。データ資料はファイルごとに管理されます。また、サブルーチン(BEGSR)が含まれる場合、サブルーチンごとに番号が付与されます。

ソースコードについては、桁位置が重要となるため、「演算要素1(ファクター1)「演算コマンド」「演算要素2(ファクター2)」など桁位置ごとに列を設定、表示させることで、桁位置ごとのデータの内容を見て読み取りやすくします。また、RPGは、CRUD※の要素が密に絡んでくるため、CRUDに関連するデータ項目についても列を設け読み取りやすくします。

また、ソース内の条件文や繰返文、CRUDに関わるデータ部分などとりわけ重要なポイントに関しては、色別になります。フローチャート図のデータ項目の色に連動します。

※CRUDは、データベースのシステムに用いられるデータの作成(Create)、読み出し(Read)、更新(Update)、削除(Delete)の頭文字

プログラム実行経路様相イメージ

●フローチャート図について

フローチャート図は、ソースコードの内容を図式化して表現いたします。図式化したデータ項目は、プログラム実行経路様相と連動した資料になっており、条件文や繰返文、CRUDに関連するような特に重要とするデータ項目には、項目に色付けることで視覚的にわかりやすくします。

 

また、下の拡大図にもありますように、SELEC(選択文)など、分岐が多岐にわたるようなソースコード部分に関しても、フローチャート図では分岐の過程が図式化して表現され、どのように分岐され、どのように処理が進んでいくのかソースコードの内容が多角的な面で掴めます。

SELEC(選択文)拡大図(ピンク範囲)


日本語表示版

フローチャート図のデータ項目をそのソースコード一行一行を日本語解釈した内容を表示することにより、よりそのプログラムの一連の流れが可視化しやすくなります。

【日本語表示サンプル】-SELEC文-