Ｌｉｎｕｘ環境でのＣＯＢＯＬマイグレーション

２００７年１２月１３日
エステー株式会社
ＩＴグループ 照井琢磨

目次

会社紹介
マイグレーションの背景と選択した手法
スケジュール案とその実際
移行手順
導入効果
プロジェクトを振り返って

会社概要

会社名

エステー株式会社（ ８月１日、 エ ステ ー化学株式会社からエ ステ ー株式会社に商号変更）

設 立

1948年8月31日

主な事業内容消臭芳香剤・防虫剤・手袋・除湿剤などの製造販売

従業員数

連結 602名、単体356名 （2007年3月31日現在）※パートタイマー・ 嘱託を除く。

本 社

東京都新宿区下落合

資本金70億6,550万円

上場証券取引所

東京証券取引所 市場第一部

発行済株式総数

29,500,000株

事業展開
日用品業界に属するメーカー
エアケア（消臭芳香剤）
衣類ケア（防虫剤）
湿気ケア
（除湿剤）
脱臭剤

ハンドケア
（手袋）

クリーナー

セルフメディケーション・
セルフメディケーション・
美容・健康をサポート
美容・健康をサポート
サーモケア（使いすてカイロ）

システムの歴史
2007年 新体制・エステーへ商号変更

2007
年 新環境へ
2007年
新環境へ
2000年 ＧＳ８３００をホスティング

1995年 ＦＡＣＯＭ−Ｍ１７００にリプレース
1991年 東証第１部に指定
1989年 プラネット物流に参加
1986年 東証第２部に上場
1985年 プラネット参加

1990年 ＦＡＣＯＭ−Ｍ７６０にリプレース

1986年 ＵＮＩＶＡＣ−２２００にリプレース
1982年 ＦＡＣＯＭ−Ｍ１４０Ｆにリプレース

1975年 ＦＡＣＯＭ−Ｖにリプレース
1970年 ＦＡＣＯＭ２３０−１０導入

1948年設立

新システム検討の背景
処理能力の限界•日次処理の終了が27時（午前3時）になるときもあった

Ｈ／Ｗ増設が費用的に困難•ディスク容量の慢性的な不足

情報系サーバーへのデータ送信量増大•もっともＣＰＵを消費する処理が情報系サーバーへのデータ送信

ホスティング契約期限•ホスティング契約先から契約は2007年3月末までとの通告を受けた。

汎用機リプレースを含めた再構築検討が必須

移行対象システム

新システムの要件
処理速度、レスポンスの向上•現行機のサービスレベルは維持が最低条件。より速いシステム設計を。

汎用機レベルの可用性の確保•全基幹システムを移行するため、安定したサービス提供が必要•障害発生時にも迅速に復旧できる（３０分以内の復旧）

必要に応じて機能アップできる拡張性の確保•処理能力やディスク容量が不足した場合、拡張が容易にできる•他システムとの連携が容易にできる

方法・効果・費用・期間の比較
対応方法

メリット

デメリット

・業務プロセスを適応しないと多額の費用が発生
・全体最適化がはかれる・ライセンス料、ソフト保守料高い
ＥＲＰパッケージ ・リアルタイム処理が可能
・自社仕様の開発をするとソフトが進化するのに対応できない①
導入による・最新技術が導入しやすい
・現場運用が破綻する危険性あり
全面刷新
・統合的なシステムの実現
・現状全業務は対応できない・ＥＲＰに自社仕様をいかに作らないかが大きなポイント・トップダウン導入以外成功はありえない・自由度が高く、当社に最適な・導入に時間を要するしくみが作れる・費用がとても高い
新言語による ・段階的な構築が可能
・新言語の習得が発生②
・業務リスクが少ない
全面刷新
オ
・最新技術が導入しやすい・費用が高く、時間もかかるが、最適なしくみを構築できるプ
・業務改革も実行するためにはトップダウン導入が必要
ン・導入期間が比較的短い・システムの統一感がない
系
・費用はピンキリ
・最新技術が導入しやすい
・複数のパッケージを導入すると適応パッケージ ・システムの成長性がある③
保守費用等が高くなる可能性あり

運用費用 現場
ＩＴ
3年間 適用度 難易度

追加費用

期間

中上

１２〜
１５ヵ 中上
月

低

大１８〜
２４ヵ
月

小高 高

中下

１０〜
２４ヵ 中下
月

中 中

中下

１０〜
１５ヵ
月

小高 低

0ヵ月 中上− 低

・業務プロセスが世界標準化

ー

組み合せ

・費用はパッケージによりマチマチである（特に会計）・導入効果はＥＲＰほど出ないが、リスクが低減される
・導入期間が比較的短い・システムの成長は自社努力
・自社で対応する場合、期間が長・最新技術が導入しやすい
引く可能性あり・費用は比較的安い④ 既存言語の変換
・自由度が高い・言語の習得が容易
・従来のしくみがオープン化されるが、不足分は要開発・慣れている言語で作成するので、修正・開発リスクが低減される・最も安価・新技術に対応できない・開発要員が減少しており、将来・移行に伴うリスクがない性はない
ホス・堅牢性が高く安定している ・システム拡張はオープン系⑤
現状継続
ト・リアル性が低い
系
・システムの成長は自社努力
・従来のしくみ以外はオープン系で開発する・ハードの費用はやはり高い

0
小中（現場調整は高い）選択した対応方法とその提案概要【既存言語の変換】 方式の提案概要

汎用機資産（ＣＯＢＯＬ，ＪＣＬ等）を活用する•東京システムハウス株式会社のメインフレームマイグレーションサービス（ＭＭＳ）を利用

可用性、経済性を確保するためＯＳはＬｉｎｕｘ•安価で安定性の優れたＬｉｎｕｘを採用することで、可用性、経済性の両方を確保

ファイルシステムはＯｒａｃｌｅ•信頼性、他システム連携、データ利用の容易さ

文字コードはＳＪＩＳ•既存のオープンシステムの文字コードがＳＪＩＳ

決定した対応方法の概要

東京システムハウス株式会社のＭＭＳを採用•既存汎用機からのマイグレーション実績があり、短期間かつ正確にオープン環境に移行可能という提案を受け決定

ＯＳはＬｉｎｕｘを採用•不安はあったが、ＯＳとしては安定しており安価という第三者の意見もあり決定ファイルシステムはオープンＣＯＢＯＬ独自システムを採用•既存汎用機の索引ファイルの方式そのままで移行が可能との事で決定

文字コードはＳＪＩＳを採用•扱いやすさを考えるとＳＪＩＳがベストということで決定

プロジェクト体制図
プロジェクトオーナー（エステー担当役員）
プロジェクトマネージャー（エステーＩＴＧマネージャー）

エステーＩＴグループ
基幹系担当 ４名

Ｓ社
移行全般支援基盤系担当 ４名
運用担当

１名

東京システムハウス

Ａ社

汎用機資産移行支援

基盤設計支援基幹システム移行スケジュールと実際

フェーズⅠ
05/03-05

フェーズⅡ
05/06-09

計画

HOST
資産棚卸

移行
設計

実際

HOST
資産棚卸

移行
設計

フェーズⅣ
06/09-

フェーズⅢ 05/10-06/08

コンバージョン

結合テスト〜
統合テスト

コンバージョン

並行
稼動

フェーズⅤ
0７/1〜

本番
稼動

結合テスト〜
統合テスト

本番稼動フェーズ1 汎用機資産棚卸
バッチCOBOLプログラム、JCL
直近1年2ヶ月間の稼動実績から、実際に実行したバッチをピックアップ
全ＪＣＬ、プログラムを実行実績有りと無しに分ける
実行実績有り、無しそれぞれを担当者が全てチェックし移行対象を決定

画面プログラム
全資産を担当者がチェックし移行対象を決定

COBOL COPY句
全プログラム中のＣＯＰＹ句を解析しＣＯＰＹライブラリの資産を使用、未使用に分ける
使用、未使用それぞれをチェックし移行対象を決定

その他資産担当者が選定し決定

資産棚卸結果
未使用

使用

計

移行対象

COBOL本体

８４８２２１９

３０６７

１８０４

COBOL COPY句

１３１０

２１６１

３４７１

１６６９

アセンブラ

６８

３４

１０２

１６JCL

７５１

１６８４

２４３５

１２２５

オーバーレイ

３００

１６３

４６３

１１４

ユーティリティ等

０５２

５２１０

フェーズ２ 移行設計
先行コンバージョンの実施
先行コンバージョンとは移行対象プログラム・JCLから色々なパターンのものを選択し、それらをコンバーターを使ってコンバートを行い、コンバート後のオブジェクトで処理を実行した結果とメインフレームでの実行結果を比較検証しながらコンバーターをチューニングして行くことにより、コンバーターの変換精度を向上させ、マイグレーション仕様を確定させる
８０強のＪＣＬと画面ＰＧで実施

各種アプリケーションソフトウェアの選定•帳票出力・管理、運用管理、EDI機能を実現するソフトウエアの選定

ハードウエア構成の設計•サーバー、ストレージ、ネットワーク機器の選定と構成設計

移行設計フェーズの結果
先行コンバートで発生した問題点など（１）zデータ変換用マッピング定義の精度が悪い
定義間違えによる誤変換、マルチレイアウト対応モレ等

z画面プログラムの変換の難易度が高い
汎用機固有の機能に依存する動作の再現が難しい

z自動変換の限界
プログラム、JCLとも、自動変換できない人間の判断が必要な記述がある

z既存ホストCOBOLとオープンCOBOLの文法と動作の差異
コンパイルが通らない、動作が異なる等
既存汎用機では一度も発生しなかった潜在バグが発見された

移行設計フェーズの結果
先行コンバートで発生した問題点など（２）zアセンブラプログラムの機能移植
アセンブラプログラムは同機能を有するCOBOLプログラムに書き直す必要がある

z可変長ファイルの扱いが汎用機と異なる
SORTでのキー位置指定がズレてしまう

z既存汎用機特有ユーティリティの機能移植
VSAMファイルユーティリティなどの機能

z既存汎用機特有機能の移植
JOBグループによる多重実行制御などの機能

移行設計フェーズの結果
各種アプリケーションソフトウェアの選定
帳票出力・運用システム
ＤＵＲＬ（プリズム（当時））
ＢＳＰ−ＲＭ（ＢＳＰ）

運用管理システム
ｅＸｓｅｎｊｕ（ＮＲＩ）

ＥＤＩシステム
ＮＴＳシリーズ（アルゴ２１）
ＥＤＩマスター （アルゴ２１）

移行設計フェーズの結果
ハードウエア構成案
Redhat Linux

アプリケーション
サーバー１（アクティブ）

ＳＷハブ

ロード
バランサー

アプリケーション
サーバー２(アクティブ）アプリケーション
サーバー３(アクティブ）ファイル
サーバー１(アクティブ）ファイル
サーバー２（ホットスタンバイ）

共有ストレージ

Windows2003 Server

プリント
サーバー

運用管理
サーバー

ＥＤＩ
サーバー

フェーズ３ コンバージョン・結合テスト
先行コンバージョンで確定した仕様で全プログラム、JCLを変換
変換したプログラム、JCLの受入テストの実施
アプリケーションソフトの動作テスト、設定
アプリケーションソフトとの連携テストの実施
ハードウエア構成の動作検証

コンバージョン、テストフェーズの結果
コンバージョン、結合テストで発生した問題点（１）コンバーターが完璧でないので、全数検査が必要
先行コンバートで色々な問題点があることがわかったので、結局全数検査を行った

５００件弱の問題点、要変更点が発生
先行コンバートで対象にしなかったプログラムに高難易度のものが存在
画面プログラムは動作、見栄えなどの点で修正が多発
SORTの複雑なSELECT条件がそのまま移行できない（考えながら手修正）
乗算と除算が混在する計算式で計算誤差が発生
計算結果がゼロの場合 ０ または −０（マイナスゼロ）になる現象が発生
トランザクション制御が既存汎用機と合わない（暗黙指定時の挙動の違い）
オーバーレイのズレ
各種アプリケーションソフトとの連携が思ったようにできない
同じキーボート（特にテンキー）操作でもカーソルの挙動が違う
画面のコピー＆ペーストが１項目ずつしかできない等々コンバージョン、テストフェーズの結果
コンバージョン、結合テストで発生した問題点（２）システム構成に問題がありパフォーマンスが悪くなり、構成変更しなければならなかった
ファイルサーバーのパフォーマンスが悪く、検討の結果外す事になり、結果的にアプリケーションサーバーが１台構成となった

移行中にプログラムを変更しなければならないことがあった
移行資産の凍結は事実上不可能

コンバージョン、テストフェーズの結果
ＣＯＢＯＬの問題点（１）(既存ホストCOBOLとオープンCOBOLの仕様差異）
既存ホストCOBOLでは省略していたのに、オープンCOBOLでは省略不可
EVALUATE XXX ALSO YYY のALSOは省略不可

既存ホストCOBOLではANSI規格違反の記述でも正しく動作する
異なるSECTION への GO TO ジャンプ異なる属性間のMOVE命令で値が勝手に変換されてしまう
Ｘタイプから９（数値）タイプへの転送で A が １ に自動変換
ＰＥＲＦＯＲＭ ＵＮＴＩＬ 文の書き方によりエラーが発生する場合がある
PERFORM VARYING IDX UNTIL AAA(IDX) = SPACE OR IDX > 6 ではコケるコンバージョン、テストフェーズの結果
ＣＯＢＯＬの問題点（２）(既存ホストCOBOLとオープンCOBOLの仕様差異）
既存の除算式の書き方では除算例外が発生しない
ON SIZE ERROR句を書かないと発生しない（標準仕様）

帳票ファイルの改ページの制御文字の違い
LINAGE句指定のファイルで AT EOP 条件で WRITE AFTER PAGE を実行すると改頁制御記号が入らない半角スペースと全角スペースの違い
SJISでは半角スペースと全角スペースのコードが異なるコンバージョン、テストフェーズの結果
ハードウエア構成
Redhat Linux
ＳＷハブ

アプリケーション
サーバー１（アクティブ）

ロード
バランサー

アプリケーション
サーバー２(コールドスタンバイ）

共有ストレージ

Windows2003 Server

プリント
サーバー

運用管理
サーバー

ＥＤＩ
サーバー

フェーズ５ 本番稼動

様々な問題が発生したが、ＴＳＨ様を初め各社様と共に問題をクリアし本番稼動ができる状態になった
ギリギリ（２００６年１２月）まで受入テストを行っていたため実運用テストが不十分だった基幹システムの切替にもかかわらず現場説明会はほとん
ど行わず、イントラ上の「お知らせ」だけで済ませた
現場での帳票出力などのテストはほとんど実施しなかった本番稼動の結果

他システムとの連携などでエラーが続出した
帳票関係のトラブルが現象が続出した
しかし社内の事務部門が集約されていたため、エンドユーザーサイドの混乱はあまり発生しなかった

ほぼ１週間で安定稼動
２００７年１月末にホスティング契約解除

導入効果

バッチ処理の高速化
アプリケーションサーバーが１台構成になったが、パフォーマンスは汎用機に比べ劇的に向上した。夜間処理の終了時間が遅くても ０時 になった

Linuxは非常に安定
本番稼動からほぼ１年経過したが、OSが原因のシステム停止は一度も発生していない
基幹システム担当者もすんなりと受入られた

オープンCOBOLならではの機能の活用
GUI機能、Web機能を活用した画面開発などが可能になった
Oracle等のDBMSとの接続が可能になった

汎用機に比べかなり強力な開発環境で作業効率ＵＰ
強力なデバック機能で開発効率が大幅に向上

プロジェクトを振り返って

COBOLからCOBOLのマイグレーションでも簡単では無い
早期に安定稼動できたのは、全数検査実施の成果
Linuxの採用は正解だった
ソフトウエア提供会社の先行きに一抹の不安あり

最後に

ＣＯＢＯＬはまだまだ現役でいけるし、発展もする。
基幹システム全面切替、Ｌｉｎｕｘの採用は相当リスクがあったがマイグレーションを行って良かった。

ご協力いただいた各社様ありがとうございました。

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

２００７年１２月１３日
エステー株式会社