Caché 2012.1

2KB データベースのサポート終了

2KB データベースのサポートが今回のリリースで終了することは、バージョン 2011.1 で告知していました。既存の 2KB データベースは、今回のリリースにアップグレードする前に、SYS.Database.Copy() を使用して 8KB 形式に変換しておく必要があります。

新しいインストールでは既定の GMHEAP の最小サイズが 22 MB に増加

今回のリリース以降、新しいインストールで一般メモリ・ヒープ (gmheap) に必要とされる最小サイズが 4 MB から 22 MB に増加されました。これは、最初の iKnow 言語テーブル en (英語) および es (スペイン語) のロードを可能にするためです。

アップグレード時に、gmheap に対して設定された値がインストーラによって次のように検証されます。

• gmheap に 21,184 KB よりも小さい値が設定されている場合、その値は元の値よりも大きい値に変更されます (元の値に 16,384 KB を加えた値、または 21,184 KB のいずれか大きいほうの値になります)。

• 値が 21,184 KB より大きい場合は、インストーラによって設定が変更されることはありません。その場合、管理者には gmheap の値をより大きく設定する他の理由があることが考えられますが、その新たに必要なメモリ量も新しい値の計算に入れる必要があります。

  また、この場合に、この値によって基本的な言語テーブルがロードできないと、Caché は cconsole.log に警告を生成し、正常に機能を低下させようとします。

アプリケーションで英語またはスペイン語以外の言語を利用する場合、希望する言語ごとに gmheap のサイズをさらに増やす必要があります。次のテーブルに、使用可能な言語モデルと増加量を示します。gmheap サイズが 21,184 KB を超えるものについては、英語およびスペイン語の各テーブルのサイズも加えられています。

最後に、サイトで iKnow 機能を一切使用しない場合、gmheap 値をアップグレード/インストール後に低く設定することもできます。この変更を有効にするには、Caché を再起動する必要があります。

ルートとしてではなく所有者ユーザ ID で実行される緊急モード

緊急モードの起動コードは、“cacheusr” ではなく所有者ユーザ ID で実行されるようになりました。これにより、CSP ポータルなどの特定のリソースを初期化する際の不要なエラーが生じなくなります。

グローバルのデフラグに %Admin_Manage が必要

今後、データベース内のグローバルをデフラグするには、%Admin_Manage ロールが必要になります。以前は、データベースへの書き込みアクセスしか必要ありませんでした。

^DATABASE 機能の対象がプライマリ以外のミラー・メンバに拡大

今回のリリース以降、空き容量の解放、圧縮、削除、デフラグに関する各種の ^DATABASE 機能は、ミラーリングされたデータベース上で、メンバの現在のロールに関係なくすべてのミラー・メンバから実行できるようになりました。以前は、ノード上でプライマリ・ミラー・メンバである場合しか実行できませんでした。

^DATABASE メニューの変更

今回のバージョンで、^DATABASE メニューに次のオプションが追加されました。

4)* Mirror Set Name:

このオプションの場所は次のメニュー項目の下です。

1)      Create a database

^DATABASE をスクリプトによって操作しているサイトは注意してください。

ライセンス適用の強化

今回のリリースでは、ライセンス制限の適用などのライセンスの管理機能が向上しています。

• ライセンスが CSP サーバ・プロセスから取得できない

  アプリケーションで $SYSTEM.License.Login() を (CSP ページ要求や SOAP 要求を処理する) CSP サーバ・プロセスから呼び出す場合、<FUNCTION> エラーが発生するため、%CSP.Session login を使用するように変更する必要があります。

• 管理ポータルの使用によるライセンスの消費

  システム管理ポータル・アプリケーションは、1 ライセンスを消費するようになりました。今後は、ライセンス使用の観点から、ターミナル接続を通じて Caché にログインしてから文字指向の管理/オペレーション・ユーティリティを実行する場合も、この機能にブラウザベースの管理ポータルからアクセスする場合も、違いはありません。

  正確なユーザ数に合わせてライセンス・キーのサイズが調整されて実行されるサイトがある場合、管理ポータルが使用され最後のライセンスが消費されてから、別のユーザが Caché にログインしようとすると、ライセンス制限を超過する問題が発生します。

• ライセンスのないリモート CSP 接続の禁止

  Caché では、有効なライセンス・キーがインストールされていない Caché インスタンスは、CSP アプリケーションをリモート・ホストに提供しないという規則が適用されるようになりました。今後は、有効なライセンス・キーがなければ、CSP アプリケーションにはローカル・マシン上のブラウザからしかアクセスできません。

• タスク・マネージャによって開始されたプロセスが Web アドオンが有効なライセンス・キーを消費

  タスク・マネージャによって開始されたプロセスは、Web アドオンとして 1 ライセンスを消費するようになります。

完全に独立したログイン Cookie 認証モード

今回のリリース以降、非認証モードとログイン Cookie 認証モードの両方が利用できるアプリケーションについては、ログイン Cookie が非認証モード前にチェックされるようになりました。以前のリリースでは、ログイン Cookie が使用可能な場合でも UnknownUser としてアプリケーションにログインすることができました。

64 ビット・システムにおけるフレーム・スタック・サイズの増加

今回のリリースで、64 ビット・プラットフォームにおいて、最近のリリースでのスタック使用量の増加に相当するフレーム・スタック・サイズが増加されました。現在のサイズは、64 KB を超えることがあります(32 ビット・プラットフォームのスタック・サイズは、既に以前のリリースで増加済みです)。これにより、今後プログラムを移行した場合に <FRAMESTACK> エラーが生じなくなります。

この変更の結果、64 ビット・プラットフォームに応じて、次のようにパーティションごとのメモリ使用量が増加します。

• Unicode ： 25,032 バイト

• 8 ビット ： 19,817 バイト

%Manager ロールに対する変更

今回のリリースで、%Manager ロールに %Admin_Journal:USE リソースが追加されました。

タスクの管理には新しいロールが必要になる

このリリースから、タスクの作成、変更、実行を行う場合は、%Admin_Task:USE リソースが必要になります。このリソースが USE 権限を持つ %Manager ロールに追加されたため、このロールを所有するユーザはタスクを管理することができます。

管理者が %Operator ロールに基づくロールを作成し、管理ポータルの [オペレータ] メニューへのアクセスに使用していた場合、管理者は、そのロールに %DB_CACHESYS:RW 特権が追加されるようにロールを変更する必要があります。また、このロールからタスクを管理する必要がある場合は、%Admin_Task:USE を追加する必要もあります。

DeepSee リソースの追加

今回のリリースで、システムに DeepSee で使用できる次のような新しいリソースが追加されました。

• %DeepSee_AnalyzerEdit - DeepSee アナライザへのフルアクセス権限を付与します。

• %DeepSee_Analyzer - DeepSee アナライザへの読み取り専用アクセス権限を付与します。

• %DeepSee_PortalEdit - DeepSee ユーザ・ポータルへのフルアクセス権限を付与します。

• %DeepSee_Portal - DeepSee ユーザ・ポータルへの読み取り専用アクセス権限を付与します。

• %DeepSee_ArchitectEdit - DeepSee アーキテクトへのフルアクセス権限を付与します。

• %DeepSee_Architect - DeepSee アーキテクトへの読み取り専用アクセス権限を付与します。

• %DeepSee_Admin - DeeepSee の構成設定およびセキュリティ設定へのアクセス権限を付与します。

%Admin_Task リソースの追加

今回のバージョンの Caché では、新しい %Admin_Task リソースが定義されます。タスクの作成、変更、実行を行う場合は、%Admin_Task:USE リソースが必要になります。

%Admin_Task:USE が %Manager ロールに追加されたため、このロールを所有するユーザはタスクを管理することができます。

既定では、このリソースは %Operator ロールには付与されません。このロールを持つユーザは、%Admin_Task:USE リソースがロールに追加されない限り、タスクを管理することはできません。ユーザが %Operator ロールに基づくロールを作成し、管理ポータルの [オペレータ] メニューへのアクセスに使用していた場合、そのロールに %DB_CACHESYS:RW 特権が追加されるようにロールを変更する必要があります。また、タスクを管理したい場合は、%Admin_Task:USE 特権も追加する必要があります。

最後に、タスクの作成時に、"タスクを実行するユーザ" をログイン・ユーザ以外のユーザに変更する場合、その操作には %Admin_Secure:USE 特権が必要です。

バックアップ・スクリプトの配布の廃止

“cbackup” および “cbackups” スクリプトは、UNIX® の配布およびインストール (RPM キットや DMG キットなど) から削除されました。

起動時のキーの有効化に関するダイアログの変更

Caché インスタンスの起動時に、データベース暗号化に使用される暗号化キー・ファイルの参照ができなくなりました。これにより、暗号化キー・ファイルへのアクセスを、キーの有効化に必要なパスワードの知識から分離することで、2 要素セキュリティが適用されます。

アップグレードおよびインストール時の USER データベースの処理における変更

インストール処理では、アップグレード時の USER データベースおよびネームスペースの設定の変更や、USER データベースおよびネームスペースの定義が存在しない場合はそれらの再作成が行われなくなりました。新しいインストールでは、あらゆるプラットフォーム上で USER データベースおよびネームスペースが既定で作成されます。

“server_user” 機能は Windows 上でのカスタム・インストールでは表示されなくなりましたが、Windows への新しいインストールで USER データベース・インストールを無効化することができます。そのためには、コマンドラインの使用、変換の生成、または MSI パッケージの変更のいずれかの方法で “server_user” 機能のインストールを無効化します。

UNIX 上の Apache の CSP ゲートウェイ・インストールに対する変更®

外部 Web サーバが既に CSP ゲートウェイに対して構成されている場合、UNIX® インストール・スクリプトによる外部 Web サーバ構成の更新は行われなくなりました。Web サーバが CSP ゲートウェイに対してにあらかじめ構成されていない場合は、新しい構成で共有モジュール・メカニズムが使用され、以前のバージョンでは既定で使用されていた CGI ベースのメカニズムは使用されません。この変更は、通常の UNIX® インストーラ、CSPInstall スタンドアロン CSP ゲートウェイ・インストール・スクリプト、および RPM や DMG のインストールに影響を及ぼします。

CSP ゲートウェイのインストール・プロセスでは、Web サーバが CSP ゲートウェイに対して構成済みであることが検出されると、Web サーバ構成は変更されません。最新の検出メカニズムでは、コメント文字 (#) で始まらない行に “/csp” 文字列がないか調べるために、Apache 構成ファイルの解析が行われます。インストーラによって Web サーバが既に CSP ゲートウェイに対して構成済みであることが検出されると、必要な再構成は手動で行う必要があることを示すメッセージが生成されます。ただし、CSP ゲートウェイのバイナリ・ファイルは必要に応じてアップグレードされます。

構成ファイルの変更

• STU パラメータの削除

  CPF ファイル内の STU=1 パラメータが削除されました。メンテナンスのためにシステムを起動するには、緊急起動オプションを使用してください。

  緊急起動は次のように拡張されています。

  • TASKMGR、シャドウイング、ミラーリング、(該当する場合は) Ensemble プロダクションは、いずれも起動されません。

  • ZSTU、%ZSTART、%ZSTOP、ZSHUTDOW は、システムの起動時にも停止時にも実行されません。

  • 緊急 ID を使用してログインするユーザ・プロセスは %ZSTART も %ZSTOP も実行しません。

• 2KB バッファ割り当ての再割り当て

  [config] セクションでは、空き容量が globals= 宣言内で 2KB バッファに割り当てられた場合、8 KB バッファと同じ量のメモリが 8 KB バッファに割り当てられた空き容量に追加され、2 KB の割り当ては無視されます。

  [Startup] セクションでは、DBSizesAllowed パラメータに 2KB バッファのエントリが含まれていましたが、これは削除されます。

• MirrorSet オプションの拡張

  [MirrorSetMembers] セクションには、新たに ConnectTo および MemberType パラメータが追加されました。各パラメータに指定できる値は、AgentAddress、AgentPort、ConnectsTo、ECPAddress、GUID、InstanceDirectory、MemberType、MirrorAddress、MirrorSSPort、Reserved です。

• SSL 認証のミラー・クライアント名の取得および保存方法の変更

  ミラーリングにおける SSL 識別フィールドの処理が変更されました。コンマをスラッシュに変換する必要や、比較のためにフィールドを並べ替える必要がなくなりました。この変更は、サブジェクト・フィールドのデータ内にスラッシュ (/) が含まれている場合に証明書を使用しようとするアプリケーションに影響を及ぼすことがあります。DN フィールドは、.cpf ファイルへの保存時に base64 でエンコードされるようになりました。これにより、コンマで区切られたフィールド内のデータに含まれるコンマによって問題が発生するのを回避できます。

  Note:

  この変更によって、フェイルオーバー・メンバにこの変更の対象とそうでないものが混在している場合に、相互運用上の問題が発生します。アップグレードに対しては混在構成がサポートされているのでそれが正しく機能しますが、混在構成がある場合、SSL を使用するようにミラーを再構成することはできません。ミラーが SSL を使用するよう構成済みの場合は、引き続き SSL が使用されます。SSL を有効にするには、すべてのフェイルオーバー・メンバが互換性のあるバージョンを実行している必要があります。

トルコ語ロケールへの Latin5 および CP1254 変換テーブルの追加

今回のリリースで、Latin5 (ISO-8859-9) および Windows CP1254 の入出力変換テーブルがトルコ語 Unicode ロケール (turw) に追加されます。

ジャーナル・エラー時のフリーズをオーバーライドするジャーナリングの停止

今回のリリース以降、ジャーナルの停止が、ジャーナル・エラー時にシステムをフリーズする設定をオーバーライドします。つまり、ジャーナル・エラー時にフリーズするよう設定されたシステム上で (cache.cpf で FreezeOnError = 1)、ジャーナルの停止が可能になり、その後、システムがフリーズすることがなくなります。

使用前の 8 ビット・ジャーナルの Unicode 変換

以前の 8 ビットでのリリースから今回リリースの Unicode バージョンにアップグレードする場合、2 つのステップを踏む必要があります。最初に、以前のバージョンを今リリースの 8 ビット・バージョンにアップグレードして、必要なジャーナル・ファイルを処理します。次に、この 8 ビット・バージョンを Unicode バージョンにアップグレードします。

ストリーム処理の改善

今回のバージョンには、Caché でのストリームの処理方法に対する大きな改善が含まれます。それらの改善には、バッファの不要なコピーの廃止、CacheTemp のより効果的な使用、ストリーム・ノードが保存される順序の改善などがあります。ストリームの負荷が高いアプリケーションに対するこれらの変更によって、1 秒あたりのストリームの処理数が 1,600 件から 2,400 件に向上しました。

Web サービス・セキュリティの高速化

以前のリリースでは、セキュリティ・ヘッダの生成にかかる時間が、メッセージ全体を生成する時間のかなりの部分 (平均的なメッセージで、全時間の 4 分の 3 程度) を占めていました。今回のバージョンでは、ヘッダの生成時間がおよそ 3 分の 2 短縮されたため、スループットが大幅に向上しました。

ECP ロールバックに対する変更

以前のバージョンでは、ECP ロールバックによってサービスがロールバックの終了まで抑制され、これに関与する時間は再設定するデータの量によって異なりました。今回のバージョンでは、ロールバックと通常の ECP サービスが、同時に処理できるようになりました。サービスが一時停止することはありません。

生成されたクエリの形式における変更

場合によっては、DeepSee アナライザが以前とは異なる形式の MDX クエリを生成することがあります。これにより、ピボット・テーブルに基づくスコアカードに影響が及び、スコアカードが機能しなくなるため、次の手順で再実装する必要があります。

影響を受けるクエリは、次のように作成されるピボット・テーブルのクエリです。

• 必要に応じて、任意の項目を [行] にドラッグ・アンド・ドロップする

• メンバ、レベル、またはディメンジョンを [列] にドラッグ・アンド・ドロップする

• 1 つのメジャーを [メジャー] にドラッグ・アンド・ドロップする

前回のリリースでは、この方法で作成したピボット・テーブルに、次の例のような MDX クエリが含まれていました。

SELECT NON EMPTY [Outlet].[H1].[Region].Members ON 0,
       NON EMPTY [Product].%TopMembers ON 1 
FROM [HoleFoods]
WHERE [Measures].[Amount Sold]

この形式のクエリの結果は、スコアカードに表示できます。

今回のリリースでは、同じ方法で作成したピボット・テーブルに、次の例のような MDX クエリが含まれます。

SELECT NON EMPTY NONEMPTYCROSSJOIN([Outlet].[H1].[Region].Members,{[Measures].[Amount Sold]}) ON 0,
       NON EMPTY [Product].%TopMembers ON 1 
FROM [HoleFoods]
WHERE [Measures].[Amount Sold]

このクエリには CROSSJOIN が含まれているため、スコアカードに表示できません。

前者の形式のクエリに依存する既存のスコアカードがある場合は、次の手順を実行してください。

1. 目的の MDX クエリに基づく KPI を作成します。

2. 以前に保存したピボット・テーブルの代わりに、その KPI をスコアカードのデータ・ソースとして使用します。

DeepSee インデックスの再構築

2012.1 で、生成済みディメンジョン・テーブルのインデックスが変更されました。この変更により、すべてのディメンジョン・テーブルのインデックスを再構築しない限り、クエリが機能しなくなる可能性があります。インデックスを再構築するには、DeepSee キューブが格納されている各ネームスペースで、ターミナルから次のコマンドを入力します。

Do ##class(%DeepSee.Utils).%BuildDimensionTableIndices("*")

Mac OS X

• libcache.dylib の名前の変更

  Mac OS X 10.7 (コード名 “Lion”) では、libcache.dylib という新しい共有ライブラリが導入されました。名前の競合を避けるため、Caché コールイン・ライブラリの名前が libisccache.dylib に変更されました。libcache.dylib にリンクされている既存のアプリケーションは、libisccache.dylib を使用するよう変更する必要があります。

• Kerberos 認証のキー・ファイル

  MacOS 10.7 上の Kerberos 認証は、Caché サービス・プリンシパルのキーを含む keytab ファイルが /etc/krb5.keytab ファイルに存在しない限り機能しません。その他すべてのプラットフォーム、および以前のバージョンの MacOS 上では、このファイルは <installdir>/mgr/cache.keytab である必要があります。Kerberos ライブラリから返される、この状態を示すエラーは次のとおりです。

  ERROR #956: Kerberos error: GSS-API error acquiring server credentials; 
  No credentials were supplied, or the credentials were unavailable or inaccessible.
  (00070000); unknown mech-code 0 for mech 1 2 840 113554 1 2 2 (00000000) 
  

UNIX® — ジョブ生成の高速化

ジョブを追加するために子プロセスを生成する場合、親プロセスで開かれているファイルを閉じる必要があります。このバージョンでは、Linux、HP-UX、および AIX でこの作業を行うために、より効率的な手段が使用されます。多数のファイルが開かれ、多数のジョブが生成される状況では、開かれているファイルの管理は、最高 1 桁分くらい早くなります。

OpenVMS — OpenVMS の Xerces および Xalan の更新

今回のリリースで、XERCES および XALAN ユーティリティがそれぞれバージョン 3.1.1 および 1.11 にアップグレードされました。

OpenVMS 以外のシステム — 大規模なジャーナル書き込み

今回のバージョンでは、ジャーナル書き込みの最大サイズが 4 MB まで拡大されました。これによって、SAN 以外のディスク上で 1.5 GB のジャーナルを生成する際のストリームの負荷に対して、ジャーナリングの速度が 2 倍に向上したことが測定で示されています。

複雑な SET における多すぎる引数のチェック

複数の変数に同じ値を設定する SET コマンドによって、引数スタックがオーバーフローして予測できないエラーが発生する可能性がありました。そこで、コンパイラによってコマンドが使用する引数スタック・エントリの数が正しくカウントされ、エントリ数が 255 を超えるとコンパイル・エラーが生成されるようになりました。

エラーごとのエラー・スタックの初期化

今回のリリース以前は、エラー・スタック情報は$ECODE が NULL 文字列に設定されるまで維持されていました。これは、より深いスタック・レベルで発生した古いエラーのレベルが、より浅いレベルで発生した新しいエラーのレベルと混在する可能性があることを意味します。その結果、新しいエラーのスタック表示を解釈することが難しくなっていました。

2012.1 以降は、既存のエラー・スタック情報は新しいエラーの発生時にクリアされ、新しいエラー・スタックには現在のエラー発生時の状態を示すエントリのみが含まれるようになります。

この変更により、エラー分析コードが簡素化され、以前の方法で生じる可能性のあった混乱を避けることができます。既存のコードは、以前の動作の補正を試みるための特別な対策がない限り、変更する必要はありません。

文字セットの %RO エクスポートへの挿入とインポートでの使用

%RO エクスポート・ユーティリティおよび Export^%apiRTN によって、ルーチンの出力時の文字セットがルーチン・ヘッダに挿入されるようになりました。インポートでは、%RI または Import^%apiRTNのいずれかからこの文字セット情報が使用され、インポートされたルーチンがエクスポートされたものと同じであることが確認されます。インポートするシステムに必要な変換テーブルがない場合、それを示す適切なエラー・メッセージが報告されます。

インポートされるファイルに文字セット情報が含まれていない場合 (以前のリリースで作成されたものなど) の動作は、以前のリリースでの動作と同じになります。

複数のジョブを使用するルーチン・コンパイル

いくつかのルーチンをコンパイルするための ^%RCOMPIL、##class(%Routine).CompileAll、Compile^%R の呼び出しで、可能な場合は複数の CPU 間で処理が分散されるようになりました。コンパイルの動作は変わりませんが、スピードが向上します。

現在のジョブ内でのみコンパイルが実行される以前の動作をリストアするには、以下の処理を実行します。

Set ^%SYS("Compile","MultiCompile") = 0

%Routine の読み取り/書き込み動作の変更

これまでのリリースでは、%RoutineOpens in a new tab を使用して、ルーチンを n 行記述し、ReadLine メソッドを使用して、これらの行を読み込んだ場合、n+1 行目を読み込もうとするまで、AtEnd プロパティは True に設定されません。これは今回のリリースで変更され、最後の行が読み込まれたときに、AtEnd が True に設定されるようになります。

クラスの削除

2011.1 バージョンに存在していた以下のクラスは、今回のバージョンで除外されています。

• %Compiler.LG — EJBRoot

• %Library.EIVX

• %Library.EIVXBench

• %Library.EIVXBenchNew

• %Library.EIVXBenchNewNew

• %Library.EIVXBenchOld

• %Library.EIVXBrowser

• %Library.EIVXDemo

• %Library.EIVXRecreate

• %Library.EIVXSAXHandler

• %Library.EIVXUnitTest

• %Library.EIVXxmlDOM

• %Projection — EJB、EJBFlexible、EJBJBoss、EJBPramati、EJBWebLogic

• %template — soapclientwizard、soapclientwizardns、soapclientwizardout、soapclientwizardpreview、xmlschemawizard、xmlschemawizardclasses、xmlschemawizardns、xmlschemawizardout、xmlschemawizardpreview

• EMS.UI.Component — emsCheckbox、emsDropLabel、emsListBox、emsTagRemoveButton

• Ens.Enterprise — Portal.LogTablePane、MsgContentsPane、Portal.MsgPane、MsgTablePane、Portal.MsgTraceFilterPane、Portal.MsgTracePane、Portal.MsgTraceSVG

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

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

メソッド返り値の変更

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

• %IO.LibraryStream — ReadLineIntoStream

• %Monitor.Health.Control — ClearConfig

• %Net.POP3 — WalkParts

• %SOAP.MsgDescriptor — InvokeService

• %SOAP.Policy — WriteOneAlternative

• %SOAP.Security.Policy — ApplySendAlternative、ApplySupportingTokens、SignEncryptParts

• %ZEN.Portal.standardPage — DoLogout

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

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

サーバのみのクラス

次のクラスは、今回のリリースでサーバ専用としてマークされています。

• %MV.Adaptor.xml

• %MV.EnumClass.xml

• %MV.File.xml

• %MV.PropertyParameters.xml

• %MV.SelectList.xml

• %MV.StudioRoutines.xml

• %MV.Verbs.xml

新しい $SYSTEM.Bit クラス

今回のリリースで、次の 2 つのエントリ・ポイントを持つ新しい $SYSTEM.Bit クラスが追加されました。

• StringToBit(str) は、ビット文字列を $BIT 形式のビット文字列に変換します。

• ZBitToBit(str) は、従来の DTM スタイルの $ZBIT* 文字列を $BIT 形式のビット文字列に変換します。

引数を有効な $BIT 文字列に変換できなかった場合は、これらのメソッドによって <ILLEGAL VALUE> エラーが生成されます。

プラットフォーム名に対する変更

$System.License.KeyPlatform() によって返されるプラットフォーム名が、一貫性のある形式を提供するために変更されました。以下のようになります。

その他すべての値は、廃止されたものか、使用されていないものです。

ExportToStream での Raw ファイル入出力の使用

アプリケーションによって $SYSTEM.OBJ.ExportToStream が呼び出されると、Caché は項目をファイルにエクスポートしてから、そのファイルをポイントするファイル・ストリームを作成するので、呼び出し元のストリームにデータが含まれます。以前のリリースで使用されたファイル・ストリームは、%FileCharacterStreamOpens in a new tab でした。このため、既定のファイル文字入出力テーブルはストリームの再度読み取り時に有効になり、場合によってはファイル内のデータが破損することがありました。今回のリリース以降、Caché では %FileBinaryStreamOpens in a new tab が使用されるため、元のデータ形式が保持されます。

%Open OREF チェックの強化

以前のリリースでは、ClassA および ClassB という %Library.PersistentOpens in a new tab の 2 つの異なるサブクラスがあり、それぞれ OIDA および OIDB というオブジェクト ID を持っていた場合、次の文がエラーなく実行されました。

Set InstanceB = ##class(ClassA).%Open(OIDB)
Set InstanceA = ##class(ClassB).%Open(OIDA)

今回のリリースでは、%Open によって、OID が開く処理を実行するクラスと一致することがチェックされるようになりました。正確なサブクラスが不明なインスタンスでは、開発者は次の例のように一番近い共通のスーパークラスを使用する必要があります。

Set InstanceB = ##class(%Library.Persistent).%Open(OIDB)

ミラーリングされるデータベース情報を分割するための Config.Databases:List クエリの変更

Config.Databases:List クエリが更新され、クエリの実行ごとに SYSLOG エントリが生成されることがなくなりました。Config.Databases:List クエリによって、Mirrored フラグや、データベースが現在のミラーでアクティブかどうかを示す MirrorStatus フィールドが返されることがなくなります。 また、新たに Config.Databases:MirrorDatabasesList クエリが追加されました。これにより、構成ファイル内のローカルのミラーリングされるデータベースに関する情報が返されます。

s システム・フラグの廃止

今回のリリースで、CompileAll などの関数内のクラスのリストをフィルタ処理するための “s” システム・フラグの使用が廃止されました。“s” システム・フィルタを以前に使用していた、クラスのリストを返す関数は、クラスが “system” キーワードを持っているかどうかにかかわらず、クラスを返すようになります。

これにより、一部のユーザがクラスのコンパイル順序を定義するためにクラス “system” キーワードを使用した問題が解決されます。このような場合、ユーザがクラスのコンパイルを試みると、コンパイル要求に “s” フラグが含まれていなかったために、“system” キーワードが定義されたすべてのクラスがコンパイルされませんでした。今後は、system キーワードを持っているかどうかにかかわらず、すべてのクラスがコンパイルの対象になります。

クラス依存性の認識の向上

クラス・コンパイラによって、クラス・リストが並べ替えられ、2 つの主なタイプにコンパイルされます。1 つは強い依存関係で、この場合、一つのクラスをコンパイルするには、もう一つのクラスが完全にコンパイルされ、実行可能である必要があります (DependsOn キーワードで示されます)。もう 1 つは弱い依存関係で、この場合、他のクラスが同じセットの一部としてコンパイルされる必要がありますが、実行可能である必要はありません (スーパークラスなど)。

依存関係を解決するコードによって、最初に強い依存関係を解決します。次に、各グループの弱い依存関係が解決されます。これらの強い依存関係の解決では、弱い依存関係を同じグループに入れる必要があります。例えば、クラス A がクラス B に依存 (DependsOn) している場合、クラス B がクラス A よりも先にコンパイルされる必要があります。ただし、クラス B がスーパークラス C を持つ場合、C も先にコンパイルされるグループに含まれなければなりません。そうでないと、Caché は B をコンパイルできないためです。

強い依存関係を解決するコードも、各項目の弱い依存関係を再帰的にチェックして、項目を正しい順序に挿入する前に、これらの弱い依存関係のいずれも強い依存関係を持たないことを確認します。この変更によって、まれに以前のリリースでは正常にコンパイルされていたように見えた一部のクラスによって、依存関係のコンパイル・エラーが報告される可能性があります。エラーが発生した場合、それは、実際の依存サイクルが存在しても、前のバージョンのコードによってそれが正しく検出されなかったことが原因です。

不明確な参照の解決

多次元プロパティとメソッドが次の例のように同じ名前を共有している場合を考えてみましょう。

Class Objects.Test Extends %Persistent
{
   Property Uncertain As %String [ MultiDimensional ];

   Method Uncertain(a As %String, b As %String) As %String
   {
        Quit "Uncertain Method Return"
   }
}

式 “Uncertain(foo, bar)” のあいまいさは、コンテキストによって変わります。式が値の受け取り側 (等号の左側) である場合、多次元値として扱われます。つまり、次の文では、

Set obj = ##class(Objects.Test).%New()
Set obj.Uncertain("A", "B") = "Some string"
Write obj.Uncertain("A", "B")

値 “Some string” が obj によって参照されるインスタンスの多次元配列 Uncertain に格納されます。

一方、式が値の提供側 (等号の右側) である場合、同じ参照がメソッドに解決されます。したがって、上記の例では、値 “Uncertain Method Return” は出力デバイスに書き込まれます。

クラス・メソッドでのインスタンス参照に対するチェックの再有効化

アプリケーションで次のようにローカル・メソッドを参照する場合を考えてみましょう。

Write ..Method()

クラス・コンパイラによって、このメソッドが存在すること、クラス・メソッドではなくインスタンス・メソッドから呼び出されることがチェックされます。同様のチェックがプロパティに対しても行われます。バージョン 2011.1 ではエラーが発生したため、このチェックは無効化されていました。しかし、2011.1 で (誤って) コンパイルされていた一部のクラスが、今回のバージョンではコンパイルに失敗するようになるため、この機能が再度有効になりました。

Light C++ バインディングのタイムスタンプの秒の小数部に含まれる末尾のゼロの切り捨て

Light C++ バインディングでは、d_timestamp 型フィールドの秒の構成要素の小数部に含まれる末尾の “0” を保存しなくなりました。さらに、タイムスタンプの秒の構成要素の小数部の値が 0 の場合、秒と秒の小数部を区切る “.” も保存されません。これにより、Light C++ バインディングによって保存されたタイムスタンプを、SQL のタイムスタンプ定数と正しく比較できなかった問題が解決します。

より Java に適したスタイルを使用するための MDS API の改善

Globals 製品の主要 API として認識されるようにするために、MDS API が大幅に改善されました。その主な理由は、"グローバル" という用語や概念の認識を再度高めること、スタイルを Java コミュニティの想定とより一致させること、インタフェースを簡素化および明確化すること、使いやすさを向上させることです。MDS API は、Cache 2010.1 でリリースされましたが、ユーザにより使用されているインタフェース、XEP の実装で内部的に使用されていました。

すべてのクラスおよびメソッドの詳細については、com.intersys.globals パッケージ内の Javadoc を参照してください。

Cacheé に含まれる Globals API

今回のリリースでは、次のような GlobalsDB でサポートされていない Globals API の機能のいくつかの関連領域が、Caché で使用する際に提供されるようになりました。

• スレッド固有の接続。これらは、GlobalsDB でサポートされる唯一のタイプである既定のスレッド固有でない接続に追加されます。

• Globals API およびその他の eXTreme API (XDO、eXTreme JDBC) は、両方の API が Caché 内の同一アプリケーションで使用される場合に互換性のない接続タイプ (一方の API ではスレッド固有の接続、もう一方ではスレッドに固有でない接続) を開くことは決してありません。

• 基礎となる JNI コードは、さまざまな API の呼び出しが同一アプリケーション内に散在する場合でも、呼び出し元の API に基づいて正しい例外タイプをスローします。

つまり、MDS (Globals API の非推奨の先行バージョン) に存在する機能は、他の eXTreme パッケージからの Globals パッケージの独立性を維持する形で提供されます。したがって、同じ Globals コードを、Globals DB 製品の globalsdb.jar 内の他の eXTreme パッケージから独立して提供することが可能です。

Enterprise Java Bean (EJB) プロジェクションのサポート終了

今回のリリースでは、Enterprise Java Bean (EJB) のサポートが Caché から廃止されました。

Python バインディングでの %Decimal 型のサポート

今回のリリースでは、%Decimal 型を導入することによって、Python バインディングにおける不備が修正されました。このサポートは、Python 2.7 と Python 3.0 の両方を対象とします。10 進数は Python クラス intersys.pythonbind.decimal を使用して導入されます。コンストラクタは intersys.pythonbind.decimal(significand, exponent)、10 進数の値は仮数*(10の指数乗) です。

d_list の既定のエンコードとして Unicode を使用

以前のリリースでは、データ型 d_list にはスレッドのロケールが既定で使用されました。その結果、特定の場合に、リストに要素を追加すると情報が失われることがありました。今回のリリースで、既定が Unicode となったため、情報が失われることがなくなりました。

この変更によって、一部の $LIST 要素がタイプ 2 (Unicode) になる可能性があります。そのため、リスト全体のバイナリ比較では、$LISTBUILD("1") と $LISTBUILD(1) の比較のように、データが論理的に同じであっても別々に保存されることから誤検出が報告される可能性があります。

Java eXtreme の XEP の変更

Java メソッドを使用してエクステント全体を削除する機能は、特に開発段階やテスト段階における強力なツールです。また、注意せずに使用すると極めて危険なツールでもあります。今回のリリースで行われた次の 3 つの変更によって、使いやすさが向上すると共に、誤用のリスクが低減します。

1. OPTION_IMPORT と、OPTION_IMPORT_PRESERVE_EXTENT あるいは OPTION_IMPORT_DELETE_EXTENT 修飾子のいずれかとの組み合わせが廃止されました。これにより、スキーマのインポート処理中にスキーマの一部を削除する可能性がなくなりました。get/setOption(OPTION_IMPORT) を呼び出すと、例外が発生します。オブジェクト・モデルが変更されない限り、既定でスキーマは保持されます。必要に応じて、新しく追加された EventPersister.deleteExtent メソッドを使用して、エクステントを削除してください (次の項目を参照してください)。

2. EventPersister クラスに新しいメソッドが追加されました。スキーマ全体を削除するには、このメソッドを使用することをお勧めします。その宣言は以下のようになります。

   void deleteExtent(String eventName) throws XEPException
   

3. Event.deleteExtent メソッドは非推奨になりました。これを使用するアプリケーションは、EventPersister.deleteExtent を呼び出すように変更する必要があります。Event.deleteExtentは将来のリリースで削除される予定です。

XEP のすべての例は、この新しい方法を使用するように変更されています。

CREATE PROC 文でのインクルードおよびマクロのサポート

今回のリリースでは、埋め込み SQL 文としてコンパイルされた場合や、ダイナミック文として作成された場合の、DDL CREATE PROCEDURE、CREATE FUNCTION、CREATE METHOD、CREATE QUERY、および CREATE TRIGGER の各文の動作が変更されています。この変更では完全な下位互換性は確保されていないため、特に ObjectScript タイプのコード本文を CREATE 文で使用する場合には、アプリケーションに変更が必要となることがあります。

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

&sql;(CREATE PROCEDURE SquareIt(in value INTEGER) RETURNS INTEGER LANGUAGE COS 
     {
        #define Square(%val) %val*%val
        QUIT $$$Square(value)
     }
)

この変更以前は、CREATE PROCEDURE 文がコンパイルされる場合に、#if、#define、$$$Square マクロ参照が拡張および処理されていました。この変更後、この処理および拡張はプロシージャ・メソッドの定義に追加され、メソッドのコンパイル時に処理と拡張が行われるようになります。

マルチ・インデックス最適化でのすべての 効率的な 等値条件に対するインデックスの使用

クエリが適切なインデックスのあるいくつかの等値条件を同じテーブル上に持つ場合、それらはそのテーブルが最初の処理対象として選択されている場合には常に使用されるようになりました。以前は、1 つか 2 つ “十分な” 選択性が提供されていれば、追加のインデックスは無視される可能性がありました。

クエリ機能によっては、この動作をオーバーライドすることがあります。例えば、ORDER BY、DISTINCT、または GROUP BY クエリの場合、インデックスがこれらの処理を支援する利点が、マルチ・インデックス方法と比較され、優先される可能性があります。同様に、TOP は最初の行を返す時間を最適化するため、同様にこの新しい既定の動作をオーバーラードする可能性があります。最後に、以降の結合でパフォーマンスを向上させるために行を生成する場合も、異なるクエリ方法が優先される可能性があります。

SQLStorage に関連付けられたストレージ・メソッドにおける変更

コンパイラによって Caché SQLStorage を使用するクラス用に生成された内部メソッドでは、SQL コードで使用されるいくつかの % 変数が適切に NEW で処理されませんでした。今回のリリースでは、これらのメソッドで、%msg、%ok、および %ROWCOUNT; が NEW で処理されるようになりました。なお、%ROWID と SQLCODE は、適切に NEW で処理されていました。

アプリケーションでこれらの変数が “処理されなかった” 事実を利用している場合、変更する必要があります。

トリガ定義の強化

Caché で複数のタイプのトリガ・イベントがサポートされるようになったため、{field} 参照のパフォーマンスを向上させるために、SQL トリガに変更が加えられました。 トリガによって生成されたコードは、トリガのイベントが複数ある場合でも、一度だけ実行されるようになります。この変更を有効にするための {Field*Flag} 参照の動作に関する規則は、次のようになっています。

• {Field} ：

  • INSERT の場合、列の挿入値に解決されます。

  • DELETE の場合、ディスク上の削除前の列の値に解決されます。

  • UPDATE の場合、更新される列の新しい値に解決されます。

• {Field*N} ：

  • INSERT の場合、列の挿入値に解決されます。

  • DELETE の場合、削除される行からのディスク上にある列の値に解決されます。

  • UPDATE の場合、列のこの行で更新される新しい値に解決されます。

• {Field*O} ：

  • INSERT の場合、NULL に解決されます。これは新しい動作です。

  • DELETE の場合、削除される行からのディスク上にある列の値に解決されます。

  • UPDATE の場合、更新される列の古い値に解決されます。

• {Field*C} ：

  • INSERT の場合、挿入される値が NULL 以外の場合は真、それ以外の場合は偽です。これは新しい動作です。

  • DELETE の場合、削除される値が NULL 以外の場合は真、それ以外の場合は偽です。これは新しい動作です。

  • UPDATE の場合、新しい値が古い値またはディスク上の値とは異なる場合は真、それ以外の場合は偽です。

さらに、トリガには行ラベルを含めることが可能ということも、トリガ・コードに適用されます。ただし、トリガ・コードは、プロシージャ・ブロックの範囲外で生成されます。 つまり、ラベルはクラス定義内で一意である必要があります。このクラスにコンパイルされるその他すべてのコードには、同じラベルを定義することはできません。これには、その他のトリガ、プロシージャ・ブロックを使用しないメソッド、SqlCompute コードなどが含まれます。

TSQL ： UPDATE STATISTICS

Caché TSQL コンパイラでは、UPDATE STATISTICS 文がサポートされるようになりました。この文によって $SYSTEM.SQL.TuneTable() の呼び出しが生成されます。この文は、ダイナミック文としてもサポートされています。

%ObjectSelectMode 以外の SELECT 文の処理の変更

ダイナミック SQL 文の実行結果は、結果オブジェクトになります。この結果オブジェクトは、単純な結果 (成功または失敗を示す)、結果セット・オブジェクト、またはプロシージャ結果オブジェクトのいずれかの場合があります。文を %ObjectSelectMode = 1 で作成した場合、行型のプロパティを参照するときに、プロパティに対応する列の型がスウィズル可能な型であれば、結果セットの列が自動的にスウィズルされるようにできます。以下はその例です。

SELECT Spouse from Sample.Person where Spouse IS NOT NULL

その文をダイナミック SQL 文として %ObjectSelectMode = 1 で作成した場合、<resultORef>Spouse プロパティを取得することで、スウィズリングがトリガされ、oref が返されます。ただし、%ObjectSelectMode が 0 の場合は、プロパティが単純な ID 値として返されます。

ストリームの場合、完全修飾されたストリーム OID (SOID) 値が SQL によって返されます。これは、%ObjectSelectMode が 0 の場合に、埋め込み SQL およびダイナミック SQL に当てはまります。完全修飾された SOID 値を手動でスウィズルされるようにするには、##class(%Stream.Object).%Open(<SOID>) を使用します。%ObjectSelectMode = 1で作成したダイナミック SQL 文を実行することによって選択されたストリームの列は、自動的にスウィズルします。

ダイナミック SQL 内のエラーによって、%ObjectSelectMode が 1 でないときにストリームの列が自動的にスウィズルする問題がありました。今回、この点が修正されました。アプリケーションでこの動作を利用していた場合は、%OBJECT(streamcol) を使用するように処理を変更するか、%StreamObject.%Open を使用してストリームの SOID を手動でスウィズルするように変更する必要があります。

ダイナミック SQL の %Print の変更

結果セットに対して実装された %Print ユーティリティ・メソッドは、出力値に改行が含まれている場合、その値を引用符で囲むようになりました。これより以前、値が引用符で囲まれるのは、値に区切り文字が含まれている場合のみでした。

SQL DECODE 文に対する変更

SQL DECODE 関数が変更されました。この変更以前は、DECODE によって、DECODE 関数呼び出し内の最初の返り引数と同じ型が返されていました。今回のリリースではそれが変更され、考えられるすべての返り値の中で最も互換性が高い型が関数から返されるようになります。

以下の関数の呼び出しを考えてみましょう。

DECODE(999, ' ', 1, 0.7)

Caché では、この返り値の型は INTEGER であると見なされました。xDBC ドライバを通じて値として 0.7 が返されると、値は型が INTEGER であると想定されているため、0 に切り捨てられます(一方、Oracle では、値 1 は INTEGER ではなく FLOAT(38) であると見なされ、0.7 は変更されることなくクライアントに返されます)。

現在、上記の関数呼び出しで考えられる返り値は 1 および 0.7 であるため、この場合、関数によって NUMERIC(1,1) が返されます。VARCHAR、DOUBLE、NUMERIC、BIGINT、INTEGER、SMALLINT、TINYINT の各データ型に互換性があり、この優先度 (最高レベルから最低レベル) で順位が指定されます。例えば、DECODE 関数の呼び出しで NUMERIC、INTEGER、または TINYINT の値が返される可能性がある場合、NUMERIC の優先順位が一番高いため、この返り値の型は NUMERIC になります。xDBC クエリ内のリテラル置換された引数に対して指定された型により、上記の関数が xDBC クエリ列に含まれていた場合、報告される型は NUMERIC(18,9) になります。

ビューのクエリで使用できないホスト変数

ホスト変数は、ビューのクエリで使用が許可されていませんでした。ホスト変数の使用を試みると、これらの文をコンパイルしようとしたときに、SQLCODE = -51 のような予期しない説明できないエラーが発生することがありました。ビューのクエリや、CREATE VIEW 文または ALTER VIEW 文でホスト変数を参照しようとすると、SQLCODE = -148 と共に、該当するエラーメッセージが %msg 内に表示されます。

TSQL の ROWCOUNT に対する変更

TSQL SET ROWCOUNT 機能によって問題が修正されました。アプリケーションが Caché TSQL 内の ROWCOUNT の従来の動作に依存している場合、変更する必要があります。

次のようなTSQL コードについて考えてみましょう。

ClassMethod RowCountTest() As %Integer [ Language = tsql, 
                                         ReturnResultsets, 
                                         SqlName = RowCountTest, 
                                         SqlProc ] 
{ 
    set ROWCOUNT 1 
    select * from Cinema.Film 
    set ROWCOUNT 0 
} 

以前のリリースでは、このプロシージャを実行して返される結果セットで、すべての行が返されました。今回のリリースでは、最初の行のみが返されるようになりました。

%IGNOREINDICES の変更

指定されたインデックス名が存在しない場合、非推奨の %IGNOREINDICES キーワードによって構文エラーが示されるようになりました。%IGNOREINDICES は非推奨であるため、すべて %IGNOREINDEX に変更される必要があります。

ハイパーイベントのエラー処理の改善

ハイパーイベント・リクエストに関する問題を処理するために %CSP.LoginOpens in a new tab の OnErrorSetup() メソッドを使用している開発者は、ハイパーイベントのエラー処理が CSP サーバによって実行されるようになったことに注意してください。また、これらのエラー状況に基づいて対応したい場合は、クライアント側のエラー処理を利用するようにしてください。ハイパーイベントにおいて発生したエラーでは、エラーの原因に関するより多くの情報が得られるようになりました。これにより、ユーザはアプリケーション・レベルで対処する必要のある対応について、より多くの情報に基づいて判断できるようになります。

このリリースでは、cspHyperEventError タイプの新しい Javascript オブジェクトが導入されます。このオブジェクトが持つプロパティとその値は次のとおりです。

• code ： HTTP 応答コード、または使用中の XMLHttpRequest オブジェクトからの応答コードに相当します。XMLHttpRequest コードは、ブラウザ固有の場合があります。

• text ： cspRunServerMethodError() コールバック関数に返された現在のテキストに相当する制限のないテキスト・フィールドです。

• serverCode ： サーバ上のエラー番号に相当します (ある場合)。この値は、NULL の可能性があります。

• serverText ： サーバからのエラー・メッセージです (ある場合)。この値の既定値は空の文字列 “” です。

• exception ： エラーをトリガした例外です。この値は、NULL の可能性があります。

• arguments ： 例外がトラップされた関数に対する引数のリストです。この値は NULL の可能性があります。例外が定義されている場合のみ入力されます。

ハイパーイベントの呼び出し中にエラーが発生した場合 (Zen メソッドに対するサーバ側の例外も含む)、cspxmlhttp.js 内の新しい cspHyperEventErrorHandler() 関数によって、ユーザがハイパーイベント・エラーの処理に cspRunServerMethodError() コールバックを定義したかどうかがチェックされます。定義済みの場合、cspRunServerMethodError() が cspHyperEventError オブジェクトを含む追加引数を使用して呼び出されます。ページに対して cspRunServerMethodError() 関数が定義されていない場合、既定のエラー処理関数によって従来と同様に警告がログに記録されます。

Zen に対する動作は多少異なります。Zen では、常に cspRunServerMethodError() コールバックが定義されます。Zen では、%ZEN.Component.abstractPageOpens in a new tab から継承された onServerMethodError() コールバック関数が使用され、ユーザがハイパーイベント・エラーの処理を行うこともできます。このコールバック関数にも、拡張された cspHyperEventError オブジェクトを含む 2 番目の引数が指定されます。そのため、Zen 開発者は、ハイパーイベント・エラーを処理する方法を積極的に制御することができます。サーバ側の例外およびエラーは、ハイパーイベント・エラーとして報告されるようになると共に、HTTP 500 応答として報告されるようになります。ステータス・エラーによってトリガされるものには、サーバ側のエラー・コードやテキストが含まれます。onServerMethodError() コールバックが実装されていない場合、Zen コードによって、ユーザがログアウトし自動的にログインできなかったことをエラーが示していないかどうかがチェックされます。このチェックは 401 の HTTP コードおよび 864 のサーバ・コードに基づいて行われます。この場合、Zen フレームワークによって、次の Javascript を使用したページの更新がトリガされます。

self.document.location.reload()

これは、現在の CSP アプリケーションに対して指定されたログイン・ページをユーザに示します。ユーザは、再度ログインすることなくさらに処理を行うことはできません。アプリケーションで onServerMethodError() コールバックを実装した場合も、このメソッドから返される False の値によって、ページが更新されるべきかどうかがチェックされることに留意する必要があります。返り値が未定義の場合や True の場合、それ以降の Zen でのエラー処理は省略されます。サーバからのさらに多くの Zen エラーがこれらのコールバックを通じて報告されるようになりました。アプリケーション開発者は、このようにして報告されるエラーが増えることを認識しておく必要があります。

これらの変更の延長として、次のような場合には、CSP サーバによって %CSP.BrokerOpens in a new tab に対する要求がログイン・ページにリダイレクトされることはなくなります。

• 以前の認証情報 (group-by-id の CSP アプリケーション・グループ、スティッキー・コンテキストなど) が使用できない

• ユーザ名が提供されていない

• 認証されていないアクセスが現在のアプリケーションに対して許可されていない

このような状況は比較的一般的であり、セッションの有効期限が切れ、ハイパーイベントに認証が含まれていない場合に発生します。この状況が発生すると、CSP サーバによってログイン・ページへのリダイレクトは行われませんが、HTTP 401 エラーがクライアントに報告され、認証を求める 864 のサーバ・コードが提供されます。ハイパーイベントに対してログインが試行された場合 (これは一般的ではありません)、ログインの失敗がログイン・ページの OnErrorSetup() メソッドによって案内されることはありませんが、サーバで発生したエラー・コードを含む HTTP 401 エラーとしてクライアントに直接報告されます。

有効な返り値としての 200 の使用

以前のリリースでは、Caché は単方向処理からの返り値として 202 のみを受け入れていました。WS-I Basic Profile 1.1 に従って、単方向処理から 200 を返すことがまったく問題なくなったため、200 が使用可能になりました。

NUL を含む文字列の処理の変更

理論上は、Caché から返され、SQL_VARCHAR として報告され、SQL_C_CHAR に変換されるデータは NULL で終了し、内部 NULL 値は含まれません。しかし、Caché 文字列には NULL を含めることができるため、ODBC アプリケーションで値に対して SQLGetData の実行を試みる際に問題が発生していました。以前のリリースでは、完全な長さのデータの前に、Caché で NUL が検出された場合にデータの切り捨てが報告されました。ODBC アプリケーションは通常、その切り捨てエラーに応答するために、値を取得しようと成功しないままループを繰り返していました。

今回のリリースでは、Caché ですべてのデータが SQL_C_CHAR に変換され返されます。$CHAR(0) が埋め込まれている場合でも同様です。これは通常の NULL で終了する C 文字列に対して予期するものとは異なりますが、この壊れたデータの処理方法は ODBC アプリケーションで判断されるようになります。

SQL_BINARY データの場合、$CHAR(0) 文字を含む SQL_C_CHAR に変換され、完全に読み取られてマルチバイト値に変換されます。これは、Caché からより大きなバッファが必要であることを示す切り捨てエラーが誤って返されることがないためです。

UNIX® および OpenVMS プラットフォーム上で返されるユーザ名

以前のバージョンでは、UNIX® および OpenVMS 上で $USER に対して Caché からユーザの UID 値が返されていました。今回のバージョン以降、$USER によってユーザ名が返されます。

SYSTEM(1001)、SYSTEM(1051)、SYSTEM(1056) 関数に対する修正

SYSTEM(1001) は、エミュレーションに依存するようになりました。jBASE エミュレーションでコンパイルされるプログラムの場合、コマンドラインが属性の区切り文字列として返されます。その他すべてのエミュレーションでは、従来どおり、プログラムのコンパイル時に使用されたエミュレーション番号が返されます。

SYSTEM(1051) では、従来どおり、プログラムのコンパイル時に使用されたエミュレーション番号が返されます。

SYSTEM(1056) は新たに追加されました。次のようにエミュレーションを説明する 4 つの属性が返されます。

1. プログラムのコンパイル時に使用されたエミュレーション番号

2. プログラムのコンパイル時に使用されたエミュレーション名

3. MV アカウントの現在存在するエミュレーション番号

4. MV アカウントの現在存在するエミュレーション名

R95 から POWER95 へのエミュレーション名の変更

エミュレーションとしての R95 への参照はすべて、POWER95 に置き換える必要があります。

Unidata スタイルのグローバル・カタログの動詞をサポート

MV コマンドの最初の単語が “*” で始まり、現在のエミュレーションが “UNIDATA” または “UDPICK” である場合、“*” が削除され、その動詞を調べるためにグローバル・カタログへのアクセスが行われるようになりました。

ファントム・プロセスに対してポート番号が設定できる

今回のバージョン以降、ファントム・プロセスでは、^||%MVPortNo で割り当てられたカスタム・ポート番号が使用されるようになりました。

COPY.FILE による @ID の更新

COPY.FILE コマンドの宛先には @ID ディクショナリ項目が含まれ、新しいファイル名を反映するよう更新されるようになりました。

MV トリガのラッパ名の変更

MV トリガのラッパのルーチン名は、ファイルのデータ・セクションを保持するグローバルの名前を取り、その名前の前に “MVTW” を付けることで設定されるようになりました。

投影されるストレージの変更

今回のリリース以降、MVENABLED クラス内のコレクションに対するインデックスは、フルとして投影されるようになりました (以前は、条件付きとしてマークされていました)。さらに、MVENABLED クラス内のリスト・コレクションから投影される子テーブルには、そのコレクション (MultiValue) が NULL の場合、1 つの空白行が含まれるようになりました。

MVBASIC の変更

• 指数項が欠けている場合の MVBasic の既定値

  MultiValue BASIC の PWRS(A,B) 組み込み関数およびベクトル ** 演算子 (ベクトル ^ 演算子と同じ) が変更されました。動的配列 B の何らかのコンポーネントがない場合、あるいは空の文字列の場合、そのコンポーネントが値 1 として扱われます。

  Note:

  この動作は、DIVS(A,B) と MODS(A,B) の各組み込み関数およびベクトル/演算子とは異なります。これらのベクトル演算では、2 番目のオペランドの欠けているコンポーネントは 1 として扱われますが、空の文字列を含むコンポーネントは 0 として扱われます。

• MVBASIC への DIVSZ 関数の追加

  新しい動的配列関数 DIVSZ が MV BASIC に追加されました。DIVSZ 関数は、DIVS 関数と同じですが、動的配列コンポーネントがゼロで除算された場合にエラーを生成しない点が異なります。DIVSZ の 2 番目のオペランドのコンポーネントに値 0 が含まれる場合、結果の動的配列の対応するコンポーネントは 0 になります。

  Note:

  アプリケーションで名前 DIVSZ を使用してユーザが記述したルーチンまたは変数を定義する場合は、ルーチンや識別子の名前を変更する必要があります。

• 記述子が必要な場合に MVB システム変数が使用できない

  MVBASIC では、$DATA(@ME) または $GET(@ME) を呼び出すと、コンパイラがクラッシュします。$DATA() および $GET() をその他のシステム変数 (例えば、$DATA(@ACCOUNT)) に適用すると、システム変数が未定義であるかのような結果が常に返されます。システム変数は、変数として実装されていませんが、代わりに特殊ケースとされ、通常は式として実装されています。システム変数は、(式の値を必要とするのではなく) 変数を必要とする関数や文に対する引数として使用することはできません。コンパイラによって、これらの状況が検出され、適切なコンパイル時エラー・メッセージが提供されるようになりました。

  Note:

  $DATA(@ME->Property) などの呼び出しを記述することは、引き続き正当な方法です。これは、変数が参照できる場所であればどこからでも、クラス・プロパティが参照可能なためです。

• 許可されない入れ子になった動的配列参照

  以前のリリースでは、プログラムに VAR<i><k,j> のような入れ子になった動的配列参照が含まれている場合に、MVBASIC コンパイラによって構文エラーが示されることはありませんでした。この不正な構文のコンパイルを試みることによって、多くの場合、MVBASIC コンパイラのクラッシュが発生することになります。また、コンパイルが正常に行われたとしても、プログラムを実行すると予測できない結果が生じることになります。そのため、この構文は使用できなくなりました。

  MVBASIC 構文に、変数の参照 (割り当ての左側、または READ 文の最初のオペランドなど) が必要な場合、変数参照には、最大 1 つの動的配列参照 (例 ： A<i,j>) と、それに続く最大 1 つの部分文字列参照 ( A<i,j>[s,l]) を含めることができます。以前はこれらの規則が適用されておらず、複数の動的配列参照や複数の部分文字列参照が含まれた変数参照は、多くの場合に誤ったオブジェクト・コードを生成することになりました。

  複数の動的配列参照や部分文字列参照を指定できるのは、次の例のように変数が式の一部として評価される場合でした。

  LET X = A<I><1,J><1,1,K>[s1,l1][s2,l2]
  

  以前は、式の評価内に3 つ以上の動的配列参照のシーケンスがあると、構文エラーが発生する可能性がありました。

• IFS() 関数の修正と使用可能になった REUSE()

  関数 IFS(ifarray, array1, array2) は、3 つの動的配列をパラメータとして取り、動的配列結果を返します。引数 ifarray にはブーリアン値が含まれ、関数の結果のシェイプは、ifarray のシェイプと同じになります。 ifarray に True コンポーネントが含まれている場合、結果の対応するコンポーネントは、array1 の対応するコンポーネントになります。ifarray に False コンポーネントが含まれている場合、結果の対応するコンポーネントは、array2 の対応するコンポーネントになります。

  array1 または array2 の選択されたコンポーネントが存在せず、REUSE() が選択された引数に対して使用されない場合、結果のコンポーネントは空の文字列になります。一方、array1 または array2 の選択された対応するコンポーネントが存在しなくても、REUSE() がその引数に対して使用される場合、結果のコンポーネントは、欠けているコンポーネントの位置の前の最も近い既存の array1 または array2 コンポーネントになります。

  REUSE() が最初の引数 ifarray に適用されるとエラーになります。

  Note:

  アプリケーションでシェイプが一致しない配列を使用して IFS() が呼び出された場合、その結果はそれぞれの MultiValue ベンダ間で異なる可能性があります。アプリケーションは、希望する一貫性のある動作が得られるように IFS() に対するパラメータの再構築が必要となるよう変更する必要がある場合があります。

• MVB Ultimate の既定 -FULL.LOGICAL.EVALUATION

  Ultimate エミュレーションの簡易ブーリアン評価の既定の動作が以下のようになりました。

  $OPTIONS -FULL.LOGICAL.EVALUATION
  

  以前の動作は以下のとおりでした。

  $OPTIONS  FULL.LOGICAL.EVALUATION
  

  新しい動作では、A オペランドが False と評価 された場合、A & B (A AND B) の B オペランドは評価されません。また、A オペランドが True と評価された場合は、A ! B(A OR B) の B オペランドは評価されません。

• MVB OPENSEQ に TO 節が必要

  OPENSEQ 文には、TO 節 が必要です。この制限が正しく適用されるようになりました。

ハイパーイベントのエラー処理の改善

CSP ハイパーイベントのセクションで詳細に説明されている変更を参照してください。

tablePane 行の選択でトグル動作を選択的に有効化するためのフラグの追加

以前の機能強化では、ユーザが現在の行の選択を行をクリックすることで解除できるようになったため、行のクリック・オプションが事実上のトグルとなり、ユーザはページを再ロードすることなく "何も選択しない" ことが可能になりました。これで、その後選択した行をクリックしても何も起こらず、現在の選択をクリアする方法が別のものを選択するか、API を終了するしかなかった以前の動作から脱却できました。今回の変更では、enableToggleSelect フラグが tablePane に追加されました。これにより、実際上前回の拡張機能が選択可能になります。既定は、下位互換性のために 2010.2 以前の動作と類似しています。

この新しい動作を今回の変更の前にすでに採用しているユーザは、選択解除の操作を希望する任意の tablePane タグに、enableToggleSelect="true" 属性を追加する必要があります。

PDF 生成におけるページ・ヘッダ

PDF の生成では、複数のセクションを持つレポートに最上位のページ・ヘッダが含まれている場合、そのページ・ヘッダ は出力に表示されません。複数セクション使用時の別の最初のページには、pagePosition="first" で masterreference を指定します。加えて、pagePosition="any" が指定された masterreference だけが、HTML 出力に含まれます。

CObjInstance での ITypeInfo のサポートの終了

以前のバージョンでは、CObjInstance によって、クラスに対して既定の ATL ITypeInfo が返されました。これは、CObjInstance の実際のインタフェースが既定の実装によって返されるものよりもはるかに多いことから、正しくありませんでした。これを廃止したことで、CacheActiveX クライアントは CObjInstance の誤ったメタ情報に基づいて判断することがなくなります。