Caché 2008.2

スタジオ

スタジオに [変数を追跡する] オプションが追加されました。これは、制約付きの変数トラッキングを有効にし、値なしで使用されている変数を特定するためのオプションです。これを READ-UNDEFINED といいます。

スタジオ・アシスト

以下は、プログラム開発をサポートするためスタジオ・アシストに追加された新機能です。

• マクロのインジケータ・シーケンス “$$$” を入力すると、頻繁に使用するシステム・マクロの名前がリスト表示されるようになりました。ユーザ定義のマクロもこのリストに追加されます。これまでは、システムで定義されているマクロがすべて表示されていました。

• スタジオ・アシストがクラス・パラメータへの参照の開始 (..#) を認識したとき、そのクラスで現在定義されているパラメータの中から必要なパラメータを選択できるようになりました。

• 該当する場合は、使用可能なローカル変数のリストも表示されます。ルーチンまたはメソッドの範囲内で一度だけ使用された変数は、入力ミスの可能性があるので色分けして示されます。

長いストリームでのテキスト検索

従来のバージョンの Caché では、ストリームとして表されるテキストを検索する機能が用意されていました。ただし、32KB を超えるストリームを検索する場合は、長い文字列のサポートを有効にする必要がありました。このバージョンの Caché では、%CONTAINS と %SIMILARITY を使用する場合を除き、この制限が大幅に解消されています。

テキスト検索でのクエリの最適化

SQL オプティマイザの機能が向上し、テキスト・クエリを伴う検索を効率的に実行できるようになりました。テキスト文字列が個々の単語からなることを考慮し、さらにそれ自体をコレクションとしてインデックス付けすることができます。

保護されたログインに必要な新しいリソース

インストール時に、新しいリソース %Service_Login が作成されるようになりました。このリソースは、$SYSTEM.Security.Login() 関数で使用されます。$SYSTEM.Security.Login 関数は、この関数を呼び出すアプリケーションがこのリソースに対して USE アクセス権を持つユーザとして実行される場合のみ成功するようになりました。

このように変更される前は、アプリケーションは $SYSTEM.Security.Login() を呼び出し、有効なユーザ ID とパスワードが示されると、そのユーザ ID としてログインできました。このリリースでは、さらにリソースを USE できるようにする必要があります。

コマンド行からのロール追加の禁止

コマンド行やデバッガ内から関数 $SYSTEM.Security.AddRoles() を呼び出すことができなくなりました。コマンド行やデバッガからこの関数を呼び出すと、その呼び出しから制御が戻されたとき、プロセスが上位ロールのまま残ってしまう可能性があります。このようにメソッドを呼び出すと、ロールが昇格せず、

ERROR #940: Insufficient privilege for operation 

関数の値として次のエラーが返されます。さらに、

• $SYSTEM.Security.AddRoles() を呼び出すルーチンがあり、かつ

• プログラマ・モードのときにこのルーチンで未処理の ObjectScript エラーに直面し、かつ

• デバッグ・プロンプトでルーチンが中断した場合、

プログラマはデバッグ・プロンプトから $SYSTEM.Security.AddRoles() を呼び出せなくなり、アプリケーションのスコープ外にロールが上がります。

データベース・プロパティを変更するための特権の変更

データベースのプロパティを編集するには、特権 %Admin_Secure:USE が必要になりました。この特権がないユーザがこの処理を実行しようとすると、次のエラーが発生します。

ERROR #921: Operation requires %Admin_Secure:USE privilege 

UNIX® ： インストールの改善

“cinstall” パッケージで、従来の "標準" と "カスタム" に代わり、3 つの設定タイプを使用できるようになりました。

• 開発 ： (既定) サーバおよびすべてのクライアント・コンポーネントをインストールします。

• サーバ ： Caché サーバのコンポーネントのみをインストールします。クライアント・コンポーネントはインストールしません。また、通常は /dev 領域にあるコンポーネントもインストールしません。

• カスタム ： サーバ・コンポーネントをインストールします。また、ダイアログにすべてのクライアント・コンポーネントが表示され、そこから個別に選択できます。

また、前のインストールで作成した parameters.isc ファイルを使用すると、ユーザにプロンプトが表示されずインストールをパラメータ化できます。

UNIX® ： Caché の複数コピーの起動に対する保護

従来のバージョンで、Caché データベースの .lck ファイルを使用してフェイルオーバーを制御する場合、すべての環境において同じデータベースに対して複数の Caché のインスタンスを起動できなくするのに不十分であるということが判明しました。Caché では、制御プロセス、ライト・デーモン、およびジャーナル・デーモンの追加ロックを取り除き、より高度に分離されるようになりました。

この変更の一環として、cache.ids ファイルから情報が削除され、システム内部ファイルに保存されることになりました。cache.ids は、マーカに使用するためだけに存在します。

Macintosh ： CShell の実効 ID の異常

csh でコマンド実行用の実グループ ID および実効グループ ID の確立に使用される setregid 呼び出しは、実効グループ ID を無視します (セキュリティの問題と推定されます)。ある Caché を実行しているアカウント以外のアカウントから Caché を管理する場合、管理者は、sh、ksh、bash などの別のシェルを使用する必要があります。

この問題は、Macintosh 対応のすべてのプラットフォームで発生します。

Windows ： ライセンス承認ダイアログ

Windows インストーラにおいて、インストール・プロセスの最初のステップで InterSystems ライセンス条件を明示的に承認しなければならなくなりました。これは、アップグレードと新規インスタンスのインストールの両方に適用されます。ライセンス承認ダイアログの [次へ] ボタンは、ユーザが [ライセンス条件を承認する] を選択するまで有効になりません。他にできる操作は、インストールをキャンセルすることだけです。

Windows 64 ビット版 ： スタジオのアクティベート・ウィザードの使用不可

アクティベート・ウィザードは、現時点では 32 ビット Windows プラットフォームでのみサポートされています。64 ビット・システムでは、スタジオの [ツール] メニューを使用できません。

ObjectScript コンパイラのバージョン

ObjectScript コンパイラでは、コードの生成の向上が図られました。この変更は重要であるので、内部的にはこれを記してコンパイラのマイナー・バージョンが上がりました。このバージョンの Caché でコンパイルされたルーチンまたはメソッドのコードは、従来のバージョンでは実行できません。

クラス・コンポーネントのシグニチャ

このバージョンの Caché では、バージョン 2007.1 および 2008.1 でのクラス・コンパイラの不具合を修正しています。これらのリリースでエラーがなくコンパイルされた既存のクラスでも、一部のオーバーライドされた継承コンポーネントではシグニチャのエラーがあると認識されるようになる場合があります。

プロパティ参照

このバージョンの Caché では、従来のバージョンに存在していたクラス・コンパイラの不具合を修正しています。プロパティの参照にはインスタンスのコンテキストが必要であり、それに OREF を付与せずにプロパティを取得することはできません。

この変更は、アプリケーションがクラス・メソッドとして propertyGet() メソッドを呼び出した場合にも影響します。例えば、##class(name).property を使用して propertyGet() を呼び出すアプリケーションは、正しいクラス・メソッドを呼び出すように変更する必要があります。正しく呼び出さないとエラーが発生することになります。 これらのメソッド呼び出しは、計算プロパティでなくクラス・メソッドとして記述し直す必要があります。

呼び出し間の $TEST 値の保存

$TEST の値は任意のプロシージャへの呼び出し間で保存されると、マニュアルには記載されています。しかし従来のバージョンでは、呼び出し側と同じルーチン内に定義されているプロシージャを呼び出す場合にのみ、その値が保存されていました。このバージョンの Caché では、呼び出されるプロシージャが定義されている場所にかかわらず、$TEST の値が保存されるように変更されました。

保存場所のグローバル名ジェネレータの変更

クラスのインスタンスの保存場所を保持するために使用されるグローバル名は、クラスの完全修飾名 (パッケージ名とクラス名) から導出しています。その結果、名前の長さがグローバル名の最大長を超えると、クラス・コンパイラは、パッケージ名、クラス名、またはその両方の一部を切り捨て、定められた制限内に収まるようにグローバル名を生成します。

名前の一部が切り捨てられると、一意の名前を生成できるように切り捨てられた部分は暗号化されます。従来のバージョンでは、この暗号化により 3 文字の文字列を生成していました。このバージョン以降の Caché では、4 文字の文字列を生成するようになります。

$SYSTEM.Task の廃止

Caché バージョン 5.2 で、タスク・マネージャ・クラスを %SYSTEM.TaskOpens in a new tab から %SYS.TaskOpens in a new tab に移行しました。クラスの説明も変更され、%SYSTEM.TaskOpens in a new tab クラスを使用しないよう示しました。アプリケーションで %SYS.TaskOpens in a new tab を使用するように推奨しました。

Unicode-16 および JIS2004 のサポートの追加

Caché では、Unicode バージョン 3.0 のサポートを導入します。この最初の実装では、基本多言語面 (BMP)、つまり U+0000 ～ U+FFFF の範囲の文字のみがサポートされていました。バージョン 2007.1 で、1 バイトおよび 2 バイト値の GB18030 のサポートが導入されました。

このバージョンでは、Unicode のサロゲート・ペアOpens in a new tabとなるコード・ポイントをサポートするよう拡張します。それらは 16 ビット文字のペアで、1 つのユニットとして処理され、BMP 外の Unicode 文字を表します。サロゲート・ペアは、高位コードと下位コードで構成されます。高位ワードは U+D800 ～ U+DBFF の範囲で、下位ワードは U+DC00 ～ U+DFFF の範囲です。UTF-16 文字として解釈すると、これらのペアは U+10000 ～ U+10FFFF にマップされ、100 万コード・ポイントに対応します。サロゲート・ペアを含む Unicode 文字列は、UTF-16 でエンコードされると言われています。

$Extract、$Find などの既存の ObjectScript 文字列関数は、サロゲート・ペアを考慮していないため、サロゲート・ペアを含む文字列を処理する場合、矛盾した結果が返されることがあります。このバージョンの Caché では、サロゲート・ペアを正確に処理する特別版の正規文字列関数を導入しています。関数は以下のとおりです。

• $WAscii

• $WChar

• $WExtract

• $WFind

• $WIswide

• $WLength

• $WReverse

単一の 16 ビット値で表される文字とサロゲート・ペアで表される文字があるので、これらの新しい関数は、文字間の境界を判断するために文字列をスキャンする必要があります。例えば、4 ワード列 0x41、0xD800、0xDC00、0x42 は、サロゲート・ペアを考慮すると中央の 2 文字は単一の文字 U+10000 に対応するので、3 文字の文字列になります。

一部の Unicode ロケールの新しい照合の既定

一部の Unicode ロケールには、新しい照合に置き換わる既定の照合があります。その照合により、任意の Unicode 文字をサブスクリプトにエンコードできます。その従来の既定の照合は、8 ビット・ベースの文字セットで 256 文字に制限されていました。

新しい照合は従来のバージョンでも使用できましたが、既定ではありませんでした。従来の照合は今後も使用できます。

簡体字中国語の既定の変更

簡体字中国語ロケール (chsw) は、従来は変換の既定として GB が使用されていましたが、GB18030 が使用されるようになりました (磁気テープ、プリンタ、ターミナル、シーケンシャル・ファイル、$ZCONVERT)。GB テーブルは、使用可能なテーブルから削除されました。

^NLSMGR、^%Wsnls、^%Wsnls2、LOCGEN

各国言語サポートを実装し直した結果、これらのルーチンは削除されました。

%ERN および %SS の許可

%Development:USE 許可を持つユーザは、%ERN および %SS を実行できるようになりました。従来は、%Admin_Operate:USE 許可を持つユーザしか実行できませんでした。 %SS を実行するには、依然として CACHESYS への Write アクセス許可が必要です。

$DOUBLE への明示的変換の必須化

大きな 10 進数から IEEE 倍精度数への自動変換に依存するプログラムは、その変換を実行するために明示的に $DOUBLE() を呼び出すことが求められるようになりました。

数値リテラルが 9223372036854775807E127 を超える (または -9223372036854775808E127 に満たない) 場合、<MAXNUMBER> エラーが生成されます。数値計算にこの範囲を超えた数値が含まれる場合も、このエラーが生成されます。 これは、バージョン 5.2 以前の Caché の動作に戻すものです。

バージョン 5.2 で、IEEE 倍精度数が導入されました。 このリリースでは、IEEE 倍精度数は $DOUBLE 関数およびその数値の範囲を超える 10 進数の演算で生成されていました。 バージョン 2008.2 以降は、最初に IEEE 倍精度数を作成する場合、$DOUBLE 関数のみが使用できます。 数値リテラルおよび数値計算で範囲を超えると、<MAXNUMBER> エラーが生成されます。 10 進関数を含む一部の未定義の計算 (例: $ZLOG(0)) は、IEEE 無限大や NaN 値でなく、＜ILLEGAL VALUE> エラーを返すようになりました。

10 進数と IEEE 倍精度数が混じったオペランドを含む演算は、従来どおり IEEE 倍精度の結果になります。 IEEE 倍精度数を 10 進数に変換する場合、新しく定義された $DECIMAL 関数を使用できます。

この変更の背景にある論法は、次のとおりです。10 進数の浮動小数点と 2 進数の浮動小数点を混合すると、その導入時から問題が発生していました。 Caché の 10 進数の型には約 19 桁の精度がありますが、IEEE 2 進数の浮動小数点型の精度は 16 桁未満です。 IEEE 2 進数の倍精度浮動小数点型の範囲は約 1.7976931348623158E308 で、Cache の 10 進数型の 9223372036854775807E127 (9.223372036854775807E145) より非常に大きくなります。 そのため、いずれの方向の変換でも、範囲または精度のいずれかが失われることになります。 また、ほとんどの 10 進数の小数は、正確に 2 進数の浮動小数点で表すことができません。 そのため、小数の 10 進数を IEEE 2 進数の浮動小数点数に変換する際、ほとんどの場合、値が多少変更されます。

この 10 進数の浮動小数点値と 2 進数の浮動小数点値の不一致の影響を低減するために、インターシステムズではこれらの値間で自動的に変換を行わないよう決定しました。 これらの数値間で直接変換を行うには、$DOUBLE や $DECIMAL 関数の直接呼び出しが必要になります。

新規の $ISVALIDDOUBLE 関数の追加

このバージョンの Caché では、新しい関数呼び出し $ISVALIDDOUBLE(num) および $ISVALIDDOUBLE(num,scale,min,max) が追加されました。 これらの関数は、$DOUBLE 型の妥当性を常に検証することを除けば、$ISVALIDNUM と同じです。

min および max の値は、常に IEEE 64 ビット浮動小数点型に変換されます。 num 引数が有効な形式であれば、それは IEEE 64 ビットの 2 進数浮動小数点型に変換されます。 min/max の範囲は 2 進数の浮動小数点比較を使用して検証されます。 min が指定されない場合、$DOUBLE("-INF") が使用されます。 max が指定されない場合、$DOUBLE("INF") が使用されます。 値 $DOUBLE("NAN") は、min/max の値にかかわらず、常に有効と見なされます。

新規の $DECIMAL 関数の追加

このバージョンの Caché には $DECIMAL(X, N) が実装されています。これは、IEEE 倍精度数値 X を有効桁 N の 10 進数文字列に変換します。丸めは IEEE 浮動小数点の標準に従って実行されます。現時点では、40 を超える N の値はサポートされていません。

N の値が 0 の場合、その結果は有効桁が 20 で特別な丸めが行われた文字列になります。$DECIMAL(X, 0) の結果も、IEEE の倍精度数値 X から文字列への既定の変換になります。

$decimal(X,0) が評価されるときに、次の丸めが実行されます。

• 結果の有効桁が 20 以下で表される場合、丸めは不要です。

• 結果の有効桁が 20 を超える場合、20 桁目が 0 または 5 であれば、それぞれ 1 または 6 に切り上げられます。20 桁目がその他の数値であれば、そのままです。20 桁を超える部分の数字は切り捨てられるか、必要に応じて 0 で置き換えられて、文字列が数値キャノニック形式に入ります。

$ISVALIDNUM の変更

関数 $ISVALIDNUM() の動作が変更されました。このバージョンの Caché では、$ISVALIDNUM は文字列が正しい構文の場合のみ 1 を返します。そうでない場合はすべて 0 を返します。

$DOUBLE の変更

$DOUBLE() 関数に、引数として “INF” および “NAN” を指定できるようになりました。その結果、それぞれ IEEE 値の無限大と非数値になります。

標準の Caché の動作と同調して、“INF” および “NAN” の後に無関係な文字が続いても、それらで開始される文字列に対して正しい値を生成します。そのため、$DOUBLE(“INFRACTION”) では正の無限大が生成され、$DOUBLE(“NANTUCKET”) は NaN が生成されます。また、$DOUBLE(“-+-inf”) のように任意数の数値符号を文字列値の前に置くことができます。文字列の大文字/小文字は無関係です。

無限大と NaN

変換時のオーバーフローの制御

このバージョンの Caché では、数値変換エラーの発生時にプログラムの動作を制御できるようになりました。これは、関数 $ZUTIL(68,70,x) で実行します。

• “x” の値が 1 の場合、$DOUBLE または $ZDCHAR が IEEE 64 ビット 2 進数の浮動小数点型の無限大値となる絶対値の大きい数値文字列に直面すると、<MAXNUMBER> エラーが報告されます。

• “x” の値が 0 の場合、エラーは報告されません。Caché では、値を適切な無限大の値 (“INF” または “-INF”) に置き換えます。

例えば、次を実行するとします。

Write $ZUTIL(68,70,0) 
Write $DOUBLE("1e309")

これは、<MAXNUMBER> エラーとならずに、値として "INF" が書き込まれます。

数値リテラルの変換

コンパイル中に数値リテラルを解析する場合、または実行時に文字列を数値に変換する場合、値が Caché の 10 進数の浮動小数点数型の範囲を超えると、数値は $DOUBLE (IEEE 64 ビットの 2 進数の浮動小数点型) に変換されます。これにより数値の範囲が拡張しますが、数値精度が 10 進数で約 3 桁分低下します。

このような動作が好ましくない場合、関数 $ZUTIL(68,45) を使用すると、数値文字列から 10 進数への変換で 10 進数の浮動小数点の範囲を超えたときに、最大正数/最小負数の 10 進数の浮動小数点値を返すことができます。また関数 $ZUTIL(68,70) は、$DOUBLE (IEEE 64 ビットの 2 進数の浮動小数点) の範囲を超えたときのエラー報告の制御に使用できます。

0 乗の指数計算

以前のバージョンでは、ゼロはゼロの 0 乗と定義されていました。これは、数値表現に関係なく正しいものでした。そのため、X**Y という式の場合、0 であるか、$DECIMAL(0) であるか、$DOUBLE(0) であるかにかかわらず、X と Y が両方とも 0 であれば必ず 0 と評価されていました。

この解釈は、IEEE が推奨する浮動小数点の標準と対立します。標準では、任意の IEEE 値 (NaN および無限大を含む) の 0 乗を 1 と定義しています。したがって、このバージョンの Caché では、標準に適合するように、$DOUBLE(0) の 0 乗の定義を変更しました。

$FACTOR の改善

従来のバージョンの Caché では、負数で $FACTOR を呼び出すと、INF および NAN は一貫した結果が得られませんでした。これは、次の変更により修正されました。

• $FACTOR は近似結果を計算せず、有効ビット数を 64 に制限しなくなりました。 $FACTOR は引数の整数部分のすべてのビットを計算し、適切なビット文字列を返すようになりました。

• $FACTOR を負の引数に適用すると、その引数の絶対値に対応するビット文字列が返されます。 $FACTOR を $DOUBLE("NAN") または $DOUBLE("INF") に適用すると、空のビット文字列が返されます。

$LISTSAME の変更

関数 $LISTSAME の演算が若干変更されました。各リストの引数からアイテムを比較する場合、次のように処理します。

• $DOUBLE(+0)、$DOUBLE(-0)、および 0 の値を持つ要素は、同一と見なされます。

• $DOUBLE("NAN") の値を持つ要素は、$DOUBLE("NAN") を含むその他の任意のリスト要素と同一と見なされます。

引数なしの THROW の非推奨

このバージョンの Caché では、引数なしで THROW を使用することを非推奨としました。その代わり、例外を引数として明示的に THROW に渡すことを強くお勧めします。この論理を理解するために、次のコードについて考えてみます。

    TRY {
        Some statements
    }
    CATCH {
        Error correction statements
        …
        THROW
    }

“Some statements” を実行することによりエラーが発生すると、CATCH ブロックのコードが実行されます。“Error correction statements” 自体でエラーが発生しないと、THROW は “Some statements” が実行されて括弧内のエラー・ハンドラに渡されるときに発生するエラーを発生させます。

ただし、“Error correction statements” を実行してエラーが発生すると、“Some statements” からのエラーはオーバーライドされ、括弧内のエラー・ハンドラはこの後のエラー情報を受け取ります。TRY ブロックで発生したエラーは報告されません。

上記のコードを次のように書き換えることをお勧めします。

    TRY {
        Some statements
    }
    CATCH ErrorData{
        Error correction statements
        …
        THROW ErrorData
    }

これで、THROW に達したとき、エラー情報が括弧内のエラーハンドラに渡されるようになります。“Error correction statements” の実行によりエラーが発生した場合、これは括弧内のエラーハンドラに報告されますが、TRY ブロックからの例外データはデバッグにも使用できます。

書き換えられた例では、エラーが検出されると、ErrorData が %Exception.SystemExceptionOpens in a new tab のインスタンスになります。このクラスは、Caché で使用するために予約されています。独自の例外データを提供するアプリケーションは、%Exception.AbstractExceptionOpens in a new tab のサブクラスを定義して、そのサブクラスのインスタンスを THROW の引数として使用する必要があります。

サポートされるマクロ

このバージョンの Caché では、正式にサポートされた ObjectScript マクロの初期セットが定義されています。プログラム入力中にシーケンス “$$$” が認識されると、これらのマクロは StudioAssist で表示される唯一のものになります。マクロの完全なセットとその定義は、$SYSTEM.OBJ.ShowMacros メソッドを使用して表示できます。

コンパイル・コードに対する変更

このバージョンの Caché では、従来は各ソース行の開始を記すために生成されていたトークンを削除しています。システムは、従来より効率的に実行された CacheObjectScript (または CacheBasic、CacheMVBasic、CacheMV PQ/PQN PROC) 文の番号を追跡するようになりました。

これにより、ルーチン内での処理量が正確にわかります。従来のバージョンでは、空白行、コメント文、および実行可能な文を含む行は、すべてこれらのトークンでマークされていました。この変更により、プログラマは個々の行に読みやすくモダンなスタイルで、文や大量のコメントを書き込むことによる影響について心配する必要がなくなりました。

JOB コマンドに必要な起動ディレクトリ

JOB command に渡される “process-params” の中に os-directory があります。これは、子ジョブが起動の一環として切り替える必要があるディレクトリです。これは子ジョブのネームスペースに関連付けられた既定のディレクトリでオーバーライドできるので、必ずしもジョブで使用するディレクトリである必要はありません。

従来のバージョンでは、os-directory への切り替え時に子ジョブで発生したエラーの処理方法が、プラットフォーム間で一貫していませんでした。Windows および OpenVMS では、エラーは無視されていました。UNIX® では、プラットフォームにより動作が異なっていました。

子が指定された o/s-directory への切り替えに失敗した場合、すべてのプラットフォームで <DIRECTORY> エラーを元の Job コマンドに返すように変更されました。

クラス・コンパイラの修正 — シグニチャ

Caché 2007.1 および 2008.1 では、クラス・コンパイラの継承のメカニズムに不具合がありました。これは、メソッド以外のすべての継承されたコンポーネントに影響していました (メソッドは正しく処理されていました)。特にコンパイラは、サブクラスでオーバーライドする可能性のある値を含む継承されたコンポーネントの属性を正しくリコンパイルできませんでした。

この不具合はこのバージョンで修正され、サブクラスが継承されたコンポーネントの属性を不正にオーバーライドするという事象は、コンポーネントのシグニチャ・エラーとして報告されるようになりました。

クラス・コンパイラの修正 — プロパティ

従来のバージョンの Caché では、インスタンスのコンテキストを指定せずにクラスのプロパティ “Get” を試行することが可能でした。しかし、Caché では Java クラス定数と同様のクラスにプロパティを関連付けることは許可されず、プロパティはクラス・インスタンスにのみ関連付けられました。従来のバージョンのこのケースで生成されたコードは、返される結果に関して予測不可能でした。

このバージョンのクラス・コンパイラは、試行された処理の結果が未定義というエラーを報告します。

クラス・コンパイラ — ジャーナリング

ジャーナルの切り替えをグローバルでの個別の設定からデータベース・プロパティに切り替えた場合、クラス・コンパイルがジャーナルされるという影響がありました。ただし、クラス・コンパイルが失敗すると、適用されたデータベースはリコンパイルされるまで一貫性のない状態になります。つまり、クラス・コンパイル自体をジャーナルする必要はありません。

このバージョンでは、クラス・コンパイルのジャーナリングは既定ではオフになります。これは修飾子 '/journal=1' を使用して有効にできます。

クラス・コンパイラ — クエリ・コンパイル

従来のバージョンの Caché では、クラスで定義されたすべてのクエリは、カタログ・クエリ上で SQLPROC としてマークされているだけのものでも、ストアド・プロシージャとして呼び出すことができました。このバージョンでは、SQLPROC として明示的に定義されていないクエリは、ストアド・プロシージャとして呼び出すことができなくなりました。従来の動作を利用しているアプリケーションは、更新する必要があります。

クラス・コンパイラ — クエリ中間コードの保持

このバージョン以降、Caché では生成されるテーブル・ルーチンの MAC コードが生成されなくなり、.INT ルーチンが生成されるようになります。これらは、"k" フラグまたは /keepsource 修飾子が指定されている場合にのみ保持されます。この動作は、生成されたクラス・ルーチンの動作と一致します。

オブジェクト・インタフェースを使用する NLS の変更

このリリースでは、Caché オブジェクト・テクノロジを使用して ^%nls ルーチンが書き換えられました。従来のリリースで直接 ^%nls を使用していたアプリケーションは、%SYS.NLS または %CollateOpens in a new tab クラスにあるメソッドのいずれかを使用するよう変更する必要があります。

$SYSTEM.SQL.TuneTable に新しい引数を追加

新しい (6 番目の) オプション引数がメソッド $SYSTEM.SQL.TuneTable に追加されました。この引数では、指定したテーブルの SELECTIVITY 値と EXTENTSIZE 値をクリアするかどうかを示すブーリアン値を渡します。

この引数が true であり、かつ 2 番目の引数 (テーブルの値を更新するかどうかを示す) も true である場合、SELECTIVITY および EXTENTSIZE がリセットされます。

$SYSTEM.OBJ.ShowMacros() メソッドの追加

このバージョンの Caché で、ShowMacros() メソッドが　$SYSTEM.OBJ クラスに追加されました。このメソッドを呼び出すと、サポートされる Objectscript マクロのドキュメントおよび定義が表示されます。

$SYSTEM.OBJ.GetClassList() メソッドの追加

このバージョンの Caché で、GetClassList() メソッドが　$SYSTEM.OBJ クラスに追加されました。このメソッドを呼び出すと、クラス名が添え字となるローカル配列として現在のネームスペースのすべてのクラスが返されます。クラス選択は以下の修飾子で制御できます。それぞれ、値 0 または 1 が割り当てられます。

• /application=<N> - アプリケーション・クラスを含む (<N> = 1)

• /system=<N> - システム・クラス (クラス属性 'system' が 0 以外の値に設定されたクラス) を含む (<N> = 1)

• percent=<N> - パーセント・クラスを含む (<N> = 1)

• /mapped=<N> - 他のデータベースからマップされたクラスを含む (<N> = 1)。または、メソッドに渡される既定のデータベースのクラス (<N> = 0)

修飾子に関する詳細情報を表示するには、メソッド $SYSTEM.OBJ.ShowQualifiers() を呼び出します。

オブジェクトを移動するための %SYNC.Transporter クラスの追加

このバージョンの Caché では、新しく %SYNC.TransporterOpens in a new tab が追加されました。これは、あるネームスペースから別のネームスペースに永続オブジェクトをコピーするためのものです。このクラスには、オブジェクトを送信および受信するための機能が用意されています。送信側では、次の処理が行われます。

• Transporter クラスのインスタンス T が作成されます。

• T の Import が呼び出され、コピーするオブジェクトを取得します。インポート操作により、自動的にオブジェクトが新しく作成されるか、必要に応じて既存のオブジェクトが更新されます。

• この交換ですべてのオブジェクトが登録されている場合、ExportFile メソッドが呼び出され、システム・ファイルに登録されたオブジェクトが保存されます。

受信側では、次の処理が行われます。

• Transporter クラスのインスタンス T が作成されます。

• 送信されるオブジェクトの OID が T に登録されます。

%Studio.SourceControl.File クラスの追加

このバージョンの Caché では、クラスやルーチンなどをファイル・システムのファイルにインポート/エクスポートする、新しいクラス %Studio.SourceControl.FileOpens in a new tab が追加されました。ユーザにファイルの書き込み許可があると、アイテムは編集可能と判断されます。

これは、基本的なソース・コントロール・クラスであり、あるソース・コントロール・クラスと対話できるように容易に拡張できます。これは、顧客のソース・コントロール・クラスのベース・クラスとして、またはコードの例として使用されることを意図しています。

%Library.File の既定ディレクトリ

%Library.FileOpens in a new tab クラスでは、次のメソッドでディレクトリ引数に値を指定しない場合は、$ZUTIL(168) (現在の既定のディレクトリ) の値が使用されます。

• GetDirectory()

• GetDirectoryLength()

• GetDirectoryPiece()

• GetDirectorySpace()

%Stream.FileBinary および %Stream.FileCharacter クラスの追加

このバージョンの Caché では、%Stream.GlobalBinaryOpens in a new tab および %Stream.GlobalCharacterOpens in a new tab に相当する 2 つの新しいクラスが導入されました。これらは、新しいストリーム形式を使用し、グローバルではなくファイルにデータを保存します。

データを保存するディレクトリは、次のようにプロパティ・レベルで指定できます。

property FileStream As %Stream.FileBinary(LOCATION="c:\temp");

従来の %Library.FileBinaryStreamOpens in a new tab および %Library.FileCharacterStreamOpens in a new tab クラスに変更はなく、従来どおりに動作します。ただし、新しいクラスを記述する場合、新しいファイル・ストリーム・クラスを使用することをお勧めします。

クラス %Library.EnumString の追加

このバージョンの Caché では、新しいシステム・データ型クラス %Library.EnumStringOpens in a new tab が実装されました。 このクラスは、文字列値がクラスの VALUELIST パラメータで指定された値に制限されることを除き、%Library.StringOpens in a new tab と同じです。

• LogicalToOdbc メソッドは、VALUELIST パラメータで文字列の値を検索し、DISPLAYLIST の対応する値を表示します。

• OdbcToLogical メソッドは、その反対を行います。DISPLAYLIST で値を検索して、VALUELIST の対応する値を返します。

また、LogicalToOdbc 変換では VALUELIST->DISPLAY のリスト変換が行われ、OdbcToLogical 変換では DISPLAYLIST->VALUELIST のリスト変換が行われます。

クラス %SYS.Date.SlidingWindow の追加

このクラスは、%DATE ユーティリティの頻繁に使用するエントリ・ポイントを定義します。%SYS.Date.SlidingWindowOpens in a new tab クラスは、検査のエントリ・ポイントをサポートし、システム全体またはプロセス特有のスライディング・ウィンドウの定義を設定および変更します。GetSystem() と GetProcess() を除く各クラス・メソッドは、成功または失敗を示すステータスを返します。

%SYS.Date.SlidingWindowOpens in a new tab クラスは、%DATE ユーティリティのエントリ・ポイントのほとんどを実装します。この変更により、すべての Caché スクリプト言語でこのメカニズムを使用できます。%DATE の関数は、%SYS.Date.SlidingWindowOpens in a new tab では若干異なる名前で実装されるのでわかりやすくなっています。

%Library.RelationshipObject のナビゲート

コレクション・オブジェクトに同化させるための %Library.RelationshipObjectOpens in a new tab クラスにメソッドがいくつか追加されています。これらのメソッドは、カーディナリティが MANY または CHILDREN のリレーションシップに呼び出すことができます。以下のメソッドが実装されました。

• GetObjectIdAt()

• GetObjectIdNext()

• GetObjectIdPrevious()

%SYS.Task に追加されたインベントリ・スキャン・タスク

新しくオンデマンド・タスクがタスク・マネージャに追加されました。“インベントリ・スキャン” タスク (%SYS.Task.InventoryScan) は Inventory.Scanner.RunScan() メソッドを実行し、結果のインベントリ・スキャンを保存します。

インベントリ・スキャンはインスタンス・インストール・ディレクトリから開始し、すべてのディレクトリ、ファイル、データベース、データベース内のルーチンを再帰的に検証して、それらの名前、サイズ、最終更新日付、およびハッシュ識別子を記録します。このデータは、%SYS データベースに保存されます。

インベントリ・スキャン・タスクは、インストールまたはアップグレードが終了したら自動的に実行されるように設定されています。また、後でシステムに変更があった場合、ユーザが手動で起動することもできます。

PROCEDUREBLOCK を意味する TSQL

このバージョン以降、言語が TSQL に設定されたメソッドを定義すると、自動的に PROCEDUREBLOCK = 1 と見なされ、そのクラスまたはメソッドの明示的な設定をすべてオーバーライドします。

CDL 修飾子の削除

CDL でデータをエクスポートする機能を参照するオブジェクト・フラグおよび修飾子 (それぞれ “4” および “version4compatible”) は削除されました。

既定のクエリ・インタフェースから FetchODBC メソッドを削除

以前のバージョンでは、クエリ・データを xDBC クライアントに送信するインタフェースを提供するために、FetchODBC メソッドが用意されていました。このバージョンの Caché では SendODBC メソッドが追加されました。これにより、クエリ・データがより効率的に xDBC クライアントに送信され、FetchODBC メソッドが必要なくなりました。そのため、Fetch クエリ・メソッドを呼び出してデータを再フォーマットするだけの FetchODBC コードは生成されなくなりました。FetchODBC メソッドが記述されている場合、SendODBC メソッドは従来どおりそのユーザ・コードを使用します。

LogicalToStorage および StorageToLogical メソッドの認識の拡大

LogicalToStorage および StorageToLogical メソッドは論理値と保存値との間の変換を行います。以前のバージョンでは、プロパティ型クラス (またはプロパティ・クラス) から継承されたメソッドのみが認識されていました。この制限は、SQL がプロパティ・メソッドを認識する方法によるものでした。

このバージョンでは、継承されたメソッドもローカルでオーバーライドされたメソッドも認識されます。プロパティに LogicalToStorage および StorageToLogical メソッドを実装して、SQL および Object の操作により適宜呼び出すことができるようになりました。

%IO.FileStream の変更

メソッド Clear() の機能が、メソッド TruncateAt() および ExternalByteTruncateAt() によって拡張されました。さらに、メソッド OutputToDevice() および CopyFrom() は、低速なストリームからコピーする際に正確にグローバル・タイムアウトを処理できるように改善されました。

再起動間のストリーム・コンテンツの保存

従来の Caché では、アプリケーションでファイル・ストリームを作成する際に LOCATION が指定されていないと、システム全体の一時ストリーム場所に作成されていました。その後でアプリケーションがファイル・ストリームを保存すると、Caché はそれをデータベースに永続的とマークしていましたが、ストリームをそのディレクトリから移動していませんでした。

そのようなファイル・ストリームが削除されるように、Caché の再起動時にシステム全体の一時ストリームの保存場所は自動的にクリーンアップされていました。

この問題に対処するために、Caché では次のように処理するようになりました。

1. 各ネームスペースに対して、既定のストリーム・ディレクトリ構成パラメータを使用できるようになりました。これが指定されない場合、それは CACHE.DAT ファイルの場所のストリーム・サブディレクトリと見なされます。

2. ストリーム・ファイル・プロパティが最初に初期化されるときに、LOCATION プロパティ・パラメータがないと、ディレクトリはこのネームスペースの既定のストリーム・ディレクトリに設定されます。

3. アプリケーションでストリームに書き込む場合、そのディレクトリが設定されていないと、システム全体の一時ディレクトリに一時ファイルが作成されます。このストリームを保存すると、ファイルは一時ディレクトリからそのネームスペースの既定のストリーム・ディレクトリに移動されます。

これにより、いずれのファイルも消失することなく、既存のストリームの動作の変更を最小限に抑えられます。現在のストリームの動作は以下のとおりです。

1. 既存のファイル・ストリームを開いたり既存のファイルにリンクしてストリームに書き込むアプリケーションは、既存ファイルと同じディレクトリに新しく一時ファイルを作成します。これが保存されると、既存のファイルが削除されて一時ファイルはリンクされたファイルと同じ名前になるように一時ファイル名が変更されます。

2. 存在しないファイル名にリンクし、ストリームに書き込むアプリケーションは、指定されたファイル名で新しいファイルを作成します。このストリームを保存すると、これは永続的とマークされます。

3. 永続オブジェクトのプロパティとしてファイル・ストリームを定義するクラスでは、新しいインスタンスを作成してストリームに書き込むと、既定のストリーム・ディレクトリに新しいファイルが作成されます。このオブジェクトを保存すると、ストリームは永続的とマークされます。

4. プロパティ外で新しいファイル・ストリームを作成し、%New コマンドでディレクトリを指定しないアプリケーションは、ストリームを書き込むときにシステム全体の一時ディレクトリに新しく一時ファイルを作成します。ストリームが保存されるときに、これはネームスペース固有の既定のストリーム・ディレクトリに移動されます。

インポート時の時刻の処理の変更

このリリースの Caché では、XML および %apiRTN でインポートされるファイルに指定される最終更新時刻の処理方法が変更され、一貫性が改善されました。現在のルールは次のとおりです。

• クラスの場合、Caché では TimeChanged クラス属性を使用してクラス定義の XML エクスポート時にエクスポートできます。これは、/diffexport 修飾子で抑制できます。

• インポート時に、ファイルに最終更新時刻がない場合、Caché では次のアルゴリズムを使用します。

  • クラスが既に存在し、前のコピーと同じ場合、前のコピーの timechanged 値が使用されます。

  • クラスが既に存在し、timechanged がファイルの更新時刻と同じ場合、現在の時刻が使用されます。これは、クラスが前のクラスと異なるためにこのノードを確実に変更する必要があるためです。

  • それ以外の場合、timechanged はファイルの更新時刻に設定されます。

• ルーチンまたはクラスをインポートするときに、ファイル内の最終更新時刻のファイルの最終更新時刻が異なると、ファイルはなんらかの外部ツールで変更されたと見なされますが、ファイル内のタイムスタンプは更新されず、ファイルの最終更新時刻が使用されます。これにより、Caché のアイテムのタイムスタンプは保証され、このアイテムが変更されたことを検出できます。

%Monitor.Alert.External() メソッドの追加

The %Monitor.Alert.External() メソッドが追加され、ユーザ・アプリケーションで SNMP または WMI を介してアラートを送信できるようになりました。このメソッドは、アラートを記述するパラメータを受け取り、汎用の Cache SNMP トラップ (cacheAppAlert) または WMI Cache_Event を使用して、情報を送信します。 詳細は、%Monitor.AlertOpens in a new tab クラス・ドキュメントを参照してください。

ファイル・アーカイブ・クラス

このバージョンの Caché では、外部のドキュメント保存サービスに接続を許可するクラスが追加されました。このクラスにより、コンテンツの定義 (%Archive.ContentOpens in a new tab)、およびデータ転送の初期化の管理 (%Archive.SessionOpens in a new tab) を行えます。この最初のリリースで、アーカイブ・インタフェースが EMC Centera™ サーバで使用できるか検証されていました。

ResultSet メタデータに追加された行 ID フラグ

クエリで返される列メタデータと結果セットで、ビット 12 を使用して列が RowId の一部であることが示されます。

%BuildIndices および %PurgeIndices での名前の検証

メソッド %BuildIndices および %PurgeIndices は、インデックス名として $LIST を受け取り、その処理に使用します。このバージョン以降、そのリストは検証されるようになりました。これに現在のクラスで構築できるインデックス名以外の名前が含まれると、メソッドはエラー・ステータスを返します。

システム・クラスから削除された FreezeOnError

データベースの FreezeOnError プロパティは必ずオンに設定されるようになりました。そのため、このプロパティを定義、操作、または表示するシステム・クラスから FreezeOnError の参照が削除されました。具体的には以下の処理が行われました。

• SYS.DatabaseOpens in a new tab ： FreezeOnError プロパティが削除されました。また、これは Detail クエリで返されなくなりました。

• SYS.MetricsOpens in a new tab ： FreezeOnError プロパティがデータベース・メトリック表示から削除されました。

また、これは管理ポータルからも削除されました。

XMLNew メソッドの引数の変更

最初の引数は、型 “tree” (グローバルの DOM のインデックス) から型 “document” (%XML.DocumentOpens in a new tab インスタンス) に変更されました。

2 番目の引数は、わかりやすくするために node から nodeId に名前を変更しました。

XMLNew にオプションの 3 番目の引数ができました。これは、既にインスタンス化されて含まれているオブジェクトの oref です。これにより、XMLNew をオーバーライドするときに、オブジェクト・コンテキストを確認できます。containerOref 引数は、参照されるオブジェクトを含まれているオブジェクトとしてインポートする際に、XMLImport によって渡されます。関連付けられたオブジェクトの %XML.ReaderOpens in a new tab により渡される場合、インスタンス化された含まれているオブジェクトがないため、containerOref 引数は “” になります。

詳細は、%XML.AdaptorOpens in a new tab クラス・ドキュメントを参照してください。

ポルトガル語の変換リストの更新

ポルトガル語のアクセント記号付きの大文字が %Text.PortugueseOpens in a new tab クラスの文字セットに追加されました。これにより、ポルトガル語のテキストにアクセント記号なしの文字と対をなすアクセント記号付きの大文字を含めることができます。この形式で処理されるポルトガル語のアクセント記号付き文字は、“ÀÁÂÃÇÉÊÍÓÕÔÚÜ” です。

TCP ブロードキャスト・ロジックの変更

従来のリリースでは、$zu(94) 関数を使用したブロードキャストのターゲット・プロセスに $Principal のような TCP デバイスがあると、このデバイスに出力データがバッファされていました。このバッファがいっぱいになるか、プロセスがデバイスにサブシーケンス "write !" を発行するまで、転送されませんでした。このバージョンの Caché では、ブロードキャスト・メッセージが即座に転送されます。

EnsLib.SOAP.Service から削除された AllowSessions プロパティ

2008.1 の Ensemble リリースで、AllowSessions プロパティは EnsLib.SOAP.ServiceOpens in a new tab クラス設定から削除されました。このパラメータは構成できなくなりました。代わりに、EnsLib.SOAP.ServiceOpens in a new tab の SOAPSESSION クラス・パラメータを使用して、サービスでコンパイル時に CSP/SOAP セッションを使用するかどうかを選択する必要があります。このパラメータの既定値は SOAPSESSION = 0 です。

EnsLib.SOAP.ServiceOpens in a new tab のサブクラスで AllowSessions 設定を使用してセッション動作を制御していた場合は、SOAPSESSION クラス・パラメータを使用するようにそのサブクラスを書き換える必要があります。セッションを使用している場合、SOAPSESSION = 1　に変更する必要があります。セッションを使用していない場合は、既定の設定をそのまま使用できます。

詳細は、"Ensemble での Web サービスおよび Web クライアントの作成" の “Ensemble Web サービスの作成” の章の "SOAP セッションの有効化" のセクションを参照してください。

MVBasic コマンド行に影響するアカウント・エミュレーション設定

この変更がある前は、最新の BASIC ルーチン・コンパイルで設定されたオプション・セットを使用するか、コマンド行で $OPTIONS 設定を入力してコンパイルしていました。

このバージョン以降は、ターミナルのコマンド・プロンプトで BASIC コマンドが入力されると、アカウント・エミュレーション設定を使用してコンパイルされるようになりました。既定以外のオプションが必要な場合 (CEMU の既定でないオプション)、$OPTIONS とコマンドをセミコロンで区切り、それを 1 つのコマンド行として入力する必要があります。

デバッグの表示

ターミナルで MVBasic ルーチンをデバッグする場合、<BREAK> メッセージに MVBasic ソース・ルーチン名とソース行番号を示す行が含まれるようになりました。

ユニバース・バックアップの MVIMPORT

このバージョンの Caché では、次のようにユニバース・バックアップのインポート方法が変更されました。

• O オプション は削除されました。

• アカウントが既に存在している場合、MVIMPORT はその上でバックアップをインポートしません。ユーザは、存在しないアカウントにインポートする必要があります。

• MVIMPORT が既定でアカウントが使用する名前と同じ名前のネームスペースを探す可能性がある場合、それが現在空であればそのネームスペースにリストアします。

MVIMPORT による IMPORTED.VOC のコンテンツの変更

従来のバージョンでは、IMPORTED.VOC ファイルには MVIMPORT 例外 (VOC に書き込まれないすべてのアイテム) が含まれていました。このバージョンでは、アイテムが VOC にリストアされてもされなくても、すべての元の VOC が含まれるようになりました。 これにより、顧客は MVIMPORT がアイテムを VOC に適用するかどうか決定する前の元のシステムの VOC の内容を確認できます。

未定義の変数を参照すると既定で返される <UNDEFINED> エラー

MVBasic ルーチンは、Caché で定義されていない変数に対するすべての参照を制御できるように変更する必要があります。現在の MVBasic ルーチンで未定義の変数を参照しようとすると、既定で <UNDEFINED> エラーが発生します。 この変更の前には、未定義の変数は暗黙的に空白文字列に置き換えられていました。

この既定の動作を変更する手順は次のとおりです。

• 現在のプロセスに対する処置 –

  現在のプロセスでは、$ZUTIL(18, 2) または $ZUTIL(68, 72, 1) のいずれかを呼び出し、以前の動作をリストアできます。

• システム全体に対する処置 –

  ZSTU ルーチンなどで、システム起動時に $ZU(69, 72, 1) を呼び出します。 この時点以降に起動するあらゆる新規プロセスが以前の動作になります。

$GET 関数の追加

関数 $GET がMVBasic に追加されました。この関数は、Caché 関数 $GET の MultiValue 版です。ただし、Caché で使用できる省略形 $G は、ここでは使用できません。

照合の変更

従来のバージョンでは、0 または NULL を含む右揃えフィールドは、インデックスの同じ場所にソートされていました。このバージョン以降は、NULL フィールドは 0 を含むフィールドの前にソートされます。

ED の変更

MV プラットフォームと同じ方法で ED に値マークまたはサブ値マークを入力することができるようになりました。Ctrl-\ と押すとサブ値マーク $CHAR(252) が入力され、Ctrl-] と押すと値マーク $CHAR(253) が入力されます。

TB コマンドは、ED の中で動作するようになりました。例えば、次のように実行します。

TB 3,6,9

これは、タブが 3、6、9 に停止するよう設定されることを意味します。ED エディタで任意の場所にタブを入力すると、タブは TB の設定を満たすような個数のスペースに置き換えられます。

タブの停止位置の区切りは、スペースまたはコンマを使用できます。 TB の設定は、ユーザがログオフした後に再度ログオンするまで持続されます。

TCL の変更

Caché で TABS コマンドがサポートされるようになりました。これは TCL コマンドで、書式および使用方法は ED エディタの TB と同じです。例えば、次のように使用します。

USER: TABS 3,6, 9

#PRAGMA の追加

既定では、MVBasic ルーチンがコンパイルされると、MVB.xxx というルーチン名が生成されます。 この名前は、中間 MVI ソース・コードおよびオブジェクト・コードに適用されます。 ソース・ファイルに特定のルーチン名を指定する場合、ファイルに #PRAGMA 文を追加します。

#PRAGMA ROUTINENAME=rrr

ここで、“rrr” はルーチン名です。“rrr” の最初の文字は % またはアルファベット、以降の文字はアルファベット、数字、またはピリオドとして、Cache ルーチンの構文を満足する必要があります。指定した名前がこの形式でない場合、“無効なルーチン名です” というコンパイラ・エラーが発生します。

ルーチン名がソース・ファイルに関連付けられると、その名前は #PRAGMA が削除されても使用され続けます。関連付けられた名前の使用を停止してシステムに新しい名前を生成させるには、次のように空のルーチン名を指定します。

#PRAGMA ROUTINENAME=

SYSTEM(31) で一意の値を返す

SYSTEM(31) は変更され、ユニバース関連のエミュレーションごとに一意の ID を返すようになりました。以前は、それらの間に区別はありませんでした。

SYSTEM(30) および SYSTEM(40) でポート ID を返す

ロック操作の後、ロックの所有者を報告する SYSTEM() 関数は、所有者のプロセス ID ではなく、ポート番号を返すようになりました。 D3 エミュレーションの場合は SYSTEM(30) で、それ以外のエミュレーションの場合は SYSTEM(43) です。

プロセス ID は、従来どおり操作が失敗した後に STATUS() で取得できます。

D3 エミュレーションの SYSTEM(0) の変更

従来のバージョンでは、D3 エミュレーションの SYSTEM(0) はロックの所有者を返していました。 このバージョンでは、現在の STATUS() 値を返すようになりました。これは、ステータス値を設定した最後の操作により異なります。

$CHAIN のサポートの終了

このディレクティブは、元々はプログラムのサイズの制限を補うために PICK に導入されていました。Caché では、この問題は発生していません。このディレクティブを使用しようとするアプリケーションは構文エラーとなるので、サブルーチン呼び出しなどのよりモダンなプログラム・リンク・メカニズムを使用するようアップグレードする必要があります。

INPUT での中断の処理

Ctrl-C (中断) シーケンスが INPUT 文の実行中に入力されると、COS デバッガに移行するようになりました。従来のバージョンでは、アプリケーションはコマンド行に戻っていました。

ログ・ファイルでの誤った使用の収集

MultiValue プログラムにおいて数値演算で数字でない文字列が使用された場合、値 0 が使用されます。この処理が発生すると、Caché では mv.log ファイルにエントリが書き込まれるようになりました。このファイルを確認して、プログラムやデータの修正などの対策を講じることができます。 ファイル mv.log は、Caché インストール Mgr ディレクトリにあるオペレーティング・システムのファイルです。 このエントリは、不正な値を使用したプログラム行を示します。

MVBASE の淡い前景色のサポートの追加

MVBASE エミュレーションでは、淡い前景色 @(-57) ～ @(-64) をサポートするようになりました (それぞれ白、黄色、マゼンダ、赤、シアン、緑、青、黒)。

ターミナル・タイプの追加

このバージョンでは、新しいターミナル・タイプ vt100-color、vt220-color、および vt330-color が追加されました。これらは、カラー・スキーマがオプションである場合に "-color" の定義を作成する慣行に合わせるために、既存の定義の変更ではなく、追加されました。

PICKMON TERMDEF ファイルへの XPICKCOLORS のサポートの追加

PICKMON ターミナルの定義に、新しいブーリアン値 XPICKCOLOR が追加されました。これは、標準でない terminfo 値です (そのため、名前が “X” で始まります)。これにより、ANSI スタイルのカラー・シーケンスの代わりに、PICK スタイルのカラー・シーケンスからカラー定義 'setab' および 'setaf' を使用できます。

XPICKCOLORS,

ストリームの SQL のサポートの改善

このバージョンの Caché では、SQL テーブルのフィールドとしてストリームの処理が改善されました。

• ストリームの OID 値を返す単純な関数を使用して、返されたストリームを開くことができるようになりました。ストリーム・フィールドが NULL の場合でも、それを読み込もうとすると即座に EOF に到達してしまいますが、開くことはできます。

• INSERT および UPDATE 節は、テーブルのストリーム・フィールドの新しい値として OID などを受け取るようになりました。

• SUBSTRING 関数は、最初の引数としてストリームを受け取るようになりました。

• INSERT および UPDATE 節は、テーブルのストリーム・フィールドの新しい値として OID などを受け取るようになりました。SUBSTRING 関数は、最初の引数としてストリームを受け取るようになりました。

• ODBC および JDBC ゲートウェイも、このサポートを提供するようになりました。

SQL 列レベルの特権のサポートの追加

Caché SQL では、SQL の INSERT、UPDATE、SELECT、および REFERENCE 特権の列レベルの特権をサポートするようになりました。 INSERT の列レベルの特権を付与する構文は、次のとおりです。

GRANT INSERT ( FieldName1 [,FieldNameN ...] ) ...

以下はその例です。

GRANT INSERT ( Name, SSN ) ON Sample.Person TO John

これにより、John は Sample.Person テーブルに挿入する権限が与えられますが、Name および SSN フィールドにしか値を指定できません。 その他の列には、既定値があればそれが設定され、既定値がなく NULL 値が可能であれば NULLが設定されます。

UPDATE および SELECT 権限を付与する構文も同様です。

Caché SQL では、列の REVOKE 特権の機能もサポートされるようになりました。 REVOKE の構文では、権限の後にオプションで列リストを指定する必要がありますが、それ以外は従来と同じです。 以下はその例です。

REVOKE INSERT (SSN) ON Sample.Person FROM John

その他の注意事項

• REFERENCE 特権でも列レベル特権の付与および削除が可能ですが、Caché SQL では、現時点で REFERENCE 特権を完全にはサポートしていません。 今後、REFERENCES を完全にサポートする予定です。

• 列レベルのセキュリティによって、テーブル・レベルの権限を無効化することはありません。下位互換を保つよう従来どおりこれは完全にサポートされています。 アプリケーションでテーブル・レベル特権のみを使用し、列レベル特権が不要な場合、すべて従来どおりに機能します。

• ユーザがテーブル・レベルで特権を付与すると、SQL 標準では、特権を与えられたユーザは現在定義されているとおりにテーブルの全列に特権が付与され、それ以降テーブルに追加される任意の列にもすべての特権が付与されます。 これはサポートされます。 ただし、Caché SQL ではテーブル・レベルで特権を付与することはできず、したがってテーブルの列のセットの特権を無効にすることもできません。代わりに、必要な列のみに許可を付与して、テーブルの残りの列にはアクセスできないようにすることができます。

• %CHECKPRIV 文は、列レベルでの特権のチェックをサポートするように改善されました。

• INSERT または UPDATE フィールド・リストになくても、INSERT または UPDATE 文で指定された任意のフィールド名には SELECT 特権が必要になりました。また、矢印構文が含まれている場合、参照されるフィールドに加えて参照されるテーブルの ID にもSELECT 特権が必要になります。

長いストリームでのテキスト検索

従来のバージョンの Caché では、ストリームとして表されるテキストを検索する機能が用意されていました。ただし、32K を超えるストリームを検索する場合、長い文字列のサポートを有効にする必要がありました。このバージョンの Caché では、次を除いてその制限は取り除かれます。

• %CONTAINS 述語を使用する場合、語幹抽出され、ノイズワードがフィルタされたテキストは文字列に変換する必要があります。テキストが極度に長くならないように、アプリケーションでは %CONTAINSTERM 述語を使用します。

• %SIMILARITY 演算子をインデックスでないフィールドに使用する場合、ドキュメントは 32K 以下の文字列のチャンクに分割されます。その場合、境界をまたぐ語は正しく参照できません。この問題を回避するために、%SIMILARITY はインデックス・フィールドでのみ使用します。

計算プロパティの自己参照

このバージョン以降、計算プロパティで {*} を使用して計算コードで現在のプロパティを参照することができます。これにより、計算コードの移植が容易になります。例えば、次のように指定して Studio で表示します。

Property FOO As %String [ Calculated, SqlComputeCode = { s {*}="bar"}, SqlComputed];

INSERT または UPDATE 文の重複の禁止

このバージョン以降、重複フィールドを含む SQL の INSERT または UPDATE 文があると、文が作成またはコンパイルされたときにエラーとして報告されるようになりました。例えば、次の文を実行すると、SQL エラー・コードが出力されます。

insert into sample.person (name, Name) values ('Dave','tom')

 insert into sample.person set name = 'Dave', Name = 'Tom'
 
 update sample.person (name, Name) values ('Dave','tom')

update sample.person set name = 'Dave', Name = 'Tom'

新しいエラー・コードの値は -377 です。このメッセージは、“insert または update 文の引数リストにフィールド名 '%1' が複数個あります” です。

SQL COALESCE 関数には互換のある型が必要

SQL で COALESCE 関数を含むクエリを作成またはコンパイルする場合、引数のデータ型が相互に互換性がないと、Caché でエラー (SQLCODE = -378) を返すようになりました。データの ODBC タイプによって互換性が判断されます。このタイプに互換性があるが多数ある場合、COALESCE 関数は最高の優先度を持つタイプの値を返します。すべての数値型には互換性があり、次のような優先度があります。

• DOUBLE

• NUMERIC

• BIGINT

• INTEGER

• SMALLINT

• TINYINT

例えば、COALESCE 関数で TINYINT、INTEGER、および NUMERIC 型の引数を使用して呼び出した場合、NUMERIC が最高の優先度を持つので、列の型は NUMERIC になります。

その他すべての ODBC タイプは現在他のタイプと互換性がないので、型を混合する場合は関数の引数で明示的に CAST を指定する必要があります。

SQL の UNION による型互換の強制変換

従来のバージョンの SQL で、次のクエリを実行したとします。

    SELECT 0 AS var1 FROM Table1 
    UNION ALL 
    SELECT 0.1 AS var1 FROM table2

すると、ODBC および JDBC に対する var1 の列タイプとして INTEGER が報告されます。値が 0.1 の場合もクライアントには整数として送信され、その結果データは切り捨てられました。

このバージョンでは、SQL プロセッサにより UNION のすべての部分が検証され、各列の最高の優先度の型が返されます。Caché の型の優先順位は次のとおりです。

• VARCHAR

• DOUBLE

• NUMERIC

• BIGINT

• INTEGER

• SMALLINT

• TINYINT

次のクエリを実行したとします。

    SELECT MyTinyIntField AS var1 FROM Table1 
    UNION ALL 
    SELECT MyIntegerField AS var1 FROM Table2 
    UNION ALL 
    SELECT MyNumericField AS var1 FROM Table3 

この場合、NUMERIC の優先度が TINYINT や INTEGER より高いため、この列にデータ型 NUMERIC が返されます。

今回のバージョンの Caché では、UNION でのデータ型に対する前述の優先度のみを使用します。その他のデータ型が存在する場合は、自動型検出が行われません。最も高い優先度を持つ UNION フィールドの型が返されます。他の型は無視されます。列に特定の型を使用する場合は、次のように明示的に CAST 文を使用する必要があります。

    SELECT CAST(MyStringField AS DATE) AS var1 FROM Table1 
    UNION ALL 
    SELECT MyDateField AS var1 FROM Table2 

すべての UNION に依存する SQL クエリ照合結果

このバージョン以降の Caché では、FROM ビューまたはサブクエリが UNION で構成される場合、結果の照合フィールドはすべての UNION 範囲内で対応するフィールド/式の照合に依存します。それらが一致しない場合、EXACT (照合なし) が使用されます。従来のバージョンでは、照合は最初にある UNION で決定されていました。

SQL UPDATE でストリームの強制変換不可

このバージョン以降、UPDATE 文を作成またはコンパイルするときに、非ストリーム・フィールドとストリーム・フィールドのコンテンツをイコールで結び設定しようとすると、エラーが返されます。このケースでサポートされる暗黙のデータ型変換はありません。以下はその例です。

UPDATE SQLUser.MyTable 
     SET MyStringField = MyStreamField ... 

これを実行すると、"SQLCODE = -303: UPDATE 割り当てでストリーム・フィールドから非ストリーム・フィールド 'MyStringField' への暗黙の変換はありません" が返されて失敗します。

この割り当てを正しく実行するには、SUBSTRING 関数を使用してフィールドをストリームから文字列に変換します。MyStringField の長さは 2000 文字とします。以下に例を示します。

UPDATE SQLUser.MyTable 
     SET MyStringField = SUBSTRING(MyStreamField, 1, 2000) ... 

すると、MyStringField には MyStreamField の最初の 2000 文字が設定されます。

LAST_DAY 関数のサポートの追加

Caché SQL で、LAST_DAY() スカラ式関数がサポートされるようになりました。構文は以下のとおりです。

LAST_DAY(<expr>)

ここで、<expr> は %Library.DateOpens in a new tab または %Library.TimeStampOpens in a new tab　の値です。この関数の返り値は、指定した日付またはタイムスタンプを含む月の最終日の数字です。

先頭の % なしのフィールド照合名のサポート

SQL の DDL で列の照合関数を指定する際に、先頭の “%” なしの照合名がサポートされるようになりました。 例えば、以下のように指定できます。

CREATE TABLE MyTable (NAME VARCHAR(50) COLLATE EXACT) 

これは、次の文と等価です。

CREATE TABLE MyTable (NAME VARCHAR(50) COLLATE %EXACT) 

TCP キープ・アライブ間隔

このバージョンでは、(マシン全体の設定に依存せずに) 個々のプロセスの TCP キープ・アライブ・タイムアウトを制御する新しい SQL 構成設定を導入しました。 これにより、より確実な方法でネットワーク障害や VPN の障害などが原因となる切断を検出できるようになりました。ネットワーク障害があった場合、マシンの既定 (約 60 分) ではなく、指定したタイムアウト期間内に <DISCONNECT> エラーがスローされます。

間隔の値にアクセスするには、管理ポータルの ホーム, 構成, SQL 設定 で [TCP のキープ・アライブ間隔] フィールドを使用します。この値は、プログラムから $SYSTEM.SQL クラスの SetTCPKeepAlive メソッドを使用して設定することもできます。

スタティック・カーソルで多くの行を返す

スタティック・カーソルで返される行数の上限が大きくなりました。従来のリリースでは 32K 行でしたが、このバージョン以降は 4GB になります。

名前なしの SAVEPOINT のサポートの終了

SAVEPOINT 機能は、Caché バージョン 5.1 で導入されました。今回の変更により、他のベンダのセーブポイントの実装との互換性を改善するために、名前なしのセーブポイントのサポートを終了しました。名前なしのセーブポイントは、Caché アプリケーションの中では広く使用されていません。この機能を使用するアプリケーションは、セーブポイント名を指定するよう変更する必要があります。

ビューでの ORDER BY の禁止

従来のバージョンでは、ORDER BY 節が SQL 式のビューで使用されると、Caché はその ORDER BY 節を無視していました。このバージョン以降、そのような場合に ORDER BY を使用すると、"SQL エラー -143: ORDER BY はビューのクエリに使用できません" が生成されます。

マップのコンパイル・チェック・フィールド名

従来のバージョンでは、CacheSQLStorage マップで存在しないプロパティが参照されていても、クラス・コンパイラは何もメッセージを出力せずに処理していました。このバージョンでは、マップの添え字の式に存在しないフィールドがあると、クラス・コンパイル時にエラーとして報告されるようになりました。

また、コンパイラは、すべてのフィールド参照が schema.fieldname という形式であること、およびそのスキーマが正しいことをチェックするようになりました。

クエリから呼び出される関数に対する特権のチェックの拡大

このバージョン以降、クエリにユーザ定義 SQL 関数として呼び出されるプロシージャがある場合、クエリを実行するユーザにそのプロシージャを実行する特権があるかどうかが Caché SQL でチェックされるようになりました。 関数プロシージャを呼び出す SQL 文を実行するために、ユーザはその関数プロシージャに対する EXECUTE 特権が必要です。例えば、以下のクエリを実行するとします。

SELECT A, B, MyFunction() from SQLUser.MyTable

その場合、ユーザは SQLUser.MyTable テーブルに対しては SELECT 特権、SQLUser.MyFunction プロシージャに対しては EXECUTE 特権が必要になります。

xDBC クエリの長いフィールド

クラスで %Library.String 型のプロパティを定義し、このプロパティの MAXLEN が 16374 より大きい場合、ODBC または JDBC 上のクエリでこのフィールドを選択すると、フィールの最初の 16374 文字のみが返されます。16374 文字を超える単一のフィールドでデータをサポートするには、文字列の代わりにストリーム・データ型を使用します。

SQLBINARY、SQLVARBINARY、および SQLLONGVARBINARY の変換の変更

SQLBINARY、SQLVARBINARY、および SQLLONGVARBINARY の変換動作が変更されました。SQL_C_CHAR および SQL_C_WCHAR として返されたデータのバイトごとに 2 文字の 16 進値を返すようになりました。

以前のリリースで使用されていたアルゴリズムでは、誤った変換や間違った文字列長が発生することがありました。 これは、WinSQL で SQLLONGVARBINARY 列を表示する際に発生する問題の原因となっていました。 この変更により、これらのデータ型を使用した列で SQLFetch および SQLGetData を使用するときの動作が変化しています。 動作は、SQLServer データで得られるものと一致するようになりました。

%request のプロパティの読み取り専用のマーク

CSP ゲートウェイで提供される %request オブジェクトのプロパティの一部を変更すると、同じプロセス内の次の要求にも、この変更された値が提示されます。これにより、アプリケーションで些細なエラーを引き起こす場合があります。この問題が発生しないようにするため、このバージョンの Caché では、UserAgent、ContentType、CharSet、Method、Protocol、Secure、GatewayApplication、GatewayConnectionName、GatewayBuild、GatewaySessionCookie、GatewayInstanceName、CSPGatewayRequest という %CSP.RequestOpens in a new tab のプロパティが読み取り専用になっています。

追加された %request のプロパティ

このバージョンの Caché では、GatewaySessionCookie プロパティおよび GatewayInstanceName プロパティが %CSP.RequestOpens in a new tab オブジェクトに追加されました。

ハイパーイベントで xmlHttpRequest を使用する変更

従来のリリースでは、CSP では CSP Java イベント・ブローカーおよび JavaScript フレームワークを介して iframes を使用しサーバのメソッドを呼び出すハイパーイベントをサポートしていました。ハイパーイベントをサポートしていたのは、すべてのブラウザにこのような目的で xmlHttpRequest オブジェクトが用意されていたわけではないためです。もうそのようなことはありません。サポートされているすべてのブラウザにはこの機能が用意されています。これは、複数のリリースの CSP で既定のメカニズムになっています。

このリリース以降、従来のメカニズムのサポートを終了し、すべてのサーバの要求はハイパーイベント処理用の xmlHttpRequest を使用します。具体的には、次のように対応します。

• iframe および Java アプレットをサポートするコードを組み込むために使用されるメソッドは、非推奨とします。

• Java イベント・ブローカーおよび iframes は製品から削除されました。

• メソッド呼び出し HyperEventFrame　および HyperEventBody (%CSP.PageOpens in a new tab

  クラス) は、常に空の文字列を返すようになりました。

• メソッド呼び出し HyperEventBody (%CSP.ResponseOpens in a new tab

  クラス) は、常に空の文字列を返すようになりました。

• CSP:CLASS タグの属性 InsertBrokerIframe および InsertBrokerApplet は、非推奨とします。使用されていても、XMLHttpRequest ハイパーイベント用の Javascript (.js) ファイルが代わりに組み込まれます。

• 既存のアプリケーションを変更する必要がないように、%CSP.PageOpens in a new tab メソッド HyperEventBody および HyperEventFrame は保持され、常に空の文字列が返されます。

• “ハイパーイベントの実装” の選択は、管理ポータルから削除されました。

• Security.ApplicationsOpens in a new tab クラスのプロパティ HyperEvent は、非推奨とされました。セキュリティ API を使用して CSP ページを操作するアプリケーションのコードは作用しないので、変更することをお勧めします。このプロパティは、将来のリリースで削除される予定です。

CSP ゲートウェイの変更

CSP ゲートウェイは、管理モジュール CSPmsSys.dll とランタイム CSPms.dll の 2 つのモジュールから構成されます。ランタイムは CSP ファイルの要求の処理を行い、管理モジュールはゲートウェイの管理インタフェースを提供します。

ゲートウェイの従来のバージョンでは、これらの 2 つのモジュールは Web サーバ構成で個別に構成されていました。このバージョンでは、ランタイムは管理モジュールに対して管理要求のロードおよび転送処理を行います。Web サーバで管理モジュールを構成する必要はなくなりました。これにより、ゲートウェイの Web サーバ構成全体が単純化されます。

Web サーバに代わり Caché から静的ファイルを処理

従来のバージョンでは、Caché は CSP エンジンにより .csp、.cls、および .zen タイプのファイルのみを処理していました。その他すべてのファイル (静的ファイルなど) は、Web サーバにより処理されていました。このバージョンでは、CSP エンジンは CSP アプリケーション・パスに配置されている任意のタイプのファイルを処理できるようになりました (静的ファイルを含む)。このアプローチの利点は、次のとおりです。

• すべてのファイルは Cache サーバ上にあるので、アプリケーションの管理および配置が容易になります。静的ファイルを Web サーバ・マシンにコピーする必要がなくなり、すべてのファイルは同じ場所から取得されます。

• これにより、/csp/broker アプリケーションの一元的な場所に共通ファイルの単一のコピーがあっても、それらがそれぞれのパスにあるように見えるようにファイルの場所をリマップできます。

• Caché セキュリティ・ルールは、動的ファイルにも静的ファイルにも一貫して適用できるようになりました。

• アプリケーションの静的ファイルが存在する場所を表すために Web サーバ構成にエイリアスを作成する必要がなくなるので、CSP アプリケーションの Web サーバ構成はより単純化されます。これにより、単一 (共通) の Web サーバで 2 つの異なるバージョンの Caché を処理する場合、それぞれで異なるバージョンの特定の静的ファイル (例えば、ハイパーイベントのブローカ・コンポーネント) を要求する際の競合の問題が解決されます。

これらの変更をサポートするために、CSP アプリケーションで指定される新しい構成オプションが追加されました。

• 静的ファイルをキャッシュに保持する時間 ： 指定しない場合の既定値は 1 時間です。これは、キャッシュがオンの場合にブラウザがこのファイルをキャッシュする時間と CSP ゲートウェイがこのファイルをキャッシュする時間の両方です。

• “サーバ・ファイル” の質問に対して次のように選択を変更します。

  • いいえ ： このアプリケーション・パスからのサーバ・ファイルではありません。

  • 常時 ： 常にこのアプリケーション・パスからのサーバ・ファイルです。静的ファイルで使用するこのパスの CSP セキュリティ設定は無視します。これは新しいアプリケーションの既定で、Web サーバからのファイルを処理する従来の動作と下位互換があります。

  • 常時およびキャッシュ ： 常にこのアプリケーション・パスからのサーバ・ファイルです。CSP ゲートウェイでこれらのファイルをキャッシュするため、Caché からこれらのファイルを要求する必要がなくなります。これは、ほとんどのアプリケーションが使用するモードです。

  • CSP セキュリティの使用 ： ユーザにこのアプリケーションの .csp または .cls ページを表示する許可があれば、静的ファイルを表示することができます。その許可がなければ、エラー・コード 404 (ページが見つかりません) ページが返されます。そのサーバしかユーザが正しいセキュリティ許可を持っているかどうか判断できないので、これはゲートウェイにはキャッシュされません。

/csp/broker に配置されている任意のファイルは、/csp/user/file.txt ファイルが存在する場合、サーバが最初に直面するように実質的にすべてのディレクトリに表示されます。存在しない場合、/csp/broker/file.txt を調べ、その名前のファイルがそこにあれば、そのファイルを処理します。そのため、アプリケーションで /csp/broker ファイルへのハード・リンクを削除できます。これにより、複数のバージョンの Caché からアプリケーションを単一のサーバで処理できるようになります。

空であったパスワードの変更の検出

従来のバージョンでは、古いパスワードが “” であった場合、CSP パスワード変更ページを使用してパスワードを変更しようとしても、成功しませんでした。古いパスワードが正しくない場合のように処理されていました。現在のバージョンでは、古いパスワードが正しい “” であればそれが検出され、パスワード変更コードが呼び出されます。

バイナリ SOAP メッセージのサポート

Web サービスのパラメータ SOAPBINARY が 1 に設定されている場合、Caché インスタンス間の SOAP メッセージのバイナリ転送が有効になります。Web サービスは、HTTP 上で通常の XML ベースの SOAP または Caché 独自の SOAP フォーマットをサポートしています。SOAP バイナリ転送は、カスタム・オブジェクト・シリアル化メカニズムを使用して実装されます。Web サービスで使用されるクラスはいずれも、%XML.AdaptorOpens in a new tab のサブクラスである必要があります。

SOAPBINARY パラメータを 1 に指定して Cache Web サービス用に生成される WSDL は、Cache Web クライアントに必要な情報が送信されるよう機能拡張されました。これらの WSDL の拡張機能は、XML スキーマ、WSDL、および WS-I Basic Profile の仕様に適合し、すべての対応する Web クライアント・ツールキットにより無視されることを想定しています。

XML Exclusive Canonicalization バージョン 1.0 のサポート

Caché では、XML Exclusive Canonicalization バージョン 1.0Opens in a new tab がサポートされることになりました (Exclusive Canonicalization InclusiveNamespaces PrefixList 機能を除く)。つまり、%XML.WriterOpens in a new tab の Canonicalize メソッドは、仕様に示された標準化された形式で %XML.NodeOpens in a new tab クラス・インスタンスでサブツリーにより表される XML ドキュメントを記述します。この実装の一環として、Tree、Document、および DocumentNode メソッドの属性の出力順は、標準的な順序に変更されます。スキーマおよび WSDL の出力のほとんどで、この変更は認識されます。

この実装の一環として、SuppressAutoPrefix プロパティが %XML.WriterOpens in a new tab および %XML.NamespacesOpens in a new tab に追加されました。これにより、現在の要素に不要でも既定の XML ネームスペースに作成される接頭辞を任意で抑制することができます。

%XML.WriterOpens in a new tab のほとんどのメソッドでは、XML Canonicalization 規格で指定されているように文字をエスケープするようになりました。以下の表では、特定の文字が属性および要素に見つかったときに、このクラスのメソッドでどのようにエスケープされるかを説明しています。

*この列が該当するのは、メソッド WriteAttribute() と、WriteAttribute() を使用するメソッドである Document()、DocumentNode()、Tree()、Canonicalize()、CanonicalTree()、Element()、および RootElement() です。

†　この列が該当するのは、メソッド WriteChars() と、WriteChars() を使用するメソッドである Document()、DocumentNode()、Tree()、Canonicalize()、および CanonicalTree() です。

Object() と RootObject() では、WriteAttribute() も WriteChars() も使用されません。

テキストのエスケープと属性の変更は認識される可能性がありますが、XML の処理に違いはないはずです。最もわかりやすい変更は、%XML.WriterOpens in a new tab の WriteChars メソッドで $CHAR(13) 文字がエスケープされるようになったことです。そのため、$CHAR(13,10) では $CHAR(13) がエスケープされ、&#xD となります。つまり、後でインポートする際に $CHAR(13) がデータに入ります。以前は消失していました。

ターミナルのローカル・ネットワーク・エンコーディングの変更

ターミナルのローカル接続の既定のネットワーク・エンコーディングは、Caché サーバの既定値に合わせて 8 ビットの UTF8 がインストールされるよう変更されました。

スクリプトから呼び出される際のターミナル接続表示の変更

バージョン 5.1 以降、ターミナル・セッションは、接続のエンドポイントとなるノードとインスタンス名を表示して開始されました。これは、ユーザがマシンに Telnet 経由で接続する際に、正しいインスタンスに接続されていることを確認できるように表示されていました。しかし、ノードおよびインスタンスを表示することにより出力の解析が混乱する可能性があるため、一部の既存の顧客のスクリプトが失敗していました。

このバージョンでは、例えば次のようにコマンド行でルーチンが渡されると、ターミナルにはノードおよびインスタンスが表示されません。

csession cache -U%SYS ALL^%FREECNT

これは、Caché に入力されるプロセスは正しいノードにあり、コマンド行で正しいインスタンスを指定しているためです。その他すべての状況では、ノードおよびインスタンス名は表示されます。

Light C++ バインディング参照のカウント動作の変更

この変更がある前は、同じクラスと ID で openid() が 2 回呼び出され、その結果が 2 つの異なる lc_d_ref に割り当てられた場合、それらの lc_d_ref はメモリ内の別々のプロジェクション・オブジェクトを指し、それぞれは同じデータベース・オブジェクトからプロパティ値で初期化されていました。 いずれかを使用して新しいプロパティ値を設定しても、他方には影響しませんでした。一方に行われた変更を保存してからもう一方に行われた変更を保存すると、最後に保存されたプロジェクション・オブジェクトからのプロパティ値は前に保存されたプロジェクション・オブジェクトからのプロパティ値をオーバーライドします。

同様に、create_new() で返されたプロジェクション・オブジェクトが lc_d_ref に割り当てられてデータベースに保存された後、新しく保存されたオブジェクトの ID を使用してそのクラスの openid() が呼び出され、その結果が 2 番目の lc_d_ref に割り当てられた場合、2 つの lc_d_ref はメモリ内の別々のプロジェクション・オブジェクトを指していました。

このバージョンでは、複数の lc_d_ref が同じ ID で同じクラスのオブジェクトを参照する場合に、正しい C++ バインディング・オブジェクト参照 (d_ref) の処理に適合するように、Light C++ バインディング・オブジェクト参照 (lc_d_ref) の処理を変更しました。