OpenVMS Alpha
V7.3-2 リリース・ノート【翻訳版】

前へ 次へ 目次 索引

5.3.20 論理名混在の検索リストが動作するようになった

V7.3-2

OpenVMS Version 7.1-2 では，最上位の論理名と最上位でない論理名が混在した検索リストを使用しても動作しましたが， OpenVMS Version 7.2-2 以降ではエラーが発生することがありました。

OpenVMS Version 7.3-2 からは，新しい機能論理名が追加され，この問題が解決されました。 DECC$NO_ROOTED_SEARCH_LISTS 機能論理名は， decc$to_vms関数が検索リストの論理名を解決する方法を制御します。

decc$to_vms関数は，UNIX 形式のパス文字列を評価し，論理名となる 1 番目の要素を検出する際に，次の処理を行います。

上記の 3 つのケースでは，予測可能な，期待どおりの結果が得られます。

1 番目の要素が，最上位の論理名と最上位でない論理名が混在した検索リストの場合，以前の説明のとおりにパスを変換すると，次の点で，古いバージョンの OpenVMS (Version 7.3-1 より前) とは異なる動作になることがあります。

DECC$NO_ROOTED_SEARCH_LISTS は， decc$to_vms関数が検索リスト論理名を解決する方法を制御します。また Version 7.3-1 より前の動作に戻すこともできます。

DECC$NO_ROOTED_SEARCH_LISTS を有効にすると，次の動作が行われます。

この機能論理名を有効にすると，検索リスト論理名の動作が， Version 7.3-1 よりも前の状態になります。

DECC$NO_ROOTED_SEARCH_LISTS を無効にすると，次の動作が行われます。

この機能論理名を無効にすると， OpenVMS Version 7.3-1 およびそれ以降の動作になります。

5.3.21 プログラムのデッドロックの問題が修正された

V7.3-2

以前は， 1 つのプロセスが他のプロセスからシグナルを受けるときにデッドロックが発生し，予期しないプログラム・ハングアップが起こることがありました。

この問題は，特定の Oracle アプリケーションで報告されていますが，他のプログラムでも発生する可能性があります。

この問題は，修正されました。

5.3.22 inet_ntop 関数が "const char *" を返すように定義された

V7.3-2

以前のバージョンの C RTL では， inet_ntop関数を，戻り値型 "char *"として定義していました。業界標準に準拠するために， inet_ntopの宣言が， "const char *"を返すように変更されました。

5.3.23 exec が 0x35DF94 エラーを返さなくなった

V7.3-2

以前， vfork/ exec* 呼び出しを使用する C プログラムは， exec* 呼び出しから予期しない %X35DF94 エラーが返されることがありました。

この問題が修正されました。

5.3.24 OpenVMS Version 7.3-1 へアップグレードした後のコンパイラ・エラーがなくなった

V7.3-2

OpenVMS Version 7.3-1 以降にアップグレードした後のコンパイラ・エラーが発生しなくなりました。

5.3.25 BSD 4.4 関数のエントリ・ポイント不足が修正された

V7.3-2

以前は， getaddrinfo関数， freeaddrinfo関数， getnameinfo関数，および gai_strerror関数に，誤って __bsd44_ という接頭辞が付与されていたため，次のような未定義シンボル・エラーがリンク時に出力されていました。 


%LINK-W-USEUNDEF, undefined symbol __BSD44_GETNAMEINFO referenced

この問題は，OpenVMS Version 7.3-2 で出荷される <netdb.h>ヘッダ・ファイルで修正され，これらの関数には __bsd_44_ という接頭辞は付かなくなりました。

5.3.26 UCX$IPC_XHR.EXE 内の IPv6 シンボル名が正しくなった

V7.3-2

C RTL for OpenVMS Version 7.3 に追加された， 9 個の IPv6 関連の関数 (inet6_xxxx) の名前は，基礎となる TCP/IP レイヤの対応する関数の名前と一致していませんでした。 C RTL 内のこれらの関数を使用したユーザ・アプリケーションは，これらの関数がインプリメントされていないというエラーを受け取っていました。この問題が修正されました。

5.3.27 一部の UNIX ファイル名の変換上の問題が修正された

V7.3-2

以前は， /lognameのような UNIX ファイル名は， logname が sys$login:login.comのようなファイルとして解決された場合，正しく変換できませんでした。この問題が修正されました。

5.3.28 rename 関数が論理名を正しく扱うようになった

V7.3-2

最近の一部のバージョンの C RTL では， 2 番目の引数の論理名としてあいまいなファイル指定が渡された場合， rename関数は，ディレクトリ指定への変換を許しませんでした。ここで言うあいまいさは，論理名が UNIX パス名と， OpenVMS ディレクトリ指定のどちらを示しているのか分からないということです。以前のバージョンの OpenVMS では，このような名前変更操作を正しく処理していたので，動作が変更されたことになります。

この問題が，新しい機能論理名 DECC$RENAME_ALLOW_DIR を導入して修正されました。

DECC$RENAME_ALLOW_DIR を有効にすると，論理名として渡された 2 番目の引数があいまいなファイル指定であっても，ディレクトリ指定への変換が許されるようになり， rename関数の動作が以前の OpenVMS の状態に戻ります。 DECC$RENAME_ALLOW_DIR が有効であるとして，次の例を考えます。 


rename("file.ext","logical_name") /* where logical_name = dev:[dir.subdir] */ 
                                  /* and :[dir.subdir] exists

このコードにより，次のような結果が得られます。 


dev:[dir.subdir]file.ext

この例では，ファイルの名前を，1 つのディレクトリから別のディレクトリへ変更します。この動作は，Version 7.3-1 より前の OpenVMS と同じです。またこの例では， dev:[dir.subdir]が存在しなかった場合， renameはエラーを返します。

DECC$RENAME_ALLOW_DIR を無効にすると， renameの logical_name 引数の変換が，より UNIX に準拠した動作になります。 DECC$RENAME_ALLOW_DIR が無効であるとして，次の例を考えます。 


rename("file.ext","logical_name") /* where logical_name = dev:[dir.subdir] */

このコードにより，次のような結果が得られます。 


dev:[dir]subdir.ext

この例では， logical_name 引数のサブディレクトリ部分を新しいファイル名として使用して，ファイルの名前が変更されます。これは，UNIX システムでは，ファイルの名前をディレクトリに変更することは許されていないためです。このため， renameは内部的に logical_name をファイル名に変換し，実行可能な，最も適切な変換結果は dev:[dir]subdir になります。

この新しい機能スイッチには，ファイルへの renameよりもディレクトリへの renameが優先されるという副作用があります。次の例を考えます。 


rename ( "file1.ext","dir2" )  /* dir2 is not a logical */

DECC$RENAME_ALLOW_DIR が無効の場合，この例の実行結果は，サブディレクトリ [.dir2]が存在してもしなくても， dir2.extになります。

DECC$RENAME_ALLOW_DIR が有効の場合，この例の実行結果は，サブディレクトリ [.dir2]が存在しないときだけ， dir2.extになります。サブディレクトリ [.dir2]が存在すると，実行結果は [.dir2]file1.extになります。

注意

  • DECC$RENAME_NO_INHERIT が有効の場合は， UNIX 準拠の動作になるため，DECC$RENAME_ALLOW_DIR は無視され，ファイル名からディレクトリ名への変更は許されません。

  • rename関数は失敗すると， - 1 を返し， errnoに次のいずれかの値を設定します。

    • EISDIR --- 新名の引数がディレクトリを指し，古名の引数がディレクトリでないファイルを指しています。

    • EEXIST --- 新名の引数が既存のディレクトリを指しています。

    • ENOTDIR --- 古名の引数がディレクトリの名前を指し，新名の引数が非ディレクトリ・ファイルの名前を指しています。

5.3.29 IPv6 プログラミングの注意事項

V7.3-2

最新の TCP/IP ヘッダ・ファイルが， HP TCP/IP Services for OpenVMS Version 5.4 でリリースされます。 Version 5.4 の TCP/IP Services がインストールされている場合，そのファイルは TCPIP$EXAMPLES に置かれていますが， <in6.h>だけは例外です。 OpenVMS Version 7.3-2 で出荷される DECC$RTLDEF.TLB では， <in6.h>は概念的には TCPIP$EXAMPLES の TCP/IP Services Version 5.4 バリアントと同じですが，実際には異なります。

5.3.30 glob 関数は，/POINTER_SIZE=LONG ではサポートされない

V7.3-2

/POINTER_SIZE=LONG 修飾子を指定してコンパイルした場合， glob関数はサポートされません。予期しない実行時エラーが発生することがあります。

5.3.31 新しい 64 ビット関数のサポート: 特記事項

V7.3-2

次の関数は，OpenVMS Version 7.3-2 で，新たに 64 ビット・ポインタをサポートします。 


getaddrinfo        getpwnam 
freeaddrinfo       getpwuid 
sendmsg            getpwent 
recvmsg

これらの関数は，これまでは /POINTER_SIZE=LONG でコンパイルしても， 32 ビット・ポインタだけをサポートしていました。 /POINTER_SIZE=LONG でコンパイルしても 32 ビット・ポインタをサポートするという以前の動作を維持するために，これらの関数は，『Compaq C Run-Time Library Reference Manual for OpenVMS Systems』に示されている，通常の 32 ビット/64 ビット・サポートの規約に従っていません。

新たに 64 ビット・サポートを行うために，これらの関数の以下のバリアントと，これらのバリアントで使用する構造体が導入されました。 


  関数構造体 
--------                        --------- 
__getaddrinfo32                 __addrinfo32 
__getaddrinfo64                 __addrinfo64 
__freeaddrinfo32                __addrinfo32 
__freeaddrinfo64                __addrinfo64 
__recvmsg32                     __msghdr32 
__recvmsg64                     __msghdr64 
__sendmsg32                     __msghdr32 
__sendmsg64                     __msghdr64 
__32_getpwnam                   __passwd32 
__64_getpwnam                   __passwd64 
__32_getpwuid                   __passwd32 
__64_getpwuid                   __passwd64 
__32_getpwent                   __passwd32 
__64_getpwent                   __passwd64

これらの関数の標準バージョンをコンパイルすると，動作は次のようになります。

ただし，これらの関数では，対応する構造体に関しては同様の変換は行われません。これらの構造体は，/POINTER_SIZE=LONG でコンパイルしても， OpenVMS Version 7.3-2 より前は 32 ビット・バージョンのみであったため，このような動作にする必要があります。暗黙的に構造体のサイズを変更してしまうと，予期しない実行時エラーが発生することがあります。

これらの関数の標準バージョンを 64 ビット・サポートで使用するプログラムをコンパイルする場合は，関連する構造体の 64 ビット版の定義を使用しなければなりません。 /POINTER_SIZE=64 を指定して，標準関数名と標準構造体定義を使用したプログラムをコンパイルすると，コンパイラが PTRMISMATCH 警告メッセージを出力します。

たとえば，次のプログラムは， addrinfo構造体の標準定義と， getaddrinfoルーチンおよび freeaddrinfoルーチンを使用します。このプログラムをコンパイルすると，この例に示した警告メッセージが表示されます。 


$ type test.c 
#include <netdb.h> 
 
int main () 
{ 
    struct addrinfo *ai; 
 
    getaddrinfo ("althea", 0, 0, &ai); 
    freeaddrinfo (ai); 
    return 0; 
} 
 
$ cc /pointer_size=64 TEST.C 
 
    getaddrinfo ("althea", 0, 0, &ai); 
....^ 
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value 
"&ai" is "long pointer to struct addrinfo", which is not compatible with "long 
pointer to struct __addrinfo64". 
at line number 7 in file TEST.C;1 
 
    freeaddrinfo (ai); 
....^ 
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value 
"ai" is "struct addrinfo", which is not compatible with "struct __addrinfo64". 
at line number 8 in file TEST.C;1 
$

64 ビット用にコンパイルする場合は，関連する構造体の 64 ビット版を使用しなければなりません。上記の例では， ai構造体の宣言を，次のように変更します。 


struct __addrinfo64 *ai;

または，32 ビットと 64 ビットのどちらでもコンパイルできるようにするには， ai構造体を次のように宣言します。 


#if __INITIAL_POINTER_SIZE == 64 
    struct __addrinfo64 *ai; 
#else 
    struct __addrinfo32 *ai; 
#endif

5.4 Common Data Security Architecture (CDSA) に関する考慮

V7.3-2

インストールと初期化

CDSA は，オペレーティング・システムのインストール時に自動的にインストールされます。ただし，次の点に注意してください。

前へ 次へ 目次 索引