Caché 5.1

ポータルとアプリケーション名の競合

Caché 5.1 では、システム管理ポータルを実行する CSP アプリケーションの名前は、インストール時に選択されたインスタンス名を使用して作成します。例えば、Caché システムに “/appserver” という名前の CSP アプリケーションがあると想定します。このシステム用に選択されたインストール名が “APPSERVER” の場合、アップグレード手順では、システム管理ポータルを実行するための CSP アプリケーション名は “/appserver/csp/sys” となります。このため、以前使用されていた CSP アプリケーションへのアクセスは、アップグレード後は実質的にブロックされます。

新しいパラメータ・リファレンス

.cpf を編集してサイトの運用を制御している場合は、個々の制御内容を調べて、このバージョンでも適用可能かどうかを確認する必要があります。管理者は "Caché パラメータ・ファイル・リファレンス" を参照して、最新の構成、および有効なパラメータと指定可能な設定を再確認することを強くお勧めします。

起動時の構成変更の検出

Caché の構成情報は、Caché の外部に保存されており、Caché が実行されていないときに構成情報を修正できます。そのため、このバージョンでは特別な保護オプションが追加されています。構成ファイルの内容を保護するのではなく、システムを起動する機能や実行中のシステムの構成を変更する機能を Caché は制御しています。この保護を有効にするには、構成セキュリティをオンにします(もちろん、ユーザがこのファイルを編集できるのをオペレーティング・システム・レベルで厳格に制限することにより、この構成ファイルを Caché の外部で保護できるし、そうする必要があります)。

Caché の起動時に、構成 (.cpf) ファイルがこの Caché インスタンスの前回の起動時以降に変更されたことが検出されると、起動を実行したユーザにユーザ名とパスワードの入力を求めるプロンプトが表示されます。このデータは、変更された構成パラメータを使用して Caché を起動することを認可されたユーザであるかどうかを検証するために使用されます。 ユーザの認証に成功した場合に、このユーザに %Admin_Manage:Use が付与されていれば、新しい構成パラメータを使用して Caché が起動します。

それ以外の場合は、前回の既知の構成を使用して Caché が起動します。この場合、指定された構成ファイルは cache.cpf_rejected にコピーされ (その名前のファイルがある場合には上書きされます)、構成ファイルとして指定されたファイルには、Caché の起動に実際に使用された構成パラメータが書き込まれます。

Caché のプライベート Web サーバは Apache

Caché 5.1 をインストールすると、そのプライベート Web サーバとして Apache のインスタンスもインストールされます。別の Web サーバを使用するようにサイトで構成を変更できますが、Caché のプライベート・サーバのインストールは必ず行われます。

既定のポートの変更

既定では、Caché のスーパーサーバ・ポート番号として、1972 以降で最初の未使用の番号が選択されるようになりました。この値 1972 に依存しているアプリケーションは、スーパーサーバに接続できない場合があります。さらに、Caché のプライベート Web サーバ用に別のポート番号が使用されるようになりました。選択される値は、8972 以降の最初の未使用ポートです。どちらも下 2 桁が 72 ですが、2 つのポート番号では関係はありません。スーパーサーバ・ポートが 1973 で、Web サーバのポート番号が 8977 となる場合もあります。

カスタム・インストールの実行時に、スーパーサーバのポート番号とプライベート Web サーバのポート番号の両方を明示的に設定することも可能です。

CSP ゲートウェイの変更

Caché バージョン 5.1 では、2 つのプラットフォームにおいて CSP ゲートウェイの実装が変更されています。

• OpenVMS に対するサポートの終了

  今後 OpenVMS で CSP ゲートウェイはサポートされません。これを参照している部分は OpenVMS のインストール・スクリプトから削除されており、コードは OpenVMS 向けの製品から除外されています。

  Note:

  既存の CSP ゲートウェイ・ファイルがある場合は、以前のバージョンからアップグレード時に削除されます。

• OpenVMS 用の WebServer パラメータ

  OpenVMS の .cpf ファイルには、再び WebServer パラメータが含まれるようになりました。形式は以下のとおりです。

  WebServer=[ON|OFF],<server>:<port>
  

  .cpf ファイル内でこのパラメータが指定されていない場合は、既定値として “OFF”、“”、および 8972 以降の最初の使用可能ポートが選択されます。

既定のユーザ名およびパスワード

CSP ゲートウェイが Caché に接続するときに、最初に送信されるメッセージはログイン・メッセージですが、この中には、CSP ゲートウェイ管理ページで定義されたユーザ名とハッシュ化パスワードが含まれることがあります。サーバの $username が "" の場合は、CSP ゲートウェイが Kerberos を使用して接続しなかったことを示し、既定のユーザ名およびパスワードを使用してこのサービスへのログインが試行されます。

ログインに失敗した場合は、監査ログにエントリを記録してから (監査が有効化されている場合)、CSP ゲートウェイが停止します。成功した場合、$username は NULL にはならず、CSP ページを表示するための関数など、他の関数を CSP サーバから呼び出せるようになります。$username ="" の間は、CSP サーバによって呼び出されるのはログイン・メソッドのみです。

データ表現

読み取り専用データベースの処理で一貫性を向上させるために、このバージョンの Caché では、データベースを識別する方法が変更されています。データベースのプロパティにおいて読み取り専用が指定されているか、^MOUNT で読み取り専用が宣言されているデータベースは、読み取り専用であると認識されます。

ライト・デーモンのアクセスによってデータベースのモードを判定

Caché バージョン 5.1 では、データベースがマウントされるときに、データベースを更新するのに十分なアクセス許可が付与されているかどうかの検査がライト・デーモンによって行われます。アクセス許可が付与されていない場合は、データベースは強制的に読み取り専用モードでマウントされます。

クラスタ参加ロジックの改善

Caché 5.1 では、クラスタ・マスタ上でスイッチ 10、13、および 14 の 3 つ (データベース・アクセスを不可能にする) が設定されていると、クラスタ・メンバが完全にクラスタに参加することはできなくなりました。以前のリリースでは、新しいシステムが、クラスタ・マウントや、データベースに対する読み取りおよび書き込みを行うことも可能でした。クラスタがバックアップを実行中のときにこれらの操作が行われると、問題が発生する場合がありました。

このバージョンでは、新しいクラスタ・メンバの起動時に、クラスタ・レベルで設定されるスイッチおよびローカルで設定されるスイッチの検出が行われます。このため、グローバル・アクセスをブロックするスイッチが設定されている場合は、クラスタに参加しようとしているメンバ上の Caché 起動プロセスがハングします。これが発生すると、コンソール・ログ・メッセージが生成されます。

ジャーナリングのデータベース属性化

Caché 5.1 では、ジャーナル状態の指定がデータベース単位で行われます。これによって、システムの信頼性が大きく向上します。以前のバージョンでは、グローバルでの変更がジャーナルに記録されることもされないこともあり、また、トランザクションに明示的または暗黙的に (%Save や SQL UPDATE 文を介して) 関与することも関与しないこともあり、これが原因で不整合 (クラッシュ・リカバリ後) が発生していましたが、このバージョンではこのような不整合に対処しているためです。この変更の詳細を以下に示します。

• ジャーナル状態は、個々のグローバルではなく、データベースのプロパティです。 この設定に応じて、データベース内のグローバルがすべてジャーナルに記録されるか、記録されなくなります。 ジャーナルの状態は、YES と NO の 2 つのみです。

• 新しいデータベースのジャーナル状態の既定の設定は YES です。 以前のバージョンからのデータベースを初めてマウントするときに、この値は YES に設定されます。新規グローバルの既定値に関する以前の設定値およびそのデータベース内の個々のグローバルの設定は無視されます。

• トランザクション内では、変更がジャーナルに書き込まれます。影響を受けるグローバルが存在するデータベースの設定は無視されます。 ロールバックは、以前と同様に機能します。

• CACHETEMP にマッピングされているものはジャーナルに記録されません。このジャーナル動作は以前と同様です。

• ジャーナルのリストア時には、データベースの現在の設定が考慮されます。 ジャーナルに書き込まれるときに、データベースの状態についてはジャーナルに保存されません。リストアの時点でのデータベースの状態によって、実行するアクションが決まります。 つまり、JOURNAL=YES のデータベースに対する変更は永続的ですが、それ以外のデータベースに対する変更は永続的ではない可能性があります。 Caché では、物理的な整合性は保証されますが、トランザクションに関与するデータベースの設定が JOURNAL=NO の場合、アプリケーションの整合性が必ずしも保証されるとは限りません。

• クラスタにマウントされるデータベースのグローバルがジャーナルに記録されるかどうかは、データベースの設定によって決まります。

• 実行中のシステムにおいて、データベースの設定は変更することができます。 これを行うと、考えられる影響と監査対象の状態の変更についての警告メッセージが管理者に表示されます。

この変更において、Caché 5.1 では以下の変更も行われています。

• この変更によるディスク領域への影響を低減するように、パージの既定の設定が変更されました。

• 以前のリリースでグローバル単位でジャーナル記録を有効または無効にしていたルーチン ^%JOURNAL が削除されました。

• ^%GCREATE および ^%SYS.GCREATE が変更され、グローバルをジャーナルに記録するかどうかを尋ねるメッセージは表示されなくなりました。

Z-グローバルのジャーナリング

以前のリリースでは、z/Z* グローバルをジャーナル記録対象から (トランザクション内であっても) 除外するかどうかを、JournalZGlob パラメータを使用して指定していました。バージョン 5.1 では、ジャーナリングの安定性を向上させるために、このパラメータが削除されました。このフラグが設定されている旧バージョンの Caché システムをアップグレードするときに、定義済みデータベース内の既存の z/Z* グローバルには、そのデータベースのジャーナル属性が設定されます(CACHETEMP の既定のジャーナル属性はオフです)。

サイトで新しい z/Z* グローバルをジャーナル記録対象から除外する場合、ジャーナル属性がオフに設定されているデータベースに z/Z* グローバルを管理者はマッピングする必要があります。

ジャーナル・パージへの変更

このリリース以前の既定の動作では、7 日後にジャーナル・ファイルを削除していました。Caché バージョン 5.1 では、既定の動作が変更されました。

X 日間後、または Y 回バックアップに成功した後に、Caché でジャーナル・ファイルを削除できます。推奨の設定は以下のとおりです。

• 1 <= X <= 100

• 1 <= Y <= 10

X と Y が両方とも 0 より大きい場合、X 日後、またはバックアップに Y 回成功した後 (どちらか早い方) にファイルが削除されます。X または Y がゼロの場合、残りの条件に基づいてファイルの削除が実行されます。X と Y をゼロに設定すると、ファイルの削除を完全に回避できます。

ジャーナル・ファイルは、Caché バックアップに 2 回連続して成功した後に削除されるようになりました。

シャドウの [適用済みのトランザクションのジャーナリング] の削除

シャドウ・データベースで適用済みトランザクションをジャーナルに記録するかどうか選択する設定はありません。これまでの Caché リリースの既定の動作では、シャドウ・データベースに対する更新をジャーナルに記録しませんでしたが、[ジャーナルが適用されたトランザクション] チェックボックスにチェックを付けることで、シャドウでジャーナリングを有効にすることができました。これにより、シャドウ・データベース上の活動を示す個別のジャーナル・ファイルが維持されていました。

Caché 5.1 では、このオプションがなくなり、シャドウ・データベースのジャーナリングは、データベース自体のグローバル・ジャーナルの状態で決定されます。アップグレード後、シャドウ・データベースのジャーナリングが有効になります。シャドウのストレージ容量に対する高まる要求を緩和するため、Caché では、ソース・ジャーナル・ファイルがデジャーナルされ、シャドウに実行中のトランザクションが含まれなくなると、宛先のシャドウ・コピーを削除します。

シャドウイングの宛先となるすべてのデータベースをジャーナルに記録することをお勧めします。ただし、宛先となるシャドウ・データベースをジャーナルしない場合は、CACHESYS データベースのジャーナリングも無効にする必要があります。Caché は、CACHESYS データベースの ^SYS グローバルでのシャドウイングで最後に処理されたジャーナル・レコードのジャーナル・アドレスとジャーナル・ファイル名を保存します。これは、シャドウイングが失敗した場合に、シャドウイングを再開するチェックポイントとして動作します。

互換モード (レコード・モード) シャドウイングの削除

ジャーナル転送方法を選択するオプションがなくなりました。すべてのシャドウイングでは、高速モード、変更を適用方法を使用します。

Caché バージョン 5.1 より前のバージョンでは、シャドウイングのジャーナル転送に次の 4 つの方法がありました。

• 高速モード、変更を適用

• 高速モード、変更を適用しない

• 互換モード、変更を適用

• 互換モード、変更を走査

互換モード (以前はレコード型転送モードと呼ばれていた) は、ほとんどの場合、異なるプラットフォーム間での互換性の維持に使用されましたが、異なる Caché リリースのサポートを行うこともありました。高速モード (以前はブロック型転送モードと呼ばれていた) は、異なるエンディアン・システムに必要なバイトの順序変更を自動実行するため、今後異なるプラットフォームをサポートします。

1 つのシャドウから 異なる Caché リリースを実行する複数のプロダクション・サーバをサポートする必要がある場合は、シャドウ・サーバに複数の Caché インスタンスを各 Caché バージョンに 1 つずつ設定して、古いバージョンでは互換モードではなく高速モードを使用することをお勧めします。これにより、最適なパフォーマンスと安定性が生まれます。

シャドウイングの既定値における変更

Caché 5.1 の既定では、以下のデータベースはシャドウイングされません。

• CACHEAUDIT

• CACHELIB

• DOCBOOK

• SAMPLES

これらをシャドウする場合は、システム管理ポータルの ホーム, 構成, シャドウ・サーバ設定, シャドウサーバ編集 ページで、[このシャドウのデータベースマッピング] の隣にある [追加] をクリックします。

拡張およびサイズの特性の維持

Caché 5.1 では、再起動後も CACHETEMP の拡張およびサイズの設定が維持されます。再起動後に Caché から報告されるサイズは、最小値の 240 MB とファイルに割り当てられたサイズのうち、いずれか小さい方です。オペレーティング・システムによって割り当てられたファイルのサイズが 240 MB よりも大きい場合は、Caché は最初の 240 MB のみを記述するようにマップ・ブロックを初期化し、後で必要に応じてマップを拡張します。ただし、ファイルの物理サイズを縮小することはありません。

照合

再起動後は、以前の設定とは無関係に、CACHETEMP の照合は Caché Standard にリセットされます。サイトで別の照合が使用されるようにするには、^%ZSTART ルーチンの “SYSTEM” コールバックにコードを追加して、必要な照合を設定します。

CACHETEMP 削除の条件

以下に条件を示します。

1. CACHETEMP が 2 KB データベースである

2. STU (システム起動) の実行時に CACHETEMP がマウントされる

Caché は CACHETEMP の削除と再作成を試みます。2 番目の条件に該当するのは、例えば、Caché が “nostu” モードで起動され、その後でオペレータが手動で STU を実行する場合です。

CACHETEMP が再作成されるとき、初期サイズは 1 MB、拡張係数は 0 (拡張量が 10% と 10 MB のいずれか大きい方であることを示す)、最大サイズは 0 (制限なし) に設定されます。

フィールド・テスト・バージョンからのアップグレードは不可

現在実行している Caché のバージョンが 4.1.x または 5.0.x の場合、インストール時に Caché 5.1 へのアップグレードが可能です。

DDP の使用

以前のバージョンの Caché 上で DDP を実行していた場合は、適切な数のネットワーク・スロットを割り当てるように構成ファイルを編集する必要があります。今後は、ネットワーク・スロット数の既定値は計算されません。

• 構成ファイルの [Net] セクションの maxdsmport の値を、DDP に使用されるイーサネット・カードの数と等しくなるように設定します。

• ファイルの [config] セクションの、LegacyNetConn の 4 番目のパラメータを 0 から 1 に変更します。

$SYSTEM.OBJ.UpgradeAll()

コンパイラ・バージョンの変更、グローバルおよびルーチンの再編成、および Caché クラスの変更が行われたため、事前の準備および計画を行わずに $SYSTEM.OBJ.UpgradeAll() を起動すると、大量のエラーが発生する場合があります。

合成ロール ： %LegacyUnknownUser

以前の動作に近づけるために、バージョン 5.1 へのアップグレード時に既定のロールが作成されます。このロールの名前は、%LegacyUnknownUser です。これは、高度なセキュリティが実装されていない、バージョン 5.0 とそれ以前のバージョンの Caché からアップグレードした後は、ユーザが定義されていない状態になるからです。 この場合は、すべてのユーザが UnknownUser としてログインします。 UnknownUser にアクセス特権が与えられていない場合は、管理者によってシステムが構成されるまでの間、既存のユーザは操作を実行できなくなります。

%LegacyUnknownUser ロールには、表示されるリソースとアップグレード・インストール時点で存在するカスタマ定義データベースごとに作成されるリソースに対する、読み取りおよび書き込みのアクセス権が付与されます。

Name:               %LegacyUnknownUser
Description:        Legacy Unidentified Users
Roles granted by this role:
                    <none>
Resources owned by this role:
                    Resource                      Permission
                    --------                      ----------
                    %System_CallOut               U
                    %Service_SQL                  U
                    %Service_Object               U
                    %Service_Console              U
                    %Service_CallIn               U
                    %Service_CacheDirect          U
                    %Development                  U
                    %DB_USER                      RW
                    %DB_SAMPLES                   RW
                    %DB_%DEFAULT                  RW
Users owning this role:
                    <none>

さらに、以下のサービス・リソースに対する使用アクセス権が、ここに示した条件で付与されます。

管理者によってシステムが正しく構成された後は、UnknownUser ユーザを無効にするか、アプリケーション環境の追加要素を Caché の高度なセキュリティの制御下に移行しながら、^SECURITY またはシステム管理ポータルを使用して、ロール %LegacyUnknownUser に割り当てられたリソースを徐々に減らすことができます。 %LegacyUnknownUser ロールの特権を減らすことや、このロールを削除することは、移行期に手動で行う作業です。 Caché によって自動的に実行されません。

%LegacyCD および %LegacySQL

これらは、アップグレード時のみに既存のユーザに自動的に適用され、既存のユーザが、バージョン 5.1 でも以前と同じレベルでアクセスできるようになります。 新しいユーザには、これらのロールは特に必要ありません。

% で始まるグローバルへのアクセスを以前のバージョンと同様に許可

アップグレードの場合は、Security.System.PercentGlobalWrite の値が True に設定されます(新規インストールの場合は、False に設定されます)。これによって、% で始まるグローバルに以前のバージョンと同様の方法でアクセスできます。値を変更するには、^SECURITY ルーチンを使用できます。

クラスタの全メンバが同じバージョンの Caché を実行する必要あり

ECP クラスタの全メンバが、同じバージョンの Caché を実行している必要があります。あるメンバをアップグレードする場合は、他のメンバもすべてアップグレードする必要があります。

OpenVMS でのアップグレード時の CSP ゲートウェイの削除

今後 OpenVMS で CSP ゲートウェイはサポートされません。これを参照している部分は OpenVMS のインストール・スクリプトから削除されており、コードは OpenVMS 向けの製品から除外されています。

グローバルとパッケージのマッピングの削除

以前のバージョンからのアップグレード時に、以下に示すグローバルへのマッピングが削除されます。

• 名前が “^odd” で始まるすべてのグローバル

• ^rINDEXCLASS、^rOBJ、^ROUTINE

• ^mdd

名前が “%Z”、“%z”、“Z”、または “z”で始まるパッケージの定義は維持されますが (“^oddDEF”)、コンパイル済みクラス情報は削除されます。“^odd” グローバルは、クラスが $SYSTEM.OBJ.Upgrade() を介してリコンパイルされるときに再作成されます。

さらに、構成ファイル (.cpf) 内で定義されていたクラス・マッピングは、すべて破棄されます。

高信頼アプリケーションの定義の削除

Caché 5.1 のセキュリティ・モデルでは、高信頼アプリケーションはサポートされません。ユーザが接続または再接続するときに、パスワード認証がオンの場合はパスワードの入力が要求されます。このような動作を望まない場合、管理者は Cache Direct サービスに対する認証をオフにしてください。

Windows ネットワーク・サーバのユーザ名およびパスワードの変更

以前のバージョンでは、Windows 上での Caché のサービスのインストールおよび起動には、特に構成されない限り、既定のユーザ名 “_SYSTEM” とパスワード “_sys” が使用されていました。このユーザ名およびパスワードの値は、構成マネージャの [詳細] タブの [入力/出力] オプションで設定されていました。

バージョン 5.1 では、アップグレード時に、アップグレード用に作成された Windows サービス定義内にこれらの値 (値が設定されていなかった場合は既定値) が格納されます。

Windows 管理インタフェースを使用して管理者は値を変更できます。Windows の [スタート] メニューから [プログラム]→[管理ツール]→[コンポーネント サービス] を選択します。該当する Caché サービスを選択して、[操作] メニューの [プロパティ] を選択します。ユーザ名とパスワードは、[ログオン] タブでアクセスします。

グローバル・レプリケーションの削除

グローバル・レプリケーションは、Caché 5.1 ではサポートされません。検出されると、アップグレードを行うプロセスでシステムからこの機能の使用が削除され、コンソール・ログに記録されます。以前このツールによって提供されていた機能は、シャドウイングを使用して実現できます。詳細は、"Caché データ整合性ガイド" の "シャドウイング" の章を参照してください。

ECP (Enterprise Cache Protocol)

分散されたシステムには、ECP を使用することを強くお勧めします。ECP は、DCP などの従来のネットワーキング手法よりも大幅に進歩したプロトコルです。現在 DCP を使用している場合、ECP に変更することで、パフォーマンス、信頼性、可用性、およびエラー・リカバリが向上します。

既定のパスワード設定の変更

Caché のインストール時にセキュリティ設定を “最小” にすると、作成されるすべてのユーザの既定のパスワードが “SYS” に設定されます。これらのユーザのパスワードをできるだけ早く別の値に変更することを強くお勧めします。変更することで、システムのセキュリティ・レベルが低くても、運用開始時からアクセス制御が確立されるからです。

読み取り専用のデータベース CACHELIB

Caché バージョン 5.1 では、セキュリティ上の理由から、CACHELIB が読み取り専用のデータベースになりました。これによって、以前とは運用方法が変わります。CACHELIB はサイトで読み取り専用データベースのままにしておくことを強くお勧めします。以前 CACHELIB に配置されていたサイト定義およびアプリケーション定義のグローバル、クラス、テーブルなどは、別の場所に移動してください。

システム間の情報一貫性の維持

クラスタ化された Caché システムでは、クラスタのすべてのシステムにおいて、ユーザ、ロール、アプリケーションなどのリストが同じままであることが望まれます。Caché バージョン 5.1 の初期リリースには、あるシステムから他のシステムに変更を反映する仕組みがありません。これに対処するには、管理者が手動で、同一の変更を各システム上で行う必要があります。

Kerberos との一貫性の維持

認証メカニズムとして Kerberos を使用しているサイトでは、Kerberos が保持している有効なユーザのリストに対する変更を、手動で Caché に反映させる必要があります。このことを自動的に行うメカニズムが Caché の今後のバージョンに組み込まれる場合がありますが、初期リリースにはありません。

監査ログの統合

複数のシステム (例えば 1 つのクラスタの全システム) からの監査データに対して、監査レポートや、サイト独自の分析を実行するには、個々の監査ログを手動で 1 つにまとめる必要があります。

ライト・イメージ・ジャーナル・ファイル

Caché 5.1 では、クラスタ化されたシステムにおけるリカバリ機能の向上のために、ライト・イメージ・ジャーナル (WIJ) ファイルのフォーマットが変更されています。この結果、以下の 2 つの点で影響があります。

1. アップグレード対象のシステムにおいて、未解決の障害が残っている場合は、新しいバージョンにアップグレードする前に、Caché を再起動してリカバリを行ってください。

   このようにしなければ、ジャーナル・パージ・ユーティリティが旧形式のジャーナル・ファイルを認識せず、破壊されたジャーナル・ファイルが存在するというエラーを報告します。このエラーを避けるには、アップグレード前に適切なオペレーティング・システムのコマンドを使用して、旧形式のジャーナル・ファイルをバックアップ・ディレクトリに移動します。

2. ECP 構成の全メンバが、同じバージョンの Caché を実行している必要があります。あるメンバをアップグレードする場合は、残りのメンバもアップグレードする必要があります。

古いジャーナル・ファイルを Caché 5.1 にリストアする必要がある場合、JConvert ルーチンと %JRead ルーチンを使用することができます。

シャドウイング

Caché をアップグレードすると、既存の互換モードのシャドウが高速モードに変換されます。変換された高速モードのシャドウがソースと共に機能するかどうかは、ソースの構成によって決まります。Caché 5.1 によって、高速モード・シャドウイングのための自動エンディアン変換が行われます。

互換モード (以前はレコード型転送モードと呼ばれていました) はサポートされません。

クラスタ

Caché 4.1 のクラスタ、Caché 5.0 のクラスタ、および Caché 5.1 のクラスタを同じハードウェア上で共存させることはできますが、これらをクラスタ化することはできません。これらのクラスタがお互いに通信する必要がある場合、DCP または ECP を使用する必要がありますが、ECP の使用をお勧めします。

埋め込み SQL 内の非 % 変数の管理

ObjectScript プロシージャ内で埋め込み SQL 文が使用する任意の非 % 変数は、プロシージャの public 変数リストに追加し、プロシージャ内で New コマンドを実行する必要があります。Caché の制約ではありますが、public リストと new リストにこれらの変数を手動で簡単に追加できるように、マクロ・プリプロセッサに変更が加えられています。

ホーム, 構成, 詳細設定 で SQL 設定の [.INTコード中にSQL文をコメントとして残す] が “[はい]” の場合、コメント内の SQL 文と共に、SQL 文によって使用される % の付いていない変数がコメント・テキストにリストされます。このように変数をリストすることで、簡単に変数リストを検出して、カット・アンド・ペーストで MAC コードの public リストや new リストに移動します。

グローバル名の中の Unicode

グローバル名に含まれる Unicode のサポートは、まだ完全には機能しないので、使用しないでください。

Caché RPM キット

Caché RPM キットは /usr/cachekit/5.1 にインストールします。/usr ディレクトリは、読み取り専用でマウントされる場合や、空き領域がほとんどない場合があります。必要に応じて場所を変更してください。

データベースの相互運用性

以前のバージョンの Caché で作成されたデータベースをバージョン 5.1 でマウントすることが可能です。また、データベースをアップグレードすれば、そのまま使用できます。ただし、このプロセスを元に戻すことはできません。アップグレードされたデータベースを以前のバージョンに戻すことはできません。

アップグレードではローカル・データベースのみを処理

Caché 5.1 では、$SYSTEM.OBJ.UpgradeAll() を実行したときに、アップグレード対象のデータベースがあるかどうか検索されるのはローカルのみです。リモートでマウントされたデータベースは無視されます。このようなデータベースをアップグレードするには、リモート・システム上で UpgradeAll() を実行する必要があります。

ECP を使用する場合の Caché のバージョン

コンパイラがアップグレードされているため、ECP 構成内のシステムは以下のいずれかでなければなりません。

• すべてバージョン 5.1 上にあります。または

• データ・サーバはバージョン 5.1 になければなりませんが、アプリケーション・サーバはバージョン 5.0 でもバージョン 5.1 でもかまいません。

バージョン 5.1 から以前のバージョンへのアプリケーションの移行

Caché 5.1 から以前のリリースにアプリケーションを移植することには問題が多く、アプリケーションが依存するこのバージョンの機能 (コンパイラの動作、新しいストリームの実装、アプリケーション用にエクスポートされる XML における変更、新しいクラス表現など) にも左右されます。その必要がある場合は、インターシステムズのサポート窓口Opens in a new tabにご連絡ください。

ODBC および JDBC の互換性

プロトコルにおける変更のため、Caché 5.1 付属の ODBC および JDBC クライアントが対応するのは、バージョン 5.0.13 以降の Caché サーバのみとなっています。バージョン 5.0.13 より前のバージョンの Caché サーバに接続しようとすると、エラーが発生します。

RoseLink

現時点では、RoseLink が Caché へのアクセスを試行するときに使用されるのは、標準の SQL ユーザ名およびパスワードのみです。したがって、インストールの既定のセキュリティ・レベルが "標準" または "ロック・ダウン" であるシステム上ではサポートされません。この制約は、Caché 5.1 の次回メンテナンス・バージョンにおいて撤廃される予定です。

また、使用されるクラスにアクセスするために、ユーザに %Development:Use のアクセス許可が付与されている必要があります。

Dreamweaver

Dreamweaver MX から Caché へのアクセスに使用する接続は、このバージョンでは使用できません。この制約は、Caché 5.1 の将来のメンテナンス・リリースにおいて撤廃される予定です。

Perl および Python の言語バインディング

Perl および Python の言語バインディングがサポートされるのは、32 ビット版の Windows 上のみです。

C++ 言語バインディング

C++ 言語バインディングがサポートされるのは、Visual Studio 7.1 を使用する Windows プラットフォーム上のみです。

Windows

• ヘルプのフォーマットの変更

  コマンド css.exe および ccontrol.exe の使用法についての情報が、HTML 形式で用意されています。これらのコマンドを実行するときに、最初の引数として “help” を指定すると、既定のブラウザが起動されてヘルプ・ファイルが表示されるようになりました。

• 新しい日本語ロケール

  Windows 用の新しい日本語ロケール (jpww) が追加されました。これは、標準の jpnw ロケールに似ていますが、Telnet ターミナル用の既定値が SJIS ではなく UTF8 である点が異なります。Windows 上で新規日本語インストールを行うときは、既定ではこの新しいロケールがインストールされます。Caché のアップグレードを行うときは、以前のロケールが維持されます。

• %path% 環境変数の変更

  システムのセキュリティを向上させ、Caché コンポーネントの検出方法を統一するために、バージョン 5.1 では以下のファイル・システム・ディレクトリ名が追加されています。

  \Program Files\Common Files\InterSystems\Cache
  

  このディレクトリ名は、Windows システムの %path% システム環境変数に追加されています。これは、このマシンのすべてのユーザに適用されるように、HKEY_LOCAL_MACHINE ハイブに追加されます。

• Visual Studio 7.1

  Microsoft Windows 上で、Caché が Visual Studio 7.1 でコンパイルされるようになりました。Caché と通信するアプリケーション (例えば CALLIN インタフェースや CALLOUT インタフェースを使用するアプリケーション) は、Visual Studio をこのバージョンにアップグレードする必要があります。

Windows XP Professional

マップされたドライブは Windows XP Professional 上でサポートされません — Windows XP Professional でのセキュリティの改善により、Microsoft はユーザにマップされたドライブの使用を推奨していません。また、マップされたドライブの使用を試みると、以前とは異なる動作となります。

GUI ツールから、または telnet セッションから、マップされたドライブにアクセスするには、XP Professional ユーザは以下の手順に従うことをお勧めします。

• リモートのマップされたドライブには、これまでどおり、構成でユーザ名とパスワードを入力します。さらに、ZSTU スタートアップ・ルーチンを編集し、マップしたドライブに以下の行を追加します。

  Set x=$zf(-1,"net use z: \\someshare")
  

  

• 仮想マップ・ドライブには、この行を subst コマンドでマップされた各ドライブに追加します。

  Set x=$zf(-1,"subst q: c:\somedir\someotherdir")
  

  

起動後は、それ以上のマッピングを追加することはできません。

マップされたドライブを使用するには、以下のように Caché を開始するという方法もあります。

\cachesys\bin\ccontrol start configname

この方法では、ZSTU ルーチンに何も追加する必要がなく、ユーザ名やパスワードを入力する必要もありません。さらに、ユーザがマップしたドライブ、またはスタートアップ後に subst コマンドを使用してパスをマップしたドライブも、利用可能です。この方法での制約は、Caché を開始したユーザが Caché にログオンしている間のみ Caché が稼動するということです。

Windows Enterprise Server 2003

このバージョンの Windows に付属している Internet Explorer のバージョンでは、セキュリティ関連の構成オプションがすべて無効になっています。その結果、システム管理ポータルによって表示されるさまざまなページに影響が及びます。例えば、スクリプトが実行されないので、スクリプトによって生成される情報が表示されません。正しい動作に戻すには、インターネットのセキュリティ・レベルの設定を “高” から “中” に変更します。

ユーザが、システム上のシステム管理ポータルに初めてアクセスするときに、このサイトを “信頼済み” のリストに追加するかどうかを尋ねる Internet Explorer のメッセージが表示されます。応答として承諾を選択すると、このサイトに対するインターネット・セキュリティ・レベルも "中" に変更されます。

Mac

XSLT (Extensible Stylesheet Language Transformation) プロセッサの 1 つである Xalan がサポートされるのは、OS x 10.4 上のみです。

OpenVMS

• Itanium 上で Kerberos を使用してアクセスするには ECO が必要

  Kerberos 認証を使用する OpenVMS サーバにアプリケーションからアクセスするには、ftp://ftp.itrc.hp.com/openvms_patches/layered_products/i64/ ftp サイトからダウンロードできるパッチ HP-I64VMS-TCPIP-V0505-11ECO1-1Opens in a new tab をインストールする必要があります。この ECO は TCP/IP 用のもので、実際のオペレーティング・システム用ではありません。このパッチがインストールされていない場合は、C++ バインディング、ODBC、JDBC、およびスタジオを使用するクライアントに、サーバから誤った応答パケットが送信されることがあります。

  Note:

  この ECO を適用するのは、Itanium ハードウェア上の OpenVMS のみです。Alpha 上の OpenVMS には必要ありません。

• CSP ゲートウェイの削除

  OpenVMS 上の CSP ゲートウェイはサポートされなくなりました。詳細は、"OpenVMS のインストール手順" を参照してください。

• GSS のパスワード・マスクの制限

  Kerberos を使用するシステム上で JDBC を介して Caché にアクセスしようとしたときに、ユーザの資格情報が見つからず、かつユーザの ID が呼び出し元から提示されていない場合は、JDBC が Kerberos に呼び出し元の認証を要求します。このとき、OpenVMS 上のターミナル IO の特性により、パスワードのエコーは抑止されず、マスクもされません。

• スタジオからの SOAP クライアント・ウィザードの使用

  スタジオから SOAP ウィザードを起動しようとしたとき、OpenVMS に対して使用される現在の Web サーバを指すようにアプリケーション /isc/studio/template が設定されていない場合、起動は失敗します。

• Caché のプロセスと /SYSTEM

  Caché の一部であるプロセスはすべて UIC=[1,4] で実行されます。したがって、これらのプロセスで使用される Caché 関連の論理デバイス (例えば .cpf ファイル内で指定されているデバイス) はすべて、アクセス・エラーを防ぐためにシステム・テーブル内で定義されている必要があります (/SYSTEM で定義)。

• WebServerName と WebServerPort

  バージョン 5.1 では、WebServerName と WebServerPort の両方が定義されていなければ、スタジオからクラス・ドキュメントにアクセスすることはできません。これらは、[システム管理] ページ、ホーム, 構成, 詳細設定 の [その他] カテゴリにあります。

AIX®

• IBM Java ランタイムと Kerberos

  IBM Java 実行時環境を使用するシステム上 (AIX® 32 ビット、AIX 64 ビット、および SUSE Linux Enterprise Server) では、kinit を使用すると、Kerberos のプリンシパル名およびパスワードの入力要求プロンプト表示 (プリンシパル名およびパスワードの API) と互換はありません。kinit を使用するには、以下のファイルを修正します。

  ${java.home}/lib/security/iscLogin.conf
  

  これによって、モジュール com.sun.security.jgss.initiate のオプションは以下のとおりになります。

  useDefaultCcache=true
  

  このランタイムを使用するときは、以下の場所にある Java ルーチンが動作します。

  {java.home}/bin/kinit
  

  以下の場所にあるネイティブの Kerberos ルーチンは動作しません。

  /usr/krb5/bin/kinit
  

• NFS でマウントされたファイル・システムと排他性

  Caché データベース (.dat および .ext) およびロック (.lck) ファイルを作成するときに、O_EXCL (排他的アクセス) が使用されます。ただし、この排他的アクセスが NFS によって保証されないという既知の制約があります。

Linux

Linux 環境の NetApp NFS でマウントされたファイル・システムでは、suid:sgid 実行形式ファイルによって作成されたファイルの所有者が、標準のファイル・システムの場合とは異なり、非 UNIX® 標準の所有者となります。実行可能プログラム上の SGID ビットでは実行に失敗しますが、SUID ビットではファイルの所有者が実行可能プログラムの所有者に正しく設定されます。この動作になるのは、NetApp システム上のみです。

Red Hat 3.0/4.0 と IBM WebSphere MQ

MQ インタフェースを使用する場合、Red Hat バージョン 3.0 および 4.0 上で Caché 5.1 を実行するときは、IBM WebSphere MQ バージョン 6.0 が必要です。

Linux/AMD64

Intel プロセッサ上の Linux 実装から AMD64 上の Linux に Caché をアップグレードする場合、Caché の新しいライセンスが必要です。インターシステムズの Web サイトOpens in a new tabには、以下のことを示す内容が記載されています。

“32 ビット CPU と 64 ビット CPU の間には大きな違いがあるため、32 ビット用と 64 ビット用で異なる Caché ソフトウェアが用意されています。その結果、ライセンスの観点においてはこれらは異なるプラットフォームです。そのため、プラットフォーム固有の Caché のライセンスを、別のプラットフォームに移すことはできません(通常の下取りポリシーが適用されます)。プラットフォームに依存しないライセンスは、無償で移行可能です。”

SUSE Linux Enterprise Server

• IBM Java ランタイムと Kerberos

  IBM Java 実行時環境を使用するシステム上 (AIX® 32 ビット、AIX 64 ビット、および SUSE Linux Enterprise Server) では、別の Kerberos kinit が必要になります。AIX® に付属する説明を参照してください。

• ターミナルと Kerberos 認証

  SUSE Linux Enterprise Server 9 を AMD64 上で実行する場合は、パッケージの扱いが他のバージョンの Linux とは若干異なります。その結果、このシステム上でターミナルを Kerberos 認証と併用しようとすると、エラーが発生することがあります。これは、インストール時に開発者用パッケージのインストールが選択されていない場合です。この場合、正常に動作させるには、以下のパッケージをインストールする必要があります。

  • heimdal-devel

  • heimdal-devel-32bit

  パッケージの場所を探すには、検索機能を使用して、名前が “heimdal” で始まるすべてのパッケージを検索します。インストール時、ほとんどの場合に (“フル” を除く)、一覧に前述の 2 つのパッケージ名があり、未選択の状態になっています。これらを選択して、インストールを続行してください。

UNIX®

Caché を UNIX® 上にインストールするときに、既定のディレクトリとして cachesys 以外を指定できます。 このディレクトリ・パスは、環境変数 CACHESYS で指定されているものとします。ccontrol コマンドおよび csession コマンドでは、この環境変数が使用されます。インストール時に定義されていれば、Caché はそのディレクトリにインストールされます。定義されていない場合、Caché は UNIX® での標準の場所である /usr/local/etc/cachesys にインストールされます。

ccontrol と csession のどちらも、実行可能ファイルと同じディレクトリにレジストリが存在する必要があります。セキュリティ上の理由により、ccontrol では、所有者が root で、root のみが書き込み可能であるようにレジストリが保護されていることが検証されます。

Tru64 UNIX®

Tru64 システムでは、他の UNIX® ファイル・システムとは異なり、グループ所有権は作成プロセスのグループ ID に基づいて設定されません。代わりに、ファイルのグループ ID は、親ディレクトリのグループ ID に設定されます。

ただし、vfs サブシステム属性 “sys_v_mode” が 1 に設定されている場合は、ファイルのグループ ID が、プロセスのグループ ID と親ディレクトリのグループ ID のいずれかに設定されます。後者に設定されるのは、親ディレクトリの S_ISGID ビットが設定されている場合です。新しいファイルのグループ ID が、プロセスの実効グループにも、その補助グループ ID のどれにも一致しない場合は、新しいファイルの S_ISGID ビットがクリアされます。

通常、このことによって問題が発生することはありません。Caché のユーティリティによって作成されるすべてのディレクトリのグループ ID は、正しいグループ所有者に設定されるからです。ただし、場合によっては問題が発生することもあります。例えば、管理者が ^DATABASE を使用して、存在しないディレクトリ内にデータベースを作成すると、ディレクトリは作成されますが、そのディレクトリのグループ ID の調整は行われず、親ディレクトリから継承されたグループ ID になります。その結果、親ディレクトリから継承したグループ ID を持つこのデータベースに、cacheusr がアクセスできなくなることがあります。ディレクトリを作成するその他の Cache ユーティリティ (ジャーナリング、シャドウイングなど) にも、同じ問題があります。

HP-UX

Caché の暗号乱数ジェネレータ (データベースの暗号化および暗号解読などに使用) には、内部状態を初期化するために、真の乱数性 (エントロピー) のソースが必要です。 HP-UX 11i を除く、すべてのサポート対象 UNIX® プラットフォームに、特別なデバイス・ファイル /dev/urandom があり、カーネルのスレッド・タイミングに基づく真のエントロピー・ソースとなります。 HP-UX 上では、この機能は HP-UX Strong Random Number GeneratorOpens in a new tab の一部となっています。これは、HP から無償で提供およびサポートされるオプションのコンポーネントです。

Solaris

Solaris 上で実行されるアプリケーションは、パスワードを使用して資格情報の初期セットを取得できません。例えば、Kerberos 認証を必要とする Caché インスタンスにターミナルを介してアクセスしようとした場合にこの問題が発生します。Kerberos 認証を Caché と併用するには、以下に示すパッチを Solaris に適用する必要があります。

• Solaris 10 の場合は 121239–01 および 120469–03 (以上)

• Solaris 9 の場合は 112908-22 および 112907-06 (以上)

CACHELIB を読み取り専用としてマウント

CACHESYS および CACHELIB の再編成において、通常の運用で変更可能な情報はすべて CACHESYS にまとめられました。したがって、既定では CACHELIB は読み取り専用データベースとしてマウントされます。

% で始まるグローバルへのアクセス制限の強化

既定では、他のデータベースに存在して % で始まるグローバルに対する書き込みアクセス許可はルーチンに与えられません。 バージョン 5.1 では、この規則が一貫して適用されます。このことを変更するには、システム管理ポータルの ホーム, セキュリティ管理, システムセキュリティ設定 にアクセスし、[パーセントで始まるグローバルへの書き込みを有効に] の設定を “[はい]” に変更します。

CNLS に対するアクセス許可

CNLS アプリケーションは、Caché インストールのロケールを変更するために使用します。このアプリケーションを実行するには、%Admin_Manage:U が必要です。

認証を受けたネームスペースとルーチンをコマンド行よりも優先

以前のバージョンでは、ネームスペースおよびルーチンがコマンド行のパラメータとして指定されると、作成されるプロセスでは必ずそのネームスペースが使用され、そのバージョンのセキュリティ・メカニズムで指定されたネームスペースやルーチンは無視されていました。

バージョン 5.1 では、Caché のインストール時に [最小] 設定が指定された場合の csession の動作は以前と同様になります。ユーザが認証を受ける必要がある場合は、そのユーザのネームスペースおよびルーチンが、コマンド行で指定されたネームスペースやルーチンの設定よりも優先されます。

ルーチンおよびグローバルの移動

Caché 5.1 では、すべての %- ルーチンと %- グローバルが上記のように再編成されています。

ルーチン名の "%" の削除

Caché のシステム関数の見直しを行った結果、多数のルーチンが、その使用を制御する必要のあるシステム管理関数になりました。したがって、以下のルーチンの名前から “%” が削除され、その結果、マネージャ・データベースの保護下に置かれました。

• BUTTONS

• COLLATE

• DMREPAIR、DSET

• LANG*

• MATH

• NLS、NLSCOMP、NLSLOAD、NOREP

• ROLLBACK*

• SS、SSVNJOB、SSVNLOCK、SSVNROUTINE、ST

• UPDATECLASS

• Wcomm、Wpfiles、Wr、Wr1、Wsback、Wsdb、Wsdba、Wsmkey、Wsnls、Wsnls2

ルーチン名の変更

システム関数との関係を強調するために、いくつかのルーチンの名前が変更されました。

削除されたルーチン

内容を見直した結果、いくつかのルーチンが、他の部分と重複する機能であることが判明しました。これらは削除されました。

• %CLI — 同じ機能を Caché の $zf(-1) で利用可能です。UNIX®、OpenVMS、および Mac 上では、コマンド行の解釈は !<command> によって行われます。Windows システム上では、DOS コマンドの START によってこの機能が実行されます。

• %DKIOERROR — その呼び出しは、$$$ERROR または $SYSTEM.Error の使用で置き換える必要があります。

• %GED — 代わりに %GCHANGE メソッドと %Library.GlobalOpens in a new tab メソッドを使用します。

• %GDOLD — このルーチンは削除されています。

• %GROWTH — このルーチンの機能は、SYS.DatabaseOpens in a new tab クラスに移動しました。

• %GTARGET — このルーチンは削除されています。

• %LM — このルーチンの機能は、SYS.LockOpens in a new tab クラスに含まれています。

• %LMFCLI — このルーチンの機能は、$SYSTEM.License クラスに含まれています。

• %qserver — ユーザ・アクセス可能なエントリ･ポイントは、$SYSTEM.SQL に移動しました。

• %RMAC — このルーチンは削除されています。

• %START — このルーチンは削除されています。

• %USER — このルーチンは $USERNAME に置き換えられました。

• %UTIL — この内部ルーチンは、削除されました。このルーチンのメッセージ・ロギング機能は、システム・マクロ LOGMSG に変換されました。

スタブ・ルーチンの追加

頻繁に起動されるルーチンのいくつかが CACHESYS に移動し (%DM、%LICENSE、%GD、および %SS)、名前も変更されています。これらの新しいルーチンを呼び出すスタブ・ルーチンが、互換性のために元の位置に残されています。アプリケーションでは新しい名前を使用するように移行することをお勧めします。

スタブ・ルーチンの追加で、SYS タグが %SYS ルーチンから削除されました。

ルーチンの削除

上記の変更に加えて、内部ルーチンおよび廃止されたルーチンがこれらのライブラリから削除されました。このことがアプリケーションに影響すると考えられる場合は、インターシステムズのサポート窓口Opens in a new tabにご連絡ください。

%LANG ルーチンに対してはマッピングを行わない

Caché 5.1 では、言語拡張機能に使用される %LANG* ルーチンのルーチン・マッピングは無視されます。実行されるルーチンは、必ず %SYS ネームスペース (CACHELIB) にあるルーチンになります。

置き換えられたクラス

以下のクラスは、機能性の高い別のクラスによって置き換えられたため、システムから削除されました。以下はそのリストです。

新しいクラス

以下のクラスが、このバージョンで新たに追加されました。

• %Library.AbstractResultSetOpens in a new tab

• %Library.CacheCollectionOpens in a new tab、%Library.CacheLiteralOpens in a new tab、%Library.CacheObjectOpens in a new tab、%Library.CachePopulateOpens in a new tab、%Library.CacheString、%Library.CollateOpens in a new tab

• %Library.DataTypeOpens in a new tab、%Library.DeviceOpens in a new tab

• %Library.FunctionOpens in a new tab

• %Library.GlobalOpens in a new tab、%Library.GlobalEditOpens in a new tab、%Library.GTWConnection, 、%Library.GTWResultSetOpens in a new tab

• %Library.IJCDeviceOpens in a new tab

• %Library.JavaDoc、%Library.JournalRecordType、%Library.JournalState

• %Library.ObjectJournalOpens in a new tab、%Library.ObjectJournalRecordOpens in a new tab、%Library.ObjectJournalTransactionOpens in a new tab

• %Library.PersistentPropertyOpens in a new tab、%Library.PromptOpens in a new tab

• %Library.RemoteResultSetOpens in a new tab、%Library.RowSQLQueryOpens in a new tab

• %Library.ShadowStateOpens in a new tab、%Library.ShadowType、%Library.SwizzleObjectOpens in a new tab

• %Library.UtilityOpens in a new tab

プログラムの中のクラス名が未修飾でも正しい場所に解決されていた場合に、%Library に追加された新しいクラスと同じ名前のクラスがアプリケーションで定義されていると、名前の競合が発生することがあります。

クラスのコンパイルにおけるクラス名の大文字と小文字の競合

Caché バージョン 5.0 では、クラスで定義するメソッドの名前が、スーパークラスに含まれるメソッドと同じ綴りで、大文字と小文字の区別だけが異なるということも可能でした。例えば、%Library.PersistentOpens in a new tab から継承するクラスの中で定義された %save() という名前のメソッドは、スーパークラスの %Save() メソッドとは別のメソッドであると扱われていました。

バージョン 5.1 では、この状況でコンパイル・エラーが発生します。例えば、CSP アプリケーションで include() や link() というメソッドが定義されていると、これらが %CSP.Page.Include() および %CSP.Page.Link() と競合するようになります。

単純クラス名を使用した場合のあいまいな解決

アプリケーションで参照しているクラスの名前がパーセント記号で始まり、そのパッケージ名が指定されていない場合、クラス・コンパイラは、%Library パッケージ内にそのクラスがあるかどうかを検索します。以下はコードの例です。

Set BaseDir = ##CLASS(%File).ManagerDirectory()

上記例は、以下のように記述されているものと解釈されます。

Set BaseDir = ##CLASS(%Library.File).ManagerDirectory()

プログラムの中のクラス名が未修飾でも正しい場所に解決されていた場合に、%Library に追加された新しいクラスと同じ名前のクラス、例えば %UtilityOpens in a new tab がアプリケーションで定義されていると、名前を正確に解決できないことがあります。

クラス・メンバ名検査の厳密化

Caché バージョン 4.1 では、名前の綴りが同じで大文字と小文字の使い方が異なる 2 つのクラス・メンバを定義することはできませんでした。バージョン 5.0 には、このエラーが報告されないというバグがありました。

Caché バージョン 5.1 ではこのバグが解決されましたが、バージョン 5.0 でコンパイルできたこのようなクラスを今後もコンパイルできるようにするために、"厳密チェック" フラグをオフに設定することで、この検査を無効にできます。このように設定するには、以下のコマンドを実行します。

Set ^%qCacheObjectSys("strictchecking") = 0

%Library.Persistent に追加された新しいメソッド

%Persistent において新しいメソッドがいくつか実装され、すべての永続クラスに継承されます。この 3 つのメソッドは以下のとおりです。

• %LockId ： クラスのインスタンスに対するロックを取得します。

• %UnlockId ： 前に取得したインスタンス・ロックを解除します。

• %LockExtent ： エクステント内のすべてのインスタンスに対するロックを取得します。

• %UnlockExtent ： エクステントに対するロックを解除します。

• %GetLock ： インスタンスに対するロックの取得を試行しますが、必要に応じてそのインスタンスがメンバとなっているエクステントに、ロックをエスカレートします。

これらのメソッドの詳細は、%Library.PersistentOpens in a new tab のクラス・ドキュメントに記載されています。

ユーザ記述の % メソッドとの競合

“%” で始まるメソッド名をユーザ・アプリケーションで使用している場合は、“ベース” クラス内のインターシステムズ提供メソッド (%LIbrary.Persistent など) との競合がないことを確認してください。このバージョンの Caché では、このような名前の数が大幅に増加しています。

IdKey にある <Indexname>Exists メソッドおよび <Indexname>Open メソッド

このバージョンの Caché では、IdKey の <indexname>Exists メソッドおよび <indexname>Open メソッドが用意されています。

すべての永続クラスに、IdKey があります。明示的に定義していない場合またはスーパークラスから継承していない場合、IdKey<n> という名前のインデックスが生成されます。ここで、<n> は、IdKey という名前のインデックスが既に存在する場合に、語根 "IdKey" に付加される整数です。このインデックスは、システム生成インデックスとして定義されます。

以前のバージョンでは、インデックスはクラスのコンパイル時に生成されていました。生成されたインデックスに対する継承解決は適用されず、インデックス・メソッドの生成も行われませんでした。

IsValidDT の変更

• 既定では生成されないメソッド

  バージョン 5.1 では、%Library.DataTypeOpens in a new tab を拡張するユーザ記述データ型クラスに対して、IsValidDT() メソッドは自動的には生成されなくなりました。以前の動作に戻すには、以下の処理を実行できます。

  Set ^SYS("ObjectCompiler","GenerateIsValidDT") = 1
  

  Note:

  以前の動作に戻すネームスペースごとに実行した後で、影響を受けるルーチンをすべてリコンパイルしてください。

• 変更されたメソッドの返りタイプ

  以前のバージョンでは、クラス・インスタンス・メソッド、%IsValidDT() は %Integer のタイプの値を返しました。Caché 5.1 では、より正確に %Boolean を返します。

SQLCOMPUTECODE をサポートするメソッド

クラスにおいて、SQL 計算プロパティを定義することができます。それには、プロパティの宣言時に属性 SQLCOMPUTED を指定し、目的の値を計算する SQL コードを指定します。値は、一時的でも、計算されるものでも、保存可能でもかまいません。

計算プロパティに対しては、<property>Get() メソッドが生成されます。このメソッドは、必要に応じて <property>Compute() を起動します。SQLCOMPUTECODE を利用すると、計算時に他の値を参照することができます。この参照は SQL 列に対するもので (下位互換性のために維持されています)、メソッド生成時にプロパティ名に変換されます。

この SQL 列が、埋め込みクラスから投影された列を参照している場合は、<property>Compute() によって、埋め込みプロパティへの拡張参照が生成されます。

継承処理に対する変更

以前のバージョンでは、クラスの継承規則が意図したとおりではないこともありました。例えば、ユーザが、%Library.PersistentOpens in a new tab のサブクラスである User.MyClass というクラスを作成したとします。Caché によって、スーパークラス %Library の既定のパッケージ名が自動的に User.MyClass へ #import として継承されます。この結果、User.MyClass に、以下のように宣言されたプロパティが含まれているとします。

property A as String;

この場合 Caché は、User パッケージと %Library パッケージの両方を検索してこれを解決しようとします。User パッケージに User.String というクラスがある場合は、ユーザの意図する参照先が User.String であったとしても、クラス名の競合が Caché によって報告されます。これに対処するには、以下のようにプロパティ名を完全修飾します。

property A as User.String;

Caché 5.1 でも、明示的な #import 設定はスーパークラスから継承されますが、スーパークラスのパッケージ名が #import に自動的に追加されることはありません。したがって、上記例における A プロパティの解決の結果は 'User.String' となり、名前の競合エラーは発生しません。

Caché による名前解決においても、現在のクラス・パッケージ名が使用されます。User.MyClass の名前に対する #import には、'User' が使用されます。ただし、これはサブクラスに対しては適用されません。

具体的に説明すると、Caché による名前の解決は、現在のクラス名ではなく、その名前が最初に定義されたコンテキストにおいて行われます。例えば、User.MyClass によってメソッド X() が定義されるとします。クラス MyPackage.MyClass が User.MyClass から継承されている場合は、コンパイル時に、MyPackage.MyClass で継承された X() メソッドがコンパイルされますが、このメソッドで使用される未修飾のクラス名の解決は、User.MyClass のコンテキストにおいて行われます。これは、この中で X() が定義されているからです。

ストリーム実装の変更

バージョン 5.1 では、ストリーム・メンバが含まれるクラスをクローン化するときの動作が、以前のリリースとは異なっています。このバージョンでの動作は以下のとおりです。

• ストリーム・メンバがシリアル・ストリームである場合は、ストリームの OREF がクローンにコピーされます。

• ストリームが、以下の “古い” ストリーム実装のインスタンスであるとします。

  • %Library.FileBinaryStream

  • %Library.FileCharacterStream

  • %Library.GlobalBinaryStream

  • %Library.GlobalCharacterStream

  その場合、ストリームの OREF がクローンにコピーされます。

• 上記以外の場合は、ストリーム・コンテンツが同じ型の新しいストリームにコピーされ、この新しいストリームの OREF がクローンに格納されます。

アプリケーションで元のストリームの OREF を維持するには、以下の処理を実行できます。

Set ..ThatStream = oref.%ConstructClone(0)

CDL に代わる XML エクスポート

このバージョンでは、クラスのエクスポート形式として CDL は使用できなくなりました。代わりに、クラスをエクスポートするときは XML 形式を使用します。このリリースでも、インポート形式としては CDL も可能です。

永続スーパークラスは CACHELIB の外部に存在する必要がある

現時点では、永続クラスのサブクラスのエクステント情報が、スーパークラスのエクステント情報と共に保存されます。Caché バージョン 5.1 では CACHELIB が読み取り専用データベースとなっているので、既定では、CACHELIB に存在する永続クラスをサブクラス化することはできなくなりました。このことを試みると、<PROTECT> エラーが発生します。これは、永続クラスがローカルで作成され、CACHELIB に保存された場合でも同様です。

唯一の例外は、SERIAL として指定されているクラスです。このクラスのインスタンスは、インスタンスを参照するクラスに埋め込まれるので、エクステント情報はありません。

%Library.String の TRUNCATE の既定値の変更

文字列のパラメータの代表的なものに、MAXLEN および TRUNCATE の設定があります。MAXLEN の値では、その文字列で可能な最大文字列長を指定します。TRUNCATE の値では、最大長制限の適用方法を指定します。

• TRUNCATE が True に設定されている場合は、%Library.StringOpens in a new tab 型として宣言されている変数には先頭から MAXLEN 文字数分の文字列のみが格納され、文字列の残りの部分は無視されます。

• TRUNCATE が False に設定されている場合は、MAXLEN を超える数の文字を変数に割り当てようとすると、エラー・ステータスが返されます。

Caché バージョン 5.1 において、%Library.StringOpens in a new tab の新しいインスタンスでは TRUNCATE の既定値は False になります。以前のバージョンでは、True でした。これは、バージョン 5.1 で作成される新しい文字列のみに適用されます。文字列型の古い項目の既定値は、その項目が作成された時点のままです。

%Close() の従来動作のサポートの終了

Caché バージョン 5.0 では、クローズされたオブジェクトの扱い方が変更されました。%Close が実行されるとき、オブジェクトの参照カウントが 0 になっていると、オブジェクトは破棄されます。オブジェクトに関連付けられている OREF は、“アクティブでない” 状態になると、つまりオブジェクトへの参照がすべて消滅すると、削除されます。

この動作が導入されたときは、%Close に対して Caché の "従来のサポート" を代わりに使用することも可能でした。つまり、バージョン 5.0 より前のバージョンで使用されていた、以下に示す呼び出しを使用するという方法です。

 Do $ZU(68,56,1)

このモードでは、%Close() が実行されるときに、オブジェクトのオブジェクト・レベル参照カウントがデクリメントされ、カウントが 0 になるとメモリから削除されます。OREF の再利用を防止する仕組みはありませんでした。

Cache 5.1 では、従来のモードが削除されています。この関数を呼び出すと、<FUNCTION> エラーが返されます。

%DeleteExtent() の動作の改善

以前のバージョンでは、%DeleteExtent() メソッドによって、エクステント内のインスタンスがすべて削除されなくても、常に $$$OK が返されていました。バージョン 5.1 では、意図したとおりに動作するよう改善されており、エクステントのすべてのインスタンスが正常に削除された場合にのみ $$$OK が返されるようになりました。

メソッドのコンパイルと返り値

以前のバージョンでは、値を返すことが宣言されているメソッドをコンパイルすると、以下の文字列が挿入されることがありました。

Quit ""

これが行われるのは、メソッドの最後の行の先頭に Quit コマンドがない場合です。この方法には、プログラミングのバグが隠されていました。開発者が作成したメソッドが値を返すことになっているときに、実際には値が返されないからです。

バージョン 5.1 では、これは行われません。メソッド・コンパイラによって挿入されるのは、以下の文字列のみです。

Quit

これは、メソッドの最後の行に返り値がない場合です。したがって、値を返すよう宣言されているメソッド (関数) が値を返さない場合は、<COMMAND> エラーが発生します。

必須のリレーションシップ・コレクションを空にできない

アプリケーションによってリレーションシップ・コレクションの “子” 側または “多” 側が必須であると指定されている場合は、これに 1 つ以上の要素が含まれているかどうかの確認が Caché によって行われるようになりました。インスタンスの保存の時点でリレーションシップが空の場合は、Caché によって %Save のエラーが報告されます。以下に例を示します。

ERROR #5662: Relationship child/many property 'Sample.Company::Employees
(1@Sample.Company,ID=)' is required so must have at least one member

XML エクスポートに対する循環検査

Caché 5.1 の XML 対応クラスでは、エクスポートの前に、循環が存在するかどうかを調べるために階層の検査が行われます。既定ではこの検査が行われますが、検査を無効にするには、%XML.WriterOpens in a new tab の Format プロパティの末尾に “,nocyclecheck” を付加します。

タスクの変更

• タスク・マネージャ階層のアップグレード

  タスク・マネージャでは、Caché クラス階層がより徹底的に使用されるようになりました。すべてのユーザ・タスクは、%SYS.Task.DefinitionOpens in a new tab クラスをサブクラス化する必要があります。

  これにより、サブクラスで追加のプロパティを導入して、タスク実行時に使用できるようになります。 ユーザ・インタフェースは、定義を問い合わせて、プロパティ値の入力をユーザに要求します。以下はその例です。

  Class %SYS.Task.IntegrityCheck Extends %SYS.Task.Definition
  {
  Property Directory As %String [ InitialExpression = {$zu(12)} ];
  Property Filename As %String [ InitialExpression = "INTEGRIT.LOG" ];
  
  ClassMethod DirectoryIsValid(Directory As %String) As %Status
  {
    If '##class(%Library.File).DirectoryExists(Directory) 
    {
      Quit $$$ERROR($$$GeneralError,"Directory does not exist")
    }
    Quit $$$OK
  }
  
  /// This method is responsible for executing the task
  /// At the scheduled time, the Task Manager
  /// - creates an instance of this object,
  /// - sets any property values using the stored "settings" for the task,
  /// - and invokes this method to execute the task.
  /// In order to execute a real task, override this method in a subclass.
  Method OnTask() As %Status
  {
    Do Silent^Integrity(..Directory_..Filename)
    Quit $$$OK
  }
  
  }
  
  

• ContinueAfterError プロパティの削除

  クラス %SYS.TaskSuper の ContinueAfterError プロパティは、一般的すぎるため削除されました。このプロパティに依存するタスクは、それぞれのエラー状況を処理できるように、再設計する必要があります。

• タスクに関するその他の改善

  この他にも、Caché 5.1 ではタスク管理に関して以下の改善が行われています。

  • RunLegacyTask というクラスがあり、以前のバージョンとの互換性を維持するための ExecuteCode() メソッドがあります。

  • タスクの実行時にエラーが発生すると、実行が一時停止します。

  • RunOnce() メソッドおよび RunNow() メソッドによって、一時停止しているタスクをアクティブにできるようになりました。

  • Caché のこのインスタンスに対するライセンスが見つからない場合は、タスクが起動されません。

Caché ユーザと SQL ユーザの統一

以前のバージョンでは、有効な Caché ユーザ名のリストと、有効な SQL ユーザ名のリストの間には関連性がなく、それぞれ異なるセキュリティ・メカニズムによって管理されていました。バージョン 5.1 では、このことが変更されています。SQL ユーザ名はすべて Caché ユーザ名であり、その逆も同様です。個々のユーザに許可される内容は、同じセキュリティ・メカニズムによって決まります。

アトミック SQL 文

バージョン 5.1 では、SQL 文の DELETE、UPDATE、および INSERT...SELECT は、アトミックになりました。つまり、文の実行が正常に完了しなければ、テーブル内の行は変更されません。

以前のバージョンでは、操作が完了しなかったことを検出して必要に応じて更新をロールバックするのは、アプリケーション側の責任で行うことになっていました。 このバージョンでは、いずれかの行の更新に失敗した場合は、その文によってテーブル内の行は 1 行も更新されません。

SQL パスワードの大文字と小文字の区別

バージョン 5.1 では、セキュリティ上の理由から、SQL でも Caché と同じパスワード・メカニズムが使用されます。この結果、SQL パスワードでは大文字と小文字が区別されるようになりました。以前は区別されていませんでした。

テーブル所有権と $USERNAME との連動

これは、DDL を使用して作成されたテーブルの所有者の値は、作成時点での $USERNAME の値が使用されるということです。それ以外の手段を使用してクラスまたはテーブルを作成するときは、開発者によって明示的に定義されていなければ、クラスの OWNER キーワードは定義されません。テーブルを投影するクラスがコンパイルされるときに、クラスの OWNER キーワードが NULL の場合、テーブルの所有者は _SYSTEM に設定されます。

この解釈は、以前のバージョンと同様です。変更点は、バージョン 5.1 で DDL を使用してテーブルを作成するときは OWNER の既定値が _SYSTEM にはならないことです。

区切り識別子が既定値

Caché バージョン 5.1 では、インストール時に "区切り識別子をサポート" の値が True に設定されます。つまり、SQL 文内の二重引用符で囲まれた文字列 ("My String") は、区切り識別子と見なされます。以前のバージョンの Caché では、このパラメータが false に設定され、二重引用符で囲まれた文字列は文字列定数またはリテラル文字列として扱われていました。このパラメータの値は、システム管理ポータルの ホーム, 構成, 詳細設定 で変更できます。

%msql の削除

この変数は、ObjectScript において、埋め込み SQL から SQL アクセスするための有効なユーザ名を指定するのに使用されていました。有効なユーザ名とは、User Table に登録されている名前です。

Caché 5.1 では、ユーザが認証されたときに設定される $USERNAME 特殊変数から SQL ユーザ名が抽出されます。

クエリ・キャッシュの変更

• クエリ・キャッシュと読み取り専用データベースとの連動

  Caché 5.1 では、クエリ・キャッシュを必要とする SQL クエリは、読み書き可能としてマウントされたデータベースに ^mcq グローバルがマッピングされていなければ、読み取り専用データベースに対して動作しません。この例には、SQL DDL を使用して読み取り専用データベースにテーブルを作成しようとすることがあります。

• クエリ・キャッシュの変更はジャーナルに記録されない

  バージョン 5.1 では、クエリ・キャッシュに変更が加えられても、変更内容はジャーナルに記録されないようになりました。これによって、トランザクションの内部でクエリ・キャッシュに対して行われた変更もジャーナルに書き込まれないことになります。したがって、シャドウイングによってクエリ・キャッシュの変更が他システムに適用されることはありません。

• クエリ・キャッシュのパージの即時実行

  Caché 5.1 では、クエリ・キャッシュを N 日後にパージする (N は構成設定で定義された日数) という概念はサポートされないことになりました。 アプリケーションで Purge() を呼び出すと、クエリ・キャッシュがすべて削除されます。

• 読み取りデータベースにおけるクエリ・キャッシュ

  このバージョンの Caché では、データベースのテーブルに対して SELECT を実行するダイナミック SQL クエリ・キャッシュの作成および実行を、アプリケーションで行うことができます。

  Note:

  このようなクエリをアプリケーションで削除しようとすると <PROTECT> エラーが発生します。クエリ・キャッシュを削除するには、関連付けられているデータベースに対する書き込みアクセス権が必要です。

• クエリ・キャッシュのパージは他のシステムには反映されない

  パッケージが、1 つのシステム内の複数のネームスペースにマッピングされている場合に、クエリ・キャッシュを作成したパッケージ内のクラスのコンパイルまたは削除を行うと、個々のネームスペースに存在する、そのクラスを使用するすべてのクエリ・キャッシュが削除されます。ただし、ECP を介して別のマシン上にパッケージがマッピングされている場合は、クラスをリコンパイルまたは削除しても、クエリ・キャッシュの削除が行われるのは、クラスがコンパイルされたシステム上のみとなります。 このクラスからのクエリ・キャッシュがネットワーク接続された他のシステム上にある場合は、手動で削除する必要があります。

• ^mcq("init code") 実行順序の変更

  JDBC または ODBC を介して接続したときに実行される Caché コマンドが含まれるように、グローバル・ノード ^mcq("init code") を設定することができます。Caché 5.0.12 では、接続時の実行順序は以下のようになっていました。

  1. クライアントから接続情報を読み取る

  2. ^mcq("init code") のコードを実行する

  3. ログイン・コードを実行する

  Caché 5.0.13 では、実行順序が以下のように変更されました。

  1. ^mcq("init code") のコードを実行する

  2. ログイン・コードを実行する (クライアントからの接続情報の読み取りを含む)

  Caché 5.1 では、実行順序が以下のようになっています。

  1. ログイン・コードを実行する (クライアントからの接続情報の読み取りを含む)

  2. ^mcq("init code") のコードを実行する

SQL クエリ内の不明確な名前

• FROM 節

  以前のバージョンの Caché では、SQL クエリ内のフィールド名が不明確な場合は、そのフィールド名が、FROM 節で最初に出現するテーブルに関連付けられるものとされていました。これと同じ状況のとき、バージョン 5.1 ではエラーが報告されます。不明確な名前は、起源を示すように修飾する必要があります。

• ORDER BY 節

  Caché 5.1 では、ORDER BY 節に含まれるフィールド名が不明確な場合はエラーが報告されます。以下に例を示します。

  SELECT TOP 20
         %ID as ID,
         ((ID * 2) # 20) as ID
  FROM Sample.Company
  ORDER BY ID 
  
  

  これにより、以前は検出されなかったクエリ・プロセッサのバグが修正されます。以前のバージョンの Caché でこれを実行すると、不明確な名前 (この場合は ID) には、その列名の最後の出現箇所が関連付けられます。

特定オプションの設定に必要な特権

以下に示す SET OPTION の SQL 文を実行するには、%Admin_Security:Use の権限が必要です。

SET OPTION SUPPORT_DELIMITED_IDENTIFIERS = {TRUE | FALSE}

SET OPTION PKEY_IS_IDKEY = {TRUE | FALSE}

権限を持たずにこの文を実行しようとすると、SQLCODE の値 —99 が返されます。これは、特権違反のエラー値です。このような文は Caché の構成設定を変更するものであり、実行するユーザに変更の特権が付与されている必要があるからです。

SQL の GRANT および REVOKE における変更

SQL の GRANT コマンドおよび REVOKE コマンドでは、以下の一般的な管理者特権はサポートされなくなりました。

• %GRANT_ANY_PRIVILEGE

• %CREATE_USER

• %ALTER_USER

• %DROP_USER

• %CREATE_ROLE

• %GRANT_ANY_ROLE

• %DROP_ANY_ROLE

以前のバージョンでは、SQL アクセス権限が別に保持されていました。バージョン 5.1 では、これらの特権が Caché によって管理されます。SQL コードによってこれらの操作を実行しようとすると、この名前のロールを付与しようとしているものと解釈されます。

• CREATE ROLE の詳細

  SQL の CREATE ROLE 文を使用してロール定義を作成するには、ユーザが %Admin_Security:Use 特権を保持している必要があります。 ユーザがこの特権を持たない場合は、エラー -99 およびメッセージが返されます。

• DROP ROLE の詳細

  DROP ROLE を使用してロール定義を削除するには、以下の条件が 1 つ以上満たされている必要があります。

  • ユーザが %Admin_Security:Use 特権を保持している。

  • ユーザがそのロールの所有者である。

  • ユーザに、WITH ADMIN OPTION でそのロールが付与されている。

SQL %THRESHOLD の削除

SQL %THRESHOLD 機能は、このバージョンの Caché では使用されなくなりました。コードでしきい値を付与しようとするとします。以下はその例です。

GRANT %THRESHOLD ### TO SomeUser

この場合、コンパイル時にエラーが返されるようになりました。また、以下のようなコードを実行するとします。

REVOKE %THRESHOLD FROM SomeUser

この場合、しきい値の取り消しは行われません。解釈が変更されたため、Caché 5.1 では、ユーザに付与されていた %THRESHOLD という名前のロールが取り消されます。

SAMPLES における SQL 特権がユーザ _PUBLIC に付与される

インストール時に、SAMPLES ネームスペース内のすべてのテーブル、ビュー、およびプロシージャに対するすべての SQL 特権が、_PUBLIC という名前のユーザに付与されます。

システム・テーブルに対する SQL カタログ情報

%Library.SQLCatalogOpens in a new tab クラスの SQLTables() クエリを実行すると、現在のネームスペースで定義されているテーブルおよびビューの一覧が返されます。以前のバージョンでは、この一覧にシステム・テーブルが含まれていました。バージョン 5.1 では、システム・テーブル情報が一覧に含まれるのは、%SYS ネームスペースでこのクエリが実行された場合のみです。

照合済みフィールドから返される結果の順序が異なる場合がある

バージョン 5.1 において行われた Caché SQL の最適化により、照合済みフィールドに対するクエリから返される結果が異なることがあります。例えば、以下を考えてみます。

SELECT Dept, AVG(Salary)
FROM Personnel
GROUP BY Dept

Dept は、%SQLUPPER に従って照合されますが、行に入力される値の大文字と小文字の使い方は一定しておらず、大文字のもの、小文字のもの、単語の先頭のみが大文字のものなどがあります。ただし、GROUP BY 節が指定されているので、すべての部門 (Dept) の値が、大文字に変換された値に従って収集されます。

以前のバージョンの Caché では、このクエリの結果が返されるときに、返される Dept の値は選択された行での実際の値でした。Cache 5.1 では、返される Dept の値は常に照合後の形式 (この場合は %SQLUPPER) となります。

以下の 2 つのクエリを例に考えてみましょう。

SELECT IdNum, Dept
FROM Personnel

および

SELECT Dept, COUNT(IdNum)
FROM Personnel
GROUP BY Dept

上記クエリから返される結果が、期待した結果ではないこともあります。最初のクエリでは Dept 列に格納されている実際の値が返され、2 番目のクエリでは大文字に変換された値が返されます。これは、アプリケーションで予期した結果でないこともあります。

以前の動作に戻すには、以下のように、Dept を %exact で修飾します。

SELECT %exact Dept, COUNT(IdNum)
FROM Personnel
GROUP BY Dept

時刻精度の制御

SQL スカラ関数の GETDATE()、CURRENT_TIME()、および CURRENT_TIMESTAMP() で返される時刻値の精度を指定するための新しい SQL 構成設定が追加されています。時刻精度の既定値を設定するには、以下に示す新しい API 呼び出しを使用できます。

PreviousValue = $SYSTEM.SQL.SetDefaultTimePrecision(value)

value は精度 (時刻値のミリ秒部分を表す小数点以下の桁数) です。

既定値は 0 で、これらの関数から返される値にミリ秒部分は含まれません。 この関数から返される値は、直前の (または既定の) 時刻精度設定です。例えば、次を実行するとします。

Do $SYSTEM.SQL.SetDefaultTimePrecision(3)

GETDATE() から返される値の形式は 'YYYY-MM-DD HH:MM:SS.sss' となります。 アプリケーションで、この既定値をオーバーライドする値を指定するには、時刻精度値を GETDATE() に渡します。 例えば、GETDATE(5) を実行すると 'YYYY-MM-DD HH:MM:SS.sssss' が返されます。

DDL CREATE および DDL DROP での所有者の検査

ユーザが DDL を実行して既存のクラスにプロシージャ、クエリ、またはメソッドの作成または削除を行うとき、そのクラスに OWNER が定義されていて、実行するユーザがクラスの OWNER ではない場合は、このアクションが Caché によって許可されません。

ODBC および JDBC のアクセス許可の検査

ODBC および JDBC を介して起動されるストアド・プロシージャに対する EXECUTE 特権が Caché によって検査されるようになりました。 ODBC または JDBC を介してプロシージャを呼び出すには、そのプロシージャに対する EXECUTE 特権がユーザに付与されている必要があります。

システム管理ポータルで、または ODBC または JDBC のカタログ・クエリからプロシージャの一覧を検索するとき、そのユーザが呼び出しを行う特権を持つプロシージャのみが一覧に表示されます。

DDL を使用してプロシージャを作成するとき、作成者のユーザ名がそのプロシージャの既定の所有者として設定されます (これは、後でクラス定義を編集することで変更できます)。 プロシージャがコンパイルされるときに、プロシージャの所有者に %All ロールが付与されていない場合は、EXECUTE 特権が WITH GRANT OPTION 付きで付与されます。 プロシージャを投影するクラス定義の中で所有者が指定されていない場合は、クラスをコンパイルするユーザが所有者であると見なされます。

プロシージャが削除されるとき、またはプロシージャ定義が含まれるクラスが削除されるときに、そのプロシージャに対して付与されていた EXECUTE 特権は削除されます。

^mdd の情報は ^oddEXTR に移動

^mdd グローバルは削除されました。以前のバージョンでは、このグローバルに SQL 関連の情報が保持されていました。この情報は、^oddEXTR 構造体に取り込まれました。

以前のデータベースを Caché 5.1 でマウントできますが、そのデータベースを使用するには、以下に示すコマンドを使用してアップグレードする必要があります。

Do $SYSTEM.OBJ.UpgradeAll()
Do $SYSTEM.OBJ.CompileAll()

UpgradeAll および CompileAll を実行した後は、Cache 5.1 より前のバージョンでそのデータベースを使用することはできません。

NULL が関与する比較

このリリースの Caché では、値が NULL の定数とホスト変数が関与する一部の SQL 述語において、以前のバージョンで見られた不正な動作が修正されています。

定数とホスト変数に対する NULL テストの以前の不正な動作に依存しているアプリケーションは、修正する必要のある場合があります。これは、次の形式の述語に影響を及ぼします。

field <> parameter
field > parameter
field >= parameter

ここで、“パラメータ” の値を NULL 値に設定できます。(比較演算子 “<”、“<=”、および “=” が関与する述語は正しく動作しました。)これは、:hostVar が COS で "" に結合されている場合に、

field <> :hostVar

などのクエリが、既存の述語が異なる動作をすることを意味します。SQL の 3 状態論理によれば、この述語は NULL に評価されてエラーとなります。NULL が値として扱われ、NULL 以外のフィールド値がすべて正常に実行されることはありません。

必要であれば、NULL に対して特定のテストを追加することにより、特定のクエリの以前の動作をリストアできます。既存の

 field<>:hostVar

などのクエリが前と同じ結果を生成するには、

(field <> :hostVar OR (:hostVar IS NULL AND field IS NOT NULL))

と記述し直す必要があります。

新しいエラー・コード

このバージョンの Caché では、以下の新しいシステム・エラー・コードが追加されています。

削除されたエラー・コード

このリリースの Caché では、<DISCONNECT> システム・エラーがサポートされなくなりました。

グローバルの再編成

Caché バージョン 5.1 では、ユーザ・メッセージおよびシステム・メッセージを格納するグローバル (^CacheMsg および ^%qCacheMsg) の添え字の順序が変更されました。新しい順序は、ドメイン、言語、および ID です。これによって、メッセージ・グローバルの添え字マッピングをドメイン別にできます。

クラス・ディクショナリのバージョン番号が 20 にアップグレードされました。その結果、$SYSTEM.OBJ.Upgrade() の実行をユーザに要求するメッセージが表示されます。このメソッドを実行すると、既存の ^CacheMsg グローバルの添え字が振り直されます。すべてのエラー・マクロ、ルーチン、およびメソッドにおいて元の引数の順序が維持されます。したがって、アプリケーションでメッセージ・グローバルのアドレスを直接指定している場合を除いて、ユーザ・コードの変更は必要ありません。

新しいシステム変数

• $USERNAME

  バージョン 5.1 では、セキュリティ上の目的のため、$USERNAME に格納されている名前を使用して Caché 内部でユーザが識別されます。

  例えば、あるユーザがユーザ名 "Smith" を使用して Windows XP システムに正常にログインできるとします。このユーザが Caché のオンライン・ドキュメントにキューブを介してアクセスしようとした場合、セキュリティ上の目的のため、このユーザに割り当てられる名前は “UnknownUser” となります。オンライン・ドキュメントに対するアクセス権が UnknownUser に付与されていない場合は、Caché のセキュリティ構成に応じて、Caché が認識するユーザ ID とパスワードを入力して認証を受けることをユーザに要求するメッセージが表示される場合があります。

  Caché 5.1 では、ルーチン ^%USER もあります。これは、現在のプロセスを実行しているユーザの、オペレーティング・システムが認識する名前を出力するものです。

  Note:

  ^%USER と $USERNAME が同一である必要はありません。前者は、オペレーティング・システムへのログインによって設定されます。後者は、Caché セキュリティに対するユーザ認証が成功したときに設定されます。

  例えば、あるユーザが "Smith" として Windows XP にログオンするとします。 このユーザが Caché キューブの [ドキュメント] を選択した場合に、DocBook CSP アプリケーションが起動するときの $USERNAME は "UnknownUser" となります。

• $ROLES

  この変数には、実行中の任意の時点で現在のユーザが保持しているすべてのロールが、コンマ区切りのリストに格納されています。

ObjectScript コンパイラのアップグレード

バージョン 5.1 では、ObjectScript コンパイラが改善されています。その結果、生成されたコードを以前のリリース上で実行することはできなくなりました。このことを試みると、<RECOMPILE> エラーが返されます。

その逆については、異なります。Cache 5.0 システムでコンパイルされたコードは、変更せずにバージョン 5.1 で実行できます。

Caché のバージョンと ObjectScript コンパイラのバージョンの関係を以下のテーブルに示します。バージョン番号は、“メジャー” 番号と “マイナー” 番号から構成されており、ピリオドで区切られています。ObjectScript コンパイラのメジャー・バージョンとマイナー・バージョンはそれぞれ、ObjectScript の関数 $ZUTIL(40,0,68) と$ZUTIL(40,0,69) によって返されます。

あるバージョンの Caché でコンパイルされたルーチンを、リコンパイルせずに別のバージョンの Caché で実行できるのは、以下の両方に該当する場合です。

1. Caché リリースのコンパイラのメジャー・バージョンが同一である。

2. ルーチンが実行されるシステム上のコンパイラのバージョン番号が、ルーチンがコンパイルされたシステムのコンパイラのバージョン番号と等しいか大きい。

一部の ObjectScript コマンドにはアクセス許可が必要

コマンドによってはその効力が理由で、特定の状況下でユーザにアクセス許可が付与されていなければ正しく実行できないコマンドがいくつかあります。

$ZTRAP の変更

$ZTRAP の参考資料では、エラー・トラップの名前がアスタリスク (*) で始まる場合、エラーが発生したコンテキスト・レベルでエラー・ハンドラが起動されると説明しています。ただし、エラー・トラップがプロシージャのコンテキスト内にある場合は、Caché はエラー・コンテキストと、プロシージャのローカル変数に対する適切なコンテキストを同時に確立できません。Caché 5.1 では、このような使用方法をコンパイル時に検出し、エラーとして報告するようにコンパイラが変更されています。

アプリケーションでこの機能を利用するには、以下のいずれかを満たしている必要があります。

• エラー・リカバリ・コードが含まれるサブルーチンはプロシージャではない。

• エラーのコンテキストにおいて実行する必要がないように、エラー処理ロジックが変更されている。

$ZERROR に一部のエラーに関する追加情報が含まれる

エラーが発生したときは、そのエラーに関する情報がシステム変数 $ZERROR に格納されます。Caché 5.1 では、以前のバージョンと比べて、$ZERROR に格納される文字列により多くの情報が含まれています。

例えば、定義されていない変数をルーチンで使用しようとすると、$ZERROR には未定義変数の名前が格納されます。以前のバージョンの Caché では、$ZERROR には以下のような値が格納されている場合がありました。

<UNDEFINED>zMethodName^Pkg.Class.1

バージョン 5.1 では、以下のような値が格納されます。

<ERRCODE>Tag^Routine+line *someinfo

この変更の結果、エラー処理ルーチンにおいて、$ZERROR の文字列の形式に関する何らかの暗黙の想定を行っていた場合は、以前と同様に動作させるために再設計が必要となることがあります。例えば、以下に示すコマンドはバージョン 5.1 では動作しません。

Write "Error line: ", $PIECE($ZERROR, ">", 2)

以下のように変更する必要があります。

Write "Error line: ", $PIECE($PIECE($ZERROR, ">", 2), " ", 1)

以下に示すテーブルは、追加情報が格納されるエラーと、その情報の形式の一覧です。新しい情報は、前のテキストとはスペースで区切られています。

ルーチン (またはメソッド) に対してローカルである変数の名前と、クラス・プロパティおよびメソッドの名前には、そのことを示すアスタリスクが先頭に付けられます。グローバル変数の名前の先頭には、キャレットがあります。

例 ：

<UNDEFINED> *x
<UNDEFINED> *abc(2)
<UNDEFINED> ^xyz(2,"abc")
<PROPERTY DOES NOT EXIST> *SomeProp,Package.Classname
<METHOD DOES NOT EXIST> *AMethod,SamePackage.DifferentClass
<PROTECT> ^%GlobalVar,c:\cx\mgr\notyours\

$ZUTIL

• アクセス許可の変更

  特定の $ZUTIL 関数の実行に必要な権限が、バージョン 5.1 では以前のリリースと比べてより明確になりました。以下のテーブルに示す場合を除いて、公開されている $ZUTIL のオプションを利用するのに特別なアクセス許可は必要ありません。

  関数番号	必要な権限	説明
  5	%DB_<XXX>:R	対象 ： 別のネームスペースへの変更 バージョン 5.1 では、別のネームスペースに変更を行うには、ユーザに %DB_XXX:Read が付与されている必要があります (XXX はネームスペースに対応するグローバルが格納されているデータベースの名前)。
  58	N/A	対象 ： XECUTE コマンドの使用に必要な特権レベルの設定 この関数は、Caché 5.1 では削除されています。
  69	%Manager	対象 ： システム全体の既定値の設定 この関数を起動するには、CACHESYS データベース内の未編集ルーチンから起動する必要があります。間接指定の一部としても起動できませんし、CACHESYS データベースに対する書き込み権限のあるジョブ内でも起動することはできません。
  78	%Manager	対象 ： 開いているトランザクションのジャーナル・ファイルの検索 この関数を起動するには、CACHESYS データベース内の未編集ルーチンから起動する必要があります。間接指定の一部としても起動できませんし、CACHESYS データベースに対する書き込み権限のあるジョブ内でも起動することはできません。
  130	%Manager	対象 ： ドメイン ID またはインデックスを設定するか返す この関数を起動するには、CACHESYS データベース内の未編集ルーチンから起動する必要があります。間接指定の一部としても起動できませんし、CACHESYS データベースに対する書き込み権限のあるジョブ内でも起動することはできません。
  131	N/A	以前のリリースで、サブ関数 1 によって返されるシステム識別子文字列は、現在のシステム名の後にコロン (:)、IP アドレス (Windows) または MAC アドレス (UNIX®)、コンマ (,)、および mgr ディレクトリのパス名を連結したものでした。 バージョン 5.1 では、システムの名前の後にコロン (:)、および実行されている Caché インスタンスの名前を連結したものです。

• $ZUTIL(4) の変更

  この関数は、Caché 内のプロセスを停止するために使用します。バージョン 5.1 では、特権を持たないアプリケーションによる干渉からシステム・ジョブを保護するように改善されています。例えば、$ZUTIL(4, <pid>) を実行しても、デーモンは停止しません。代わりに、エラー・ステータス 0 が返されます。

  さらに、終了しようとして %HALT またはそのサブルーチン (%ROLLBACK など) を実行しているプロセスは、この関数には応答しません。RESJOB を発行するプロセスには、ターゲットがこれを無視したことを示すエラー・ステータス -4 が返されます。

  “ccontrol stop” を使用してシステムをシャットダウンするときは、以前と同様にこれらのプロセスが終了します。これと同じことは、バージョン 5.1 では関数 $ZUTIL(4, <pid>, -65) を使用して実行することもできます。

  Caution:

  $ZUTIL(4, <pid>, -65) をこの目的のために使用するときは、保護するロックが解除されても、開いているトランザクションはロールバックされません。

• $ZUTIL(49) の変更

  返される情報は、データベースの情報を詳しく示すように改善されています。

  • $ZU(49, <sfn>, 3) — バージョン 5.1 では、以前のバージョンで返されていた情報の後にいくつかのフィールドが追加されます。

    • <SysNumber> ： リモート・システムの番号 (データベースがローカルの場合は 0)

    • <DirPath> ： システム上のデータベース・パス

    • <ResourceName> ： データベースに関連付けられているリソース

    • <BlockSize> ： データベースのブロック・サイズ (KB)

    • <Collation> ： データベースの照合

    • <DirectoryBlock> ： DB ディレクトリ・ブロック番号。ECP クライアントの場合は、CacheTemp 内のデータベースのローカル・キャッシュ・ディレクトリ・ブロック番号です。ECP サーバからクライアントに、データベース・ディレクトリ・ブロック番号は送信されません。

    返される値がすべて、"^" で区切られます。

$ZF

$ZF による操作によっては、操作に対してアクセス許可の検査が行われます。以下に示すテーブルは、実行が制限されている操作に必要なアクセス許可の一覧です。

その他の $ZF 関数は、以前のバージョンの Caché と同様に特権が不要な操作です。

%CacheStorage の変更

• 新しいプロパティ・メソッド GetStored()

  既定のストレージ (%CacheStorage) を使用する永続クラスの保存可能プロパティすべてに対して、新しいプロパティ・メソッドが実装されました。このメソッドの名前は <propertyname>GetStored() です。このメソッドはオブジェクト ID の値 (OID ではありません) を受け取り、ディスク上に保存されているプロパティの論理値を返します。<property>StorageToLogical() を使用すると、保存されている値が論理値に変換されます。

  このメソッドは、サブノード構造に保存されているコレクションに対しては有効ではありません。指定された ID が示すオブジェクトが存在しない場合は、エラーが報告されます。このメソッドは、保存されないプロパティ (Transient プロパティ、多次元プロパティ、Calculated プロパティ) に対しては実装されません。これらの場合は、<METHOD DOES NOT EXIST> エラーが報告されます。

• 既定のストレージに対する ID カウンタ検査が可能

  システムによって割り当てられたオブジェクト ID カウンタを検査する新しい API 関数がこのバージョンで使用できるようになりました。システムによって割り当てられた ID 値を持つ既定のストレージを使用するクラスごとに、コンパイラによって ID 検査式が生成されます(既定のストレージおよびシステム割り当て ID を使用する子クラスには、この式はありません)。

  関数 $$CheckIDCounters^%apiOBJ(.errorlog) を実行すると、現在のネームスペースにあるすべてのエクステントが検査されます。ID 検査式が見つかった場合は、その式が起動されます。エクステントの最後の ID の値が、ID カウンタ位置よりも大きい場合は、ID 検査式ではエラーが発生します。この場合は、errorlog 配列にエントリが追加され、添え字としてエクステント名が使用されます。ID 検査式は errorlog 内にも出力され、ユーザはこれを利用して問題に対処できます。

  アプリケーションでこのユーティリティを起動する方法を以下に示します。

  Set sc = $$CheckIDCounters^%apiOBJ(.errarray) 
  

  ユーティリティから制御が返されたとき、sc には標準のステータス・メッセージが設定されます。エラーが見つかった場合は、多次元配列 errarray にエラーが格納されます。

• 既定のストレージに対して %ExistsId() が生成される

  Caché 5.1 では、この生成されたメソッドによって、渡された ID の値が検証されます。ID の構成要素のいずれかが NULL の場合は、%ExistsId() から 0 が返されます (オブジェクトが存在しない)。すべての構成要素が NULL 以外の場合は、オブジェクト参照が存在するかどうかが検査されます。

  Note:

  このメソッドは、%Library.PersistentOpens in a new tab の拡張であるクラスの中で呼び出すためのものです。そのインスタンスのクラスによって作成されたものではない ID 値を渡すことは、カプセル化が破壊されることになるため、お勧めできません。

%CacheSQLStorage の変更

• $PIECE アクセス・タイプには有効な行参照が必要

  %CacheSQLStorage を使用するアプリケーションで、アクセス・タイプ $Piece の複数の添え字タイプを使用しており、これらの添え字レベルに対するデータ・アクセス式を指定している場合は、マップ定義において有効な行参照を指定する必要があります。このバージョンの Caché では、この状況では自動生成は行われません。

• 新しい動的値置換

  以下の指定方法が Caché でサポートされるようになりました。

  • {%%CLASSNAME} ： 引用符なしのクラス名に展開されます。以下はその例です。

    Do ##class({%%CLASSNAME}).MyMethod() 
    

    

  • {%%CLASSNAMEQ} ： 引用符で囲まれたクラス名に展開されます。

    Set ThisClass = {%%CLASSNAMEQ}
    

    

  • {%%TABLENAME} ： 引用符で囲まれたテーブル名に展開されます。

    Set MyTable = {%%TABLENAME} 
    

    

  %CacheSQLStorage マップ定義内の以下に示す場所で、これらを使用できます。

  • マップの添え字

    • データ・アクセス式

    • 無効な条件

    • Next コード

    • アクセス変数式

    マップ・データ

    • 取得コード

パッケージ名に SQL 予約語は使用できない

Java に投影される Caché がクラスで、クラス名のパッケージ部分の構成要素のいずれかが SQL 予約語 (大文字と小文字の違いは無視) に一致している場合、クラスを投影しようとしたときに、Java クラスのメタデータに列名がないというエラーが報告されます。このエラーを回避するには、SQL 予約語と同じパッケージ名を使用しないようにします。

ターミナルは常に Unicode

ターミナルのバージョンは、内部的に Unicode 文字を使用して実行されるバージョンの 1 つだけになりました。既定では、ISO ネットワーク・エンコードの Local Encoding 2 および Network Encoding 2 を使用して起動されます。255 より上の文字を表示するには、エンコードを UTF8 に変更する必要があります。このように機能が強化された結果、“Pass 8–bit Characters” 設定は削除されました。

Caché のインスタンスが複数あり、あるものは Unicode でエンコードされているものと、8 ビットでエンコードされているものがある場合は、ターミナルのインスタンスごとにエンコードを明示的に設定することをお勧めします。このようにすれば、既定値は適用されなくなります。

引数の変更

ターミナルでは、コマンド引数の /size、/pos、および /ppos はサポートされなくなりました。内部的には Unicode で文字を処理するように機能が変更されており、ロケールが異なるサーバ間の変換も正しく処理されるようになっています。

パスワードのエコー

以前のリリースでは、ターミナルでパスワードの入力が要求されるときに、出力デバイスへの文字のエコーは行われていませんでした。バージョン 5.1 の時点では、Caché パスワード・ログインが有効化されているときに、パスワードの文字はすべてアスタリスク (*) としてエコー表示されます。ターミナルのプロンプトにおいてユーザ ID とパスワードを指定してログインを実行するアプリケーションで、ターミナルから送信される文字に対するパターン・マッチングを行う場合は、エコーの動作について認識しておく必要があります。

Windows キューブからの起動

このバージョンの Caché では、キューブでのリモート・ターミナル・セッションに Telnet と TRM のどちらを使用するかを決める方法が変更されています。[リモート・システム・アクセス] メニューに表示されるサーバの一覧は、以下の規則に従っています。

1. リモート・サーバは常に、有効と表示されます。

2. ローカル・サーバのうち、サーバの IP アドレスがローカル・ホストのものと異なり、サーバ名がローカル・インスタンス名と異なるものは、リモート・サーバと同様に扱われます。これは、サーバにローカル・インスタンスが関連付けられていないからです。

3. IP アドレスがローカル・ホストのアドレスに等しく、サーバ名がローカル・インスタンス名と同一となっているローカル・サーバは、構成がダウンしているか、そのインスタンスの telnet が無効化されている場合、グレーで表示されます。それ以外の場合は、サーバ名が有効になります。

4. [リモート・システム・アクセス] メニューを使用してターミナルを起動するときは常に、telnet 接続が使用可能です。

ターミナルがキューブのメイン・メニューから起動されるとき、以下のようになります。

• アクティブな優先接続サーバがそのインスタンスに関連付けられている場合は、プライベート・ターミナル接続が確立されます。 ターミナルのウィンドウのタイトル・バーには、TRM という文字列の後にプロセス ID および Caché インスタンスの名前が表示されます。インスタンスが実行中でない場合は、ターミナルの起動の前にインスタンスが起動されます。

• それ以外の場合は、telnet 接続が確立されます。 ターミナルのタイトル・バーには、ホスト名の後に "NTI - Cache Telnet" という文字列が表示されます。 キューブでは、キューブと一緒にインストールされていない Caché インスタンスが起動されることはありません。

ローカル・エンコードとネットワーク・エンコードの区別

ターミナルのローカルおよびネットワークの変換設定は、8 ビット・インストールと Unicode インストールのそれぞれについて別個に保存されるようになりました。これによって、同じホスト上に 8 ビット・インストールと Unicode インストールが存在する場合に、それぞれ異なる動作をユーザが選択できます。以前のバージョンでは、これらは同一でした。

Windows プラットフォームの場合、以下のようになります。

Microsoft Windows 上で、Caché が Visual Studio 7.1 でコンパイルされるようになりました。CALLIN インタフェースや CALLOUT インタフェースを使用して Caché と通信するユーザ・アプリケーションは、Visual Studio をこのバージョンにアップグレードする必要があります。

CSP 猶予期間の変更

Caché バージョン 5.1 でのライセンスに関する変更の一環として、CSP によるセッションの扱い方も変更されました。

1 つの CSP セッションで複数のページにアクセスし、そのセッションがセッション・タイムアウトまたはアプリケーション設定 %session.EndSession=1 によって終了した場合、CSP は追加の猶予期間を与える代わりに、ライセンスを即座に解放します。

セッションが 1 つのページに対してのみアクティブである場合は、セッションが終了したときに、CSP は5 分間の猶予期間の間、オープンしたままセッションを保持します。

CSP ページ時間計測統計の既定値はオフ

Caché 5.1 では、クラス・パラメータ PAGETIMING の既定値が 0 となるように変更されています。以前のバージョンでは、既定値は 1 でした。値が 0 の場合は、そのクラスから継承するすべてのクラスに対して、ページ時間計測統計の収集がオフになります。CSP ページに対して収集されるページ時間計測統計にアプリケーションが依存している場合は、PAGETIMING が 1 に設定されているスーパークラスから継承するように修正する必要があります。