日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:移行プロセスの概要
第 2 章:移行方法の選択
第 3 章:アプリケーションの移行
第 4 章:再コンパイルと再リンクの概要
第 5 章:ページサイズの拡大に対するアプリケーションの対応
第 6 章:共用データの整合性の維持
第 7 章:アプリケーションデータ宣言の移植性の確認
第 8 章:アプリケーション内の条件処理コードの確認
第 9 章:OpenVMS I64コンパイラ
付録 A :アプリケーション評価チェックリスト
用語集
索引
PDF
OpenVMS ホーム

OpenVMS
OpenVMS VAX から OpenVMS I64 への
アプリケーションの移行


目次 索引



OpenVMS VAX の呼び出し規則に明示的に依存するアプリケーションは,変更が必要になる可能性があります。 OpenVMS I64 の呼び出し規則は,Intel の呼び出し規則をベースにしており,部分的に OpenVMS 固有の変更が加えられています。 OpenVMS I64 の呼び出し規則で導入された大きな相違点は次のとおりです。

  • フレーム・ポインタ (FP) はない。

  • 複数のスタックが使用される。

  • 4つのレジスタだけが呼び出し時に保存される。

  • 従来のレジスタ番号が変更されている。

詳細は,『OpenVMS Calling Standard』を参照してください。

3.7.9 特権コード

ここでは,確認が必要で,場合によっては変更も必要な特権コードについて説明します

プログラム自身をメモリへロックするのに SYS$LKWSET または SYS$LKWSET_64 システム・サービスを使用しており,VAX システムでアプリケーションを実行しない場合は,これらを (OpenVMS Version 8.2 で導入された) LIB$LOCK_IMAGE という新しい RTL ルーチンに置き換えることをお勧めします。同様に,SYS$ULWSET および SYS$ULWSET_64 も LIB$UNLOCK_IMAGE という新しい RTL ルーチンに置き換えます。

カーネル・モードに入り,IPL を 2 より大きな値に上げるプログラムは,プログラム・コードとデータをワーキング・セット内にロックしなければなりません。コードとデータのロックが必要なのは,システムが PGFIPLHI バグ・チェックでクラッシュするのを回避するためです。

VAX システムでは通常,ロックが必要なのはプログラムで明示的に参照されるコードとデータだけでした。 Alpha システムでは,プログラムで参照されるコード,データ,およびリンケージ・データをロックしなければなりません。 I64 システムでは,コード,データ,ショート・データ,およびリンカで生成されたコードをロックする必要があります。ポーティングを容易にするため,また,ショート・データとリンカ生成データのアドレスはイメージ内で簡単に検出できないという理由から,Alpha と I64 の SYS$LKWSET および SYS$LKWSET_64 システム・サービスに変更が加えられています。

OpenVMS Version 8.2 では, SYS$LKWSET および SYS$LKWSET_64 システム・サービスは,渡された最初のアドレスを調べます。このアドレスがイメージの内部にある場合は,これらのサービスはイメージ全体をワーキング・セット内にロックしようとします。正常終了状態コードが返されれば,プログラムが IPL を 2 より大きな値に上げても,システムが PGFIPLHI バグ・チェックでクラッシュすることはありません。

ワーキング・セット内でイメージのロックが成功した回数を数えるカウンタが,内部 OpenVMS イメージ構造で管理されています。このカウンタは,ロックされたときに増分され,アンロックされたときに減分されます。カウンタが 0 になると,イメージ全体がワーキング・セットからアンロックされます。

特権プログラムが Alpha および I64 用であり VAX では使われない場合は,コード,データ,およびリンケージ・データを検索してこれらの領域をワーキング・セット内にロックするようなコードをすべて削除することができます。この種のコードは,LIB$LOCK_IMAGE ルーチンおよび LIB$UNLOCK_IMAGE ルーチン (OpenVMS Version 8.2 で提供) の呼び出しで置き換えることができます。これらのルーチンの方がプログラムにとって単純であり,コードの理解と保守も容易になります。

プログラムのイメージが大きすぎるために,ワーキング・セット内にロックできない場合は,状態コード SS$_LKWSETFUL が返されます。この状態が返された場合は,ユーザのワーキング・セット・クォータを拡大することができます。また,イメージを 2 つの部分に分割することもできます。ユーザ・モードのコードが含まれる部分と,カーネル・モードのコードが含まれる共用イメージに分割します。カーネル・モード・ルーチンを開始するときに,このルーチンは LIB$LOCK_IMAGE を呼び出して,イメージ全体をワーキング・セット内にロックしなければなりません。カーネル・モード・ルーチンを終了する前に,ルーチンでLIB$UNLOCK_IMAGE ルーチンを呼び出す必要があります。

コードをメモリ内にロックするためにアプリケーションでシステム・サービス SYS$LCKPAG または SYS$LCKAPG_64 を使用している場合,このサービスを使用している部分を検討してください。 I64 では,このサービスによりイメージ全体がワーキング・セット内にロックされることはありません。

コードが IPL を上げて実行しているときにページ・フォルトが発生しないように,ワーキング・セット内にイメージをロックしようとしているのかもしれません ( 第 3.7.9.1 項 を参照)。 LIB$LOCK_IMAGE ルーチンおよび LIB$UNLOCK_IMAGE ルーチンについては,『OpenVMS RTL Library (LIB$) Manual』を参照してください。

OpenVMS I64 のターミナル・クラス・ドライバのインタフェースは, CALL ベース・インタフェースです。これは,引数の受け渡しにレジスタを使用する OpenVMS VAX の JSB ベースのインタフェースと大きく異なります。

OpenVMS I64 のターミナル・クラス・ドライバのインタフェースについては,『OpenVMS Terminal Driver Port Class Interface for Itanium』を参照してください。このドキュメントは次の Web サイトで入手できます。


http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources 



保護されたイメージ・セクションは,通常,ユーザ作成のシステム・サービスを実装するための共用イメージで使用されます。これらのイメージ・セクションは,ソフトウェアおよびハードウェアのメカニズムによって保護され,特権のないアプリケーションがこれらのセクションの完全性を危うくすることがないようになっています。 VAX および Alpha と I64 のハードウェアのページ保護機能の違いにより,わずかな制限が追加になりますので,保護されたイメージに対して変更が必要になる場合があります。

VAX および Alpha では,特権モード (カーネル・モードまたはエグゼクティブ・モード) で書き込み可能なデータ・セクションは,非特権 (ユーザ) モードで読み取りが可能です。ハードウェア保護機能は,そのようなページに対して,どのモードからも実行アクセスは許可しません。書き込み可能かつ実行可能としてリンクされた保護されたイメージ・セクションは,内部モードでの読み取り,書き込み,実行のみを許可し,ユーザ・モードでのアクセスは許可しません。内部モードでの書き込みが可能なデータへのユーザ・モード・アクセスも,書き込み可能セクションにコードを置くことも一般的ではないため, 1 つのセクションで両方を必要とするアプリケーションはほとんどないと考えられます。

このように VAX と Alpha では例外がありましたが,I64 では,すべての保護された書き込み可能イメージ・セクションは,ユーザ・モードでの書き込みから保護されます。保護されたイメージ・セクションに対するユーザ書き込みを許可する場合は, $SETPRT/$SETPRT_64 システム・サービスを使用してページ保護を変更しなければなりません。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項