インストール先の ¥Docs サブディレクトリには、以下のリリース・ノートが用意されています。

• このキットに関する最新情報 ： ¥relnotes¥readme.1st
• このキットのリリース・ノート ： ¥relnotes¥cache¥relnotes.htm (このドキュメント)
• 以前のキットのリリース・ノート ： ¥relnotes¥cache¥prenotes.htm

このドキュメントでは、Caché 2007.1.2 と Caché 2007.1.3 の違いを説明します。

トピックは以下のとおりです。

• 全般的なお知らせ
• インターシステムズのニュース、アラート、アドバイザリ
• オンライン・ドキュメント
• 変更レポートの説明
• このメンテナンス・キットの変更レポート

このメンテナンス・キットは Caché 2007.1.1 を基にしているので、5.0 以前の Caché リリースからアップグレードしている場合は、新しいライセンス・キーが必要になります。

インターシステムズは、当社のソフトウェアをお使いのユーザに対し、早急に必要となる重要な情報を随時発表しています。この中には、警告、不可避の問題点、重要な更新、修正、リリースの発表などがあります。

最新のリストは、インターシステムズの Web サイトから取得できます。

ユーザはこのリストを定期的にチェックし、お使いのアプリケーションの処理に関連する問題がある場合、その最新情報を確認してください。

インターシステムズは、ユーザの利便性を考慮し、当社 Web サイトで最新バージョンの製品のドキュメントにオンライン・アクセスできるようにしています。ホームページで [サポート&教育サービス] の [Cachéサポート] をクリックし、[Caché 日本語ドキュメント] をクリックします。次に、特定のバージョンと必要なドキュメントの種類を選択します。

このメンテナンス・キットがお使いのアプリケーションに与える影響を評価できるように、このドキュメントの以下のトピックでは、各修正点を詳細に説明しています。この説明のための書式が変更レポートです。

各変更レポートには、以下の情報を記載したテーブルが用意されています。

• 可能性 ： 該当するプラットフォームのユーザにこの問題が生じる可能性
• 危険性 ： この変更がアプリケーション環境に新たな問題を誘発する可能性
• パッチ ： この変更が以前にパッチとして配布され、プロダクションで問題なく動作しているかどうかに関する情報
• 拡張性 ： この変更が新機能や拡張機能を提供するかどうかに関する情報

IP に関連するロール/特権の変更が ECP サーバで認識されないことがあります。Caché が修正され、変更が行われると、特権キャッシュがフラッシュされるようになりました。

一部の非同期要求 (SET や KILL など) では、ECP アプリケーション・サーバはローカル・キャッシュに変更を反映してから、サーバに要求を送信します。特定の状況で、ECP サーバで障害が発生しても、アプリケーション・サーバ・キャッシュが変更されたままになることがまれにあります。

今回の変更によって ECP サーバが修正され、予期しないエラーが発生したときに、アプリケーション・サーバ上の関連するキャッシュ・ブロックがパージされるようになりました。

今回の変更によって、ユーザが Caché デバッガを実行するときの Caché のセキュリティ・ホールが修正されました。これまでは、特権ルーチン・アプリケーションの適切な位置に ZBREAK を挿入することによって、特権のないユーザが %All にエスカレートできました。

DISTINCT を使用しても重複が返されることがありましたが、このバグは修正されました。この問題は、以下の場合に発生することがありました。

• 行が DISTINCT を満たしているので、実際は DISTINCT が不要である。例 ： SELECT DISTINCT <primary key> FROM <table>
• クエリの WHERE 節にサブクエリが含まれている。

これらの両方が真の場合、クエリが重複を返すことがありました。

特定のクエリに対して誤った応答を生成するというバグがありましたが、修正されました。この問題は、以下の場合に発生していました。

• 1 つのテーブルに複数のインデックスが使用されている。
• そのうちの少なくとも 1 つのインデックスにインデックス付きのデータがある。
• ID より前のすべての添え字にそれらの等値条件がある。
• インデックス付きのデータにも条件がある。

例えば、給与のデータを含む年齢のインデックスと、姓のインデックスがあるとします。この場合、次のようなクエリで問題が発生します。

SELECT * 
FROM <table> 
WHERE age=21 AND salary > 100000 OR lastname='mellon'

給与に関する条件はテストされません。

'OR' を 'AND' に置き換えても、同じ問題が発生する場合があります。ただし、この場合は、問題が発生する可能性が低くなります。テーブルにおける選択性が適切でなければなりません。

通常のセキュリティがインストールされている Windows システムで CSP デバッガ・ブレークポイントを実行しようとすると、エラーが発生します。スタジオでは、エラー 6707 を示すポップアップが表示されます。

スタジオの出力ウィンドウには、次のように表示されます。
CSP: STOPPED セッション終了に失敗しました

この問題は、修正されています。

パターン・マッチング演算で、最新のグローバル処理からプロセスが保持している可能性があるグローバル・ブロックが解放されるようになりました。これにより、長時間に及ぶ可能性があるパターン・マッチング演算時に、他のプロセスが引き続きグローバルにアクセスできます。

プロセスの異常終了を避けるために、システムによってパターン・マッチング・アルゴリズムの再帰の深さが制限されます。その制限内でパターンを解決できなかった場合、<COMPLEX PATTERN> エラーが返されます。

これは、パターンが複雑すぎて、指定された入力文字列に適用できないために、システムがパターン・マッチングを実行できなかったことを意味します。交互パターンの数および不定カウントを減らしてパターンを簡略化するか、マッチングのために入力文字列をさらに小さいセグメントに分割する必要があります。

一部の 64 ビット・プラットフォームでは、<FRAMESTACK> エラーの後、通常のように %ETN エラー・トラップを実行することができませんでした。その結果、<FRAMESTACK> エラーが繰り返し発生し、CacheTemp データベースがいっぱいになることがありました。

現在は、<FRAMESTACK> エラーを処理するために %ETN が実行される前に、より多くのエントリが実行スタックから生成されるようになりました。

既存のローカル変数ノードへの MERGE に続けて、そのノードの KILL を実行すると、$DATA()=0 のままになるはずですが、今回の修正が行われる前は、$DATA()=10 が報告され、$ORDER() は存在しない添え字を返していました。

Caché によって呼び出されたルーチンが見つからない場合、予期しない状態でエラー・ハンドラが起動されることがまれにあります (暗黙のネームスペースからファイルを開いた場合など)。後で、コントロールが返されたとき、プロセスの状態は予期できません。

この問題は、修正されています。

ごくまれに、エラーの配信中に発生したエラーによってプロセスが中断されることがあります。この中断によって、クリーンアップが実行される場合があります (開いているオブジェクトに対する %Destruct の実行など)。クリーンアップがエラーの原因と同じルーチン内にある場合は、アクセス違反が発生することがあります。

この問題は、修正されています。

書き込みデーモンが受け渡しを完了するまでにかかる時間が 5 分を超えた場合のシステムの中断基準が拡張されました。書き込みデーモンがディスクにブロックを書き込んでいる間は、システムは中断されません。

この情報を示すメッセージがコンソール・ログに生成されます。一連のブロックをディスクに書き込むのにこのように長くかかることは、この状況が繰り返し発生する場合は特に、システムにとって正常ではないためです。今回の変更によって、処理が進行している間は、ユーザがロックアウトされなくなります。

ユーザがロックアウトされる時点で、システムは最終的に空きバッファを使い果たす可能性があります。

Unix および OpenVMS プラットフォームでまれに発生する問題が解決されました。これらのプラットフォームでは、複数の書き込みデーモンで I/O エラーが発生すると、システムが中断されます。これまでは、いずれかのデーモンが保留中の処理を完了すると、システムの中断が解除されていました。

正しい動作は、すべてのデーモンが保留中の処理を正常に完了するまでシステムを中断したままにするというものです。今回の変更によって動作が修正され、すべてのデーモンが正常に値を書き込むまで Caché が待機するようになりました。

クラス %SYS.ProcessQuery が更新されました。<pid> が $J の場合 (つまり、プロセスがそれ自体に関する情報を取得している場合)、関数はプロセス・プライベート・メモリ内の最新の値を返します。

%SYS.ProcessQuery は通常、別のプロセスから情報を抽出するときのシステムへの影響を軽減するために、共有メモリ内の情報を返します。パフォーマンスを向上させるために、各プロセスの特定のカウンタは共有メモリに定期的にしか "発行" されません。別のプロセスに対する %SYS.ProcessQuery で参照できるのは、多少古くなった値です。

Solaris で共有メモリ・セグメントを取得するために必要以上の呼び出しが行われるという状況がありましたが、今回の変更によって修正されました。このような余分な呼び出しによってメモリが消費されるほか、パフォーマンスの問題が発生することがありました。

書き込みデーモンの遅延が原因で、バックアップに予想以上の時間がかかることがありましたが、今回の変更によってこの状況は修正されました。

今回の変更によって、Windows 以外のプラットフォームでは、CPF ファイルの [Com] セクション内の 'Com' 値が削除されます。このフィールドは Windows プラットフォームのみで使用されます。

今回の変更では、^JOURNAL の一部として、ジャーナル・ファイルをパージするためのオプションのフロント・エンド・インタフェースが用意されています。これらのオプションの 1 つとして、トランザクション・ロールバックやクラッシュ・リカバリに必要なものを除くすべてのジャーナル・ファイルをパージするオプションがあります。

例 ：

%SYS>DO ^JOURNAL

1) Begin Journaling (^JRNSTART)
2) Stop Journaling (^JRNSTOP)
3) Switch Journal File (^JRNSWTCH)
4) Restore Globals From Journal (^JRNRESTO)
5) Display Journal File (^JRNDUMP)
6) Purge Journal Files (PURGE^JOURNAL)
7) Edit Journal Properties (^JRNOPTS)
8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
9) Display Journal status (Status^JOURNAL)

Option? 6

1) Purge any journal NOT required for transaction rollback or crash recovery
2) Purge journals based on existing criteria (2 days or 2 backups)

Option? 1

The following files have been purged (listed from latest to oldest):

   1. /scratch1/yang/cache/lx4.72u/mgr/journal/20070222.007

1) Begin Journaling (^JRNSTART)
2) Stop Journaling (^JRNSTOP)
3) Switch Journal File (^JRNSWTCH)
4) Restore Globals From Journal (^JRNRESTO)
5) Display Journal File (^JRNDUMP)
6) Purge Journal Files (PURGE^JOURNAL)
7) Edit Journal Properties (^JRNOPTS)
8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
9) Display Journal status (Status^JOURNAL)

Option?

今回の変更は、以下の 2 つの部分に関連します。

1. 次にリストアするファイルの検索に関するエラーをジャーナル・リカバリが取得すると、Caché の起動は中止されます。これまでは、ジャーナル・リカバリはエラーを生成せずに停止し、起動は続行されていました。
2. プライマリ・ジャーナル・ディレクトリに不正な同名のファイルがあっても、ジャーナル・リカバリは代替ジャーナル・ディレクトリで次の正しいファイルを検索することができます。不正なファイルは、ディスク・エラーによる不完全なジャーナルの切り替えの結果として生成されることがあります (通常、書き込みの途中でジャーナルの切り替えに失敗した場合、不完全なファイルは削除されますが、削除できない場合もあります (ディスクにアクセスできない場合など))。

ジャーナル・エラーが発生したときにフリーズするように Caché システムが構成されている場合、後でジャーナルの切り替えが正常に行われると、システムのフリーズが解除されることがありました。一般に、ジャーナル・エラーによってジャーナル・データが失われていなければ、これは望ましい動作です。この場合、システムを適切な状態に戻すには、ユーザによる操作が必要です。それまでは、ジャーナルの切り替えが試行されても、システムはフリーズ状態のままでなければなりません。

今回の変更によって、ジャーナルの切り替え時の致命的なエラーによってジャーナル・データが失われる可能性がある場合には、上記の動作が強制されるようになりました。このようなエラーが発生した場合は、cconsole.log に次のようなメッセージが表示されます。

An irreversible error occurred in writing <xxx> to journal file.
Any pending journal data is lost.
You should restart the system and back up databases immediately.

cachetemp の最大サイズが固定されている Caché システムでは、特定の状況でジャーナル・リストアに失敗したり、ジャーナル・リストアによって誤った結果が生成されることがあるなど、さまざまな問題がありましたが、今回の変更によって処理されました。起動時またはクラスタ・フェイルオーバー時のジャーナル・リストアは該当していません。

今回の変更では、cachetemp の最大サイズが固定されている場合、(無制限、つまり 0 の場合とは異なり) ジャーナル・リストアにおけるソートは無効になっています。

ジャーナル・エラー時にフリーズするようにシステムが設定されている場合、fsync エラーが発生した後、Caché がジャーナル・ファイルの切り替えを許可するという状況がありましたが、解決されました。

fsync エラーが発生した場合、ジャーナル・データが失われている可能性があります。そのため、ジャーナル・ファイルの切り替えによって、ジャーナル・ファイルが完全でないシステムが再開されることになります。システムがシャドウ・データのサーバであれば、シャドウ・コピーに一部の SET や KILL がなくなっている可能性があります。

この状況から回復するには、Caché を再起動するか、ジャーナリングを停止する必要があります。Caché を再起動すると、シャドウ・サーバおよびクライアントは、fsync の問題が発生しているサーバと同期され、それらのサポート・ジャーナル・レコードがジャーナル・ファイルにないデータベース・ブロックはディスクに書き込まれません。ジャーナリングを停止すると、引き続きシステムを実行することはできますが、ジャーナルにはギャップが存在します (例えば、後でシステムを再起動すると、一部の情報が失われます)。

ジャーナル・ファイルを手動で切り替えると、ジャーナルの最大サイズが変更されることがまれにありましたが、今回の変更によってこの状況は排除されました。

Ensemble ライセンスに使用されている、調整されたライセンス・ユーザの上限値がライセンス・アップグレード手順で認識されないという問題がありましたが、今回の変更によって修正されました。

%SYSTEM.License クラスのライセンス・クエリの実行で CacheSys データベースへの書き込みアクセス権が要求されるという問題がありましたが、修正されました。

シャドウの停止の結果、タイムアウト・エラーが発生することがありましたが、今回の変更によってこの状況は修正されました。Caché の停止コードは、保留中のすべての動作が確実に完了するように、シャドウの停止間隔 (既定値 ： 10 秒) と TCP の読み取りタイムアウト (10 秒) より多少長く待機するようになりました。

ユーザが管理者として実行していない限り、Windows Vista では "ccontrol force instance_name" が機能していませんでした。今回の変更では、Caché インスタンスを手動で強制的に実行する前に、このサービスを使用してインスタンスを強制終了することで、この問題が修正されました。

メモ ： Windows Vista で "ccontrol force" を実行する場合は、管理者としてログインして実行していることをお勧めします。そのためには、Windows の [スタート] メニューで [コマンド プロンプト] を右クリックし、[管理者として実行] を選択します。

エラー・トラップ・ルーチンが ^ERRORS グローバル・エントリを作成しているときに <FILEFULL> のようなエラーが発生すると、エラー情報を保持しているテンポラリ・グローバルをそのまま残しておくのではなく、削除するように Caché が変更されました。これにより、CACHETEMP データベースが不必要に大きくなるのを防ぐことができます。

今回の変更によって、存在しない構成ファイルを再度アクティブにしたときの問題が修正されました。そのシステムは、ユーザがログインできない状態になることがありました。

今回の変更によって、cpf の構文が正しくないときの問題が修正されました。この場合、Caché は、不足しているフィールドを起動時に再生成しようとします。しかし、概要フィールドもない場合は、オペレーティング・システムが Linux であっても、Caché はそれを "Windows NT" に置き換えます。その結果、その後の再起動に失敗します。

アプリケーションが Caché セッションの I/O にパイプを使用している場合、予期しない <ENDOFFILE> エラーが発生することがありましたが、今回の変更によってこの問題は修正されました。

今回の変更によって ^DATABASE ユーティリティの問題が修正されました。ユーザがディレクトリ・プロンプトで '-' を含むディレクトリ名を入力した場合、Caché ではディレクトリ・インデックスの範囲として扱われていました。これは、ディレクトリ名の一部として扱われる必要があります。

現在のディレクトリが MGR ディレクトリ (CACHESYS に対応するディレクトリ) でない場合に問題が発生していましたが、今回の変更によって修正されました。この状況で構成を再度アクティブにすると、ユーザがシステムにログインできなくなることがありました。

これまでのバージョンでは、アプリケーション・エラーが %ET または %ETN を使用してエラー・トラップにログインした場合、エラー・グローバルに書き込まれたエントリはジャーナルされていませんでした。これは、アプリケーションがトランザクション内にある場合、そのトランザクションが後でロールバックされたときに、エラー・ログ・エントリが同様にロールバックされないようにするためでした。

この動作が変更され、エラー・グローバルはジャーナルされるようになりましたが、アプリケーション・ユーザのトランザクションの一部でないとしてマークされるので、ユーザのトランザクションがロールバックされても、ロールバックされません。

メモ ： エラー・グローバルがジャーナルされるのは、そのエラー・グローバルが書き込まれているデータベースでジャーナリングが有効な場合のみです。

^DATABASE または管理ポータルを使用してデータベースを削除すると、CPF ファイルの Dataset セクションが正しくなくなることがありましたが、今回の変更によってこの状況は修正されました。この場合、構成ファイルから他のデータベースが失われることがありました。