メインフレーム完全撤去事例〜簡易言語・特殊ＤＢの移行、ERPとの連携〜

株式会社 日立ハイテクノロジーズ
情報システム推進部
部長代理 卜部 良基

会社紹介
本社
東京都港区西新橋1番14号
東京都港区西新橋1丁目24丁目24番14号
設立
1947年
1947年4月12日
12日
従業員 単独3,161名、連結名、連結9,9,974
974名
名
単独3,161
売上高 888,
2006年3月31日
31日＞
888,293百万円（連結）293百万円（連結） ＜2006年
事業内容
・電子デバイス・ライフサイエンス
・情報エレクトロニクス
・先端産業部材

半導体製造装置
バイオ関連機器、医用分析装置
電子部品実装システム、コンピュータシステム
鉄鋼製品、合成樹脂、電子材料、自動車関連

拠点
・国内営業所
・国内工場
・国内グループ会社
・海外事業所・海外グループ会社

９営業所（支店）
２工場
販売８社、製造・サービス9
販売８社、製造・サービス9社）
3支店、８出張所
米州4
米州4社、欧州6社、欧州6社、アセアン6社、アセアン6社、アジア8社、アジア8社）

1

メインフレーム撤廃の目的
2004年に中核となる基幹システムは、ＳＡＰ／Ｒ３に切り替え運用を開始。
2004年に中核となる基幹システムは、ＳＡＰ／Ｒ３に切り替え運用を開始。
しかし、特殊業務のシステムについては、既存メインフレーム上で稼動させなければならなく、ＳＡＰ／Ｒ３との連携を取りながら運用を始める。

システムとしては、無事にシステムとしては、無事に完了し本稼動したが・・・完了し本稼動したが・・・
一部のシステムの為に、既存のメインフレームをそのまま稼動していることが問題となり、“問題となり、“ランニングコストの削減“ランニングコストの削減“を目的として、現行メインフレームのコスト削減の検討開始を行う。

メインフレームのコスト削減に向けて類似パッケージの適用
類似パッケージの適用

×

一部のシステムは、適用出来そうである
一部のシステムは、適用出来そうであるが、全てが対応できない。
が、全てが対応できない。

×

現行のコストより削減出来るが、大幅な現行のコストより削減出来るが、大幅なコスト削減は見込めない。
コスト削減は見込めない。

△

残っているシステムのほとんどが簡易残っているシステムのほとんどが簡易言やﾈｯﾄﾜｰｸ・ﾘﾚｰｼｮﾅﾙ
ﾈｯﾄﾜｰｸ・ﾘﾚｰｼｮﾅﾙDB
DBであり、単純であり、単純言や言やﾈｯﾄﾜｰｸ・ﾘﾚｰｼｮﾅﾙDBであり、単純移行とは行かない。
移行とは行かない。
（移行コストも高価!!
!!））（移行コストも高価（移行コストも高価!!）

メインフレームのグレードダウン
メインフレームのグレードダウン

マイグレーション（既存資産移行）
マイグレーション（既存資産移行）

短期間・確実に出来る方法は？

雑誌等でマイグレーション
事例、、雑誌等でマイグレーション事例
ベンダーを調査2

オープンCOBOL、ベンダー選考のポイント
オープンCOBOL、ベンダー選考のポイント
簡易言語からの移行実績は無いが、多機種の豊富な移行実績や他簡易言語、他階簡易言語からの移行実績は無いが、多機種の豊富な移行実績や他簡易言語、層型DBからの移行実績がある。
層型DBからの移行実績がある。
移行コストも予算内で収まることが出来そう。
メインフレームの契約時期が、刻々と迫る。
COBOL以外の周辺製品について既に導入している製品との連携実績があること。
COBOL以外の周辺製品について既に導入している製品との連携実績があること。
（製品コストの削減）
移行手法と簡易言語の移行問題点などがきちんと整理できていたこと。
移行手法と簡易言語の移行問題点などがきちんと整理できていたこと。
メインフレーム

オープン環境

簡易言語ソース

ﾌﾟﾘｺﾝﾊﾟｲﾙ

システムサブルーチン

オープンCOBOLで
新規開発
COBOL85

ロードモジュール
ＦＴＰ

COBOLソース
オープンCOBOL
変換
COBOL85【問題】
簡易言語からCOBOL85に変換された時に利用しているシステムサブルーチンをオープン環境でどのように再現するか？

新システム構成図●ユーザ部門■アプリケーションサーバ
●ソフトウェア
・Acu4GLﾗﾝﾀｲﾑ（COBOL）
・AcuConnectｼﾝｸﾗｲｱﾝﾄ
・SyncSort
・ORACLE◆ハードウェアOS、スペック
OS:Windows 2000 Server SP4
CPU：Intel XEON 3.2GHz
ﾒﾓﾘ：8GB
HDD：144GB (72GB×3 (RAID5))●ソフトウェア
・AcuThin

ネットワーク（社内LAN）■帳票サーバ●ソフトウェア
・BSP-RM（帳票仕分機能）
・Universal Connect /X（帳票制御）
・ReportDirector（スプール管理）・Fibridge （電子帳票）
・AcuServer

日立ﾊｲﾃｸ DDP70
600dps
70PPM■運用監視・システム監視・JOB実行●ソフトウェア・JP1（JP1統合監視）(JOB実行は別のEDIｻｰﾊﾞ)◆ハードウェアOS、スペック
OS：Solaris9
CPU：Ultra SPARCⅢi 1GHz ×2
ﾒﾓﾘ：4GB（512MB×8）
HDD：73.4GB×2◆共有ディスク（ﾃﾞｰﾀﾌｧｲﾙ)
HDD：73.4GB×5※3本：RAID5ボリューム用（利用可能領域：約204GB）◆ハードウェアOS、スペック
OS: Windows 2000 Server SP4
CPU:1.4Mhz * 2
ﾒﾓﾘ:523MB
HDD:50GB●ソフトウェア・AcuThin●ソフトウェア・AcuThin

3

移行システムの概要◆稼働環境：ホスト◆対象業務：原価計算システム、材料販売部門営業取引システム

移行規模と移行方法
エミュレーター

ホスト
ﾈｯﾄﾜｰｸDB
COBOL85
ﾘﾚｰｼｮﾅﾙDB
JCL
SORT
OLTP
画面定義

新システム
ACUCOBOL
ORACLE
AJ_JCL SyncSort
AcuConnect & OLTP-MAIN
ACUCOBOL画面定義

機能本数

移行先 アプリケーション

バッチCOBOL

306

ACUCOBOL

約85%が簡易言語で作成されたアプリケーション
約85%が簡易言語で作成されたアプリケーション※簡易言語特有のOLTPｻﾌﾞを新規構築

オンライン
COBOL

80

ACUCOBOL

JCL108

AJ_JCL

画面定義

102

ACUCOBOL ScreenSection

帳票定義

21

SuperVisualFormade

ﾈｯﾄﾜｰｸDB

71

ORACLE

ﾘﾚｰｼｮﾅﾙDB

1

ORACLE

OLTP

AcuThinﾌﾘｰﾗｲｾﾝｽ

備考

関係を示すデータセット単位でサブルーチンを作成し、同等アクセスを実現させる

AcuConnect

OLTPの画面制御のみを代替するサブルーチン（OLTP-MAIN（UAP））より同等機能を実現

アプリケーション構成図
クライアントアプリケーションサーバ
DBサーバ
DBサーバ

帳票サーバ

オンライン
AcuThin
Runtime

既存のオンライン
既存のオンライン
トランザクション
トランザクション
データを活用データを活用バッチ

AcuConnect

ACUCOBOL Runtime

ACUCOBOL
ACUCOBOL
Runtime
Runtime

ACUCOBOL
オブジェクトDCCMＭＡＩＮ
ＭＡＩＮ
DCCM
OLTP-ＭＡＩＮ
OLTP

SyncSort

AJ_JCL【バッチ帳票】
AcuServer

帳票
イメージ

BSPBSP-RM
ACUCOBOL
ACUCOBOL
ACUCOBOL
オブジェクトオブジェクトオブジェクト【オンライン帳票】
AcuServer経由ダイレクト出力
AcuServer経由ダイレクト出力

Universal Connect/X
ReportDirector
Fibridge

Oracle電子
帳票

4マイグレーションスケジュール
No

作業内容

担当

１

調査分析作業

HITEC
SIer

11月

12月

1月

2月

3月

4月

5月

★プロジェクトスタート

ｽｹｼﾞｭｰﾙ調整の申し出（SIerからHITECへ）

簡易言語、ﾈｯﾄﾜｰｸDB
分析・設計
プロトタイプ

２

変換作業

SIer

３

テスト作業

HITEC
SIer

変換作業

検証要員増強SIerからも増強

データ抽出
照合テスト

４

リリース

HITEC

受入テスト

HITEC

★完成原価リリース★日次処理並行本番★月次処理並行本番★ホスト契約UP

移行時の課題簡易言語サブルーチンの仕様公開がなく、調査段階で簡易言語サブルーチンの仕様公開がなく、調査段階で影響があった。
⇒サブルーチンの利用要件をTSHと確認しながら類似サブルーチンを作成。と確認しながら類似サブルーチンを作成。
サブルーチンの利用要件をTSH
照合データの抽出タイミングの違いで照合不一致が発生。
⇒事前のデータ抽出計画が足りなかったことを反省。
オンライン帳票で利用を予定していたミドルウェア活用に困難。
⇒利用できることの検証は出来たが、運用の影響を考慮して、ミドルウェアを変更

調査分析工程で少々時間を費やしてしまい、スケジュール調整などの再検討があったが、確実な移行方法を設計することで結果的に短期間で稼動できたことが何よりである。

5

導入効果
レスポンス
−バッチ処理速度−オンライン処理速度：メインフレーム上で12分へ短縮！
：メインフレーム上で1JOB15分が、JOB15分が、2：現行のオンラインシステム以上のレスポンス！

コスト−メインフレーム撤去より、ランニングコストの大幅削減効果。
ほとんどが、既存のハードウェアを活用！！

SAPとのシームレスな連携
SAPとのシームレスな連携−コード変換やデータ転送などが無くなり、ORACLEを中心とした−コード変換やデータ転送などが無くなり、ORACLEを中心としたデータの一元管理の結果、の結果、スマートな運用を実現！
スマートな運用を実現！
データの一元管理

バッチ機能の開発手法確立−今までOpen環境でのバッチ処理がイメージできなかったが、今回の−今までOpen環境でのバッチ処理がイメージできなかったが、今回の活用によりバッチ処理の手法が確立できた。
今後の展開にも大きく役立てて行きたい。

・今後の展望・オープンCOBOLの適用場面

6

ありがとうございました。

7