本コンテンツは、メディア情報開発株式会社様のご協力のもと、帳票システム構築のアライアンスサイトとしてウイングアーク テクノロジーズが運営しています。掲載する主要な帳票連携ソリューションは、動作確認に基づいて情報をご提供しています。

Parallel Frameとは？

2007年問題に起因して、基幹系システムのオープン化プロジェクトは、今後ますます加速することが予想されます。
しかし、既存のCOBOLプログラム資産の半分以上占めるとされているバッチプログラム資産のJavaへのマイグレーションに際しては、処理スピードの問題と共に多くの課題が残っているのが現状です。
そのような背景の下、メディア情報開発では、大規模基幹系システムのオープン化プロジェクトに数多く参加しながら、ノウハウを蓄積すると共に「Parallel Frame」の製品化とブラッシュアップを強力に推進して参りました。
「Parallel Frame」の最大の特徴は、Javaを基盤技術としていながら、COBOLバッチのアルゴリズムをノンプログラミングで再構築できるフレームワークと、そのフレームワークを超高速に稼動させるプロセッシング・モジュールで構成されている点にあります。

Parallel Frame開発環境

【パターンフレームワークとは？】
パターンを選択するとパターンの構造が展開されます。パターン構造の中で、処理ロジックの部分（ブロック）を処理部品の組み合わせで組立てます。誰が開発しても同じ構造のプログラムとなりますので、品質の担保と保守性の向上が担保されます。また、基本的にはJava言語そのものを習得する必要はありません

【処理ロジックの部品に関して】
標準部品として予め準備されている部品は、全ての仕様とソースコードが開示されていますので、個別に修正した新規部品を作成することが出来ます。
また、標準部品で実現できない個別の処理は、全く独自の個別部品を開発することによって実現します。
これらの部品群を蓄積することによって、企業の業種業態に適したライブラリ資産を蓄積していくこが出来ます。

【パターンタイプごとに詳細設計書のフォーマット・テンプレートを準備】
プログラムの処理パターン・タイプごとに詳細設計書のフォーマットを準備していますので、設計者はテンプレートに沿って設計作業を進めていくことが出来ます。これによって、誰が設計しても一定のロジック構造となる為、プログラム開発工程での仕様把握の簡素化が図れると同時に理解齟齬のGAPを解消することが出来ます。また、保守・運用工程での属人性の排除が期待できます。

【リビルドとリライト・リホストの垣根がなくなる？】
Parallel Frame が前提とする構造化設計は、新規開発プロジェクトで有効であるばかりではなく、大型汎用機上のレガシーマイグレーションに際しても非常に有効な方式です。
この構造化設計の考え方そのものは、大型汎用機上でのバッチプログラム設計の定石とも言えるものである為、既存の仕様書（場合によってはソースコード）から容易に展開させることが可能です。

【仕様書の自動出力】
リポジトリ情報からプログラム設計書（Excelフォーマット）を自動生成し、リバース出力することが出来ます。これによって、開発時に発生した設計書の手抜きや、仕様変更に対応できなかった設計書の変更に完全に対応することが可能になります。
また、保守・改定フェーズにおいては、現行のプログラムからの生成になりますので、設計書のメンテナンスに関するコストはほぼゼロになります。

【プログラム情報のクロスリファレンス】
Parallel Frameの開発フレームワーク画面から設定されたプログラム情報はすべてリポジトリに格納される為、格納された情報をダイナミックに確認しながら様々な作業を進めていくことが出来ます。

Parallel Frame稼働環境

稼動時にはコントロールサーバとグリッドエンジンが強調連動して処理を行い、グリッドエンジンを複数のマシン上に配置することによって処理を分散して行います。
コントロールサーバは、Gridが担当する処理を振り分ける制御を行います。開始可能な処理をGridに順次実行指示します。
どのような処理を、どのような順序で実行していくか？を、指示したJCLファイルをコントロールサーバに投入・実行することにより、順次Gridが処理を行っていきます。

【パフォーマンス改善効果】
プログラム設計（実装）が悪い例ですが、悪いプログラムであってもGridを増やして並列処理させることによってパフォーマンスを向上させることが出来ます。
このアプリケーションは400万件ある明細レコードの処理において、毎回データベースにアクセスする処理が書かれているため、データベースへのアクセスが400万件発生し･･･レスポンスがとても悪い、というものになります。処理時間は データベースI/O、ディスクI/Oが多いと処理時間もどうしても増えてしまいますが、そのことを意識せずに開発してしまうと思った以上にレスポンスが悪いプログラムが出来上がってしまいます。
そのようなプログラムでもGrid数を増やすと処理時間は軽減されるという結果を表しているのがこのグラフです。
システムを単純に移行してしまったため、悪いプログラムを作成してしまった際でもGridを増やせばプログラムを変更することなく、それなりに処理速度の改善を望むことも可能です。

【監視コンソール】
監視コンソールでは以下情報をリアルタイムに表示します。
■JOBGroup 開始時間
■JOBGroup 終了時間
■JOBGroup ステータス
■JOB名称
■JOB優先度
■依存JOB
■処理担当 Grid名称
■JOB ステータス
■JOB 開始時間
■Grid 処理開始時間
■JOB 終了時間
■ログ　その他