HP-UX移行――第3回：Linuxへのマイグレーションで失敗しないための技術ポイント

HP-UX は、安定稼働を求められる基幹系システムで長年利用されてきました。しかし、ハードウェア更改やサポート終了をきっかけに、Linux への移行を検討するケースが増えています。

ただし、HP-UX → Linux の移行は、「OS を変えるだけ」の単純な作業ではありません。

• シェルスクリプトや運用ジョブ
• 自社開発プログラム（C言語など）
• 文字コードやロケールの扱い

といった技術的な違いを正しく理解しておかないと、「移行後に動かない」「パフォーマンスが出ない」といったトラブルを招きがちです。この記事では、HP-UX から Linux へ移行する際に押さえておくべき技術的なポイントを整理していきます。

HP-UXからLinux移行の背景と特徴

なぜ今、HP-UXからの移行が必要になるのか

なぜ、HP-UXからのLinux移行が必要になるのか、主な理由は次の3点です。

ハードウェア／ソフトウェアのサポート限界
ハードウェアの老朽化が進み、PA-RISC／Itaniumサーバ向けの交換部品や保守用パーツが入手しづらくなってきています。また、OS・ミドルウェアもサポート終了が近づき、今後はセキュリティパッチが提供されない等のリスクが高まっています。

コストと人材の問題
HP-UX環境の保守費用は高止まりする一方で、HP-UXに精通した技術者は減少しており、障害対応や更改を任せられる人材の確保が難しくなっています。

クラウド・仮想化とのミスマッチ
会社としてはシステムをクラウドや仮想化基盤にまとめていきたいのに、HP-UX などのレガシー環境はそのままではクラウドへ載せる現実的な方法がほぼなく、他のシステムと同じ方針・構成で統一できない状態です。

このような背景から、「次回の更改タイミングでHP-UXを終了し、Linuxなどのプラットフォームへ移行する」という中長期ロードマップを描く企業が増えています。

Linuxへの移行の特徴・メリット

HP-UXからLinuxへの移行には、以下のような特徴とメリットがあります。

プラットフォームの選択肢が非常に広い
Linux は、物理サーバだけでなく、VMware などの仮想化基盤の上や、主要クラウドベンダーの IaaS／PaaS 環境の上でも、ほぼ同じように動かして利用することができます。このため、特定ベンダのハードウェアや OSに縛られにくく、結果としてベンダーロックインを抑えやすい構成を取りやすくなります。

エコシステムの豊富さ
Linuxでは、Web サーバ、AP サーバ、監視基盤、ログ収集・分析基盤など、多数の OSS ミドルウェアが事実上の標準として利用されています。これらに関するドキュメントや情報も豊富で、トラブルシュートや機能拡張の際に参考にできるナレッジが多い点がメリットです。

技術者・運用スキルの汎用性
Linux のスキルは、他プロジェクトでもそのまま活かしやすく汎用性が高いスキルです。市場全体でもLinux エンジニアの母数が多いため、採用やアウトソースの面でも HP-UX に比べて格段に有利です。

コスト最適化
x86 ベースをはじめとしたハードウェアの選択肢が広く、負荷に応じてスケールアウト／スケールインしやすい構成を取りやすいことに加え、ライセンスコストや保守コストについても、圧縮の余地があります。

その一方で、HP-UX固有の前提に依存したシェルスクリプトやアプリケーションは、Linux上ではそのままでは動作しないケースが少なくありません。コマンドの挙動やディレクトリ構成、サービス管理の仕組みなど、技術的な差異を踏まえたうえで、計画的に設計・修正・検証を進めることが求められます。

HP-UX → Linux 移行で注意すべき主な技術的な違い

ここからは、現場で特に問題になりやすい技術要素を中心に解説します。

標準コマンド・スクリプト記法の違い

標準コマンド・スクリプト記法の違いは、主に「シェルの違い」と「同名コマンドの挙動差」の2点です。

シェルの違い
HP-UXは古い Bourne shellや、ksh 前提のスクリプトも多く存在します。一方Linux ではbashが多く、シェルの種類や実行環境によって実行するコマンドのパスやオプション、コマンドの実行結果の表示方法が異なります。

同名コマンドの挙動差
ps、df、sed、awk など、同じ名前のコマンドでも、HP-UXとLinuxでは使えるオプションや出力の並び・形式が違います。
例えば、

• ps の結果を「何列目」と決め打ちで切り出している監視スクリプト
• df の出力形式を前提にしたディスク容量チェック

といった処理は、そのままでは誤動作しやすいので、Linux 上で実際に動かして出力を確認しながら、ps -o で列名を指定するなど、フォーマットに依存しにくい書き方へ修正する必要があります。

環境変数の差異（動的ライブラリ）

環境変数（動的ライブラリ）の違いは、主に次の点です。

ライブラリ検索パスの指定方法
HP-UXでは共有ライブラリの検索にSHLIB_PATHを使いますが、Linux ではLD_LIBRARY_PATH とldconfig による設定となります。HP-UX 向けアプリが SHLIB_PATHを前提にしている場合、起動スクリプトなどを LD_LIBRARY_PATH／ldconfigベースに書き換える必要があります。

リンクオプション
HP-UXのcc／aCC 固有オプションはLinuxのgccでは使えないため、Makefile やビルドスクリプトを見直し、gcc向けの指定に置き換える必要があります。

プロセスID（PID）の桁数・管理の違い

プロセスID（PID）の違いは、「取りうる値の大きさ」と「再利用の頻度」がポイントです。Linuxではpid_max が大きく、HP-UX よりも桁数の大きい PID が発行されやすく、短命プロセスが多い環境では PID の消費・再利用も速く進みます。そのため、

• PID をファイルに保存して「この番号なら自分のプロセス」と決め打ちしている
• 「PID は○桁まで」といった固定桁を前提に ps 出力などをパースしている

といった HP-UX 前提のスクリプトは、そのままでは危険です。

移行時には、PIDは「番号が存在するか」だけでなく「プロセス名・起動パスも一致しているか」まで確認するようにし、PIDを固定桁の文字列として扱わない実装へ改めることが重要です。

ロケール・文字コード周りの違い

ロケールと文字コードは「画面やログにどう表示されるか」「データをどの文字コードで扱うか」に直結するため、HP-UX から Linux への移行時の重要ポイントです。両者では前提となる文字コードや、言語・文字コード・日付形式などを決めるロケール設定の方法が異なるため、この違いを踏まえずに移行すると、画面やログの文字化けや外部システム連携の不具合が起きやすくなります。

文字コード
HP-UX では Shift_JIS や EUC-JP が一般的だったのに対し、Linux ではUTF-8が標準です。そのため、HP-UX の文字コード前提のまま移行すると、文字列長のズレやファイル名／ログの文字化け、DB・外部連携との不整合が起きやすくなります。移行時は「OSロケールはUTF-8に統一する」ことを前提に確認しておく必要があります。

ロケール設定
HP-UXでは /etc/TIMEZONE や LANG／LC_* で制御していましたが、Linux では /etc/locale.conf や localectl などで設定するのが一般的です。OS／DB／アプリ／バッチでロケール方針をそろえたうえで、スクリプト内の記述を洗い出し、必要に応じて UTF-8向けに修正します。

C言語プログラムの移行ポイント

C 言語プログラムの移行ポイントは、大きく「データ型」「API」「ビルド環境」の3つです。

データ型
HP-UXと Linuxで int／long／ポインタのサイズやエンディアン・アラインメントが異なります。構造体の sizeof を前提にしたバイナリファイルや、「生構造体」の送受信をしている処理は特に注意が必要で、int32_t／int64_t など固定幅整数型の利用や、バイナリフォーマット仕様の再確認が求められます。

API
HP-UX 固有や古い UNIX 系の API（古いスレッドライブラリ、シグナル系など）を使っている場合、Linux はPOSIX 準拠の pthread／sigaction 等に揃えていく必要があります。-Wall -Wextra を有効にして警告を洗い出し、#ifdef __hpux などの分岐を整理しながら POSIX 推奨 API へ寄せていきます。

ビルド環境
コンパイラが cc／aCC から gcc／clang に変わることで、ワーニングやライブラリリンク順の違いからエラーが表面化することがあります。まずは最小限の修正でビルドを通し、その後警告を減らしつつ、Linux 上でテストを実行して HP-UX 時代と同等の動作になっているか確認する、という進め方が現実的です。

まとめ

HP-UXからLinuxへの移行は、アーキテクチャ刷新やコスト最適化の好機である一方、技術的な困難も多いプロジェクトでもあります。
特に押さえておきたいのは、次のようなポイントです。

• 標準コマンドやシェルの挙動差により、既存の運用・バッチスクリプトがそのままでは動かない可能性が高い
• 動的ライブラリの検索パスなど、環境変数周りの前提が異なる
• PID の桁数や再利用タイミングの違いによって、PIDを前提にしたロジックが誤動作する
• ロケール・文字コードは UTF-8 前提へ見直す必要がある
• C言語プログラムは、データ型サイズ・エンディアン・構造体レイアウト・API 差異を踏まえる必要がある

これらの差異を事前に把握し、１つずつ確認していけば、「切り替えたら動かない」「原因不明の不安定さに悩まされる」といった事態は大きく減らせます。本記事の内容を元に、自社システムの実装・運用に合わせて、移行計画へ落とし込んでいくことをおすすめします。

移行方針や技術的な検討でお困りの際は、下記お問い合わせフォームよりお気軽にご相談ください。