メインフレームマイグレーションの良くある問題

メインフレームマイグレーションの良くある問題

はじめに

世の中の企業の基幹システムには、いまだ多くのホストマシンが残っていますが、10数年前にオープン系のシステムにマイグレーションしていた時とは少し状況が変わりました。そこで、最近のホストシステムマイグレーションで良く起こった問題について取り上げてみます。

他システムとの連携

ここ数年、移行されずに稼働しているホストマシンは、企業の基幹システムである事が多く、その周辺のシステムの多くは既にオープン化されています。

その為、ホストシステムでは必ずと言って良いほど、ファイル転送(FTPなど)を使用して外部とのデータ連携を行っていますが、その全貌をシステム担当の方が把握されているケースは少ないのが現状です。

例えば、FTPでファイル転送を行っている場合は、ホスト自身が契機となってFTPを実行しているのであれば、マイグレーションのソース分析の過程でデータの送受信先等を調査可能です。

しかし、ホストがFTPサーバ側の場合は、クライアント側にしかFTPパラメタ等の情報が存在しない為、いくらソースを調査してもどのようなファイルをどう転送しているのかが分かりません。

 ホスト(FTPクライアント) ⇔ 他サーバ(FTPサーバ)
 ※これはホスト側にFTPパラメタがあるので調査可能。

 ホスト(FTPサーバ) ⇔ 他サーバ(FTPクライアント)
 ※これはホスト側にFTPパラメタが無いので詳細がわからない。

結局、現行システムの出力結果と移行後の新システムの出力結果を比較するテスト(以降、現新比較テストと記述)までひと通り終えないと全貌が分からない、という事が良くあります。

現新比較テストのテスト方法によっては、一部の外部連携のルートに本番直前まで気付かない事もあり得ます。それはテストデータの準備で、連携された後のホスト上に残っているデータを取得してテストを進めていた場合に起こります。このテスト方法では、FTPされたかどうかはテストの実施に関係が無いため、現新比較テストでは外部連携の処理に問題があるかどうか判断できませんし、そもそもFTPされているのかもわかりません。

マイグレーションプロジェクトには、調査・分析を行う工程がありますので、そこで全てを把握する事が理想ですが、漏れの無いように現新比較テストを実施できるようテスト方法を検討、テストシナリオを作成する事も、精度の高いマイグレーションを行うためには重要です。

調査工程では基本的にプログラムソースを解析します。このタイミングで可能な限り外部連携の実態を明らかにするため、ソースだけではなくFTPサーバに有るFTPのログを取得して分析する、といった作業が必要となってきます。

テストは思うようには進まない

最近のマイグレーションプロジェクトで関わった情報システム部の方々の中には、とても忙しかったり(ギリギリの要員で現行の運用をされている)、あるいはホストシステムの詳細を知らなかったり(知っている人は定年してしまった)と、マイグレーションを進めるための必要情報を把握・共有することが、様々な要因から難しいとお話される方もいらっしゃいました。

その様な状況であるため、テストシナリオやテストデータをなかなか提供して頂けないプロジェクトが増えています。次善の策として、弊社内でテストを実施する際は、ある時点のデータをごっそり取得して頂き、とりあえずひと通り実行してみて正常終了の確認だけ行う、という進め方を、必要に応じて取る事もあります。

ただ、この場合、テスト担当者は現行システムの運用を知らないため、詳細を把握できないままとりあえず実行するだけになってしまい、結果、エラーが多々発生するという事態になりかねません。この場合、大量のエラーをもとに、改めてお客様に操作方法やデータの整合性などをご確認頂くので、結局それなりの手間と時間が掛かってしまいます。
さらに、このテスト方法では、その時はエラーにならなくても、お客様に納品した後の受入テストで問題が発生する可能性が高くなります。現新比較テストのシナリオやテストデータはしっかりご準備頂くことで、より短期間かつ低価格で精度の高いマイグレーションを実現させることができます。

テストデータの準備にも関わってくるのですが、データ移行はお客様にかなり頑張って頂かなくてはならない作業です。データ移行と一口に言っても、実際には移行対象になるデータの判別、移行対象となったデータのレイアウトの提供や、データを現行システムから抽出するタイミングの確認、テスト時のデータ移行作業(現行システムからのデータ抽出と文字コード変換など)、本番切り替え前のデータ移行作業などがあります。どうしてもお客様主体で進めて頂かなくてはならない作業なので、マイグレーションを行う際にはそのようにご認識いただきますようお願いいたします。(基本的に文字コード変換を含めたデータ移行の仕組みの準備はマイグレーションベンダーで行います)

現新比較テストで発生する、防げるはずの問題

現新比較テストで、現行システムの出力データと移行後のプログラムを実行して出力したデータを比較した時の不一致の原因のひとつとして、ソースのバージョン差異があります。これは変換するためにホストから取得したソースと、テストのためにホストで実行した時のソースに差異があり、出力データに影響してしまったことにによる比較検証不一致となります。

マイグレーションプロジェクトは長期にわたるため、変換のためにソースを提供して頂いた後、どうしても現行システムでソースに改修が入ります。そこで、ソース提供後の変更管理をどのプロジェクトでもお願いするのですが、様々な業種・業界のお客様の中には、そのようなこまかな変更の記録に慣れているという方は決して多くはなく、記録漏れが発生しがちです。

比較検証不一致の原因調査では、基本的にソースを見てどの処理で該当データを出力しているのかを確認することから始めますが、コーディングされている通りにデータは出力されているため、何故不一致になるのかをすぐに把握することは難しく、調査時間が掛かってしまいます。そのため、出来る限りこういった不一致は減らしていきたいところです。

お客様と相談して、テスト前にもう一度ホストの資産をご提供頂きソースコンペアを行ったり、ホストのオブジェクトの更新日の情報を取得して頂いてチェックしたりするなど、精一杯の対応をさせていただきますが、エラーの早期解決のため、お客様にも可能な限りソースの変更内容の把握にご協力をお願いいたします。

時には新システムの方が遅くなってしまう事も

今まさに進行形で、新しいサーバはどんどん性能が良くなっています。それでもマイグレーション後のプログラムの方が、処理に時間が掛かってしまうという事があります。

例えば、ホストの階層型DBをオープン系のRDBに移行する時に、とあるコード以降のデータを読み込むような処理を単純にSQLへ移行すると、「>=」のような条件になりますが、これだと必要無いデータまで抽出してしまい、処理に時間が掛かります。

他にも、マイグレーションではホストと同じ動作をさせる為に共通処理を用意するのですが、その初期処理でホストと同じような環境(一時領域等)を準備する処理が実行されるため、どうしてもジョブの初動に、ほんの数秒とはいえ時間が掛かってしまいます。

性能問題の原因は上記だけとは限らないので、出来るだけ早く性能に問題無いことを確認しておくことは重要です。マイグレーションプロジェクトでは、本格的にソース変換を始める前に、一部だけ変換して実行し、課題を洗い出すパイロットテストという工程がありますが、このタイミングで実行時間についても確認しておきたいところです。その為には、性能を確認出来るような処理をパイロットテスト対象に選定する事や、パイロットテストに間に合うよう、新サーバを発注、テスト環境を準備する事が必要です。

変換すれば終わり、ではない

今まであげた問題は、マイグレーションで必ず起こるわけではありませんし、これ以外にも様々な問題が発生します。それは技術的な問題だけではなく、どちらかというと泥臭い、人間系の問題であったり、プロジェクトの進め方の問題であったりします。

いずれにしても、それらを未然に防いでいくために重要なのは、会社間、担当者間のコミュニケーションだと考えます。システムズでは、お客様がどのような状況か、ご担当者様がどの程度移行作業に携われるのか等、ご相談させて頂き、役割分担をいたします。お客様と一丸となってプロジェクトを推進していけるよう、密なコミュニケーションをとっていきたいと考えています。

著者プロフィール

著者アイコン
マイグレーション担当
マイグレーションの様々な情報を発信しています