Caché 2015.1

<STORE> のエラー処理の変更

今回のリリースでは、Caché での低いメモリ状態の処理方法が変更されており、プロセスの最大メモリを超えているために <STORE> エラーが発生しているアプリケーションの回復を、エラー・ハンドラの特殊なコードを必要とすることなく、より適切に行えるようになりました。バージョン 2012.1 から 2014.1 までは、プロセスによって <STORE> エラーが生成されると、$ZSTORAGE の最大メモリが自動的に 1MB 増やされ、追加メモリが提供されてエラーが処理されていました。ただし、最初の <STORE> エラーのクリーンアップ後にアプリケーションによって $ZSTORAGE が明示的にリセットされない限り、次の <STORE> エラーでは追加のメモリの恩恵を受けられませんでした。

今回のリリースでは、<STORE> エラーの後にアプリケーションがメモリを解放すると、最初の <STORE> エラーで使用できたものと同じ追加の 1MB をその後の <STORE> エラーでも利用できるモードに戻ります。この新しいアプローチの詳細は以下のとおりです。

• $ZSTORAGE は、プロセスによって <STORE> エラーが生成されたときに、変更されることはなくなりました。

• $STORAGE は負の値になることもできるようになりました。

• <STORE> エラーは、内部メモリのカウントではなく $STORAGE の値に基づいてスローされ、より予測しやすくなりました。

$ZSTORAGE の自動的増加 (2012.1 ～ 2014.1 の動作) に関する前提を設けているアプリケーション・エラー処理コードは見直す必要があります。さらに、$STORAGE が正の値であることに依存しているコードも見直す必要があります。この動作の詳細は、"Caché プロセスのメモリ" を参照してください。

%-ルーチンパスの設定は特権を必要とする操作

今回のリリースから、$ZU(39) または %SYSTEM.Process.SysRoutinePath() でのパーセント・ルーチンのプロセス検索パスの変更は、特権を必要とする操作になりました。プロセスは、CACHESYS データベースに対する Write 許可を持っている必要があります。パーセント・ルーチン・パスが、既定ではない値に設定されており、かつ ROUTINE^%R が使用されて現在のネームスペース以外のもので動作する場合、その処理が完了した後に Caché によって <PROTECT> エラーがスローされます。ルーチン・パスはリストアされません。

特権のないプロセスに標準以外のパーセント・ルーチン・パスを設定しているユーザは、パスを設定するための安全なメソッドを指定するか、標準以外のパスを必要としないようにそれらのコードを変更する必要があります。

^cspRule の再配置

今回のリリースでは、^cspRule の場所が既定のグローバル・データベースからルーチン・データベースに移動されています。以前のバージョンから 2015.1 へのアップグレードへの一部として、それらの CSP ルールを再コンパイルすることが必要になります。

ルーチン・キャッシュに使用される既定のメモリの増加

今回のリリースでは、メモリの自動構成を選択した場合に、ルーチン・キャッシュに割り当てられるメモリの量が約 12MB に拡大されました。 この変更の結果、これを明示的に指定していない構成では、ルーチンで消費する共有メモリが増加します。

%SYS.SYSTEM.GetNodeName() の変更

メソッド %SYS.System.GetNodeName(1) は、オペレーティング・システムが実行されているシステムに対して定義されているノード名を、そのオペレーティング・システムに返すように記述されています。以前のリリースでは、ノード名が取得され、それが大文字に変換されていました。現在では、ノード名はシステムによって定義されているとおりに返され、大文字に変換されなくなりました。

ターミナルの Control-C 入力の処理の変更

以前のリリースでは、一部のターミナル入力処理でターミナルからの読み取りの前に、保留中の Control-C シグナルがすべて解消されていました。その他のターミナル入力処理は、ターミナルからの読み取りの前に保留中だった Control-C のすべてが直接作用していました。 現在では、すべてのターミナル読み取り処理で、ターミナルからの読み取りの前に保留中の Control-C が解消されます。

インタラクティブな入力に対して先行入力を行う習慣があるユーザは、読み取りが開始された後に 2 度目の Control-C の入力が必要になります。先行入力の Control-C は、入力処理で無視されるようになりました。また、現在は、ターミナル先行入力バッファのコンテンツをクリアする操作 (例えば、WRITE *-1 や WRITE *-10 を使用) により、先行入力バッファが空になるのと同時に保留中の Control-C も解消されます。

引数なしの QUIT コマンドのエラー・レポートの変更

関数が値を返す必要があるときに引数なしの QUIT で終了する場合、<COMMAND> エラーにより、QUIT (ルーチンまたはプロシージャの終わりに暗黙的に含まれていることがある) の場所がレポートされるようになりました。$ZERROR およびエラー例外オブジェクトには、関数が値を返す必要があることを示すデータ・フィールドがあります。

ルーチンがそれ自体内の <COMMAND> を確認することでこの状態を検出する場合、$ZERROR でのルーチン名は異なったものになるため、この確認は失敗します。このテストは、“*Function must return a value” というテキストを検索するように変更できます。

$INCREMENT が障害時にエラーを通知

以前のリリースでは、$INCREMENT がエラーの通知に失敗することがありました。式が以下のとおりで、

$INCREMENT(X, Y)

非ゼロの Y 値があり、X の値の変更に失敗した場合などです。そのような状況は、例えば、X が整数値で Y が小さい小数 (約 5E-19*X 未満) である場合や、X に 10 進数値が含まれており、Y が小さい $DOUBLE バイナリの小数 (約 $DOUBLE(1E-16)*X 未満) である場合に発生することがありました。

現在は、Y が非ゼロの場合の X の値の変更の失敗は、常に <MAXINCREMENT> エラーとなります。

ミラーリングの変更

• ミラー・データベース名が Config.Database データセット名に関する検証に合格することが必要

  ミラー・データベース名は、旧システムの既存のデータベースとの互換性のために大文字でも小文字でも入力できますが、大文字で格納されるようになりました。既存のミラー・データベース名がこの変更によって影響を受けることはありません。したがって、大文字小文字の区別のみが異なる名前で 2 つのミラー・データベースを作成することはできなくなりました。さらに、ミラー・データベース名に有効な文字のみが、データセット名に使用される文字です。先頭の文字は、英字またはアンダースコアである必要があり、残りの部分は英字、ハイフンおよびアンダースコアの連続したものである必要があります。

• syncrule_ack 以外のミラー同期ルールの削除

  今回のリリースから、ミラーリングにおいて複数の応答モード (Sync、Acked、Committed) はサポートされなくなりました。 詳細ミラーリング構成オプション Acknowledgement Mode は削除されました。以前のリリースでは、既定ではない値である “Committed” を選択すると、不要な副次的作用が発生することがあり、信頼性や堅牢さにおける向上はありませんでした。

• エージェントの通信のアービターへの置き換え

  新しいミラーリング機能にはアービターという別個のシステムが採用され、可用性が大幅に高まり、構成が単純化されました。それは、プライマリのホストで壊滅的な障害が発生したかそれが分離された場合における、以前は不可能であった障害シナリオで、安全な組み込みの自動フェイルオーバーがサポートされるようになったためです。これが発生した場合、バックアップが引き継ぐことができます。それは、アービターによってそれとプライマリとの通信が途絶えたかどうかが確認され、プライマリが稼働している場合は、プライマリとしての機能を停止し、両方のフェイルオーバー・メンバがプライマリとして機能してしまう可能性が排除されるためです。

  以前のバージョンでは、これらの障害シナリオの 1 つが発生すると、バックアップにはプライマリの障害とネットワークの分離とを区別する方法がなく、プライマリがプライマリとして機能しなくなったことを確認できず、既定では、この状況でバックアップが自動的に引き継ぐことはできませんでした。特別な条件の下では、ユーザが指定した IsOtherNodeDown エントリ・ポイントを ^ZMIRROR ルーチンに追加し、[フェイルオーバーにエージェントの通信が必要] 設定をクリアすることでこの状況で自動フェイルオーバーを有効化することができました。ただし、プライマリが停止していることを確認するための完全に信頼できるメカニズムを実装することは、大部分の環境で不可能ではなくても困難です。その結果、この方法の大部分のユーザは、まれなケースとしても、場合によっては、両方のフェイルオーバー・メンバが同時にプライマリとして機能するリスクを受け入れていました。

  2015.1 以降は、このメカニズムは排除され、アービターベースのフェイルオーバー・メカニズムに置き換えられています。組み込みのアービター機能は、一般的に、完全に安全な方法でカスタム・コーディングを必要とすることなく、障害シナリオに適切に対応します。2015.1 では、[フェイルオーバーにエージェントの通信が必要] 設定は削除され、^ZMIRROR の IsOtherNodeDown エントリ・ポイントは使用されなくなります。IsOtherNodeDown^ZMIRROR を使用するサイトでは、2015.1 でプライマリ・ホストの障害に対する自動フェイルオーバーが実行されるようにするには、アービターを有効化する必要があります。

  既存のミラーを 2015.1 にアップグレードしてアービターを有効化するには、次の手順を実行する必要があります。

  1. アービターとして機能するシステムを "Caché 高可用性ガイド" の "ミラーの可用性を最適化するためのアービターの配置" の説明に従ってアービターとして機能するシステムを指定します(1 つのアービターを複数のミラーで共有できます)。

  2. 同じドキュメントの "アービターのインストール" の説明に従って、アービターをインストールおよび構成します。これには、最小のソフトウェアのインストールが含まれており、Caché がインストールされている必要はありません。

  3. "Caché インストール・ガイド" の "最小ダウンタイムによるミラーのアップグレード" の説明に従って、ミラー・メンバをアップグレードします。

  4. "Caché 高可用性ガイド" の "フェイルオーバー・メンバの編集または削除" の説明に従って、アービターを使用するようにミラーを構成します。

• 名前および昇格を管理するときの非同期メンバの選択に関する修正

  非同期メンバの昇格および認証 ID の管理の一環としてミラー名の番号付きリストを表示する、^MIRROR のコードが変更されました。これは、数値の名前を持つミラー・メンバがある場合にも適切に機能するようになりました。以前は、数値の名前がリスト内の番号付き選択肢であるのか、メンバの名前であるのかについて混乱することがありました。認証 ID を管理する際のメンバの追加は、管理するメンバ名の入力を要求されたときに Add (および有効な名前) を入力することで起動される、別個の処理になりました。それ以外の場合、応答は最初にメンバ名として、次に (可能な場合) 数値リストの選択項目として処理されます。

• ミラー・モニタ・ステータスのレポートに行われた変更

  ミラー・モニタには、いくつかのレポートの変更があります。

  • [ミラー・メンバ・ステータス] というセクションに、[ジャーナル転送の遅延] と [ディジャーナルの遅延] に対してレポートされる新しい値があります。

  • [ミラー・データベース] セクションには、[ステータス] の新しい値が表示されます。

  • [ミラー・データベース・ステータス] の [遅延] 列の名前が [次にデジャーナルするレコード] に変更されました。

  • 名前が変更された列には、ミラー・データベースの Timestamp、File Name および Journal Offset 位置が含まれています。フィールドは、コンマ (,) で区切られています。

  ステータス値の詳細な説明は、"高可用性ガイド" を参照してください。

• ^MIRROR ユーティリティからの暗号化通信設定の削除

  以前のバージョンでは、各ミラー・メンバの Encrypt Communication 設定を使用して、他のメンバから独立して SSL を使用するように個別のミラー・メンバを構成できました。今回のリリースでは、この設定は、ミラー構成画面から削除されました。

  代わりに、Use SSL オプションを設定することで、すべてのメンバに SSL が必要となるようにミラーを構成することをお勧めします。Encrypt Communication 設定は、アップグレード中もメンバに対して保持され、Config.MapMirrorsOpens in a new tab クラスを使用して管理できますが、このオプションを使用するシステムは、実用後すぐに、推奨される Use SSL オプションに変更する必要があります。

• 起動時のフェイルオーバー・ミラー・メンバへのログインの防止

  フェイルオーバー・ミラー・メンバ上のシステム・ワイド・セキュリティ・パラメータ Inactive Limit は、そのミラー・メンバが起動するたびにゼロに設定されます。このパラメータによって、未使用のアカウントを無効としてマークする間隔が制御されます。バックアップ・ミラー・メンバでアカウントが無効化されないようにするには、これをゼロに設定してこの機能を無効化します。 災害復旧メンバがフェイルオーバー・メンバに昇格された場合、これはその時点で同様にゼロに設定されます。

  これに依存してアイドル・アカウントをクリーンアップしているサイトは、ミラーでは別の方法を採用する必要があります。

• 最大ミラー・メンバ数は 16

  今回のリリースでは、各ミラー・セット内のミラー・メンバの最大数は、8 から 16 に増加しました。

  Important:

  この変更を適切に実装するには、ミラー・セットのすべてのメンバをこのバージョンにアップグレードする必要があります。

ジャーナリングの変更

今回のリリースより前は、保留中のジャーナル入出力が存在するがジャーナルのアクティビティが 10 秒間ないとジャーナル・エラーでフリーズするように設定されていました。今回のバージョンでは、この時間制限が 10 秒から 30 秒に増やされました。10 秒が経過した時点で、次の警告メッセージが cconsole.log に生成されます。

Journal Daemon has been inactive with I/O pending for x seconds

以前の短いタイムアウトを想定している場合は、このしきい値を調整する必要があります。

通常のセキュリティ・インストールでのパブリック許可からの %Service_Object:U の削除

セキュリティ上の理由から、通常のセキュリティ・インストールでは %Service_Object:U はパブリック許可ではなくなりました。 %Service_Bindings クライアントが %Service_Object を使用するには、%Service_Object:U を持つロールが必要になります。 %Developer および %Manager はこの許可を持ち、他のものは必要に応じて追加できます。通常のセキュリティ・インストールのスタジオのユーザは、%Service_Object:U を持つロールを必要とします。

<NOCATCH> エラーの名前の <THROW> への変更と例外オブジェクトの処理の変更

THROW が存在し、それを捕捉する一致する TRY/CATCH が存在しない場合に発生する <NOCATCH> エラーは、<THROW> という名前に変更されました。さらに、そのオブジェクトは、すぐに終了する代わりに特殊変数 $THROWOBJ に保存されるようになります。これにより、エラー・トラップがオブジェクトにアクセスして処理方法を決定することが可能になります。

捕捉されていない例外オブジェクトは、$THROWOBJ がクリアされるまで永続されるようになりました。例外オブジェクトが、解放する必要があるリソースを保持している場合は、オブジェクトの存続期間が長いことに問題がある可能性があります。エラー・トラップで $THROWOBJ を空の文字列に設定し、例外オブジェクトが不要になったときにそれを終了する (およびリソースを開放する) 必要があります。

CACHESYS の % ルーチンでの +offset を使用した DO/GOTO の不可

DO および GOTO の +offset 構文を使用して CACHESYS データベースに %-routines の入力を試みることは不正になりました。これが検出されると <NOLINE> エラーがスローされます。

%Status 値を返すようになった SYS.Agent.VerifyConnection

失敗した VerifyConnection() 呼び出しの戻り値が変更されました。結果は、“0” ではなく %Status 値になります。 これは、アプリケーション・コードでブーリアン演算子を使用する代わりに、このメソッドの戻り値を直接 “0” と比較する場合にのみ、非互換が発生します。例えば、以下のようになります。

If ##class(SYS.Agent).VerifyConnection() = 0 

は、現在は、VerifyConnection が失敗した場合に機能しません。検証が成功すると、$$$OK が返されます。これは、値 1 と同一であり、変更されていません。

CacheSSH の戻り値の変更

%Net.SSH.SFTPOpens in a new tab クラスには、リモート・ディレクトリのコンテンツを列挙するメソッド Dir() があります。以前のリリースの既定の動作では、“.”、“..”、“.rc” など、“.” で始まるディレクトリ・エントリ名が返されました。現在は、SFTP インタフェースの規約に従って、これらのファイルは既定では除外されています。以前の動作は、Dir() の新しいオプションの 4 番目の引数を true に設定することでリストアできます。

クラス記述子キャッシュの注意深い管理

Caché では、以前は、共有クラス・キャッシュの最大サイズはシステムのルーチンの数の割合に設定されていました。この数値が大きすぎる値に設定されていると、多数の一意のクラスが呼び出される場合に、クラス・キャッシュの共有ヒープがすべて使用される可能性がありました。 今回のリリースでは、共有クラスの制限が 900 に設定されています。

これは、小さな固定セットのクラスが実際にシステムで使用されている場合は問題になりません。 大きいセットのクラスが使用されている場合、システムですべてのクラスをキャッシュできない可能性があります。このインスタンスがパフォーマンスに影響を与えることがあります。その場合、キャッシュされるクラスの制限を手動で調整できます。インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

新しいルーチンに切り替えられない XECUTE の ZSAVE

コマンド・プロンプトから実行される場合、ZSAVE は、現在のルーチンをコマンドで指定されているものに切り替えます。以前のリリースでは、以下の文を実行し、

XECUTE "ZSAVE SomeRoutine"

新しいルーチンに切り替えることができました。ただし、これが XECUTE 内で実行される場合、初期設定されていない変数が原因でクラッシュが頻繁に発生します。

今回のリリースから、このコマンドでは新しいルーチンに切り替えることはできません。

エラー削除タスクではネームスペースではなくローカル・データベースを使用

^ERRORS グローバルは、システム・タスクによって定期的に削除されます。以前のリリースでは、タスクが実行されると、そのタスクは、タスクを実行しているマシンにローカルな既定のデータベースのネームスペースごとに ^ERRORS グローバルを削除していました。このため、データベースが存在していても、定義されたネームスペースが存在しない場合に問題が発生しました。この場合、^ERRORS グローバルは削除されず、サイズが大きくなる可能性がありました。

今回のリリースでは、タスクはローカル・システム上で定義されている各データベースを .cpf ファイルの [Databases] セクションで定義されているとおりにループするようになりました。定義されているデータベースごとに、次の条件が確認されます。

• データベースが ECP データベースである。

• データベースがミラーリングされており、タスクを実行しているシステムがプライマリではない。

• データベースが読み取り専用である。

• データベースがディスマウントされている。

これらの条件のいずれかに該当する場合、そのデータベースに対する削除はスキップされます。 最後の条件については、データベースはシステムにまだマウントされていない場合、Caché によってそれのマウントが試みられ、その条件がテスト可能になります。

共有ライブラリの参照カウントでの管理

以前のリリースでは、$ZF(-4, 1, <PathToLibrary>) によってライブラリが複数のクラスによってロードされていたり、$ZF(-6, <index>, <Function>, <arg1>, <arg2>, ...) の呼び出しによってライブラリがロードされた場合であっても、$ZF(-4, 2, <LibraryHandle>) の 1 回の呼び出しでライブラリはすぐにアンロードされました。

現在は、$ZF(-4, 1) により 1 つのライブラリがロードされた回数の参照カウントが保持されるようになりました。 $ZF(-4, 1, <PathToLibrary>) の呼び出しごとに、参照カウントが増加します。 $ZF(-4, 2, <LibraryHandle>) の呼び出しごとに、参照カウントが減少し、参照カウントがゼロになるとライブラリがアンロードされます。

ライブラリ・ハンドル引数が指定されていない $ZF(-4, 2) では、すべてのライブラリがアンロードされ、この動作に変更はありません。 参照カウントに関係なくすべてのライブラリがすぐにアンロードされます。

現在は、$ZF(-4, 1, <PathToLibrary>) によるライブラリのロードと、$ZF([-4, 5 or 7], <index>, <path>) の呼び出しによってライブラリ・インデックスが事前に構築された $ZF(-6, <index>, <function>, <args>) によるライブラリのロードの間には、ある程度の独立性があります。 $ZF(-4, 1, <path>) によってロードされたライブラリは $ZF(-4, 4, <index) の呼び出しによってアンロードされず、$ZF(-6, <index>, <function>, <args>) によって明示的にロードされたライブラリは $ZF(-4, 2, <LibraryHandle>) によってアンロードされることはありません。 ただし、<LibraryHandle> 引数が指定されていない $ZF(-4, 2) では、すべてのライブラリがそのロード方法に関係なくアンロードされます。

%SYS.ProcessQuery – ClientNodeName、StartupClientNodeName、Current Device の長さの増加

以前のリリースでは、ClientNodeName および StartupClientNodeName の値は 32 文字までに切り捨てられ、Current Device の値は 24 文字までに切り捨てられました。今回のリリースでは、それら 3 つすべてで 64 文字まで切り捨ては行われません。

統一トリガ・メカニズムの明確化

オブジェクトおよび SQL に対する統一トリガのサポートは、バージョン 2014.1 で導入されました。ストリームであるフィールドまたはプロパティがトリガ定義内で参照される場合、その参照の値がストリームの OID です。

• BEFORE INSERT または UPDATE として指定されたトリガについては、新しい値が INSERT、UPDATE または %Save 操作によって指定されている場合、{StreamField*N} は一時的なストリーム・オブジェクトの OID、または新しいリテラル・ストリーム値のいずれかになります。

• BEFORE UPDATE トリガについては、新しいストリーム値がフィールドまたはプロパティに対して指定されていない場合、{StreamField*O} および {StreamField*N} は両方とも現在のフィールドまたはプロパティ・ストリーム・オブジェクトの OID になります。

$SYSTEM.TSQL 検証の追加

$SYSTEM.TSQL の “Set” メソッドでは、それらに渡されたパラメータ値が検証されるようになりました。“Get” メソッドは、それらが冗長であったため、パラメータを取らなくなりました。

^%SYSMONMGR メニューの変更

^%SYSMONMGR のオプション #4、“Manage Sensor Readings” のラベルは、“Manage Debug Data” に変更されました。

グローバル・マッピングでの文字シーケンス || の不可

グローバル・マッピングを定義するときに、文字シーケンス “||” はマッピングのいずれの場所でも許可されません。

Java 仮想マシン (JVM) のバージョンの要件

今回のリリースの時点では、Java 仮想マシンに依存する Caché 関数には 1.7 以降のバージョンの JVM が必要です。

Docserver アプリケーションの無効化

今回のリリースから、アプリケーション /csp/samples/docserver は、アップグレードおよび新規インストールで既定では無効化されています。

Windows

• UNIX® とのインスタンス値の一致

  Windows 上で “ccontrol all” によって表示されるインスタンスの状態値は、UNIX® 上で表示される値と一致するように変更されました。 具体的には、状態テキスト “ab” が “ ” に変更されました。 ^STU が完了せずにインスタンスが部分的に起動している可能性がありログインが無効化されていることを空白の値は示します (インスタンスの状態値の完全なセットは “ccontrol help” によって表示されます)。

  Windows 上で “ccontrol list” によって表示されるインスタンスの状態値は、UNIX® および OpenVMS 上で表示される値と一致するように変更されました。具体的には、状態の略記テキストが完全な用語に拡張されました。 この状態テキストは、“ccontrol help” によって表示される Web ページに記載されています。

• 8ビット・ロケールのパターン・マッチングの変更

  以前のバージョンでは、範囲 128 ～ 159 の Windows コード・ページ (CP12xx) の未定義の文字は、パターン・コード “1E” (任意の文字に一致) によってのみ一致しました。今回のリリースから、それらは、“1C” (制御文字に一致) でも一致します。この変更の目的は、プログラムでのこれらの文字のフィルタ処理を容易にして、ターミナル出力の文字化けを回避することです。以下に、影響を受ける具体的な文字をコード・ページ別に示します。

  • CP1250：129、131、136、144、152

  • CP1251：152

  • CP1252：129、141、143、144、157

  • CP1253：129、136、138、140、141、142、143、144、152、154、156、157、158、159

  • CP1255：129、138、140、141、142、143、144、154、156、157、158、159

  • CP1257：129、131、136、138、140、144、152、154、156、159

  CP1256 では 128 ～ 159 の範囲に未定義の文字はなく、CP1250 ではその未定義の文字が既に出力不能文字として (ただし、制御文字としてではなく) マークされています。パターン・マッチングの詳細は、"Caché ObjectScript の使用法" ガイドのパターン・マッチング演算子を参照してください。

• Caché サービス・アカウントは Windows Administrators グループである必要はない

  Caché サービス・アカウントは、Windows 上で大部分の Caché プロセスの実行に使用されますが、Windows Administrators グループのメンバである必要はなくなりました。 インストール中に Caché サービス・アカウントとして指定されたアカウントは、CacheServices グループのメンバになります。 CacheServices グループは、そのメンバに Caché インスタンスを起動、停止、および制御する制限されたセットの権限を付与します。 このグループのメンバシップは、Caché サービス・アカウントが以下のもので変更された場合にも付与されます。

  cinstall setserviceusername <InstanceName> <username> <password>
  

  この変更は、Caché をローカル・システム・アカウントとして、または管理ユーザ・アカウントとして実行することを選択した場合には何の影響も与えません。 Caché を非管理ユーザ・アカウントで実行することを選択した場合は、Caché サービス・アカウント (または CacheServices グループ) に、データベース、ジャーナルおよびログ・ファイルが配置されているすべてのディレクトリへの十分なアクセス権 (読み取り/書き込み/実行) と、ファイル自体への適切なアクセス権が付与されていることの確認が必要になることがあります。

UNIX®

• Linux プラットフォームに対して推奨される TZ 環境変数の設定

  Linux プラットフォームでは、TZ 環境変数の設定をお勧めします。この変数はタイムゾーンを示します。この変数が設定されていないと、Caché の時間関連関数のパフォーマンスが大幅に低下することがあります。この変数の設定の詳細は、tzset のマニュアル・ページを参照してください。

• root 以外のインストールの禁止

  今回のリリースから、Caché のインストールは root のユーザ ID で実行する必要があります。

Red Hat Enterprise Linux 7 (Power System-64)

このプラットフォームでの上記のオペレーティング・システムのバージョンは、現時点で Perl または Python をサポートしていません。

Light C++ Binding に影響する SUSE Linux 12 リンカの変更

SUSE 12 システムのリンカの変更により、Light C++ Binding アプリケーションの構築に障害が発生します。SUSE 12 リンカでは、リンク対象の他のライブラリの依存ライブラリを明示的に指定するために、アプリケーション makefile が必要になっています。これに該当する他のライブラリがリンクされるときに、依存ライブラリを指定していたとしても makefile は必要です。 この場合、libcachet.so は libpthread.so に依存するため、SUSE 12 Linux 以降は、両方のライブラリを明示的に指定する必要があります。そのため、アプリケーションを正常に構築するには、以下の変更の 1 つを実行する必要があります。

1. アプリケーションの構築に使用する makefile の ID または g++ コマンド行のライブラリ指定に –lpthread を追加します。 例えば、Light C++ バインディングのサンプル・アプリケーションでインストールした Master.mak ファイルの 1 つに基づいた makefile を使用する場合は、以下の行を変更します。

   CACHETLIB = -L$(CACHETPATH) -lcachet 
   

   以下のように変更します。

   CACHETLIB = -L$(CACHETPATH) -lcachet –lpthread
   

2. make が呼び出される環境で、環境変数 MULTITHREADED を 1 に設定します。 Bourne シェルでは、構文は以下のようになります。

   export MULTITHREADED=1
   

この問題は、どちらのオプションでも解決できます。これらのオプションは競合しないため、両方のオプションを同時に使用できます。

OpenVMS

• OpenVMS でのジョブの名前付けの変更

  OpenVMS では、JOB コマンドでプロセス名を指定できます。このプロセス名が既に存在している場合、JOB コマンドによって <SYSTEM> エラーがスローされ、その結果、スタック・ダンプ・ログ (CERRSAVE-pid.LOG ファイル) も作成されます。このバージョン以降、エラーは、<INVALID ARGUMENT> エラーに変更され、ログ・ファイルは作成されなくなりました。

  これは、特定の戻りコードをチェックするアプリケーションに対して互換性のない変更です。

• Java 依存機能の利用不可

  今回のリリースでは、Java の最小必要バージョンは 1.7 であると規定しています。OpenVMS 向けの最新の Java リリースは、バージョン 1.6 であるため、Java 仮想マシン (JVM) へのアクセスに依存するすべての機能 (Zen レポートなど) は使用できなくなりました。

Mac OS X

インターシステムズでは、GCC の使用から Clang/LLVM への Apple の切り替えに従っています。ただし、どの C++ 標準ライブラリを使用する必要があるのかは明白ではありません。 そこで Caché では、以下の 2 つのバージョンの使用をサポートしています。

• libc++ – LLVM のより新しい C++11 互換バージョン

• libstdc++ – GNU バージョン

アプリケーションでは同じプログラムで両方のバージョンを使用できますが、それらを組み合わせることはできません。つまり、一方から他方の関数に std::string を渡すことはできません。Caché はカスタム char 型を使用するため、明示的に古いほうの GNU libstdc++ が使用されます。

ODBC とリンクする C++ ユーザまたは ObjectiveCache を使用する Objective-C ユーザにとって相違点はありませんが、C++ バインディング・ユーザは、std:: ネームスペース (std::string など) のクラスを処理する C++ バインディング API を使用する場合は、それらのビルド・フラグに “-stdlib=libstdc++” を追加する必要が生じることもあります。

%SYS.GSIZE から %GSIZE への名前の変更

%SYS.GSIZE を呼び出していたアプリケーションは、元の名前である %GSIZE を呼び出すように戻し、再びそれを CACHELIB の一部とする必要があります。データベースに対する特権を持たないユーザには、どのグローバルが存在しているかや、そのグローバルのサイズを確認できないようにする必要があります。

文内のコメントの処理の変更

次の 2 つの文について考えてみましょう。

          _________A________      _________B________

Line 1    If (i = 1) {}           If (i = 1) {}
Line 2    ElseIf (i = 2) {}       ElseIf (i = 2) {}
Line 3    // comment              ;;  comment
Line 4    Else Set I = 5          Else Set I = 5

“A” 文のシーケンスは不正であり、コンパイルされません。それは、それに Caché IF...ELSEIF 文とそれに続くレガシー ELSE 文が含まれているためです。A の行 3 にあるコメントは無視されるため、Caché IF 構文を従来の行型 IF 構文と組み合わせることは不正です。

今回のリリースより前は、“B” シーケンスはコンパイルされました。それは行 3 の “;;” コメントが Caché IF 文の構文分析を終了させており、それによって従来の ELSE 構文が正当であるとして受け入れられたためです。

現在は、“;;” コメントは終了括弧の後に受け入れられ、“B” 文シーケンスは “A” シーケンスと同様に分析されます。 これは、現在は、コンパイルされると構文エラーが生成されます。

クラスの削除

以前のバージョンに存在していた以下のクラスは、このリリースで削除されています。

• %CSP.UI.Portal — UsersParameters

• %CSP.UI.Portal.Dialog — DatabaseWizardEMS、ServiceConnections

• %CSP.UI.System — AuditPane、AuditSearchPane、ManageAuditPane

• %DeepSee.DomainExpert.components — MetadataValues

• %Net.Remote.Java — JDBCGateway

• %SYS — Monitor

• %iKnow.Classification — ClassifierProjection、LinearBuilder、NaiveBayesBuilder

• %iKnow.Classification.Definition — Term、Transformation

• %iKnow.Compiler — LexrepIdeographicStateOutputFunction、MetadataTable、PreprocessOutputFunction

• %iKnow.Objects.tfidf — MetadataAnalyzer

• %iKnow.Queries — EquivAPI

• %iKnow.UI — ITablesLoadingWizard

• %iKnow.UI.Dialog — Classifier

• %iKnow.ont — SourceMatches、TableGenerator、TableManager

• SYS — Volume

• Security — Common

クラス・コンポーネントの削除

このバージョンでは、以下のクラス・コンポーネントが、以前に存在していたクラスから移動または削除されています。

メソッド返り値の変更

今回のバージョンの Caché では、以下のメソッド返り値が変更されました。

• %iKnow.Utils.MaintenanceAPI — BlacklistContainsElement

• %iKnow.Utils.MaintenanceQAPI — BlacklistContainsElement

• %iKnow.Utils.MaintenanceWSAPI — BlacklistContainsElement

• SYS.Agent — VerifyConnection

メソッド・シグニチャの変更

今回のバージョンの Caché では、以下のメソッドのシグニチャが変更されました。

##class(%Library.%File).ParentDirectory() の動作の変更

今回のリリースでは、##class(%Library.%File).ParentDirectory() が変更され、それにディレクトリ名ではなくファイル名を指定すると “” が返されるようになりました。 以前は、呼び出し元の親ディレクトリが返され、混乱を招きやすくなっていました。

%Net.HttpRequest でのすべてのタイプに対する charset 値の処理

%Net.HttpRequestOpens in a new tab クラスでは、Content-Type が “text/” ではない場合でも HTTP 応答の CharSet 値が処理されるようになりました。これにより、“utf-8” 文字セットが指定されている場合であってもタイプ “application/json” を適切にデコードできます。また、RFC2616 によれば、テキスト・コンテンツのみに文字セットを適用するという制約はありません。

エラー後のタスクの続行の可能化

今回のリリースでは、タスクに SuspendOnError という新しいプロパティがあります。以前は、すべてのタスクが、エラー・ステータスが返されると中断されていました。現在は、既定でタスクはエラー後に再スケジュールされ、続行されるようになりました。従来の動作に戻すには、管理ポータルまたは ^TASKMGR のいずれかで SuspendOnError に “Yes” を設定します。

$SYSTEM.Lock.ReturnCode() の新しい戻り値

この変更により、$SYSTEM.Lock.ReturnCode() メソッドに新しい戻りコードが追加されました。すでにロックがエスカレートされていることを示す値の 4 を返すことができるようになりました。2 の値がロック・コマンドによってロック・エスカレーションが開始されたことを示すのに対し、この新しい値は、前のロック・コマンドでロック・ノードがエスカレート済みであることを示します。

シリアル・クラスでの再帰的プロパティ・タイプの明示的不正

シリアル・クラスのプロパティのタイプは再帰的にすることはできません。つまり、型クラスをコンテナ・クラスにしたり、そのコンテナ・クラスのプライマリ・スーパー・クラスまたはサブクラスにすることはできません。例えば、タイプが Sample.Address であるプロパティを Sample.Address で定義することは無効です。

このモデルは以前は実行時に機能していなかったため、この変更により大きな問題は発生しません。 Caché では、再帰的シリアル・タイプの SQL プロジェクションをサポートしたことはありません。以前のバージョンではそのようなクラスが正常にコンパイルされていましたが、この変更により、コンパイル時に新しいエラーが報告されるようになりました。

DataType クラスでの最適化されたメソッド呼び出しの処理の修正

今回のリリースでは、ターゲット・メソッドがローカル・クラスと宣言されたデータ型クラスの両方で定義されている場合に、“DO ..otherMethod()” 形式のメソッド呼び出しの解決で発生するエラーが修正されました。

大まかに以下のように定義されているデータ型クラスを考えてみましょう。

Class User.DataType Extends %String
{
    Parameter PARAM = "HELLO";

    ClassMethod someMethod()
    {
        Write ..#PARAM,! 
        Do ..otherMethod()
    }

    ClassMethod otherMethod()
    {
        Write ..#PARAM,!
    }
}

これには、“HELLO” の既定値で定義されているパラメータと、単にこのパラメータ値を書き出す otherMethod を呼び出すクラスメソッド (someMethod) があります。

ここで、このデータ型クラスを使用する標準クラスを考えてみましょう。

Class User.User 
Extends %RegisteredObject 
{
    Property Prop As DataType(PARAM = "MYVAL");
}

以前のリリースでは、以下の文のシーケンスによって

SET A = ##class(User).%New()
DO A.PropsomeMethod()

以下のものが表示されます。

MYVAL
HELLO

これは誤りです。それは、これは MYVAL を 2 回書き出すはずであるからです。ただし、“Do ..otherMethod()” の正規化は、ローカルに宣言されている PropsomeMethod メンバ・メソッドを呼び出すのではなく、User.DataType クラス自体を呼び出していました。

今回のリリースでは、この呼び出しのコンパイルは、適切にローカル・メンバ・メソッドを呼び出すようになっており、コンパイル済みコードを実行すると、本来あるべきとおりに MYVAL が 2 回出力されます。これにより、同じクラス・コンテキストにあるため、クラスメソッド・メンバ・メソッドは、異なるプライベート・クラス・メソッドを呼び出すことも可能になります。ただし、これは、現在ではエラーを生成します。

既存の動作が必要とされることは少ないですが、ローカル・メソッドではなくメンバ・クラスのメソッドを呼び出すことが必要なこともあります。これを行うには、“Do ..otherMethod()” を “Do ##class(User.DataType).otherMethod()” に置き換えると、従来と同様に動作します。

作業キュー処理の簡素化

今回のリリースでは、クラス・コンパイラが SignalAll 関数を使用してそのワーカ・ジョブに信号を送信することはなくなりました。それは、使用率の高いシステムでは、一部のワーカ・ジョブは現在のコンパイルに関与していない可能性があるためです。今回のリリースでは、同じ理由で StopWorkers 呼び出しも削除されています。

Caché の Objective C バインディングでの新しいランタイムの使用

Objective-C の新しいランタイムでは、Caché での以下の変更が必要となっています。

ISCConnection を作成する新しい方法は以下のとおりです。

ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" user:@"sys" password:@"system"];

および、安全な接続のためには以下のようにします。

ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" principal:@"principal" level:1];

ISCDatabase を作成する新しい方法は以下のとおりです。

ISCDatabase* database = [ISCDatabase databaseWithConnection:conn];

ここで、conn は、前に確立された接続です。

接続プールを設定するための新しいメソッドは以下のとおりです。

ISCConnectionPool* pool = [ISCConnectionPool pool];

CacheProvider のシステム・クラスのコード生成の削除

以前のリリースでは、.NET 用の生成されたプロキシ・クラスには、実際はクライアントからの使用を意図していない多数の API が含まれていました (例えば、ODBCToLogical および LogicalToODBC の変換)。この変更により、生成されたコードからこれらの API を削除する方法が追加されました。dotnet_generator には、-skip-system-apis (true|false) オプションが含まれるようになりました。これを true (既定値) に設定するとユーザの API のみが生成され、それにより、生成されたコードは以前の 3 分の 1 の大きさになります。

オブジェクト・プロパティの型指定コレクションのサポート

今回のリリースでは、Caché Objectscript オブジェクトのグループを、型のコレクションとして投影できます。例えば、型 T の %Library.ListOfObjects として定義されたクラス・プロパティは、CacheListOfObjects<T> として投影されます。同様に、T の %Library.ArrayOfObjects は CacheArrayOfObjects<T> として投影されます。この変更により、コレクションの投影に関連する大部分のキャストが不要になります。

この変更により、ListOfObjects.OpenAllObjects() の再帰バージョンも非推奨になりました。それは、現在は、生成されたコードには CacheListOfObjects<T> または CacheArrayOfObjects<T> が必要であるのに対し、この呼び出しによって、強制的にクライアントがサーバ・オブジェクトの CacheListOfObects または CacheArrayOfObjects の汎用バージョン (テンプレートではない) をインスタンス化する可能性があるためです。

CacheProvider による For Open() および OpenId() のオーバーロードされたメソッドの追加

以下のようなコードがある場合、

Prop = obj.Property
...
Prop.Close()

これは、プロパティをアンスウィズルすることを意図していましたが、現在では、サーバ上の値が null でなくても後続の obj.Property の呼び出しによって null 値が返されます。これは、obj がプロパティを所有しており、obj が閉じるときにそのプロパティが自動的に閉じるためです。 これを実現する適切な方法は、新しい UnswizzleProperty(<PropertyName>) メソッドの呼び出しを使用することです。

CacheADOConnection をパブリックにして ADO.NET を直接使用

CacheConnection は、すべての ADO.Net 機能を提供する CacheADOConnection クラスから継承します。 CacheConnection で、アプリケーションは同じ接続を介して ADO と DotNet Object バインディングの両方を使用できます。 これは多くのアプリケーションにとって役立ちますが、サーバへの追加のメッセージおよびプロバイダ内の内部オブジェクトの作成という点ではオーバーヘッドが追加されます。

XEP および Entity Framework 接続はそれぞれ、CacheADOConnection とそれが提供する機能にのみ依存しています。 DbConnection は、ADO.Net の DbFactory 接続に使用される一般的な方法であり、CacheADOConnection 内で完全にサポートされています。 これらの汎用 ADO API を使用する場合、CacheConnection オブジェクトによって別の値は追加されず、オーバーヘッドのみが追加されます。

この変更により、CacheConnection は引き続き従来どおり機能しますが、ADO アプリケーションは、CacheProvider のオブジェクト・バインディング・サイドを使用しない場合に CacheADOConnection を直接使用できます。 さらに、CacheFactory は少ないオーバーヘッドで CacheADOConnection オブジェクトを返します。 ADO 機能は引き続き、CacheConnection と CacheADOConnection のいずれでも機能しますが、ユーザがそれらのアプリケーションを変更する必要はありません。

いくつかの CacheConection のパブリック API は CacheADOConnection には存在しません。 必要な ADO.Net API はすべて CacheADOConnection 内に含まれていますが、アプリケーション・ライターは CacheProvider のオブジェクト・サイドによって提供される混合 API を使用した場合もあります。 その場合、引き続き、以前どおりに CacheConnection クラスを使用できます。

$LIST コンテンツが含まれているストリームの $LIST の OID の置換

今回のバージョンから、SQL を介してストリーム・フィールドに $LIST 値を格納できるようになりました。この変更により、バイナリ・データが $LIST 値に似ていた (つまり、$LISTVALID(value) が True であった) 場合にバイナリ・ストリーム・フィールドへのバイナリ・データの挿入が失敗する可能性があった問題も修正されました。

以前のバージョンでは、$LIST 値がストリーム値として挿入または更新された場合、Caché では $LIST 値がターゲット・ストリームにコピーされた別のストリームの OID であると想定されていました。 これは、既定では非外部テーブルのストリーム・フィールドを含む select クエリでは、そのストリーム・オブジェクトの OID が返されるためです。 別のストリーム・フィールドから選択した値を使用してストリーム・フィールドの値に挿入するか、またはストリーム・フィールドの値を更新する必要があるアプリケーションは、そのストリーム OID を開いてストリーム値をコピーするのみでした。

現在は、$LIST 値である値を持つストリーム・フィールドの SQL INSERT または UPDATE は、$LIST 値を、新しいストリームの値のソース・ストリームの OID として処理しなくなりました。 ソース・ストリームを開き、ソース・ストリームの OREF の値を使用してフィールドを挿入または更新する必要があります。これは、アプリケーションがストリーム・ソースの OID を持つストリーム・フィールドを挿入または更新しようとする場合の下位互換性を提供します。 互換性の問題は、ストリーム値を模倣したバイナリ・データを挿入したり、$LIST データをストリームに格納するために必ず発生します。

FOR SOME 述語でのテーブルを囲む括弧の必要性

ほとんど使用されない FOR SOME 述語の構文が変更され、Caché SQL 構文でのあいまいさが排除されました。以前は、述語の構文は次のとおりでした。

FOR SOME <tables> (<search condition> ...)

現在は、次のように表す必要があります。

FOR SOME (<tables>) (<search condition> ...)

従来の FOR SOME <tables> 構文を使用しているアプリケーションは、括弧を追加する必要があります。

新しい SQL システム特権

このバージョンでは、ネームスペース・レベルごとにユーザまたはロールに割り当てることができる新しい一般的な SQL 特権が 4 つあります。

• %NOCHECK — ユーザは %NOCHECK を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。

• %NOTRIGGER — ユーザは %NOTRIGGER を指定して、INSERT、UPDATE または DELETE コマンドを実行できるようになります。

• %NOINDEX — ユーザは %NOINDEX を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。

• %NOLOCK — ユーザは %NOLOCK を指定して INSERT、UPDATE または DELETE コマンドを実行できるようになります。

これらの特権は、INSERT、UPDATE、または DELETE 文の制限節でのそれぞれのキーワードの使用にのみ適用されます。 述語条件の前にある %NOINDEX の使用には適用されません。他の SQL 特権と同様に、これは ODBC、JDBC、%SQL.StatementOpens in a new tab、および %Library.ResultSetOpens in a new tab を介してのみ適用されます。 文を準備するときに制限節を使用するには、適切な特権を持っている必要があります。

TRUNCATE TABLE <tablename> は、%NOTRIGGER 動作によりテーブルからの行の削除を実行するため、TRUNCATE TABLE <tablename> の実行にも %NOTRIGGER 特権が必要になりました。

<Column>=<Constant> 条件の複数の JOIN があるクエリの修正

今回のリリースには、以下のようなクエリに対する修正が含まれています。

SELECT t . test_code 
FROM test . person p , test . test_result t 
WHERE p . hospital_id = ? 
AND    p . person_id = ? 
AND    t . hospital_id = p . hospital_id 
AND    t . person_id = p . person_id

ここには、以下があります。

• 2 つ以上の結合条件を持つ 2 つのテーブル間の結合があります。

• さらに、そのような結合ごとに、結合の列の 1 つに <column>=<constant> 条件もあります。

従来のリリースでは、SQL パーサによって、そのような要求ごとに不正なクエリ・プランが生成されました。そのエラーは、今回のリリースで修正されました。

タイムスタンプを使用したクエリ処理の修正

今回のリリースより前は、以下のようなクエリを実行するアプリケーションの場合：

• “TimeStampField > CURRENT_TIMESTAMP” のような WHERE 節にフィルタが含まれている。

• TimeStampField が一般的な %Library.TimeStampOpens in a new tab 値ではない。

• TimeStampField のクラス・インスタンスにより、LogicalToTimeStamp および TimeStampToLogical メソッドが実装され、その論理形式が %TimeStampOpens in a new tab 論理形式に変換される。

クエリから不正な結果が得られることがありました。このエラーは、今回のリリースで修正されました。

クエリ・プランの変更

今回のリリースでは、いくつかの条件が他の条件を暗黙的に示す場合を考慮した向上した選択機能により、クエリ・プロセッサがより正確なプランを作成するようになりました。この典型的な例は、次のようなクエリです。

SELECT *
FROM T1, T2 
WHERE T1.k = T2.k AND T1.k > 5

この場合、オプティマイザによって T2.k > 5 も真であることが導出されます。また、条件が T1.k > 5、T1.k = T2.k、T2.k >5 の順序でテストされる場合、最後の条件は冗長であり、選択がさらに追加されることはありません。同様に、条件のテストの順序が、T2.k > 5、T1.k = T2.k、T1.k > 5 である場合、似たような状況になります。ただし、条件のテストの順序が T1.k > 5、T2.k > 5、T1.k=T2.k である場合、最後の条件はテストする必要はあるものの、他のテスト順序の場合よりも追加される選択が少なくなります。以前のリリースでは、この最後のケースで選択を適切に処理する方法がありませんでした。

この変更の結果は、プランの変更が多少一般的になり、大部分は向上しますが、劣化するものもあります。

SQL 予約語の更新

以下の語は、以前のリリースの Caché SQL で予約されていましたが、$SYSTEM.SQL.IsReservedWord() によってそのように報告されませんでした。

%CLASSNAME, %ID, %KEY, %MINUS, %MVR, %ODBCIN, %PLUS, 
%RUNTIMEIN, %RUNTIMEOUT, %SQLSTRING, %SQLUPPER, 
%TABLENAME, %TRUNCATE, %VALUE, %VID

今回のリリースでは、それらがリストに追加され、予約語としての CATALOG が削除されています。

DELETE %NOINDEX の変更

以前のリリースでは、SQL 指示文 DELETE %NOINDEX は常に空命令でした。今回のリリースから、削除された行に定義されたインデックス・エントリは削除されなくなりした。

%SYS.PTools.UtilResults の変更

以前は、管理ポータルの [インデックス分析] ページでは、ラジオ・ボタンをクリックするたびに、異なるオプションが再計算されました。 今後は、テーブルに 4 つのすべてのオプションに対する結果が保持でき、新しい SQL 文が収集された場合にのみデータがクリアされます。 オプションを初めてクリックしたときはシステムによってデータが生成されますが、それ以降は単にそれが再表示されます。

アプリケーションがデータをクエリしている場合、新しいプロパティ OptionName の値を設定することで返される結果を制限できるようになりました。 設定可能な 4 つの値は次のとおりです。

• “IU” — インデックス使用

• “TS” — テーブル・スキャン

• “TI” — テーブル・インデックス

• “JI” — 結合インデックス

接続が指定された場合のチェックの強化

リンクされたテーブルがクラスの一部として定義されている場合、SQL プロセッサによって、テーブルへの接続の確立に必要なすべての値が指定されていることもチェックされるようになりました。これに該当しない場合、SQL エラー -162 (“SQL Connection is not defined”) が生成されます。

スペイン語ロケールの既定の照合における変更

Spanish4 が、ローカル配列および新規データベースのスペイン語ロケール (espw、esp8、esi8、esw8) の現在の既定の照合になりました。この新しい照合では、大文字と小文字が別々に順序付けされており、文字は以下の順序に従います。

a, á, à, b, c, ç, d, e, é, è, f, g, h, i, í, j, k, l

m, n, ñ, o, ó, ò, p, q, r, s, t, u, ú, ü, v, w, x, y, z

新しいマルタ語照合の作成

マルタ語 Unicode ロケール (mltw) および照合 (Maltese1) は、今回のリリースで使用可能になりました。この照合の特性は以下のとおりです。

• 大文字小文字は別々に順序付けされ、すべての大文字はすべての小文字より前にあります。

• 主要な順序付けは以下のとおりです (小文字の場合。大文字も同様です)。

  a b ċ c d e f ġ g għ h ħ i ie j k l m n o p q r s t u v w x  z ż
  

• 上記のドット付きの文字 (c、g、および z) は、ドットのないバージョンと同等ですが、同じものを除いてそれらはすべて、ドットのない同じ文字の前に照合されます。

• “g&hstrok;” は、“g” と “h” の間の 1 つの文字として照合されます。

• “ie” は、“i” と “j” の間の 1 つの文字として照合されます。

• “&hstrok;” は “h” と同等ですが、後で照合されます。

マルタ語アルファベットにはありませんが、ラテン文字 “c” と “y” は、英語でのそれぞれの位置で照合されます。マルタ語にない他のすべてのアクセント記号付き文字 (“á”、“é”、“ã” など) はアルファベットの後に照合されます (Caché 標準と同じ)。

新しい照合 Maltese2 マルタ語 Unicode ロケールで使用可能です。これには、Maltese1 と同じエンコードがありますが、合字 “għ” および “ie” は含まれていません。

Unicode ↔ CP437、CP850、および CP852 の新しい入出力変換テーブル

今回のリリースには、Unicode とロケール CP437、CP850 および CP852 との間の新しい入出力変換テーブルが含まれています。これらのテーブルは、8 ビットバージョンが Latin1 または Latin2 を基盤としている Unicode ロケールに追加されました。 具体的には、新しいテーブルは、以下の Unicode ロケールにあります。

• csyw – チェコ語、チェコ共和国

• danw – デンマーク語、デンマーク

• deuw – ドイツ語、ドイツ

• engw – 英語、英国

• enuw – 英語、米国

• espw – スペイン語、スペイン

• finw – フィンランド語、フィンランド

• fraw – フランス語、フランス

• hunw – ハンガリー語、ハンガリー

• itaw – イタリア語、イタリア

• nldw – オランダ語、オランダ

• plkw – ポーランド語、ポーランド

• ptbw – ポルトガル語、ブラジル

いくつかのロケール用のアップグレードされた照合

以下の 8 ビット・ロケールの既定の照合は、以前のバージョンにおける小さな問題 (スペイン語の “ll” およびドイツ語の “ss” のように 1 つの文字として照合されるいくつかの文字シーケンスを考慮できないなど) を修正する新しいバージョンにアップグレードされました。

• csw8：Czech2/CP1250 → Czech3

• huw8：Hungarian1/CP1250 →Hungarian2

• esw8：Spanish2/CP1252 → Spanish3

• esi8：Spanish2/Latin9 → Spanish3

German4 ロケールの削除

German4 ロケールは、German3 と機能的に同等であると判明したため、今回のリリースでシステムから削除されました。

ロシア語ロケールの磁気テープ変換テーブルの変更

ロシア語 Unicode ロケール (rusw) の磁気テープ・デバイス用の既定の変換が、RAW から UTF8 に変更されました。これにより、テープへのバックアップのラベルに、さらに修正することなくキリル文字を含めることが可能になりました。

Latin9 ↔ Unicode の変換テーブルの更新

Latin9 と Unicode エンコード (UnicodeBig、UnicodeLittle、および UTF8) の 1 つとの間の変換を行うテーブルで、誤って $CHAR(128) から U+20AC (ユーロ記号) にマップされていました。このマッピングは、Windows CP テーブルの多くで使用されていますが、ユーロ記号が $CHAR(164) である Latin9 では使用されていません。これらの Latin9 変換テーブルでは、$CHAR(128) は変更されずに通過します。

新しい JSON 変換テーブルの追加

今回のリリースでは、2 つの新しい NLS 変換、JSON と JSONML が追加されています。それらは、それぞれ JS と JSML に類似していますが、出力側で以下の違いがあります。

• コード 0 ～ 7、11 および 14 ～ 31 を持つ文字は \uXXXX としてエスケープされます。

• コード 39 および 47 を持つ文字は、変更されずに通過します。

Unicode LINE SEPARATOR および PARAGRAPH SEPARATOR の処理の更新

Unicode システムでは、例えば、$ZCONVERT で使用される場合、JavaScript 変換 (JS、JSON、JSML、および JSONML) の 1 つを通過するときに、文字 LINE SEPARATOR ($CHAR(8232) = U+2028) および PARAGRAPH SEPARATOR ($CHAR(8233) = U+2029) はそれぞれ "\u2028" および "\u2029" としてエスケープされます。

コード化されたディクショナリ用語の修正

ディクショナリ用語が複数の要素で構成されており、それらに (複合用語を追加するための形式の “コード化された” 記述の使用を介して) 形式要素と非形式要素の両方が含まれている場合、ディクショナリが最適化されていると、内部データ構造にディクショナリ用語が適切に保存されませんでした。これにより、形式部分と非形式部分が別々に照合されることになり、同じ CRC またはパス上の同じ用語が別個の一致になる可能性がありました。

高度な “コード化” 記述機能を使用して混合する用語 (形式ベースの要素と非形式ベースの要素の両方から成る) を挿入した場合、この修正を有効にするには、これらのディクショナリ用語を再作成する必要があります。

(以前は実験的であった) PMML モデリングの変更

2014.1 の実験的機能としてモデル構築機能が追加されました。これを活用するアプリケーションを構築したユーザは、PMML モデルを生成するためのいくつかのヘルパー・メソッドがビルダ・クラスから PMML モデル・クラスに移動したことを見つけることになります。さらに、

• 多様な演算子によって “途中で行われていた” PMML の生成が、適切な場所で行われるようになり、実行されるすべての演算子を表す PMML ファイルになります。

• モデリング・シーケンスの一部として任意のコードを実行する “Call” 演算子が存在するようになりました。

• “TypeColumn” プロパティが Attributes 構成要素に追加され、データ型の属性ごとの指定が可能になりました。

• Sequence 処理の一部として新しい行をインスタンス化する場合、PMML モデルは明示的にすべての属性を 0 に設定することはなくなりますが、初期値の入力は InitialExpressions に依存します (%IntegerOpens in a new tab および TableGenerator 処理の %DoubleOpens in a new tab 列の場合は 0)。

• 新しい “InsertOnly” プロパティが Sequence 構成要素に存在し、既にデータが含まれているテーブルに追加できます。つまり、データの一部が iKnow ドメインから、他の部分が他のソース (メタデータ) から直接取得できる場合のように、個別の Sequence 処理を使用して、同じデータ・セットの別々の列に入力できます。

%Net.HttpRequest In %XML.Sax.Parser の既定のポート値の明示的な設定

今回のリリースでは、%Net.HttpRequestOpens in a new tab によって %XML.SAX.ParserOpens in a new tab の既定のポート値が明示的に設定されます。以前のリリースでは、既定で、その %Net.HttpRequestOpens in a new tab オブジェクトを使用した最後の要求のポートが使用されました。

文字ストリーム入力 LineTerminator Implicitly の $CHAR(10) への暗黙的設定

今回のリリースでは、XMLSTREAMMODE="block" (既定値) である場合、XML ドキュメントからインポートされる文字ストリームの LineTerminator が暗黙的に $CHAR(10) に設定されます。 これにより、インポートが、従来の改行シーケンス ($CHAR(10)、$CHAR(13)、$CHAR(13,10)) と互換性を持つようになります。

ULTIMATE エミュレーションでの STR.ONEISONE の既定の設定の変更

MultiValue BASIC プログラムをコンパイルする場合、従来の IN2 または ULTIMATE システムのエミュレーションを除いて $OPTIONS STR.ONEISONE フラグは既定で OFF になります。 以前は、STR.ONEISONE は、従来の IN2 システムの場合にのみ既定で ON になりました。 コンパイル時のエミュレーション設定のみがこの既定値に影響を与え、実行時の CEMU 設定の変更によって、コンパイル時のエミュレーション設定がオーバーライドされることはありません。

STR.ONEISONE フラグは、$OPTIONS フラグである IN2.SUBSTR および T のエイリアスです。これらの 3 つの $OPTIONS フラグによって、フォーム StringVar[N] の部分文字列参照の動作が変更されます。 これらのフラグのいずれか 1 つを使用する場合、StringVar[N] への参照は、変数 StringVar に含まれている文字列内の位置 N にある 1 つの文字への参照です。 これらのフラグのいずれも使用しない場合、StringVar[N] への参照は、位置 N から始まり、文字列変数 StringVar のコンテンツの終わりまでの文字列文字すべてへの参照です。

CEMU ULTIMATE コンパイル時設定 (または MV BASIC ソース・ルーチンの $OPTIONS ULTIMATE) を使用し、STR.ONEISONE フラグがオフになっていることに依存する場合、明示的に以下の文を含めることが必要になりました。

  $OPTIONS -STR.ONEISONE

上記の文を、この変更によって影響を受ける MV BASIC ソース・プログラムに含めます。

Base64 エンコード XML からの既定としての改行の削除

このリリースから、既定では、タイプ %BinaryOpens in a new tab または %xsd.base64BinaryOpens in a new tab のすべてのプロパティの base64 エンコード XML 出力から改行が削除されるようになりました。改行を行うことを既定とするには、以下の手順を実行します。

• XMLExport で、“base64linebreaks” を形式引数に追加します。

• %XML.WriterOpens in a new tab で、BaseLineBreaks プロパティを 1 に設定します (既定値は 0 です)。

• SOAP Web サービスまたは Web クライアント・バイナリ出力について、Base64LineBreaks プロパティを 1 に設定するか、BASE64LINEBREAKS パラメータを 1 に設定します。 両方のパラメータを設定すると、プロパティによってパラメータがオーバーライドされます。

MultiValue プロセス・ロックの即座の解除

MultiValue プロセス・ロック (MVBASIC LOCK および UNLOCK コマンドで作成および解除される) は、トランザクションから独立していると想定されています。 ただし、以前のリリースでは、トランザクション中の UNLOCK コマンドでは、最も外側のトランザクションが終了するまでプロセス・ロックは解除されませんでした。 現在は、MV BASIC UNLOCK コマンドによって、アクティブなトランザクションがあるかどうかに関係なく、それに対応するプロセス・ロックが即座に解除されます。

UNLOCK コマンドでは最も外側のトランザクションが終了するまでプロセス・ロックは解除されないことに依存しているアプリケーションは、この動作の変更による影響を受けます。 以前に類似した動作を復元するための対応策は、プロセス・ロックの名前に関連するファイル名のダミー・ファイル上で取得されたファイル・ロックにプロセス・ロックを置き換えることです。 プロセス・ロックは、トランザクション内でも即座に解除されるようになりましたが、トランザクション内の FILEUNLOCK コマンドでは最も外側のトランザクションが終了するまでファイル・ロックの解除が遅延されます。

フィールド番号 0 を指定した WRITEV によるレコードの先頭への追加

以前のリリースでは、レコードの属性番号 0 に対する更新を指定する WRITEV 文の動作は未定義でした。今回のリリースから、MVBasic ランタイムが変更され、動的配列レコードの属性番号 0 に対する WRITEV によって、新しいデータがレコードの先頭に新しい属性として追加されます。 この新しいデータは、動的配列の先頭属性になり、前の属性はすべて位置が 1 つ上に移動します。 これは、動的配列変数の属性 0 に文字列値を割り当てることと類似しています。

ODBC 2.5 API の削除

以下の API は、Microsoft ドライバ・マネージャがバージョン 2.5 とバージョン 3.5 の両方を呼び出し中である場合のエラーに対処するために InterSystems ODBC 3.5 ドライバによってエクスポートされることはなくなりました。

• SQLAllocConnect

• SQLAllocEnv

• SQLAllocStmt

• SQLErrorW

• SQLFreeConnect

• SQLFreeEnv

• SQLSetParam

• SQLTransact

• SQLGetConnectOptionW

• SQLGetStmtOption

• SQLSetStmtOption

日付と時刻およびタイムスタンプのバージョン 3.5 ドライバでの既定の C タイプの変更

ODBC C タイプ SQL_C_DEFAULT (99) は SQLBindColumn の呼び出しで使用でき、ODBC ドライバによって、指定された SQL_TYPE に基づいて適切な C タイプが決定されます。 ODBC 3.5 標準では、日付、時刻、タイムスタンプの SQL_TYPES が、9、10、および 11 から 91、92、および 93 にそれぞれ変更されました。SQL_C_DEFAULT(99) が C タイプとして指定されている場合、Caché では内部で適切な C タイプを返す SetDefaultType(sql_type) が呼び出されます。

以前は、ODBC 3.5 バージョンの Intersystems ドライバの場合、Caché は値が 91、92、および 93 の日付、時刻、およびタイムスタンプについて SQL Types を検出せず、SQL_C_CHAR として C タイプを返しました。これにより、実行時にエラーが発生しました。 現在は、SetDefaultType(sql_type) は、それぞれ 91、92、および 93 の日付、時刻、およびタイムスタンプについて SQL_TYPES を検出し、対応する C タイプである SQL_C_TYPE_TIME、SQL_C_TYPE_DATE、SQL_C_TYPE_TIMESTAMP (91、92、93) を返すようになりました。

タイム・オフセットを基準にする NOW の再定義

DeepSee の時間レベルは、"timeOffset" 属性を使用した日付オフセットで構成できます。この機能については、ドキュメントで説明しています。この修正以前は、NOW という特殊なメンバの動作には不具合がありました。

年が “-6m” のオフセットで定義されているケースについて考えてみましょう。これは以下を意味します。

• 2014 = July 2013 to June 2014

• 2015 = July 2014 to June 2015

今回の明確化以前は、"NOW" の意味はオフセットに基づいて変化していました。したがって、同じ例について、DeepSee は NOW が 2014 年 7 月であると判断して、-6m オフセットを適用して 2014 年 1 月を取得し、-6m オフセットした年である 2014 年 1 月がどの年に属するのかについては、2014 年であると判断します。 要約すると、NOW を選択すると、現在の日付が属している期間が返されるようになりました。

この修正により、現在の日付が 2014 年 7 月である場合、年レベルは 2015 年が返されます。それは、2015 年の初めにマイナス 6 か月のオフセットを適用すると “NOW” は 2015 年の範囲内にあるためです。

計算メンバと計算メジャーとの区別の適用

MDX では、計算メジャーと、メジャーではない計算メンバとは区別されません。ただし、この区別を行うほうが実用的です。今回のリリースでは、DeepSee では、これらのアイテムはクロス結合に含まれている場合に区別されます。現在は、クロス結合で使用される 2 つのセットのうち、1 つのみにメジャー (またはメジャーのように動作するアイテム) を含めることができます。1 つのセット (または両方のセット) に、メンバ (またはメンバのように動作するアイテム) を含めることができます。このコンテキストでは、以下のようになります。

• 計算メンバは、AGGREGATE、SUM、MAX、MIN、AVG、または数値を返す他の関数を使用する場合、メジャーと見なされます。

• 計算メンバは、%OR を使用する場合、メンバと見なされます。

以前のリリースでは、以下のクエリが有効でした。

WITH  MEMBER [ColorD].[DEMO] AS 
'AGGREGATE({[COLORD].[H1].[FAVORITE COLOR].&[Blue],
[COLORD].[H1].[FAVORITE COLOR].&[Red],
[COLORD].[H1].[FAVORITE COLOR].&[Yellow]})' 
SELECT NONEMPTYCROSSJOIN([COLORD].[DEMO],[Measures].[Test Score]) ON 1 FROM [Patients]

今回のリリースでは、この同じクエリでエラーが発生します。

ERROR #5001: Two measures cannot be crossjoined

この変更の結果、すべての計算メンバを確認し、それらがどのように使用することを意図されているかを考慮する必要があります。計算メンバがメンバとして使用されることを意図されている場合、%OR を使用します。メジャーとして使用されることを意図されている場合、AGGREGATE または別の数値関数を使用します。また、NONEMPTYCROSSJOIN または CROSSJOIN を使用するクエリを確認し、2 つのメジャーを意図せずクロス結合していないことを確認します。

リスト・レベルの複数メンバを除外する場合のクエリの変更

今回のリリースでは、ユーザがリスト・レベルの複数のメンバを除外する場合、DeepSee によって以前とは異なるクエリが生成されます。この新しい形式のクエリは、ユーザがリスト・レベルの単一メンバを除外する場合に DeepSee によって生成されるクエリと一致しています。この変更は、DeepSee エンジンに対する変更ではなく、単にユーザが (アナライザまたはダッシュボードで) フィルタ・ドロップダウンと対話するときの DeepSee でのクエリの生成方法に対する変更です。

例えば、リスト・レベルである、SAMPLES 内の Diagnosis レベルについて考えてみましょう。以前のリリースでは、ユーザがこのレベルの asthma および CHD メンバを選択し、[除外] オプションをクリックした場合、DeepSee によってクエリに以下のフィルタが追加されました。

%FILTER EXCEPT([DIAGD].[H1].[DIAGNOSES].Members,{[DIAGD].[H1].[DIAGNOSES].&[asthma],[DIAGD].[H1].[DIAGNOSES].&[CHD]})

このフィルタによって、asthma の診断 "のみ" を持つ患者と、CHD の診断 "のみ" を持つ患者のレコードが削除されます。ピボット・テーブルで Diagnosis レベルを行として表示すると、結果は以下のようになります。

asthma のみを持つ患者は、このピボット・テーブルではどこにも含まれておらず、CHD のみの患者も同様です。このピボット・テーブルでは、asthma 行は、他の診断に "加えて" asthma の診断がある患者を表しています。同様に、CHD 行は、他の診断に "加えて" CHD の診断がある患者を表しています。これは有効な MDX クエリですが、ユーザが生成しようとしているクエリではありません。

今回のリリースでは、ユーザがこのレベルの asthma および CHD メンバを選択し、[除外] オプションをクリックした場合、DeepSee によってクエリに以下のフィルタが追加されるようになりました。

%FILTER ([DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT,[DIAGD].[H1].[DIAGNOSES].&[CHD].%NOT)

このフィルタでは、asthma 診断を持つ患者と CHD 診断を持つ患者のレコードが削除されます。ピボット・テーブルで Diagnosis レベルを行として表示すると、今回は結果が以下のようになります。

以前のリリースでは、DeepSee は、ユーザがリスト・レベルの "1 つの" メンバを除外する場合に %NOT 関数を使用していました。そして現在もこれを使用しています。例えば、ユーザが asthma を選択し、[除外] オプションをクリックすると、DeepSee によって以下のフィルタがクエリに追加されます。

%FILTER [DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT

このフィルタによって、asthma の診断を持つ患者のレコードが削除されます。

ゼロ・パディング数値のエクスポートの文字列への変更

今回のリリースから、DeepSee では、KPI のプロパティの format 属性を “%string%” として定義できるようになり、そのようなプロパティの Excel エクスポートはその形式に従ったものになりました。つまり、以下のようなプロパティ定義があるとすると、

<property name="EnfUnit" displayName="EnfUnit" columnNo="3" format="%string%"/>

現在は、形式 0008 の数値が、数値としてではなく文字列として Excel にエクスポートされるようになりました。

キューブ・レジストリでの名前の必要性

今回のバージョンから、キューブ・レジストリを初めてロードしたときにダイアログが開くようになりました。これにより、ユーザは、トップレベルのレジストリ全体の設定のオプションと共にレジストリ・ストレージに使用されるクラス名の入力を要求されます。以前のリリースでレジストリが作成されている場合、以下のように実行できます。

• 新しいアクティブ・レジストリ・クラスとして既定のクラス名 DeepSee.CubeManager.CubeRegistryDefinition を入力することで、既存のものを再度開く。または

• 任意の名前で新しいレジストリを定義し、以前の DeepSee.CubeManager.CubeRegistryDefinition の Registry XData ブロックのコンテンツをコピーする。

保存とタスク・スケジュールの関数の分離

この変更により、スケジュール・コードが %DeepSee.CubeManager.Utils:WriteToRegistry() の呼び出しから削除され、それが %DeepSee.CubeManager.Utils:ScheduleUpdaterTasks() に配置されます。 現在は、後者の戻り値によってタスク・スケジュールの成功のステータスを確認することが可能になりました。 この変更により、WriteToRegistry() はキューブ・レジストリの検証および保存のみを実行し、ScheduleUpdaterTasks() がスケジュール要件の計算と関連タスクへの結果のパラメータの通信を行います。

マルチパート要求ペイロードの個々のコンポーネント・ヘッダの解析の向上

以前のバージョンでは、個々のコンポーネントを保持している Caché ストリームに、ホストの形式で割り当てられた名前ではなく汎用 CSP ゲートウェイによって割り当てられた名前である “CONTENT” を使用して名前が付けられていました。

今回のリリースでは、マルチパート要求ペイロードの個々のコンポーネント・ヘッダの解析が向上しています。 ヘッダ行により多くのデータを含めることができ、個別のヘッダ行でさらなる処理が実行され、ペイロード (および関連する型情報) が正確に Caché に送信されるようになりました。

既定のテーブル幅の変更

今回のリリース以前は、テーブルの幅が指定されていない場合、Zen レポートによって “auto” の既定値が指定されました。現在は、新しい既定値である “100%” が指定されるようになりました。以前の既定値に依存しているレポートは、現在はそれを明示的に設定する必要があります。

コンポジット・アイテム内のテンプレートの処理

今回のリリースより前は、テンプレートがコンポジットに含まれている場合、それらは無視されました。 現在は、それらは定義されるようになりました。 これにより、レポート内に定義されているテンプレートとの競合が発生する可能性があります。

競合が発生した場合の対応策は、コンポジットまたはレポートのいずれかからテンプレートを削除し、1 つの場所でのみ定義されているようにすることです。 前はコンポジットではテンプレートがサポートされていなかったため、以前のレポートとコンポジットの組み合わせでそのような競合が発生した場合の最も簡単な修正方法は、それらをコンポジットから削除することです。

この発想は、現在はカスタム・クラスまたはコンポジットの XData に XSLT テンプレートまたは変数定義を含めることができ、それらはレポートで参照できるということです。 XData の生成ポイントは、クラスまたはコンポジットが含まれている場所ではないことに注意してください。 これは、テンプレートが XSLT ソースの最上位レベルで定義される必要があるためです。

Y 値が存在しない場合に xyChart でデータセットにポイントが含まれない

以前のリリースでは、y 値が欠落している場合、Caché によって y に 0 の値が割り当てられ、マーカ・ポイントが描画され、xyChart で接続線が定義されている場合は、そのマーカ・ポイントを通過する線が描画されます。 現在は、y 値が “” であるか、定義されていない場合、xyChart の (x,y) ペアはスキップされ、マーキング・ポイントは描画されません。

すべてのバッチ/コマンド・ファイルおよび Java コマンドの構成可能メモリのサポート

今回のリリースから、レポートを作成するための新しいバッチ・ファイルの要件が導入され、既定の最大メモリ・サイズ (-Xmx 512m) を受け入れるか、環境変数を指定することが必要になりました。 これより前は、サーバ・スクリプトにそのような引数が含まれていました。それは、メモリがマシン上の物理メモリの量に応じて割り当てられることを意味しています。 適切な方法は、メモリ・サイズの指定を適用することです。

さらに、以下の環境変数が定義されています。

• EXCELMEMSIZE、EXCELSERVERMEMSIZE

• FOPMEMSIZE、RENDERSERVERMEMSIZE

• PRINTSERVERMEMSIZE

• SAXMEMSIZE

• PDFMERGEMEMSIZE

これらは既定で 512m になります。 サーバの場合、既定値はマシン上の物理メモリの量によって決定されていましたが、これは適切でない方法であり、現在はサーバの既定値は 512m になりました。 このメモリ・サイズを大きくするには、環境変数を使用します。