HP OpenVMS Systems

この記事では，OpenVMS I64 V8.2 をリリースするために Integrity サーバへの OpenVMS のポーティングに取り組んだ 3 年半の開発作業について，歴史的背景，主な意思決定の背後にある根拠，いくつかの技術的な詳細などを交えながら紹介します。 最初に，このプロジェクトにおける主な出来事と決定事項を年代順に述べます。 後半のセクションでは，最も興味深く，また困難でもあったいくつかのテクノロジの詳細と，それらをいかに連携させて評価版リリースおよび製品版リリースを生み出したかをご紹介します。

決断

2001 年の前半，COMPAQ の上級エンジニア・グループによる Alpha プロセッサに関する評価が終わりました。Alpha は何年もの間，パフォーマンス面で Intel プロセッサよりも優位にありました。しかし，時間とともにその差は小さくなりつつありました。評価チームの結論は，計画されている Alpha プロジェクトをすべてスケジュール通りに進めたとしても，2 つのプロセッサ・ファミリのパフォーマンスは，おそらく 2005 年には同等になり，将来はほぼ間違いなく Alpha の方が遅れをとるだろう，というものでした。

経済的な投資効果を考えると，将来に渡り Alpha の開発を続けることはもはや実現可能なものではありませんでした。進行中だった EV7 の取り組みは継続しますが，それが Alpha プロセッサの最後の開発となり，このチップを搭載するハードウェア・プラットフォームが Alpha ラインの最後の製品となります。 計画されていた EV8 プロセッサの開発はすべて打ち切られました。

発表

2001 年 6 月 25 日月曜日，COMPAQ の上級幹部は，Alpha 開発の打ち切りと，Intel Itanium アーキテクチャへの OpenVMS のポーティングを正式に発表しました。顧客へのメッセージは明確でした。すなわち，将来は，現在の Alpha 計画を継続した場合よりも処理性能に優れたシステムが低価格で提供できる，というものです。さらに，その時期についても次のように発表しました：

「2004 年に Itanium アーキテクチャに対応した製品版品質の OpenVMS をリリースする」

これは，一般の人々だけでなく，OpenVMS 開発チームにとっても衝撃的な発表でした。

アプリケーション・プロバイダに対しては，再コンパイルと再リンクでポーティングが完了すること，すなわち「リ・コンパイル，リ・リンク，アンド，ゴー」を約束しました。このメッセージのバリエーションで有名になったのが，HP Integrity で動作させるまで「あとほんの少しのところいます」でした。これは極めて大胆なメッセージでした。我々はまだ，何をすべきかについて詳しい調査を始めてもいなかったからです。しかしながらこのメッセージが，プロジェクトを通じて，実装に関する決定を行う上での非常に強力な判断の目安となりました。

この壮大な計画のもう 1 つの特徴は，すでに計画されている Alpha OpenVMS のロードマップは変更しないというものでした。このことの重要性を過小評価してはなりません。我々の顧客にとっては重大なことだからです。しかも，大量のエンジニアリング・リソース (エンジニア，ビルド・チーム，リリース・チーム，業務管理チーム，認定/検証チーム，ドキュメント・チーム) が OpenVMS の次期リリースの開発に向けてすでにアサインされており，それを変更するわけにはいきませんでした。

注： この発表からわずか数日のうちに，私は多数のメールを受け取り，その内容は形はさまざまですが次のように書かれていました。「君たちはどうかしている！2 つの特権モードしかないプロセッサで VMS を実行するのは絶対に無理だ！」 そうした人たちに，「Itanium は実際には VAX と全く同じ 4 モードのプロセッサであり，VMS はうまく動く」と安心してもらえるよう努めました。

2001 年 6 月 25 日は「発表」の日であっただけではく，我々がこのプロジェクトを開始した日でもありました。まず，顧客とアプリケーション・プロバイダに，我々が何をしようとしており，それが彼らにとって何を意味するのかを伝えました。我々は，この新しい方針によって影響を受けるエンジニアリング組織とフィールド組織との話し合いも行いました。最後に，開発計画とスケジュールを検討するための情報収集を行う最初のエンジニア・チームを編成しました。

マニュアルを読む

Intel の Web サイトには，ホワイト・ペーパ，最新のハードウェア製品の案内，将来の計画など，非常にたくさんの関連情報が掲載されています。我々は，『Intel IA-64 Architecture Software Developer's Manual』を読むことから始めました。この 4 分冊のマニュアル・セットは，今でもこのアーキテクチャに関する主要な情報源として使っています (http://www.csee.umbc.edu/help/architecture/ から入手できます)。Intel の ACPI (Advanced Configuration and Power Interface) 規格も調査に欠かせないものでした。しかし，これだけで十分でないことは分かっていました。実際にシステムを構築し，実装した人たちと話す必要がありました。

質問： ワードはどのようなときにワードでなくなりますか？

回答： Intel Itanium の用語と Alpha の用語を並べて置いたとき。

1 バイトが 8 ビットというのはどちらのアーキテクチャでも同じですが，データ・サイズが同じなのはそこまでです。VAX/Alpha の「ワード」は 16 ビット長であるのに対し，Intel の「ワード」は 32 ビットです。(「付録 A - 完全な比較を行うために頭痛になる方法」を参照)。この「コミュニケーション・ギャップ」を乗り越えた後，このような根本的な違いをどのように文書化したらよいか，考えました。結局，OpenVMS についてだけ文書化するという長年の伝統を継続し，用語の相違は完全に無視することに決めました。安易な策でしたが，検討した他の選択肢はどれも，ドキュメントの対応策としては見苦しく，何も明確にならなかったのです。

エンジニアたちとの話し合い

COMPAQ のコンパイラ・グループの何人かは，以前のプロジェクトで Intel を経験していました。OpenVMS コンパイラで使用されていた GEM バックエンドはすでに「Itanium 対応」でした。我々はコンパイラ開発者たちに，どのように始めるべきかについてアドバイスを求めました。コードのコンパイルはポーティング・プロセスの第一歩であるため，彼らはすぐに重要な役割を果たしました。

知識の蓄積が勢いをつけはじめ，いくつか主だった決断をする必要があると分かったまさにそのころ，次の「発表」がありました。COMPAQ と HP の合併提案です。この発表は，毎年の COMPAQ Enterprise Technology Symposium のわずか数日前のことであったため，イベントの趣旨そのものが一夜で変わってしまいました。合併完了までに 8 カ月かかるとは，当時の我々は思いもしませんでした。OpenVMS がようやく Hewlett-Packard の一部となったのは，2002 年の 5 月 7 日でした。

歴史に関する補足： Intel Itanium プロセッサ・ファミリ上での OpenVMS の最初の公開エンジニアリング・プレゼンテーションは，カリフォルニア州アナハイムで開催された，毎年恒例の COMPAQ Enterprise Technology Symposium で行われました。プレゼンテーションは 2001 年 9 月 11 日火曜日朝に予定されていました。ところがその朝，世界が止まり，ニューヨーク市の世界貿易センター，ペンシルベニア西部，ワシントン D.C のペンタゴンでのいたましい事件を恐怖の中で見守りました。COMPAQ カンファレンスは，その週の残りの予定を変更することになりました。

「最初の発表」には，Tru64 UNIX もポーティングするという内容も含まれていました。一部の Tru64 エンジニアは，すでに他のプロジェクトで Intel を経験していました。我々は全員同じオフィスにいたので，2001 年 9 月中旬，Intel のアーキテクト・グループ数名を共同でニューハンプシャー州ナシュアに招き，命令セット，オペレーティング・システム・インタフェース，ブート・パス，ACPI を網羅した 3 日間のセミナーを開催しました。それはまさに，目からうろこが落ちる体験でした。マニュアルは我々に基本をみっちり教えてくれましたが，顔を付き合わせた会話を通じて，まだ長い道のりが残っていることが明確になりました。幸い，今度からは，質問があればいつでも相談できるエンジニアがいます。

HP は Itanium アーキテクチャを Intel と共同で開発していたため，HP のシステムはすべてその方向に動いており，我々はその行き先とされていたプラットフォームへのポーティングをすでに開始していたわけです。 5 月 7 日火曜日，我々はすぐに HP のファームウェア・エンジニアから協力の申し出を受け，HP-UX エンジニアとの話し合いも始まりました。このほか，5 月 7 日には，COMPAQ と HP のネットワークと電子メールが結合するという出来事もありました。ドキュメントとエンジニアへのアクセスが，わずか数回のキー操作で行える距離に縮まったのです。数時間のうちに，我々と知識を共有することに意欲的な多数の開発組織へのアクセスが実現したことは喜ばしいことであり，大いに心強いことでもありました。何しろ彼らは，我々が直面しようとしていたいくつもの障壁をすでに克服しているのです。彼らの知識がとても貴重であることは間違いありません。

David Mosberger と Stephane Eranian による著書 『ia-64 linux kernel』は，非常に参考になりました。2002 年春，OpenVMS のエンジニアたちは，マサチューセッツ州マルボロで開催された Mosberger 氏のセミナーに参加しました。同書は Intel のアーキテクチャについて学習したいすべての人にとって有益な参考書であり，http://www.lia64.org/book/ から入手できます。

プロジェクトのかなり早い段階で，我々はコードのポーティングに技術的に大きな影響を及ぼすいくつかの大きな決断をしなければなりませんでした。場合によっては，それらの決断は我々の顧客から見えることもありました。以降のセクションでは，これらの多くの決断について述べます。ただし我々には常に，最初に挙げた最優先課題がありました。それは，既存の Alpha コードの「バグをそのままバグとして」というレベルで互換性を保つポーティングにはしない，ということです。将来 OpenVMS を向上させるのであれば，思い切った決断もします。これから説明するように，何度か限界を押し広げましたが，製品の品質と顧客の要求が，我々の最優先課題でした。

1. Intel 呼び出し標準規則 (さらにはそれ以上のもの) を実装する

これは全く予想外の結果でした。長期の評価を終えた後，Intel 呼び出し標準規則のバリエーションを実装するという結論に達したとき，我々自身も含めて誰もが当惑しました。さらに，我々独自の OpenVMS 標準ではなく，より広く知られている ELF (Executable and Linking Format) 標準と DWARF (Debugging with Attributed Record Formats) 標準を使用することにしました。

この呼び出し標準規則に関する決断は，いくつかの考察に基づいています。パフォーマンスと共有ソフトウェア・テクノロジの利点から，我々はできる限り Intel の規約を使用するように努め，そこから逸脱するのは， オリジナルの VAX の設計から引き継いでいる機能， すなわち多言語間での互換性と相互運用性のために不可欠な特性を 残すために必要な場合に限定しました。 このようなハイブリッド設計を作り出すことは途方もない決断であると考えて いましたが，次の 2 年で，「途方もない」という表現さえ，かなり控え目であったことがわかりました。

Intel の呼び出し標準規則を使用するという決断により，我々は，コンパイラ，ランタイム，OS のエキスパートからなる Calling Standard Committee (呼び出し標準規則委員会) を作る必要が生じました。この委員会の仕事は，VAX および Alpha システム用 OpenVMS 呼び出し標準規則の細部をすべて体系的に評価し，維持すべき点，変更すべき点を洗い出し，「再コンパイルと再リンクでポーティングが完了する」というメッセージに対応するための最善策を取りまとめることでした。OpenVMS C++ および FORTRAN のコンパイラは Intel から提供されることになっていたため，この決断は早い段階で Intel のコンパイラ開発者に伝える必要がありました。

2. ELF/DWARF ファイル形式

ELF/DWARF ファイル形式の選択は，大きな衝撃をもたらしました。コンパイラ，リンカ，ライブラリアン，デバッガ，ダンプ・アナライザ，イメージ・アクティベータなど (一部を挙げたに過ぎません) は，これまでとは全く異なる入力や出力の形式を持つことになるからです。しかし我々は OpenVMS を，アプリケーションと分析ツールのポーティングという世界に，より受け入れられやすいものにしたかったのです。より広く知られている内部フォーマットを採用すれば，それを理解できる開発者も増えるため，アプリケーションにとってより利用しやすいシステムになります。

このプロジェクトの目標の 1 つは，OpenVMS の移植性を高めることでした。今度また誰かがこれを行うことになるかもしれません。呼び出し標準規則，ELF，DWARF の決断により，既存のコンポーネントをポーティングするためのコーディング時間だけでなく，全く新しい実装の概念化とデバッグ作業も付加され，OpenVMS のポーティング期間は 2 倍になりました。 きつい仕事でしたが，その結果 OpenVMS はより優れたシステムになりました。

3. Alpha アセンブラ・コード用のコンパイラは作成しない

OpenVMS の半分は MACRO-32 で書かれているため，コンパイラが必要でした。Alpha 上では AMACRO コンパイラを使用していたため，Integrity 上では IMACRO コンパイラを作成しました。Alpha アセンブラ・コードに関しては，特にアプリケーションの世界ではそれほど多くあるわけではなく，これから書かれることもないだろうという結論に達しました。命令には適切なコンパイラ組み込み関数を，内部の呼び出し標準規則には適切なライブラリ・ルーチン，たとえばスタックのアンワインドなどを提供することで，ほとんどの Alpha アセンブラを簡単に書き直すことができました。 実装担当者が Alpha アセンブラ・コードを書いた理由はこの 2 つではないかと感じられました。

Integrity C コンパイラは asm 要素をサポートしません。我々は，既存の asm コードをすべて C で書き直すことにより，我々の理論の有効性を確認できました。つまり，Alpha アセンブラを含んだ C asm を Intel のアセンブラ・コードに置き換えることはありませんでした。これは非常に良い兆候で，すべてのアプリケーションにとって確実な方法とはいえませんでしたが，「コンパイラは使用しない」という我々の決断が裏付けられました。

4. Alpha イメージ用のバイナリ・トランスレータ

発表の日，我々は，VAX から Alpha へのポーティングのために提供されたようなバイナリ・トランスレータは用意しないと表明しました。バイナリ・トランスレータは，非常に大きく，難しいコードです。この決断はシステムのさまざまなコンポーネントに影響します。基本オペレーティング・システムのコンポーネント，いくつかの RTL，および Alpha ファームウェアにさえ，バイナリ・トランスレータ専用の固有のコードがあります。トランスレータを作成しなければ，我々の手間は大幅に削減できたはずでしたが，顧客に提供するために作成の必要があることが明らかになりました。 この作業は Software Resources International (SRI) 社に委託しました。同社はこの種のアプリケーションを専門としており，別のプロジェクトですでに我々と協力関係にあったためです。

5. Ada - Yes， PL/I - No

OpenVMS はほぼ全体に渡り MACRO-32，BLISS，C で書かれており，多少 Intel アセンブラが必要であることは分かっていました。これ以外に何も使用しなくても，かなりのところまでは行けるはずです。ただし，Ada のコードが少しありました。これは OpenVMS の一部の顧客層では人気があります。我々は，OpenVMS I64 Ada コンパイラを提供するために，Ada Core Technologies と契約しました。

しかし，PL/I コンパイラに関しては逆の決定をしました。OpenVMS アプリケーションの世界では PL/I はほとんど使用されておらず，PL/I から C へのトランスレータが存在するからです (結局，MONITOR の PL/I の部分を C で書き直すことにはなりました。その結果，Alpha と Integrity で共通のコードになりました)。

6. デフォルトの浮動小数点形式は IEEE

浮動小数点形式は，当初予測していたよりもはるかに多くの影響をもたらした大きな決断でした。Alpha では，VAX 浮動小数点形式 (一般に F/D/G として知られています) と IEEE がすべてハードウェアに実装されています。つまり， IEEE に変換してもパフォーマンス上のメリットはありません。Integrity OpenVMS では，VAX 浮動小数点形式はソフトウェアでエミュレートされ，IEEE だけがハードウェア上にあります。アプリケーションによっては，パフォーマンスの違いが非常に大きくなる可能性があります。

我々は，IEEE を Integrity OpenVMS のデフォルトの浮動小数点形式とすることにしました。Alpha 上で形式修飾子を指定せずにコンパイルすると，VAX 浮動小数点が生成されます。Integrity 上では，同じコンパイル・コマンドで IEEE 浮動小数点が生成されます。このことは，最高水準の精度が求められるいくつかの計算には影響を及ぼしますが，エミュレーションをデフォルトにすることから生じるパフォーマンスへの影響を正当化することはできませんでした。ソフトウェア・エミュレーションが遅くても，それが許容できる解決策であるアプリケーションに対しては，/FLOAT スイッチを使用することによって OpenVMS Integrity コンパイラは F/D/G をサポートします。

7. 数値計算ライブラリ

数学ランタイム・ライブラリは，システムにおいて最もパフォーマンスが重視されるコンポーネントの 1 つです。 Alpha 上では，Alpha アーキテクチャ専用に C で書かれています。Integrity 上でこれを再コンパイルするのは好ましくありません。Integrity アーキテクチャ用に最適化された Intel Itanium の数値計算ライブラリを使用することが，有効な代替案に思われました。我々は，Intel からこの数値計算ライブラリを入手することにしました。発表の一部に Intel とのコンパイラ・テクノロジの共有が含まれていましたが，この数値計算ライブラリは，我々がその恩恵を受けた最初の事例の 1 つでした。難点はありましたが，パフォーマンス向上のメリットに比べれば非常に小さな問題で，将来の変更への備えも強化されました。

8. カーネル・プロセス・モデルの拡張

Alpha 上では，RMS，XQP，DECnet などのいくつかの OpenVMS システム・コンポーネントが，複数の実行スレッドをコンポーネント自身で管理していました。つまり，個々のコンポーネントはコンテキスト・スワップの詳細を知っており，実行コンテキストの中断と再開のために必要となる要素をそれぞれの環境で実装していました。 「コンテキスト」の細部の違いにより，これらの実装を Integrity 用に書き直さなければなりませんでした。一部の顧客も同じような設計上の決断をしたことを我々は知っていました。これらの変更はどのようなシステムにおいても困難ですが，Integrity では特に困難です。 変更が必要となるコンポーネントの数を考えると，気が遠くなるほど大変な作業です。同様に，顧客にとっても Integrity へのポーティングの際の非常に大きな課題となります。このため我々は，「カーネル・プロセス」と呼ばれる内部メカニズムを拡張してどのようなモードからも呼び出せるように変更し，この拡張したルーチンを呼び出せるように，プライベートなスレッド処理を行うすべての OpenVMS コンポーネントを修正することにしました。 とても複雑なコードを一度だけ書き，その後呼び出し側を変換していくという方法は，非常に良いアプローチであり，コードの保守性が格段に向上します。もう 1 つの利点として，OpenVMS が Alpha と Integrity で共通のコードになったことが挙げられます。Alpha コードをポーティングするのではなく，新しいルーチンへの変換 (強く推奨します) についてのサンプルを記したドキュメントがあります (Google で EXE$KP_START で検索してください)。

9. ライセンス

OpenVMS を HP の製品としてあらたに提供するために検討すべき点がありました。 OpenVMS のライセンス体系は，HP の既存製品のいずれとも，全く異なっていたからです。大がかりな変更をいとわなければ，このような懸念はなくなります。 Integrity 用の OpenVMS については，必要なレベルのオペレーティング環境 (OE) を購入するという，HP-UX のライセンス・モデルを採用することになりました (Alpha 版 OpenVMS のライセンス体系は従来どおりです)。 これにより，我々はかなりの追加作業を行う必要が生じましたが，推進すべき正しい戦略でした。

OpenVMS のように大規模で複雑なオペレーティング・システムでは，コードの大部分はプラットフォームや CPU アーキテクチャに依存しません。たとえば，デバイス・ドライバ，ネットワーク・プロトコル，クラスタ，ロック・マネージャ，ファイル・システムは，Integrity 上で実行するためにコーディングし直す必要はありませんでした。 しかし，アーキテクチャに関係する非常に大きな課題がいくつかあり，システムのいくつかの領域で集中的に多くの作業が発生しました。

以降のセクションでは，我々の作業の大部分を占めたベース・オペレーティング・システムのコンポーネントについて述べます。これらのコンポーネントは次のどちらかのカテゴリに分類されます：

1. Alpha と類似しているが，細部が異なるコンポーネント
2. Integrity に固有のコンポーネント

提供されなくなった Alpha コンソール

Alpha 上では，コンソールはファームウェア・パッケージの一部です。システムのブートと OpenVMS 用のデバイス検出の際に欠かせない役割を果たします。Intel Itanium アーキテクチャは，特定のオペレーティング・システムに特化せずに複数のオペレーティング・システムからの基本的な要求に対応することを目指しているため，そのブート・パスは必然的に汎用的で最小限の環境となっています。 したがって，ブート・パスは SYSBOOT を開始するところまでは全く新しいコードになります。Integrity 上では，Alpha のファームウェアが提供していた多くのランタイム・サービスを OpenVMS 自身が提供します。

提供されなくなった Alpha PAL (Privileged Architecture Library)

PAL もまた，Alpha のファームウェア・パッケージの一部です。Alpha アーキテクチャはオペレーティング・システムを選びません。オペレーティング・システムが固有の PAL を提供できるようになっています。OpenVMS PAL には，VAX キュー命令，VAX 特殊レジスタ，VAX IPL および権限モード変更管理，割り込み処理，トランスレーション・バッファ・ミスに対処するための PTE フォーマットの情報，およびアラインメント・フォルトのためのコードが含まれています。したがって，VAX でこれらの機能を使用するために特別に書かれたコードは，Alpha でも変更なしで動作できます。 Integrity 上では，これらの機能を OpenVMS 自身が提供することになります。 Alpha PAL の置き換えは特に難しい仕事でした。

異なるプロセッサ・プリミティブ

Itanium のレジスタ・セットは，Alpha とは全く異なり，サイズもはるかに大きいものです。Register Stack Engine は，オペレーティング・システムがこの巨大なスタック環境を管理するのを支援するメカニズムです。OpenVMS において全面的に新しいコードが必要でした。

Alpha では，load-locked 命令と store-conditional 命令のペアが，マルチプロセッサ環境でのデータへのアトミックなアクセスを保証しています。VAX と同様，Itanium にはアトミック性を保証する特定の命令があります。

新しいレジスタ・セットでは，プロセスのコンテキストの保存方法が変わります。このため，独自の「スレッド処理」を行っていたコードはすべて，本格的な変更を行う必要がありました。

Alpha PAL は，オペレーティング・システムに割り込み通知を行う前に，多数の割り込み処理を実行します。このポーティング・プロジェクトの最も大きな部分の 1 つが，SWIS (Software Interrupt Services) でした。これは，割り込み処理，および関連するモード・チェックと管理を完全に制御する Integrity 固有のコードです。

呼び出し標準規則の影響

Intel 呼び出し標準規則のレジスタ規約とスタックの使用法は，Alpha 呼び出し標準規則のそれとは大きく異なります。レジスタの違いから多数のソース・コード・モジュール，特に MACRO-32 と BLISS で書かれたモジュールを変更するのを避けるために，Alpha の R0 〜 R31 から Itanium の R0 〜 R31 へのマッピングを定義しました。コンパイラは，スイッチに基づいて自動的に変換を行います。ただし，プログラマはデバッグ時にこのレジスタのマッピングについて知っている必要があります。このマッピングは，ワークステーションにメモとして貼り付けられ，そこから PowerPoint スライド，やがてマウス・パッドへと進出していきました。マウス・パッドは，今でも貴重な参照先となっています。(レジスタ・セット全体については，「付録 B - OpenVMS Alpha と Itanium のレジスタのマッピング」を参照してください)。

Integrity の例外処理では，VAX と Alpha で慣れ親しんだ「フレーム・ポインタ」のスキームではなく，「PC マッピング」を使用します。さらに，2 つのスタックを調整する必要があります。すなわち，ハードウェアによって管理されている整数レジスタ・スタックと，生成されるコードによって管理されるメモリ・スタックです。VAX と Alpha では，情報を見つけるためにプログラマが「スタックを歩く」ということを行っています。Integrity のメモリ・スタックには，この種の情報はごくわずかしかありません。呼び出し元の保存レジスタを見つけるには，プログラマは，現在の PC をインデックスとして使用して，一連の保存レジスタを指す「アンワインド・テーブル」を探します。コンパイラによって作成されたアンワインド・データは，イメージの起動時にアンワインド・テーブルに読み込まれます。アンワインド・テーブルの使用は，例外処理の基礎となっています。

注： 我々は，OpenVMS においてこの情報の入手先が 1 つだけとなるように，LIBRTL 呼び出し標準規則内のルーチンを，すべての特権モードから使用できるようにしました。

基本オペレーティング・システムと LIBRTL アンワインド・インタフェースが正しく動作するまで，永遠に時間がかかるように思えました。我々が受け取る例外処理に関する問題レポートは，何カ月もの間，途切れることがありませんでした。コードが正しく機能するようになった後も，そのパフォーマンスの向上のために，2 回の書き直しが行われました。予想通り，ここはプロジェクトの中でも困難を極めた部分でした。

ELF/DWARF の影響

ELF/DWARF 内部フォーマットを使用するという決定により大量のコード を追加することになりましたが，最も影響を受けたのが我々自身の開発ツールであったため，先の見通しを計画することも困難になりました。 独創的なデバッギングの発想が何よりも重視されました。

2001 年後半中に，我々は開発計画の断片を組み合わせて暫定スケジュールを組みました。これは，初期の依存関係を把握するのに必要でした。長期の計画ではありませんが，全員が動き出し，自分たちが現状を把握しているかどうかを判断するには十分でした。

Alpha と Integrity で共通のコード・ベース

実装に関する最初の決断は，Alpha と Integrity の共通コード・ベースを作ることでした (VAX と Alpha ではコード・ベースは異なります。このような失敗を繰り返すつもりはありませんでした)。実際には，既存の Alpha ソースに Integrity サポートを追加しました。以下の 3 種類の作業となりました：

• Integrity 固有のモジュールをいくつか作成する
• 既存モジュール内でコードを条件分岐させる
• いくつかの既存ルーチンを両方のプラットフォームで実行できるように書き直す

共通コード・ベースを作成するということは，これから見ていくように，このプロジェクトが VAX から Alpha へのポーティングとはまるで異なるプロジェクトになるということです。

外部の協力

我々が「OpenVMS Alpha の開発スケジュールは変更しない」と約束したことを思い出してください。我々は，Alpha の開発を継続しながらポーティング作業を行わなければなりませんでした。新しい Integrity 作業の一部は，特定の OpenVMS エンジニアにしかできない作業でした。しかし，それよりもはるかに多くの作業は「リ・コンパイル，リ・リンク，アンド，ゴー」の方針でうまくいきました。

EDS は何年もの間，多くの OpenVMS ユーティリティをサポートしており，エンジニアも我々のコード，ビルド手順，インテグレーション・テストに精通していました。このため，多くの OpenVMS ユーティリティとレイヤード製品のポーティングを EDS に委託しました。その中には，EDS がサポートしたことのないものも含まれていました。OpenVMS コードの大部分のポーティングとテストを担当した EDS エンジニアのおかげで，我々はスケジュールを守ることができたのです。

さらにいくつかの協力会社が，我々の当初のスケジュール要件を満たす上で重要な役割を果たしました。以前から OpenVMS の内部について経験を積んでいたため，Integrity 固有のコードに取り組んだその日からすぐに貢献してくれました。

プロジェクトの依存関係とスケジュール

簡単にいうと，方針は，書いて，コンパイルして，リンクして，実行するべし，というものでした。計画の初期段階から，我々は BLISS コンパイラと C コンパイラを先に用意する必要があり，数カ月後に Intel アセンブラ (IAS) と IMACRO を，そして LINKER はかなり先でもよいと認識していました。コードのリンクとデバッグができるようになるまでに，大量のコードを書き，コンパイルしました。このことが，その後の数カ月に多くの影響をもたらしました。 V8.0 をリリースした後の LINKER は OpenVMS のどのコンポーネントより多くの変更を受け，その機能の進化にともない，次の年には各コンポーネントにさらに多くの変更が行われました。

SCD (System Code Debugger) もまた遠い先の約束でした。SCD は，DEBUG と同種の機能ですが，カーネルとドライバのデバッグに使われるという点が異なります。残念ながら，非常に長い間，我々がデバッグに使用できたのは XDELTA および print 文だけでした。このことがどの程度スケジュールに影響するのかは分かりませんでした。確実に分かっていたのは，SCD がなければ何もかも長引くだろうということでした。

最大の難関は，十分に機能する OpenVMS を，レイヤード製品の無数のエンジニアリング・グループ (DECthreads，Java，DECnet，TCP/IP，DECwindows など) に届け，彼らがそのポーティング作業に移れるようにすることでした。

VAX から Alpha へのポーティングを参考に

このプロジェクトに携わる多くのエンジニアは，何年も前に VAX から Alpha へのポーティングを経験していました。その経験をできる限りたくさん，現在の作業に対する洞察力に変えようとしました。 確かにいくつか共通点はありましたが，大きな違いもありました。 VAX から Alpha へのポーティングと比較するのは当然のことです。 技術レベルでの顕著な違いは，「広く浅く」対「狭く深く」であるといえます。

VAX から Alpha へのポーティングの際には，主に次の 2 つが大きな課題でした。

1. OpenVMS は過去に一度もポーティングされことがない。MACRO-32 コードのすべてをコンパイルし，妥当な期間内で動作させるにはどうすればよいか？
2. OpenVMS は 32 ビット VAX アーキテクチャ専用に書かれている。それを 64 ビット・アーキテクチャで動作させるために，何をすべきなのか？
   Alpha の場合は，システムごとに OpenVMS 専用の PALcode があり，それがシステムを VAX によく似たものにしていたため，懸念事項はほとんどありませんでした。実際，プロジェクト全体は EVAX，すなわち「拡張 VAX」と呼ばれていました。

これは「広く浅い」プロジェクトでした。大量のコードを変更する必要がありましたが，大部分は難しい作業でなかったのです。

Alpha から Integrity へのポーティングは，大きな難関が 1 つありました。それは，Integrity は VAX とは全く似ておらず，いくつかの概念とオペレーティング・システムのコア部分のコードが完全に新しいものになることでした。一方，システムの大部分は，必要な作業はあってもそれらはごくわずかでした。これは「狭く深い」プロジェクトでした。エンジニアの数ははるかに少なかったのですが，「1 ビットもなし」から「出荷開始」の状態になるまでに要した時間は VAX から Alpha へのポーティングの際とほぼ同じでした。

評価版リリース

我々は正式なフィールド・テストの前に，1 つの社内用ベースレベルをいくつかのグループに配布し，次に 2 つの社外向け評価リリースを公開することにしました。 社内用ベースレベルはコンパイラ・グループに提供し，生成したコードが正しく動作するか彼らが検証できるようにしました。

最初の評価版リリース (E8.0) の目標は，アプリケーション開発者が Alpha 上でコンパイルおよびリンクして生成したイメージを Integrity 上で実行できる，「クロス・ツール」環境に仕上げることでした。 限られたコンパイラ群で構成され，オペレーティング・システムの大部分を揃えていました。 制約はありましたが，E8.0 は我々の成果を少し公にすることになり，冒険好きな社外の開発者たちに試してもらうことができました。

その 6 カ月後に第 2 の評価版リリース (E8.1) をリリースし，目標は Integrity システム上でコードのコンパイル，リンク，実行ができる「ネイティブな」環境を用意することでした。システムの完成度が高くなるようにパートナーを増やしました。 この段階で，もう 1 つ新しいハードウェア・プラットフォームを追加できたことになります。

この 2 つの評価リリースは，Integrity 専用でした。Alpha と Integrity の両方の顧客が OpenVMS の新しいバージョンを目にするのは，正式なフィールド・テストのときでした。 48 台の Alpha へのインストール，54 台の Integrity へのインストールという，OpenVMS 史上最大規模のフィールド・テストとなりました。

開発が始まった正確な日付を特定することはできません。次の数カ月間は，何が必要なのかを設計チームが把握し始めていく中で，こまごまとした作業が個別に発生していました。同時に，手順が確立され，それに基づいて開発環境が構築されました。 2001 年末までに，小集団のエンジニアが連携するようになり，一体となって動き始め，勢いが増しました。初版のストリーム・コードの変更が行われたのは 2002年 1 月 15 日でした。

2002 年 2 月 1 日の「The Inquirer」(http://www.theinquirer.net) の ヘッドラインは，我々に対する信頼感が感じられて光栄でした：

クールです。このときはまだ最初のコード・チェックインの 13 日前でしたが，とにかくこの報道を気持ちよく読みました。

コンパイラ

当初，我々が使用できるのはクロス・ツール環境に限られていました。コンパイラを Alpha 上で実行し，Integrity 用のコードを生成しました。こうした状況が長い間続き，少なくとも，Integrity 上での OpenVMS の実行までに 1 年かかりました。ここでもまた，独創的な考え方が貴重であることが証明されました。

ビルド・コンパイラがすぐに適切なコードを生成していたら，実行可能なシステムにもっと早くたどり着いたことでしょう。C コンパイラ・エンジニアは，プロトタイプの Integrity Linux コンパイラを作成し，生成されたコードと ELF/DWARF の生成を Integrity Linux システムでテストしました。コンパイラに関する Linux の作業のほとんどは，我々が販売していた Alpha Linux コンパイラ用のものがすでに開発されていましたのでこれを利用しました。 2001 年 9 月，Integrity Linux コンパイラの作業が開始し， コンパイラ・エンジニアたちが，彼らの既存のコンパイラを使ってコード生成の約 95% と，最初のシステム・ブートに必要な ELF/DWARF 生成の大部分をテストしました。

初期のコンパイラ開発で重要だったのは，OpenVMS に必要な組み込み関数を特定する作業でした。コンパイラ・チームはいくつかの既存の Intel コンパイラを調べてその組み込み関数から着手し，オペレーティング・システムに必要なものが明らかになるにつれていくつかを追加しました。MACRO-32 と BLISS に関しては，Integrity に固有の新しいコードは C で書くことになっていたので，組み込み関数はほとんど必要ありませんでした。

OpenVMS は，Alpha 上ではかなりの量の C ASM を使用しています。これにより以下のことが可能です：

• 呼び出し元のリターン・アドレス・レジスタとして R26 を参照
• LOAD-LOCKED / STORE-CONDITIONAL 命令を使用したアトミックなプログラミング

Alpha と Integrity の C コンパイラはどちらも，組み込み関数 __RETURN_ADDRESS および __CMP_SWAP_QUAD を定義していたので，ASM を排除して共通コードを作成しました。

MACRO-32 コードには特別な問題がありました。VAX から Alpha へのポーティングは，(そのように設計したのですが) 呼び出し標準規則がほぼ同じであったため簡単でした。今度は，全く異なる呼び出し標準規則に直面しています。最も大きく異なるのは，Intel の呼び出し標準規則で定義されている汎用保存レジスタは 4 個だけ (R4 〜 R7) であるのに対し，Alpha では 14 個 (R2 〜 R15) だという点です。これは，MACRO-32 コードでの多くの前提条件が，Integrity では適用されないことを意味します。 IMACRO (Integrity 上での MACRO-32 コンパイラ) は，この違いを認識しており，新しいコンパイラ・ディレクティブによって明示的に指定されない限り，危険にさらされる可能性のあるレジスタを保存/復元します。我々は，特にパフォーマンスが重要な処理の場合に，この種のコードを適宜書き直しました。

R0 または R1 以外のレジスタにデータを戻すルーチンへの CALL に対しても，IMACRO が戻された値を上書きしないように，新しいディレクティブによって指定する必要があります。我々は，レジスタの前提条件が有効でない可能性がある場合に，LINKER が診断警告メッセージを提供する手法を考え出しました。最初は手間がかかりましたが，その後これが大いに役立ちました。次に，OpenVMS で使用されているすべてのリンケージを新しいファイル $IA64_LINKAGES で定義しました。このファイルは，ARCH_DEFS.MAR を使って各 MACRO-32 ソース・モジュールに挿入されます。

MACRO-32 のもう 1 つの問題は，CALL の手動によるコーディングでした。つまり，引数を R16 〜 R21 へ移動し，引数の数を R25 に入れ，次に JSBing を標準の CALL ルーチンに置くという作業で，これはもうひどかった！ 呼び出し標準規則の違いのために，これらのすべての出現箇所を変更しなければならなかったので，それらのコードを CALL に書き直しました。世の中が完璧だったとしたら，すべてが標準 CALL になっていたはずですが，そのようなことは，OpenVMS 開発の最初の 12 年間は誰も考えもしないことだったのです。ある意味では，「VAX から Alpha へのポーティングでは楽をしすぎた」のです (Alpha から Integrity へのポーティング・プロジェクトの間，これが我々の口癖になりました)。

BLISS グローバル・レジスタは予想外に難関でした。BLISS グローバル・レジスタは，イメージ内のすべてのモジュール (FAB を含む RMS の GLOBAL REGISTER など) で共用するために定義されたレジスタです。これは，どの Intel のレジスタ規約にも合いません。BLISS のコード生成は，「生きた」値が入っている可能性のあるレジスタを認識し，それを保護するように拡張されました。

何年も前に，「The Thing (遊星からの物体 X)」というホラー映画がありました。我々はその子孫の 1 つと思われる NaT (Not a Thing) というものに遭遇しました。NaT は，レジスタの 65 番目のビットです。これが設定されていると，そのレジスタの内容は無効であることを意味します。投機的アクセスの一部として使われます。特殊な命令を使用しない限り，レジスタをメモリに保存できるのは NaT ビットが 0 の場合 (レジスタが NaT でない場合) だけです。つまり，投機的アクセス (変更なし) はできますが変更はできないということです。

これは，IMACRO にとっては新しい概念であり，問題がなくなるまでしばらくかかりました。また，コンテキストの切り替え時に NaT の状態を正しく維持するのは簡単ではないことが分かり，オペレーティング・システムも苦しみました。そしてついに怪物は退治されました。

Itanium アセンブリ言語の学習

我々は，アセンブラ・コードはできる限り書かないという目標を持っていましたが，多少は発生すると分かっていました。アセンブラなしでどう始めればよいでしょう。IAS を OpenVMS にポーティングするまでに数カ月を要します。原因は難易度ではなく，タイミングとスケジュールです。最終的にはオープン・ソースの IAS アセンブラを使い，我々の ELF 拡張をいくつか追加し，比較的小規模の作業となりました。しかし一方で我々は，Itanium1 ProLiant DL590/64 を入手し，Linux をインストールしました。マニュアルを読むのも方法の 1 つですが，3 つの命令で構成されるバンドル，プレディケート，アンワインド・ディレクティブについて本当に学べたのは，Linux システム上で C コードを書いてコンパイルし，生成されたコードを調べることからでした。

実際，以下は最初に Linux 上で GNU C とアセンブラを使ってコンパイルし，デバッグしました。

• SWIS (Software Interrupt Services)
• EXCEPTION
• IVT (Interruption Vector Table)
• TLB (Translation Lookaside Buffer) ミス・ハンドラ

しばらくの間，この重要なコードのコンパイル，リンク，デバッグには， Itanium ハードウェア上で実行する Linux ツールを使用しました。これにより，IPB と SYSBOOT で必要になったときには，OpenVMS の基本機能は準備できていました。

最初に ELF/DWARF を採用すると決定した時点では，初期の開発中にそれがどれだけ役に立つのか認識していませんでした。アプリケーションにとって意味があるとした根拠が，OpenVMS にとっても意味があったわけです。

Alpha PALcode の置き換え

主に，次の 3 つの領域での作業となりました：

• OpenVMS の知識をほとんど必要としない，割り込み，IPL，権限モード管理
• 直接的な PAL ルーチン呼び出し
• メモリ管理

期間短縮と簡便性を考え，我々は，C，IMACRO，BLISS 用に適切なヘッダとライブラリ・ファイルを作成することによって，個々の PAL 呼び出しに対してシステム・サービスを定義しました。これにより作業が迅速に進み，その後のパフォーマンス改善も楽になりました。

SWIS は，OpenVMS を Integrity 上で動作させるための心臓部です。システム内で IPL および権限モードのチェックと操作を必要とするものはすべて SWIS によって制御されます。SWIS ログのデータは，我々が遭遇した重大な問題のデバッグを行う上での頼みの綱となりました。

入り組んだ VAX キュー命令のエミュレーションは，開発の初日から問題となりました。このような命令は多数あり，複雑でもあります。OpenVMS は，これらの命令の多くがないと全く動作しません。

メモリ管理の変更としては，仮想アドレスから物理アドレスへの変換，アラインメント・フォルトの処理，PROBE エミュレーションがありました。我々は，Alpha の仮想アドレス変換および GH リージョンを持つアドレス空間レイアウトを維持する仕組みを，Itanium の基本要素である VHPT を使って考え出しました。

ポーティング・ガイドライン

我々は，コーディング規則を記した簡単なドキュメントを作成しました。我々は，Alpha の V7.3-2 を本格的に開発しながら，Integrity をサポートするためのコードを Alpha のソース・コードに追加していました。 この種の作業を必要としたのはコードそのものだけではありません。共通のソースから，共通のビルド手順で，同じクラスタ上で Alpha と Integrity を対象にビルドを行っていたため，開発環境にも本格的な拡張が必要でした。ポーティングのガイドラインは，プロジェクトのあらゆる面で必須だったのです。この小さなドキュメントは，充実するにつれて我々以外の開発グループにも使われるようになりました。

コンピュータ・プログラマが「バイナリ思考」なのは不思議なことではないと思うかもしれませんが，我々はかなり早い段階で，既存のコード・ベースの一部とビルド環境が，もっと違いを考慮するべきなのに「VAX か Alpha か」と決め打ちするようなアプローチを採っていることに気が付きました。これは，VAX から Alpha へポーティングしたときの我々の状況を考えれば，全く理解できることでした。しかし，それは近視眼的であり，後で多くの手間がかかる要因となります。このような失敗を繰り返すつもりはありませんでした。

我々からプログラマへの最初の注意の 1 つは，「二元論的な条件分岐には注意」し，将来のためにできる限り汎用性のあるものに変更せよ，というものでした。条件分岐はすべて入念にチェックしなければならず，そのうちの多くは変更が必要でした。これは，DCL コマンド・プロシージャや，C や BLISS などに関しても同じでした。このことは非常に重要だったため，条件分岐を 1 つチェックするたびに，コードの変更が必要ない箇所にもエンジニアは「IA64 用に確認済み」というコメントを追加しました。以下にいくつか例を挙げます：

• IF VAX (.....) ELSE (.....) ENDIF
• IF ALPHA (.....) ELSE (.....) ENDIF
• IF VAX (.....) ENDIF の後に IF ALPHA (.....) ENDIF

これらの命令は，3 つ目の選択肢がくると問題になることは明らかです。最初の 2 つの例では，Integrity 上で VAX または Alpha のコードが使われることになります。Integrity 上でコンパイル・エラーまたはリンク・エラーが発生し，プログラマは調整を考えなければなりません。しかし 3 つ目の例は，Integrity 上でエラーは発生しないながらもコードが全く生成されないので，特に問題です。我々は既存の条件付きコードに対して必要な作業量を，明らかに過小評価していました。読みやすい共通のソースを維持するために，我々は頻繁に条件をマクロ内に埋め込みました。

ブート・シーケンスが形になる

2001 年の秋，我々は最初の HP i2000 を購入しました。我々は，まだ COMPAQ に属していましたが，HP との合併提案が発表された直後であり，i2000 があれば新生 HP で 幸先の良いスタートが切れると考えていました。

間もなく，ブート・パスの設計およびコーディングの担当者たちと，定期的な調整ミーティングが必要になりました。第 1 回目の「デバッグ・ミーティング」が 2001 年 11 月 14 日に開催され，その後約 2 年間，週に何回もこのミーティングが続きました。進捗確認のためではなく，我々の無知をさらけ出す間抜けな質問をしたり，特に互いに学び合ったりするためのミーティングで，毎回，どこか愉快なミーティングでした。デバッグ・ミーティングは開発者のみが参加し (マネージャは参加不可)，30 〜 45 分程度で仕事に戻りました。何がうまくいき，何がうまく行っていないかや，どうしたら先に進むことができるかを，非常に細かいレベルで話し合うことが目的でした。

2002 年春，我々は，Intel プロセッサ・ベース製品の開発会社に貸し出される，数台の Intel 「ホワイト・ボックス」，すなわち汎用の開発スタート用エンジニアリング・サンプルを入手しました。これらのホワイト・ボックスで，システムの数は 2 倍近くに増えました。さらに，設計と開発に役立つさまざまな実験テクニックを学び始めていました。

議論を進めるに際し，ブート・シーケンスの定義を「ブート・コマンドが発行されてから，必要な execlet (OpenVMS のコアを構成するイメージ一式) をすべて読み込むまでに必要なコード」としました。次のコードがその対象です：

• VMS_LOADER.EFI
• IPB.EXE
• SYSBOOT.EXE
• EXEC_INIT.EXE

コードの説明に入る前に，Intel によって定義されている汎用のブート・パス構造を見てみましょう。

1. ブート・デバイス上には FAT (File Allocation Table) パーティションが必要です。OpenVMS には，PC で使われる意味でのディスクの「パーティション」はありません。OpenVMS の FAT パーティションはコンテナ・ファイルです。つまり，システム・ディスク上にあり，特殊な内容とフォーマットを持つ，通常の OpenVMS ファイルです。

2. パーティション内のファイルの 1 つがオペレーティング・システムのローダです。このファイルは，Intel Itanium アーキテクチャ・システム上でのブートを目指す各オペレーティング・システム開発グループによって作成されます。

.EFI の拡張子から分かるように，最初に実行するコードは OpenVMS イメージではありません。OpenVMS エンジニアリング・チームによって書かれた EFI (Extensible Firmware Interface) アプリケーションであり，これがシステムを準備して IPB.EXE を読み込み，起動します。IPB は Itanium Primary Bootstrap で，Alpha 上では APB.EXE，VAX 上では VMB.EXE に相当するものです。このローダには，ブート・シーケンス・ロジックに加えてプリミティブなファイル・システムが含まれており，通常のメカニズムが利用可能になる前に，OpenVMS イメージの検索，読み込み，起動を実行できるようになっています。このため，実行される最初の部分のコードも，ELF イメージの内部構造について知っていなければならないのです。

ローダは Integrity 用の全く新しいコードです。 このローダは，IPB.EXE が，Alpha における同等の機能と同じような動作をするための環境を整えるもの，という見方もできます。 VMS_LOADER.EFI は，構成ツリーや HWRPB の作成など，Alpha においてはファームウェアが実行する処理を多数実行します。IPB は，SYSBOOT.EXE のために，Alpha と同じ状態を Integrity 上で実現するためにできる限りのことを行います。 SYSBOOT.EXE を開始した後は，外部インタフェースからは多くのものが Alpha とほぼ同じに見えます (たとえば，システム・パラメータの確認と変更の停止など)。SYSBOOT.EXE はデータ構造体をいくつか作成し，いくつかの execlet を読み込み，最後に EXEC_INIT.EXE に制御を渡します。

この時点で，ブート・シーケンス内のプラットフォーム固有コードの大部分は完了します。EXEC_INIT.EXE は，残りの execlet (通常は 20 数個) を読み込み，その初期化ルーチンを実行し，最後に SWAPPER プロセスに制御を渡します。

このプロジェクトのもう 1 つのテーマは，よほどの理由がない限り「違うものにしない」でした。これは，いくつかの領域で難問になりましたが，特に ACPI とブート・パスとの関係がそうでした。「違うものにしない」ことの 1 つは，HP Integrity 対応の他のオペレーティング・システムが Intel の仕様に従って何かを厳密に行っているのであれば，OpenVMS でも同じアプローチをとる，ということでした。我々は，アーキテクチャやファームウェアの設計者および実装担当者が特別な対処を必要としないように努力しました。システムのブートは，オペレーティング・システムごとに大きく異なる可能性のある領域の 1 つです。具体的に言うと，ほとんどのオペレーティング・システムは，1 つの巨大なファイルを読み込むことによってブートが成り立っているのです。 必要なコードはすべて実行中であるとの認識のもとで，ACPI は，次にすべての構成データを提供します。これは，明らかにこれまでの説明の中で見てきた OpenVMS モデルとは異なります。

原始的なデバッグ作業

デバッガが持つぜいたくな機能やクラッシュ・ダンプをとる能力が得られるまでは，さまざまな形の print 文が，問題を見つけ出す唯一の手段でした。我々はしばらく print 文に苦しみながらも進展はしていました。そこに特効薬の 1 つが実現しました。命令デコーダです。呼び出し可能な命令デコーダと命令フォーマット構造定義は，DELTA，XDELTA，DEBUG，SDA，SCD，PCA など，あらゆるデバッグ・ツールの土台となります。さらに，フォーマット定義はアラインメント・フォルト処理の際に基本オペレーティング・システムによって使われます。XDELTA が機能するようになると，ブレークポイントとシングル・ステップ命令が生産性向上に役立ちました。基盤となるデバッグ・コードのほとんどは，Integrity 用の全く新しいコードでしたが，「古い」ものが 1 つありました。PSR.ss ビットの設定方法が VAX の Tbit にそっくりなのです。ただし Alpha 上よりはずっとシンプルです。

クラッシュ・ダンプが可能になったことは，このようなプロジェクトでは重大な出来事であり，最初の 1 回は全く意図せずに起こりました。何かのコードを進めているときに，ブレークポイントが間違って配置されました。";P" によって ACCVIO が発生し，そして何と，クラッシュ・ダンプが完璧に実行されたのです。コードはコンパイルとリンクが済んでおり，実行されるのを待つだけでした。クラッシュが喜ばしい出来事になった，めったに見られない瞬間でした。

初期の「ビルド」

2002 年の前半中に，かなりの量のコードが書かれ，コンパイラも形になり始めました。いくつかの OpenVMS ソース・コードの機能は，まだ Integrity 向けビルドの初期段階にありました。 Integrity 用のフル・ビルドを行うにはあまりに早い段階だったので，前進するために必要ないくつかの部分に集中しました。初期のうちは，これらのいくつかのイメージだけをビルドして OpenVMS Alpha システム・ディスクにコピーし，それを使ってブートの初期段階をテストしました。少し面倒なやり方でしたが，少数のエンジニアで実行でき，とてもうまく進行しました。業界標準コンポーネントの採用で良かった点の 1 つは，新たにいくつかディスクが必要になったときには，いつでも CompUSA に行って入手できるという点があります。これは OpenVMS の開発にとって，全く新しい概念です。

プロジェクトのこの段階では，OpenVMS の大部分をどのようにビルドするかを司る LIBRARIAN はまだありませんでした。我々は，大きなオブジェクト・ライブラリは作成せず，.OBJ も削除しないようにビルド・プロセスを変更し，次に，すべてのリンク・プロシージャを変更して，.OBJ をライブラリから取り出すのではなく直接含めるようにしました。

当時は LINKER の機能が非常に限定されていたため，OpenVMS を通常とは全く異なる方法で実行せざるを得ませんでした。LINKER は単一のイメージをリンクしますが，ベース・イメージを通じて次々と呼び出される execlet をまだリンクできていませんでした。20 年前 (V5.0 よりも前) に OpenVMS を経験していた人であれば，モノリシックな SYS.EXE のことを思い出すでしょう。それは現在の我々が必要としているものではありませんでしたが，非常に巨大な SYSBOOT.EXE が役割を担いました。 成長するブート・パスのデバッグの非常に早い段階では，通常は execlet にある必要なすべてのコードが，SYSBOOT.EXE にリンクされました。この先祖返りのような方法は長く使うものではありませんでしたが，1 日も無駄にはできませんでしたし，これにより我々は前に進むことができました。

2002 年 6 月 3 日，最初の全体的な Integrity ビルドが発表されました。ブート・パスの作業を担当したエンジニアを除き，一般のエンジニアにとっては，ここがコードのコンパイル結果を見るための実際の出発点でした (大まかに言い換えると，この段階で，MACRO-32 コードが新しい IMACRO コンパイラをうまく通ったことが明らかになった，ということになります)。

HP の一員となった我々は，2002 年 7月，rx2600 の最初の社内向けのハードウェアを受け取りました。プロジェクトは，ほぼ通常どおりに開始されていました。 つまり，定期的なビルドと定例ミーティングが行われ，開発システム数は増加し，いくつかのコードがうまく動作しました。i2000，ホワイト・ボックス，さらに rx2600 が導入され，重要な作業を行うそれぞれの開発者に，独占的に使用できるシステムが行き渡りました。実装担当者の数が増えるにつれて，もっと優れた，多数のプロシージャが必要になりました。

Integrity 上でまだネットワーク機能がなかったため，開発クラスタから Integrity システムへ手早く簡単にファイルを移動する手段が必要でした。我々は HP ディスク・システム 2100 (「ピザ・ボックス」あるいは「パンケーキ」などと呼んでいました) を持ってきて，これを小さな OpenVMS Alpha システムと 6 台の Integrity システムに接続し，同じ構成をいくつも再現しました。当然これは完全にサポート対象外の構成でしたが，マウントとマウント解除を慎重に行うことでうまく動作しました。我々は開発クラスタ上でビルドし，生成されたキットを「サーバ」の Alpha にコピーしました。各開発者は，指定されたディスク上でシステム・ディスク・ビルドを実行し，それをマウント解除し，Integrity システムをブートしました。

この頃から，再配置データ，アンワインド・データ，命令の数により，Integrity 上のイメージ・サイズがどれほど大きくなるのか認識し始めました。それに加え，現場のデバッグを支援するために作成すると決定したトレースバック情報もあります。その結果，Integrity 上の OpenVMS イメージ (アプリケーション・ソフトウェアとオペレーティング・システムのイメージ) は，Alpha 上の対応するイメージの約 3 倍の大きさでした。

「初ブート」は，このようなプロジェクトにおいては常に一大イベントです。しかし，技術的な観点からは，これは最終目標に到達できる可能性があるという，ささいな実証ポイントでしかありません。見えないところでのごまかしも多く行われるので，限りなく幻想に近いのです。大部分の人がこのことを理解しています。それでもやはり，積み上がった期待から非常に盛り上がるのです。

Integrity OpenVMS の初ブートは，公開コンテストになりました。ブートの日付を正確に予測して賞を獲得しよう！ (しかしながら，そもそも何かを動作させるために奮闘している場面で，まして，システム・ブートのような目立つことにフォーカスするのは，我々にとっては単にプレッシャーが増すだけでした)。

コンテストには必ずルールがあります。「初ブート」の正式な定義は，次のとおりでした。

1. システムは "MIN" でブートすること。
2. SYSTEM としてログインできること。
3. $ DIRECTORY が正しいファイル一覧を返すこと。

セキュリティ，ネットワーク，クラスタリング，SMP，バッチ，エディタ，あるいは，絶対的に必要ではないその他ものについては，要件には入っていませんでした。

プロジェクト計画のために予定日を見積る際に，我々は VAX から Alpha へのポーティングを振り返りました。そのときは，OpenVMS をブートしたのは，適度に信頼性のあるリンクされたイメージができてから 6 カ月後のことでした。当時我々は，開発中のハードウェアで作業していました。Alpha から Integrity への初ブートの場合は，実際に出荷されている HP 製品である Integrity システムを使っていることを考慮して，期間を半分と考えていたため，目標を 3 カ月と定めました。つまり，2003 年 2 月 13 日でした。苦心のエンジニアリング計画にもかかわらず，我々が 2002 年末までのブートを目指していると，誰かが世界に公表してしまいました。

幻想ばかりじゃない

最低限の初ブートであっても，達成するためにはシステムの多くの基本部分が動作していなければなりません。以下にいくつか挙げます：

• IMACRO-32，BLISS，C コンパイラ
• LINKER
• デバイス検出
• メモリ・レイアウト
• デバイス・ドライバ
• プラットフォーム・サポート
• 割り込み
• クロック・チック
• メモリ管理
• IPL の引き下げ/引き上げ
• AST 配信
• MOUNT
• ファイル・システム
• RMS
• DCL
• イメージ・アクティベータ

条件の範囲内であれば，ごまかしは許され，推奨さえされていました。例外処理，エラー戻り，セキュリティ，課金情報は，DIRECTORY リストが正しい限り無視しても問題ありませんでした。

Integrity OpenVMS の初ブートの正式な日時は，2003 年 1 月 31 日午後 3 時 31 分 (東部標準時間) で，HP i2000 (Itanium1) システム上でのことでした。ブートが確認されると，互いに抱き合い，握手し，祝いの言葉を掛け合いました。我々の自信と安堵感も一気に高まりました。確認されたブート・コンテストのディレクトリ出力と，コンテストの勝者は，付録 D「ブート・コンテストの公式発表：2003 年 1 月 31 日午後 3 時 31 分 (東部標準時間)」に記されています。

注： ファイルをリストした後に，$ プロンプトに戻っていません。コンテストのルールで，特にそのようにしました (指摘に備えて念のために書いておきます)。理由は，DIRECTORY コマンドの処理の最後のイベントは，「ファイルが見つかりません」を戻すことだからです。システムでシグナルやエラーの処理が可能になるのはまだ先なので，最後のファイル名を出力した後，ブレークポイントで停止したのです。

初ブートで使用したファイルの完全なリストは，付録 E「ブート・コンテスト・コード」にあります。

社内用ベースレベル - 2003 年 3 月 28 日

2003 年 3 月 17 日，OpenVMS は HP rx2600 (Itanium2) システム上でブートしました。これが，我々の初期のユーザのほとんどが持つことになるプラットフォームでした。それから 2 週間と経たない 2003 年 3 月 28 日，我々は最初の社内用のベースレベルをコンパイラ・グループに公開しました。間違いなく順調に進んでいました。自信を持ってシステムを他のグループに提供し，彼らの開発とテストをしたいという期待に十分応えられる状態になったのは，飛躍的な前進でした。間もなく DECnet と TCP/IP が利用できるようになり，開発システムの共有が簡単になりました。

2003 年 5 月 15 日，我々は，初めて Alpha システムと VAX システムが混在するクラスタ内で Integrity システムをブートしました。クラスタのデモが最初に公開されたのは，2003 年 5 月 19 日，アムステルダムの HP-Interex Conference においてでした。我々の開発ラボ・クラスタからの $SHOW CLUSTER コマンドの出力については，付録 F「クラスタ T シャツ」を参照してください (このクラスタには VAX が含まれていましたが，クラスタ内に VAX と Integrity を混在させた場合のサポートについて，当初はまだ確実ではなかったため，編集して削除してあります)。

先はまだ長かったのですが，ネットワーク接続したクラスタ・システムをブートできたことで，Integrity 上で完全に機能する OpenVMS が可能だということを確信しました。始まったばかりの頃は，Alpha 上の OpenVMS の品質とパフォーマンスを達成できるわけがないと，多くの人が思っていました。そもそも動作させるのは不可能だという声もありました。12 年前，VAX から Alpha へのポーティングに関しても同様に懐疑的な意見 (5%) があったことにも注目しなければなりません。OpenVMS のポーティングは全く初めての試みで，それができるかどうか本当に疑わしかったので，1990 年に批判的だった人たちの意見には信ぴょう性がありました。今回は，ポーティングができるかどうかについて疑問は全くありませんでした。唯一の疑問は，システムがどれだけの性能を出せるかということだったのです。

V8.0 の社内的な開発コード・ネームは MAKO でした。開発環境はクロス・ツールを使用していました。Alpha 上でコンパイルおよびリンクし，イメージを Integrity システムに移動しました。この最初の評価版リリースの目的は，一部のアプリケーション・プロバイダ向けに，早期に開発に着手できる機会を提供することでした。最初の一般リリースが出荷されるときには，アプリケーション・プロバイダの準備が整っていてほしかったのです。また，限定的ではありましたが，我々自身の環境以外での公開にもなりました。重要な局面に入りつつありました。

クロス・ツールは以下の通りです：

• コンパイラ -- BLISS32，BLISS64，C，IMACRO，FORTRAN
• IAS アセンブラ
• LINKER
• CRFSHR
• LIBRARIAN
• CHECKSUM
• CDU
• ANALYZE_OBJ

OpenVMS Engineering は Fast Track と呼ばれる特別プログラムを用意し，ごく限られた OpenVMS 環境でしたが，厳選した 20 のパートナーに対して専用のサポートを提供しました。一方我々は，目指すものが形になり始めていることが分かりました。

2003 年 7 月 8 日と 9 日，ニューハンプシャー州ナシュアで行われた HP のファームウェア・グループとオペレーティング・システム・グループのエンジニア技術交換会は，特に Intel と共同で Itanium の開発を行った HP チームのメンバーの 1 人も参加していて，とても有意義でした。我々には十分に機能するシステムがありましたが，「知れば知るほど，知らないことが増える」という経験の 1 つでした。

そして，多くの OpenVMS エンジニアがシステムのさまざまなコンポーネントのコンパイルとリンクにかかわり始めました。我々は，エンジニアリング・コミュニティ全体を対象に，ランチタイム・セミナーを何度か開催しました。初期の開発作業に携わっていたエンジニアたちが，システム内の Integrity 固有の新しい領域の詳細をプレゼンテーションしました。

名前よりも中身

1998 年，ロサンゼルスで行われたごく一般的なフォーラムで，OpenVMS ビジネスのマネジメントが「OpenVMS が V8.0 になることはない」と述べました。いつまでも V7.x であり続ける，つまり，その余生を通じて可能な限りシステムの変化を抑えるということでした。当時は OpenVMS の将来について考え方が異なっていたのです。

時代は変わりました。2003 年，OpenVMS Integrity のどのリリースを V8.0 と名付けるか，OpenVMS グループ内で議論が広がりました。 「V8」はローカルなキャッチフレーズとなり，あるジュース・メーカーの商品が，不思議と社内のあちらこちらに見られるようになりました。

V8.1 の開発コード・ネームは JAWS であり，それはネイティブな開発環境に由来します。我々は Integrity システムでコンパイルし，リンクしました。この 2 つ目の評価版リリースの目的は，2 つありました。

• パートナーの数を増やすこと
• 完全な Integrity 環境を構築すること

コンパイルとリンクが Integrity システム上でサポートされるようになり，クロス・ツールとファイル転送機能は不要になりました。実際，この環境の初期テストの 1 つは，ツール自体をネイティブでビルドすることでした (たとえば，コンパイラが自分自身をコンパイルするなど)。

プログラム全体の浮動小数点モード

浮動小数点 . . . 浮動小数点 . . . 浮動小数点！ 浮動小数点の動作は，Alpha と Itanium では全く異なります。異なる浮動小数点修飾子 (制御，丸め，精度) でコンパイルされたソース・コード・モジュール，およびオブジェクトが，1 つのイメージにリンクされます。Alpha では，浮動小数点の設定は，コンパイラが生成する命令ストリームの中に含まれています。Integrity 上では，命令の実行時に FPSR (Floating Point Status Register) の内容によって決まります。

Alpha では，各モジュールについて宣言したとおりものが得られ，途中で判断や仮定をする必要がありません。Integrity では，浮動小数点の設定は各オブジェクト・ファイルで指定され，LINKER はエントリ・ポイント MAIN のあるモジュールの浮動小数点設定をイメージ内に格納します。イメージがメモリに読み込まれた後，何らかの命令が実行される前に，FPSR には LINKER によって設定された値が設定されます。 OpenVMS には，このような混在モードの場合に正確な Alpha の動作を魔法のように再現する方法はありません。 個々のモジュール宣言に敏感なアプリケーションのために，プログラムの実行時の動的な変更に対応するシステム・サービス，すなわち SYS$IEEE_SET_* があります。

VAX F/D/G から IEEE への変換

アプリケーションが VAX の浮動小数点型を IEEE に変換できるように，ライブラリ・ルーチンをさらに追加する必要がありました。多くのルーチンはすでに存在していましたが，今度はアプリケーション開発者に対して，変換を積極的に勧め，我々は足りない機能があることを発見しました。 この予定外の作業をこのような遅い時期に誰ができるのでしょうか？ 我々は Customer Support Center のエンジニア数名に協力を依頼し，彼らは期待通りの成果をあげてくれました。

メモリ内のワーキング・セットの固定

カーネル・モードに入って IPL を上げる特権プロセスは，自身のコードとデータをワーキング・セットにロックすることで，I/O の IPL が高くなりすぎても，ページ・フォルト・ハンドラが呼び出されるのを防いでいます。システム・サービス SYS$LKWSET は，特定範囲のアドレスを受け取り，メモリ内で該当するページをロックします。互換性のために，我々は，受け取ったアドレスの 1 つがコード・イメージ・セクションにあることが分かった場合に，SYS$LKWSET がメモリ内のイメージ全体をロックするように変更しました。

VAX ではコードとデータだけをロックする必要がありますが，Alpha では，コード，データ，およびリンケージ・データをロックします。少々複雑ですが実現可能です。Integrity 上では新しい ELF イメージ・フォーマットになったため，プログラマはコード，データ，short 型データ，リンケージ・データをロックする必要があります。これらはアプリケーション・レベルで知るのはほぼ不可能です。アプリケーションでは LIB$LOCK_IMAGE を使用して，イメージ全体をメモリ内でロックすることを強く推奨します。SYS$LKWSET を何度も呼び出すよりは簡単です。この新しい $LIB ルーチンは，Alpha と Integrity の両方で利用できるので，共通コードを維持できます。イメージ全体がロックされるため，プロセスのワーキング・セット・クォータを増やす必要がある場合が発生します。 OpenVMS では，特権プロセスの多くを，LIB$LOCK_IMAGE を使用するように切り替え，SYSTEM アカウントのワーキング・セット・クォータを増やしました。

Superdome デモ

ちょっと衆目を集めることほどわくわくするものはありません。2004 年 2 月 13 日，マサチューセッツ州ウエストボロの HP アナリスト・ミーティングで行われた，Superdome での 4 OS (HP-UX，Linux，OpenVMS，Windows) のデモには，たくさんの注目が集まりました。4 つセルから成るシステムは，それぞれが別々のオペレーティング・システムが稼動する 4 nPar (ハード・パーティション) として構成されました。

V8.2 は，セル・ベースのシステムはサポートしておらず，このことがいくつか新しい問題を引き起こしました。今回は (多少のごまかしが許される) デモだったので，完全なソリューションを考え出すのではなく，いくつかの I/O 関連アドレスをドライバにハードコードしました。セル 0 で OpenVMS をブートしなければなりませんでしたが，この簡単な暫定的な対策で大きな効果が得られました。

50 ビットの物理アドレス指定

悪いタイミングで雷に遭いました。2004 年の真夏，最初の正式な Integrity フィールド・テストに向けてすべてが整っていましたが，rx4640 用の mx2 CPU でテストを開始したときに新たな事実が発覚しました。mx2 のキャッシュは，OpenVMS がサポートしている最大 43 ビットを超えるアドレスを使用する必要があったのです。1 つの選択肢は，rx4640 の 8 CPU バージョンをサポートせず，必要なメモリ管理作業は次のリリースまで延期することでしたが，それ以前に新しいプラットフォームが追加される可能性もあったため，V8.2 で対応することに決定しました。データ構造とソース・コードの変更は，DECnet や TCP/IP など，PFN と直接連携するあらゆる特権コードに影響するため，既知で必須の特権コードの変更を，すべて最初の Integrity リリースに盛り込みたいと考えていました。

急遽，OpenVMS に以下の変更を加えるために，設計書が作られ，プロジェクト計画が書かれ，5 人のエンジニアが選抜されました。

1. PTE の PFN フィールドを 32 ビットから 40 ビットに拡張する。
2. データ構造体，グローバル・セル，ルーチン・インタフェース内の他すべての PFN フィールドを，64 ビットに拡張する。

これらの変更は広範囲に及び，Integrity だけを対象としていましたが，プラットフォームの相違を埋めるマクロを使うことで，共通のソース・コードが維持されました。この作業でしばらくの間，週 1 回のビルドに混乱が生じ，影響を受けるレイヤード製品 (すでに完了したと思っていた) では，対応が難しい作業となりました。量は多くありませんが，慎重を要する領域にあったためです。基本オペレーティング・システムの作業が終わると，「50-Bit Physical Addressing Programming Cookbook」を参考に，開発者は間際になって割り当てられた追加作業を終わらせ，全員何とか生き残りました。

VAX キュー命令のエミュレーションの書き換え

Alpha PAL の呼び出しを OpenVMS のシステム・サービスに置き換える作業は，ほとんどのケースでうまく行きました。プロジェクトの早い段階で，我々は Integrity の EPC (Execute Privileged Code) 命令を使用する仕組みとして「プロモート・ページ」を作成しました。このメカニズムを利用して，SWIS に移行する前にカーネル・モードに入り，スタックの切り替え，レジスタの保存し，システム・サービス・ディスパッチャの呼び出しを行いました。

SWIS がない状態では，EPC は特権モードを切り替えるときにスタックの切り替え，レジスタの保存，IPL や AST などの処理を行いません。これはまさに，パフォーマンス重視のキュー命令のエミュレーションに必要なものです。ただし，スタックのセット・アップを行う SWIS がない状態では，多くの制約があります。コードはアセンブリ言語で慎重に正しく書く必要がありましたが，トラブルが重なった後，必要なコードを作成することができました。

スレッド化されたプロセス環境では，アラインメントに誤りのあるキュー要素へのアクセスをチェックするのは困難でした。我々は，呼び出し側の特権モードではアクセスできないキュー要素を検出する例外ハンドラをプログラミングしました。さらに，コードがアトミックにキュー命令の実行を続けられるかどうかを素早く判断するために，割り込みを不可にした TAK，PROBER，PROBEW 命令をうまく使う方法を設計しました。何度かつまずきましたが，最終的には良いソリューションができました。EPC は我々が必要としていたことを確実に実現しました。それ以外の PAL 呼び出しのいくつかをこの方法で変更しました。

最終的な V8.2 の変更点

2004 年のクリスマス直前，手に負えないような NaT の消費の問題が見つかりました。それが修正されてから，終わったと思いながら休暇に入りました。休みの間中テスト・クラスタを稼動させ，休暇明けには我々は勝利を宣言するはずでした。残念ながら，満足のいく結果にはなりませんでした。実際，休暇中に何人かのエンジニアが 2 つの問題に気づいていました。

浮動小数点 . . . 浮動小数点 . . . 浮動小数点！

Integrity システムには 128 個の浮動小数点レジスタがあります。コンテキストが切り替えられたときに，これらすべてのレジスタを無用に保存/復元しないことが望まれます。そのために，レジスタは構造上は，F0 〜 F31 (下位) と F32 〜 F127 (上位) の 2 つのセットとして扱われます。各セットでプロセッサによって維持されるステータス・ビットは，そのセット内のレジスタに変更が加えられたかどうかを示します。多くの場合，上位の浮動小数点レジスタ・セットは使用されず，OpenVMS は「変更」ビットを利用して不要な保存/復元をなくしています。しかし，AST 配信にかかわるところでそれが正しく行われておらず，それを見つけ出すまで非常に長い時間を要しました。

すると，また別の浮動小数点問題に直面しました。修正可能なメモリ・エラーが報告されたときに，浮動小数点レジスタが壊れたのです。この問題は発見が難しかっただけでなく，浮動小数点の使い方に関する社内の OpenVMS の決定に関係していました。OpenVMS および HP-UX とコンパイラ作成者との間には，コードが /INSTRUCTION_SET=NOFLOAT を使ってコンパイルされた場合，生成後のコードではレジスタ F6 〜 F11 のみを使用可能とするという協定があります。割り込み処理レベルでの保存と復元を制限するために，オペレーティング・システムはこの方法でコンパイルされています。レジスタの破損は，メモリ・エラーと同時に起こりました。ファームウェア・テスト・エンジニアリングで，修正可能なメモリ・エラーを挿入するテスト・プログラムを用意しました。我々はすぐにそれを OpenVMS にポーティングし，エラーのポーリング頻度を増やし，問題を診断して修正しました。OpenVMS のエラー・ログ機能がファームウェアを呼び出しており，浮動小数点レジスタを適切に保存していませんでした。

2005 年 1 月 10 日，V8.2 リリースの最後のコード変更が行われ，最終テストが始まりました。テストは問題ありませんでした。ついに完成したのです。2005 年 1 月 13 日，OpenVMS Engineering Readiness Review が行われ，完成は正式なものとなりました。最終版の DVD が製造工程に送られました。

パフォーマンスの評価

製品として出荷できる品質のシステムが完成しましたが，どれだけの性能を発揮したでしょうか。いくつもの答えがある問いなので，同等レベルの Alpha と Integrity ハードウェア・プラットフォームが，特定の CPU，メモリ，I/O テストに対してどのような成績だったかに重点を置くことにしました。たとえば，Alpha DS25 と Integrity rx2600，Alpha ES45 と Integrity rx4640 を比較しました。

全般的に，Alpha システムと Integrity システムはほぼ同等の性能でした。いくつかのテストでは一方が少し優れており，別のテストでは反対の結果になりましたが，ほとんどの場合，差は少しでした。はるか昔の 2001 年の「発表」が行われたとき，パフォーマンスの優位が Alpha から Integrity に入れ替わるのは，2005 年頃になると述べられました。これはかなり正確な予想だったという結果となりました。

Integrity システムは，ソフトウェアからアクセス可能なパフォーマンス・カウンタを豊富に備えています。OpenVMS ツールには，データを収集し，適切な情報をルーチン内の命令ポインタに関連付ける機能が組み込まれています。これは，当初十分に性能を発揮していない領域を追跡し，改善するのに役立ちました。たとえば，RTL の特定の呼び出しシーケンスの中で，スタックのアンワインドが無用に行われていました (非常に高くつきます)。もう 1 つの例は，効率の悪い OTS データ移動ルーチンです。

1 つの普遍的な発見は，アラインメントが合っていないデータをなくさなければならないということです。アラインメントが合っていないデータ参照は Alpha 上でも高くつきますが，Integrity 上では 2 倍悪化することがあります。したがって，このようなデータ・セルは必ず自然な境界に合うようにアラインしてください。

これらの新しいプラットフォームでの経験を重ねるにつれて，当然ながらオペレーティング・システムとコンパイラも継続的に性能が向上し，CPU とプラットフォームの速度も向上するはずです。rx1600，rx2600，rx4640 (V8.2 でサポート) や，OpenVMS の将来のリリースでサポートされるもっと大型のシステムについても同じことが言えるでしょう。

3 年半の取り組みの成果が，HP Integrity サーバで動作する OpenVMS I64 です。我々は，アプリケーション・プロバイダが Alpha から Integrity へできる限り簡単に移行できるように努めました。ときどき例外が生じる可能性があることは認識していますが，ほとんどのアプリケーションに対して目標を達成しました。 Integrity 対応のために絶対に必要というわけではなかった変更もあり，少し迷惑をかけたかもしれませんが，OpenVMS を 2005 年には 2001 年よりも優れたシステムにすることが目標であり，我々はそれを実現したのです。

このような大規模なプロジェクトは，製品のライフサイクルの中で何度も起こるものではありません。 今回は，OpenVMS にとって 2 度目であり，まだまだ前進を続けていきます。

OpenVMS のポーティングには，ここでは紹介しきれないほど大勢の人々とグループにご協力いただきました。OpenVMS のコミュニティ全体が，この巨大な計画に参加しました。我々の顧客に自信をもって提供できる製品を作り上げるために，全員が最高の力を発揮してくれました。

今回の Integrity へのポーティングは非常に優秀な多くの人たちの努力の結果ですが，過去数年，もっと言うと数十年にわたり OpenVMS に貢献してきた人たちの仕事も大きく貢献しました。OpenVMS は，概念も実装も，一緒に仕事をするにはすばらしいシステムであり，我々よりも前に携わったすべての人たちに感謝します。

本稿をレビューしてくださった次の方々には特別にお礼申し上げます：Burns Fisher，Karen Noel，John Reagan，Ron Brender，Jeff Nelson，Josh Cope，Gaitan D'Antoni，Sue Lewis，Ken Moreau，Randy Barth。

ブート・コンテスト・シャツを獲得した方々：

• Luciana Silva
• Gabriel Sterk
• Randy Loch
• Geoff Bryant
• Kurt Huddleston
• James Wilkinson
• Lee Mah
• Alan Frisbie
• Hans Vlems

以下のファイルには，Integrity OpenVMS の初ブートを成し遂げた 1361 のモジュールが含まれています。