Caché 4.1.14 変更概要このドキュメントは、Caché 4.1.14 に加えられた変更箇所の概要を記述しています。このメンテナンス・リリースにおける変更箇所の概要を説明します。
「はじめに」 の章の詳細情報は、Caché 4.1 リリースノート
を参照してください (Caché インストール・ディレクトリのファイル Docs/GCRN/GCRN.html)。4.1
以前のメンテナンス・キットの情報は、以前の変更概要のドキュメント を参照してください
(Caché インストール・ディレクトリのファイル Docs/GCRN/GCRN_41x.asp)。
Caché 4.1.14 の変更点
カテゴリ ： クラスタ プラットフォーム ： OpenVMS 説明 ： OpenVMS クラスタ構成では、2 KB ではなく 8 KB
でフォーマット済みのデータベースを使用することをお勧めします。クラスタ・ノードが失敗した場合のリカバリ機能は、8 KB のフォーマット済みデータベースの方がはるかに優れているためです。
カテゴリ ： ODBC プラットフォーム ： Linux 説明 ： Caché 4.1 は Caché
5.0 ベースのクライアントを通して、Linux ODBC サポートを提供します。このクライアントの使用方法に関する詳細は、付属の
ODBC 構成ドキュメント (odbcconf.txt) を参照してください。odbcconf.txt ファイルは、Caché
5.0 インストールの一部である ODBC の自動インストールについて説明しています。このドライバは、Caché
4.1 インストールの一部として自動的にインストール されません。
カテゴリ ： コントロール・パネル プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンでは、リモート・システムに対し (コントロール・パネルのローカル・データベース・フォルダから)
[整合性チェック・ログの表示] をクリックし、表示されるログファイルを選択しなかった場合、[ファイルの表示] ダイアログ・ボックスを閉じ、コントロール・パネルにランタイム・エラーを生成しました。これは、修正されました。
カテゴリ ： システム プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンでは、2KB データベースを使用する Caché
環境が、複数のマルチボリューム・データベースをマウントするよう構成されている場合、データベースの中にはマウントできないものもありました。
Caché は、対応するマルチボリューム・データベースの数を大幅に増やしました。 修正前、この問題はデータベース・セットアップ中に生じていました。
カテゴリ ： システム プラットフォーム ： すべてのプラットフォーム 説明 ： Caché デバイスから読み取った際、以下 2 つの条件でローカル変数が破壊される問題に対処しました。
カテゴリ ： システム プラットフォーム ： すべてのプラットフォーム 説明 ： 現在、CACHÉTEMP の拡張と最大サイズが、Caché
の再起動で保存されます。 また Caché の再起動後、CACHÉTEMP のサイズは、データベースの現在のサイズか
240MB のいずれか小さいサイズになります。 実際のサイズよりも小さく CACHÉTEMP の初期サイズを制限する目的は、Caché
の起動時間を最小限にするためです。
カテゴリ ： システム プラットフォーム ： OpenVMS 説明 ： Caché は、OpenVMS ハードウェア上の任意のアクセス違反に関し、原因ではないが関連する情報を記録します。
以前のバージョンでは、 SS$_PAGRDERR や SS$_PAGRDERRXM エラーに関する情報はログされなかったため、追加されました。
これらのエラーの追加ログは、Caché の性能を制限してきた OpenVMS のデバッグの問題に役立ちます。
カテゴリ ： ジャーナリング プラットフォーム ： すべてのプラットフォーム 説明 ： パージされたジャーナル・ファイルが、誤って JRNDUMP や
Caché コントロール・パネルに表示された問題に対処しました。
カテゴリ ： ジャーナリング プラットフォーム ： OpenVMS 説明 ： ジャーナル・スイッチが非同期のジャーナル入出力を完了するまで待機しないため、ジャーナルが論理的に破壊される問題に対処しました。
これはフィールドでは発生せず、潜在的な障害を表示しようとしてもできませんでした。 この障害は、ジャーナリングで他の変更に関連したコート・レビューの際に発見されました。
カテゴリ ： クラスタ プラットフォーム ： OpenVMS 説明 ： 2KB 形式のクラスタ・マウント・データベースでまれに発生する
false <FILEFULL> エラーを解決しています。 複数のクラスタ・ノードで高頻度にデータベース更新を再生、要求するのは困難です。
拡張により他のノードからの更新を待機し、<FILEFULL> を報告する前に何度も拡張を再試行します。
カテゴリ ： クラスタ プラットフォーム ： OpenVMS 説明 ： クラスタ・フェイルオーバー中、別のプロセスに拡張デーモンが必要になると実行します。
以前のバージョンでは、このような状況でクラスタは停止していました。
カテゴリ ： クラスタ プラットフォーム ： すべてのプラットフォーム 説明 ： Unicode をインストールしたクラスタ・ノード上で、ルーチンのパージに関連する問題に対処しました。
この問題が発生した場合、性能低下を引き起こしました。
カテゴリ ： ロック プラットフォーム ： すべてのプラットフォーム 説明 ： 複数のプロセスが高位レベル・ロックを解放するまでロックを停止すると、ロックの公正さが向上します。
これは、ロックを実行し、特定のロック参照で競合するアプリケーションにのみ影響します。 また、DCP 経由でロックする構成にのみ関連します。
カテゴリ ： ロック プラットフォーム ： すべてのプラットフォーム 説明 ： ロック・テーブルは、サーバがロックの許可を待機しているとき、ロック・エントリに
"P" フラグを表示します (ロックの Pending (停止) を示す)。 これにより、ロック・テーブルで許可されたロックが、まだサーバで許可されていない可能性があることを明確にします。
カテゴリ ： ロック プラットフォーム ： すべてのプラットフォーム 説明 ： アプリケーションが複数のエントリ・ロック・コマンドを使用する場合 (括弧内で複数のロック参照)、プロセス間のアプリケーションを致命的に占有する可能性を削減しました 。 例えば、5 つのジョブを実行する場合、以下のようになります。 Kill ^q For Quit:$Data(^q) Lock +(^a(1),^b(1),^c(1,$Job)) Quit:$Data(^q) Lock その後、以下の 1 プロセスを実行します。 For Lock +^a(1) Lock -^a(1) その後、ループに割り込むために Cotrol−C コードを生成し、5 つのプロセスがデッドロックになります。これは、修正されました。
カテゴリ ： ロック プラットフォーム ： すべてのプラットフォーム 説明 ： 全ロック・テーブルにロックを追加しようとする際のメモリ損失の問題に対処しました。
この状態が緩和されずに継続すると、システムは定期的に "ロック・テーブルが一杯" というイベントを取得します。これは、修正されました。
カテゴリ ： ロック、DCP プラットフォーム ： すべてのプラットフォーム 説明 ： DCP では、ジョブがサーバにアンロック・リクエストを送信する必要があった場合、リクエストがネットワーク・バッファにキューされた直後に、ローカル・ロック・テーブルでロック・エントリを削除しました。 しかし、アンロックの返答が到着するまで、ロック・エントリがロック・テーブルに存在するケースはまれでした。 この点で、DMNNET デーモンはサーバの返答を処理する際に、ロック・エントリを削除します。 問題は、DMNNET デーモンが動作のリソースを維持しないことです。 したがって、リストからロックを削除すると、テーブルで動作中の他のジョブを干渉することがありました。これは、修正されました。
カテゴリ ： ロック、DCP プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンでは、DCP でマルチエントリ・ロック・コマンドがロック・リストに同じノードを持ち、それらが同じリモート・システムの場合
(つまり、"Lock +(^a(1), ^b(1), ^a(1))")、ロック・コマンドは停止しました。これは、修正されました。
カテゴリ ： ネットワーキング、DCP プラットフォーム ： UNIX、OpenVMS 説明 ： 以前のバージョンでは、OpenVMS と UNIX システムのデフォルト・パケット・サイズは、性能を向上するよう 3600 に設定されました。 ネットワークの中には、断片化を実行しないあるいはパケットの再組み立てをしないものもあるため、これにより DCP クライアントがタイムアウトになり、<Server... is down...> メッセージを表示します。 断片化の問題は、オペレーティング・システムやルータ設定が原因となる場合があります。 この問題を修正するよう、すべてのプラットフォームのデフォルト maxudppktsiz
パラメータは現在 1468 になります。これは、Caché から送信される最大のパケット・サイズで、 パケットを断片化する必要性を除去します。
Caché 構成マネージャを使用すると、maxudppktsiz のサイズを最大の 3600 まで増やすことができます。適切に断片化する方法によりネットワークでの性能が若干向上します。
カテゴリ ： トランザクション処理 プラットフォーム ： Linux、OpenVMS 説明 ： 以前のバージョンでは、ジョブがオープン・トランザクションを持つ間に
Telnet セッションを切断すると、トランザクションはジョブを終了した後にロールバックされません。 これは、修正されました。
カテゴリ ： ユーティリティ プラットフォーム ： すべてのプラットフォーム 説明 ： シングル・データベースでは、一度に 1 つの GCOMPACT
プログラムのみ実行できます。
カテゴリ ： ユーティリティ プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンでは、旧 ISM データベース (バージョン 6.2
以前) を変換、コピーする場合、GBLOCKCOPY は Caché 標準照合にグローバルの照合を変更したいかどうかを尋ねることはなく、また照合を変更しませんでした。
グローバルの照合を変更しない場合、性能に若干の影響を与えていました。 現バージョンでは、GBLOCKCOPY は照合を変更するかどうかを尋ねます。
インターシステムズは、古い照合を Caché 標準照合に変換するようお薦めします。
カテゴリ ： オブジェクト、ActiveX プラットフォーム ： Windows 説明 ： 以前のバージョンでは、プロパティが 0.1 以下の %Float 値を持つ場合、オブジェクトを保存できずにエラーを生じていました。 ERROR #5802: データタイプの妥当性検証が失敗しましたこれは、修正されました。
カテゴリ ： Caché ObjectScript、コンパイラ プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンでは、For ループに対応する Quit コマンドは、特定の条件下で正常にコンパイルされませんでした。 その条件は以下の通りです。
Quit コマンドにより、For ループ後にくる次のコマンドに制御を移しますが、For ループはアクティブなままです。 したがって、外部ループの外側で実行する次の Quit 文は For ループに適応され、For ループ後のコマンドに制御を移します。以下はその例です。
Set i=0 While i<3 {
For j=1:1:3 {
If j=2 { Quit }
}
Write i Set i=i+1
}
Quit
このコレクションを役立てるには、アップグレードがインストールされた後に、既存のルーチンをリコンパイルする必要があります。
カテゴリ ： SQL プラットフォーム ： すべてのプラットフォーム 説明 ： 外部キーの参照が UPDATE あるいは DELETE で実行される可能性がある場合、<UNDEFINED>
エラーを生じる問題に対処しました このバグは、Caché バージョン 4.1.9 から 4.1.13 までにのみ存在します｡
カテゴリ ： SQL ゲートウェイ プラットフォーム ： すべてのプラットフォーム 説明 ： 以前のバージョンで、 SQL ゲートウェイは整数として特定の内部変数を維持します。現在、これらにはバイナリ値を使用します。
この変更は、テストが更新されていない特定箇所に対応します。 この問題が生じたアプリケーションは、接続に失敗したり、過度な接続を生成する可能性があります。
カテゴリ ： サンプル プラットフォーム ： すべてのプラットフォーム 説明 ： ctrldemo サンプル・プログラムは、現在特定の例外を防ぐエラー処理を提供します。
Copyright © 2001-2003, InterSystems Corporation. All Rights Reserved. |