Cloud Service for オフコン サービス終了に伴う移行方式について――第3回：リホスト／マイグレーションでLinux Serverへ移行する際の注意点

はじめに

「Cloud Service for オフコン」が、2031年3月末をもってサービス終了となることが発表されました。このサービスは、オフコンシステムを富士通データセンター上で安全かつ安定的に運用するためのクラウドサービスとして、多くの企業に利用されてきました。

しかしながら、富士通のオフコン事業の戦略転換に伴い、サービスの継続提供が困難となり、今回の決定に至ったとのことです。これに伴い、オフコンシステムを利用している企業は、オープンシステムへの移行を検討する必要があります。

今回は、ホストコンピュータからLinux Server環境へのリホスト／マイグレーションを検討されている方に向け、「移行時の主な注意点」についてまとめました。移行作業で押さえておきたいポイントをご紹介します。

リホスト／マイグレーションでLinux Serverへ移行する際の注意点

資産の文字コード変換
多くのオフコンシステムでは、EBCDICやJEFコードといった独自の文字コード体系を採用しています。一方、Linux環境のほぼ標準とされるのはUTF-8です。このギャップを埋める文字コード変換処理は、単純な変換作業をイメージしがちですが、実務では以下の様な落とし穴があります。

・全角・半角・改行コード等、細部の表現の違いでトラブルが生じやすい
・アーカイブファイルやバイナリ混在データの自動変換では、データ消失や文字化けの懸念
・プログラム／データ両方に変換が必要な場合、適切なツール選定と自動・手動の使い分けが不可欠

オフコン特有の文字コードをLinux標準のUTF-8に変換する際は、細かな表現の違いやデータの破損・文字化けなどのリスクがあるため、データやプログラムごとに慎重な変換作業とツール選定が必要です。

ワンポイント：
帳票出力やデータ連携先など、下流のシステムや業務で想定外の文字化けトラブルが発生しやすいので、端末・プリンター・連携先も含めて入念なチェックが必要です。

COBOL規格の互換性
オフコンでは長年COBOLが主流でしたが、「オフコンのCOBOL（COBOL-G等）」と「Linux系COBOL（Micro Focus、GnuCOBOL等）」には、以下の様な非互換な仕様や独自拡張が無数に存在します。

・データ型宣言・エディット機能・日本語処理の仕様差
・ファイルアクセス命令（OPEN/INPUT/OUTPUT/EXTEND など）の微妙な動作違い
・システムAPIの呼び出し方法（オフコン独特 or OS依存部分）

これらを事前にソース解析ツールなどで可視化し、どこを修正・テストが必要か把握しましょう。場合によっては「ロジック再設計」「手作業による大量修正」が避けられません。COBOLバッチの自動変換ツールはありますが、万能ではないため人の目による最終確認も必須です。

ワンポイント：
オフコン独自命令やジョブ制御文はLinux上では動かないことが多く、「新規で書き直す」前提の見積りを立てておくと無難です。

画面・帳票・オーバーレイの互換性
画面I/F（GUI／文字ベース）、帳票フォーマット、和文フォントや印刷用オーバーレイなどの表示・印刷資産も、大きな移行課題です。

・Linux環境での「プリンタドライバ不足」や「フォントの置き換え」が必要
・オーバーレイ──帳票上に背景イメージやロゴを重ねる仕組みは、Linuxプリントシステム（CUPS等）への置き換えや、新規開発での対応が必須の場合が多い

画面や帳票、オーバーレイなどの表示・印刷資産は、Linux環境固有のプリンタドライバやフォント対応、印刷方式の違いにより、再設計や新たな対応が必要になる重要な移行課題です。

ワンポイント：
帳票や印刷が業務物で、見た目が少しでも違うと現場で混乱・業務停止の場合も存在します。業務詳細への理解と十分なコミュニケーションも重要です。

ファイルシステム → RDBへの対応
オフコンのファイル管理（VSAM/KSDS等）は、Linux移行にあたっては、RDB（リレーショナルデータベース。PostgreSQLやMySQLなど）への載せ替えが必要となります。

・「ファイル直アクセス」→「SQLを使ったデータアクセス」へ再設計・再実装
・キー項目、排他制御、トランザクションの仕様差をすり合わせ
・大量データ移行時のバッチ処理設計や最適化にも注意

既存帳票やバッチ処理プログラムがファイル名や構造に依存している場合、RDBに移行後の「データの整合性」「検索・集計パフォーマンス」等にも注意が必要です。

CL（コントロール・ランゲージ）の変換
オフコンの「バッチ運用」や「夜間処理」などはCL（コントロール・ランゲージ）が多いですが、Linux環境ではそのまま動作しません。

・OSコマンド体系の違い（例：JCL/CL → bashやksh等）
・外部システム連携やファイル操作、ジョブ管理の変換は手作業が多い
・例外処理や運用管理（ログ取得・異常通知等）の自動化も再設計が必要

移行後も運用ミスが起きやすいポイントなので、「誰でもメンテナンス可能なスクリプト設計」「十分なドキュメント整備」も移行計画に盛り込むことが大切です。また、変換作業は、難易度が高いケースが多いため、事前調査と分析が欠かせません。

DHS、QWEの代替製品の選定
オフコン時代に利用されていた専用ミドルウェアやジョブ管理ツール、帳票生成エンジン（例：DHS、QWEなど）。
Linux環境で同じものが動作しない場合、代替製品へのリプレースや、別方式で機能の再構成が必要となります。

・実績のあるLinux用ジョブ管理ミドル「JP1」「Zabbix」（一例）や、帳票ツール「SVF」「ActiveReports」などへの置き換え
・サポート体制や運用コスト、実運用も検討

「安定稼働＋移行納期＋コスト」のバランスを見極めながら選定しましょう。

Linux運用・操作性のギャップ
オフコンに慣れた運用担当者にとって、Linuxコマンドライン中心の管理体制は心理的ハードルが高いのが実態です。

・admin運用やトラブル対応、障害時のリカバリ手順等、未経験者には難易度が高い
・一括操作のためのスクリプトや自動化仕組み（Ansible/Shell等）も新規学習が不可欠
・ドキュメント化・マニュアル整備・教育研修計画も「移行完了＝終わり」ではなく、運用フェーズでのサポートも必要

このように、オフコンからLinuxへの移行後も、運用担当者への継続的な教育やサポートが欠かせません。運用の安定化には、新しい操作に慣れるための体制づくりが重要です。

まとめ

Linux Serverへのリホスト／マイグレーションには、多くの技術的課題が伴います。一つひとつ丁寧に事前チェック・検証を進めることで、スムーズな移行と安定稼働を実現しましょう。お困りの際は、お気軽にご相談ください！