#ヒントとコツ

Windows環境にWebGatewayのみをインストールした場合に、「Service Unavailable / HTTP Error 503. The service is unavailable.」エラーとなりWebアプリケーションに接続できない場合があります。

こちらは、Visual C++ 再頒布可能パッケージ がインストールされていない環境に、Webゲートウェイをインストールした場合に見られる事象です。

Microsoft社のホームページより、Visual C++ 再頒布可能パッケージ（X64）をダウンロードしてインストールしてください。

インストール後IISを再起動し、以下のリンクよりWebゲートウェイ管理ページに接続できることをご確認ください。
 

Webゲートウェイ管理ページ：
http://localhost/csp/bin/Systems/Module.cxw

エラーが解消されない場合は、IISのアプリケーションプールが起動しているかをご確認ください。

【ご参考】
Microsoft Visual C++ Redistributable latest supported downloads

こちらの記事では、RESTやCSPなどの「Webアプリケーションのトラブルシューティング」のヒントをご紹介します。

何かしらのトラブルと思われる事象が発生した場合、確認したいのがログファイルになります。
各コンポーネント間のやり取りで、どこでどのようなトラブルが発生しているかを、それぞれログを取得して確認することができます。

① クライアント ⇔ Webサーバ間では、「Webサーバログ（IISやApacheのアクセスログなど）」、
② Webサーバ ⇔ Webゲートウェイ間では、「イベントログ」・「HTTPトレース」、
③ Webゲートウェイ ⇔ IRISサーバ間では、「ISCLOG」・「監査ログ」・「messages.log」などがあります。

こちらの記事では、IRISで取得できるログとして と で取得可能なログの取得方法をご紹介します。
 

② Web サーバと Webゲートウェイ間のアクセスに関連するログ情報

◆ イベントログ

1) Webゲートウェイ管理ページ（http://<IPアドレス>:<ポート>/csp/bin/Systems/Module.cxw）に接続します。

2) イベントログを削除します。
　[イベントログを参照] > ログをクリア をクリック

3) イベントログレベルを設定します。

IRISをアップグレードすると、SQLクエリオプティマイザの機能向上により、旧バージョンとは異なるクエリプランによるクエリ実行コード(クエリキャッシュ)が作成される場合があります。
ほとんどの場合はパフォーマンスが向上するのですが、稀にパフォーマンスが低下するケースもあります。

・アップグレードによりオプティマイザが改善しているとはいえ、中には遅くなるクエリがあるのではないか？
・予期しないSQLの問題が起きるのではないか？
・アップグレード後に全てのクエリパターンをテストするには時間と労力がかかりすぎる

このように、機能向上よりも安定性を優先して「今までのプランのまま実行したい」というご要望もあることでしょう。
こちらの記事では、そのようなお客様への解決策をご案内します。

解決策 = 凍結プラン（Frozen Plan）を使用する：

Cache2016.2以降（IRISはすべてのバージョン）で、クエリプランの凍結機能 が実装されました。
この機能により、IRISを新しいバージョンにアップグレードする際、既存のクエリプランは自動的に凍結されます。
これにより、アップグレードによる既存のクエリのパフォーマンスの低下の可能性を防げます（古いバージョンと同じプランが使用されるため）。
新しいクエリについてはもちろん、アップグレード後のクエリオプティマイザによるプランが使用されます。

この「DeepSee トラブルシューティングガイド」は、DeepSee プロジェクトの問題を追跡して修正する支援を提供することを目的としています。

このガイドラインに従って問題を修正できない場合でも、少なくとも DeepSee サポートに WRC の問題を提出し、すべての証拠を提供するのに十分な情報を得ることができます。この情報によって、一緒に調査を続け、より迅速に解決することが可能となります。

ご注意ください: 特定のアクションやコマンドによってどのような結果がもたらされるかがよくわからない場合は、実行しないでください。本番システムに影響を与える可能性があります。  この場合は、サポートセンターにお問い合わせください。 

左から右の操作列に進むと、このガイドを最も簡単に活用できます。

あるメソッドやルーチンを実行してエラーとなった場合、エラー発生個所はエラーメッセージより取得することができますが、処理の呼び出し履歴（スタックトレース）はエラーメッセージのみではわかりません。
また、.Net や Python など IRIS 外からの呼び出しの場合に、エラー情報の詳細がクライアントに返らない場合などもあるかと思います。

/// 例：エラーメッセージだけでは、エラーが発生した処理の呼び出し履歴まではわからない。d##class

そんなときは、エラー処理にて Do BACK^%ETN を実施することで、IRIS側で強制的にスタック情報を記録することができます。
スタック情報を記録することで、どのような処理がどの順番で呼び出されたかや、エラー時の内部変数情報を知ることができます。

BACK^%ETN は、エラー発生後に $ZError($ZE) 変数に値が set されている場合、アプリケーションエラーログ（^ERRORS）に情報が記録されます。
上のエラーの場合の $ZE は、以下のように確認できます。

>write

スタック情報は、以下のようになります。こちらよりスタックトレースを確認することが可能となります。

※こちらは管理ポータルで確認した結果になります。

ターミナルにライセンス期限切れの警告メッセージ（「*\* Warning: This Cache license will expire in 3 days **」）が表示されており、そのメッセージを表示したくない場合は、以下のコマンドを実行すると、メッセージの表示を無効（または有効）にできます。

Do ExpirationMessageOff^%SYS.LICENSE - Disable

Do ExpirationMessageOn^%SYS.LICENSE - Enable

これは InterSystems FAQ サイトの記事です。
 

以下の方法で、$ZF(-100) で実行したコマンドの出力を取得することが可能です。
 

★$ZF(-100) での実行でコマンドキーワードを使用する方法：

/STDOUT や /STDERR などの便利なキーワードを指定して、$ZF(-100) でコマンドを実行することが可能です。

USER>write$zf

USER>

コマンドキーワードについては、以下のドキュメントをご覧ください。
$ZF(-100) で指定できる便利なキーワード
※ /STDOUT と /STDERR に同じファイルを指定した場合、両方のタイプのデータがそのファイルに書き込まれます。

★標準エラー出力(2) を 標準出力(1) へリダイレクトする方法：

以下の方法で、標準エラー出力(2) を 標準出力(1) へリダイレクトし、さらにコマンドの 標準出力 を ファイル(result.log) へ出力する方法が使用できます。

USER>

上記コマンドの場合、実行したネームスペースのデフォルトデータベースのフォルダに result.log が出力されます。
内容は以下のような標準出力が記録されています。

ファイルとディレクトリの操作に使用できる API 、%Library.File クラス (%File が省略形) の便利なサンプルコードをご紹介します。

こちらのAPIを使用して、ディレクトリやファイルの中身をのぞいたり、作成・書込み・読込みを行ってみます。

★ディレクトリ内のファイル一覧をリストする

以下のサンプルは、C:\temp フォルダ内の *.txt ファイルをリストします(ファイルパス_サイズ_作成日)。

 set##class

サブディレクトリ内のファイルを含む場合はこちら (filetest.mac で保存) ↓

test(dir)
  

実行結果：

USER>

★シンプルなファイル作成＆書き込み＆読み込み

作成＆書き込み

※OPEN モード・パラメータ

または (Streamの場合)、

読み込み

または (Streamの場合)、

 
★ファイルをバイト単位で読み込む

%Strean.FileCharacter の場合、Readした時点でUnicodeに変換されているため、バイト数で切ることは難しくなります（文字数単位となる）。
バイト単位で読み込みたい場合は、FileBinaryを使い「無変換」で取り込み、それを Unicode に手動で変換する方法を使用します。

※注意
バイト単位で読む場合、$ZCVT

開発者の皆さん、こんにちは！

InterSystems IRIS 、InterSystems IRIS for Healthのコミュニティエディションは、WindowsやLinuxにインストールするキットの他にコンテナ版も公開されています。

コンテナ版はダウンロードページからではなく、InterSystemsコンテナレジストリ よりpullいただけます。

この記事では、InterSystemsコンテナレジストリ の使い方と、コンテナ開始までの流れをご紹介します。

クラスメソッドの多くは、%Status データ型を使用して、成功 または 失敗 の情報を返します。
成功の場合は 1 が返り、失敗の場合はエラーステータス および 1 つ以上のエラーコードとテキストメッセージを含むエンコードされた文字列が返ります。
このようなメソッドでは、戻り値を必ず取得して確認するようにしてください。

こちらの記事では、失敗の場合の具体的なエラー情報を確認する方法をご紹介します。

USER>set##class0

エンコードされたエラーの文字列より、具体的なメッセージを表示したい場合、%SYSTEM.Status クラスのメソッドを使用します。

0

Do $SYSTEM.Status.DisplayError(st)

でエンコードされたエラーの内容を知ることができるようになりました。
見ることはできましたが、毎回このコマンドを実行するのは面倒だ、という方に良い方法をご紹介します。

こちらの記事 で紹介しているように、覚えにくいコマンドに対して alias を設定し、ObjectScript コマンドのショートカットを作成することが可能です。
※コマンド行インタフェースでのみ使用できます。これらは ObjectScript の拡張機能ではないため、ルーチンやメソッドで使用することはできません。

各エラーコードのメッセージ一覧は、以下のドキュメントをご覧ください

これは InterSystems FAQ サイトの記事です。

LOAD DATAは、バージョン2022.1から追加されたSQLコマンドで、CSVファイルやJDBCソースからデータをテーブルにロードするコマンドです。
データが存在するテーブルにLOAD DATAを実行した場合、データは追記されます。

※ バージョン2022.1をご利用いただく場合は、バージョン2022.1.3 をご利用ください。（2022.1.0～2022.1.2は、使用するJARファイルの不備により動作しません。）

LOAD DATAを利用する際、Javaの外部サーバ（Javaゲートウェイ）を使用するため、IRISをインストールした環境にJavaのインストールが必要です。
サポート対象のJavaバージョンについては、ドキュメントの「サポート対象Javaテクノロジ」をご参照ください。

LOAD DATAを利用するためには、Javaインストール済、かつ外部言語サーバで %Java_Server 設定済の環境である必要があります。

※ 環境変数JAVA_HOMEの設定がある場合は以下 %Java_Serverの設定は不要です。

%Java_Server 設定詳細は以下の通りです。

• Javaホームディレクトリ：インストールしたJavaのホームディレクトリを指定します。

利用手順は以下の通りです。

Apache経由でREST通信する場合、ApacheでRESTを動かす場合の設定方法 (含：Webゲートウェイのインストール手順) の方法 で設定を行います。

この際、Apachの構成ファイル（httpd.conf）にRESTを動かすための設定を入れるのですが、設定後のシンタックスチェックで以下の警告が出る場合があります。

※httpd -t 実行時
Apache Configuration: CSP directive 'csp' detected in VirtualHost, only supported at default server level

こちらは、<VirtualHost> ～ </VirtualHost>  内に、CSP ディレクティブ の内容を設定している場合に出力されます。

 CSP on
 CSPFileTypes *

などの IRIS にアクセスをするための設定は、<VirtualHost> ディレクティブの外に設定するようにしてください。

詳細は以下のドキュメントをご覧ください。
追加ファイル・タイプを渡すための Apache の構成 (すべてのプラットフォーム)

プロセスの単位の詳細情報（使用メモリサイズ、ユーザ名、実行ルーチンなど）は管理ポータルで確認できますが、それらをコマンドで取得する方法をご紹介します。 

管理ポータル：
[システムオペレーション] > [プロセス]  （プロセス毎の）詳細リンク 

%SYS.ProcessQuery クラスを使用して、以下のように行います。

USER>setx

Embedded Python で呼び出したい場合は以下のようにします。

＃ 以下のサンプルは自プロセスの情報を取得する方法

実行例：

USER>:p
 
Python 

こちらで、実行ルーチン（Routine）や、グローバル参照数（GlobalReferences）、プロセスの状態（State）なども確認できます。
エラー発生時など、デバッグでプロセスの状態を調査したい場合にぜひご活用ください。
【ご参考】
すべてのプロセスの情報を取得する方法は、以下の記事でご紹介しています。
プロセス一覧をプログラムで取得する方法

これは InterSystems FAQ サイトの記事です。

注意：本番環境では実行しないでください。テスト環境でご利用ください。

開発時にプロダクションに残っているキューを一括でクリアしたり、プロダクションに関連した一次的な情報をすべて消去したい場合、以下メソッドを利用して実行中のプロダクション情報をリセットできます。

set$namespace"プロダクションのあるネームスペース名指定"

ドキュメント：ネームスペースでのプロダクションのリセット

プロダクション全体ではなく、一部コンポーネントの実行中データをリセットする場合は、アダプタの ClearAllAppData() を使用します。
引数にはプロダクションに登録している構成名を指定してください。

例）SQLインバウンドアダプタが保持している永続値をリセットする

"構成名称"

ドキュメント：受信アダプタで以前に処理された行のリセット

例）FTPインバウンドアダプタが処理したファイルの情報をリセットする

"構成名称"

FHIRドキュメント（診療情報提供書や退院時サマリ―など）をFHIRリポジトリにPOSTする場合、

エンドポイント/Bundle

上記URLでPOSTできます。（以下の例では、IRIS for Healthに用意したFHIRリポジトリを使用しています。）

GET要求で確認してみます。

登録できたことを確認できました。

FHIRリポジトリに登録したFHIRドキュメントですが、文書番号を指定してGETできると便利なのですが、現時点（バージョン2023.1）のIRIS for HealthのFHIRリポジトリでは、FHIR標準仕様にあるBundle の SearchParameter ：composition について未対応のため、Composition.identifier を指定した Bundleリソースに対する GET要求が行えません。

そこで回避策として、Bundle登録時 Composition.identifier.value に設定している文書番号を Bundle.identifier.value にも設定しPOSTします。こうすることで、Bundle の Search Parameter：identifier に文書番号を指定でき、対象となるBundleリソースをGETできます。

IRIS for HealthのFHIRリポジトリには、「条件付き削除結果の最大数」がデフォルトで3件に設定されています。

そのため、条件指定のDELETE要求で4件以上が対象となる場合、以下のエラーが発生します。

例えば、あるcodeで条件指定したリソースが5件あるとします。

これをDELETE要求に変えて実行すると、以下のようにHTTPステータス412が戻り、「Conditional delete search found more than maximum allowed number of 3 results」のエラーが発生します。

HTTP応答を確認すると、ConditionalDeleteOverflowのエラーが発生しています。

これは、条件付き削除の最大値が3件で設定されているため、発生しています。

ということで、FHIR Configuration画面を開き、設定を確認します。

管理ポータル > [Health] > ネームスペース選択 > [FHIR Configuration] > [Server Configuration]

対象のエンドポイントを選択すると以下の設定画面が表示されます。

Max Conditional Delete Resultsの項目に 3 と設定されています。

FHIRリソースをリポジトリから削除するには、対象リソースに対してDELETE要求を使用すればよいのですが、例えば「テスト的に登録していたリソースばかりなので、リポジトリのデータを一括で全消去したい！」という場合の方法をご紹介します。

実行前に、エンドポイントのURLを確認します。

管理ポータル > [Health] > ネームスペース選択 > [FHIR Configuration] > [Server Configuration] で確認できます。

データの全消去を行うには、IRIS for HealthのFHIRサーバ機能で提供されているAPIを使用します。実行のため IRISのターミナルを開く、またはIRISにログインします。

ご参考：HS.FHIRServer.Storage.Json.RepoManagerクラスにあるDeleteService()メソッドを使用して削除します。

WindowsにIRISをインストールされている場合は、タスクバー上のIRISランチャー  をクリックし、ターミナルを選択します。

Windows以外でお試しいただいてる場合は、iris session コマンドでIRISにログインしてください。

FHIR関連トレーニングの中で複数の方よりいただいたご質問をご紹介していきます。

IRIS for HealthのFHIRリポジトリでは、リソースPOST時のデフォルトの動作としてリポジトリ内でユニークな論理ID（id）を自動的に付与します。

例えば、以下のようなPatientリソースをPOSTした場合
​

{
    "resourceType""Patient"

以下　"id":"1"　とあるように、リソースidにリポジトリ内でユニークとなる値を自動で設定します。（Patientリソースの一部抜粋） 

Patientリソースを例に、もともとユニークな値である患者IDをFHIRリポジトリのリソースidとして使用したい！という場合の登録方法をご紹介します。

新規登録時はPOST要求を使用しますが、PUT要求を利用することでリソースidを指定した登録が行えます。

指定するURLは、例えば患者IDが P101001 の場合

http://localhost:52773/csp/healthshare/r4fhirnamespace/fhir/r4/Patient/P101001

のように指定します。

これは InterSystems FAQ サイトの記事です。
 

こちらでは、InterSystems Container Registry(ICR) より入手可能なDockerコンテナイメージを使用する方法をご案内します。

※WRCDirectのダウンロードサイト より入手可能なイメージを使用する場合も同じようにできます。
　その際、Name：Web でフィルタリングしていただくと、Web Gateway の Docker イメージが見つけやすくなります。
※インターシステムズが提供する webgateway コンテナイメージには、Web ゲートウェイと Apache Web サーバの両方が含まれています。

【手順】

1. ブラウザより https://containers.intersystems.com/ にアクセスし、インターシステムズWRC認証情報でログインします。

2. Dockerログイントークンかログインコマンドを取得します。

3. 取得した認証情報を使い、Dockerインターフェース(PowerShellウインドウやLinuxコマンドラインなど)でICRへの認証を行います。
    以下の例のように、表示されるDocker ログインコマンドをコピー、ペーストすることで認証できます。

これは InterSystems FAQ サイトの記事です。

ターミナルでルーチンやクラスのコンパイルを行う際、コンパイル結果が画面に表示されるのでエラーが発生した場合でも確認しやすいですが、一括コンパイルの場合は、大量のコンパイル結果の中にエラー情報が含まれてしまうためエラー情報だけを取得したい場合には少し工夫が必要です。

以下、ルーチン／クラスの一括コンパイル時の結果からエラー情報を取得する方法をご紹介します。

ルーチンの場合

ネームスペースにあるルーチンをターミナルで一括コンパイルするには、%Library.Routine クラスの CompileAll() メソッドを使用します。

以下実行例は、USERネームスペースにあるルーチンを一括コンパイルした結果です。TestRoutine1でコンパイルエラーが発生しています。

USER>do##class

大量にルーチンがある場合、出力結果が流れて画面から消えてしまうため、カレントデバイスに出力されている内容をファイル保存し、保存したファイルの中からエラー情報を取得するようにします。

1) コンパイル結果をファイルに保存する

CompileAll() メソッドの第2引数にファイル名をフルパスで指定します。

開発者の皆さん、こんにちは！

この記事では、ワークフローコンポーネントを使ってみよう！～使用手順解説～ でご紹介したユーザ操作画面（ユーザポータル）を任意のWebアプリに変更する際に便利な REST API の使用方法をご紹介します。

ワークフロー用 REST APIですが、開発者コミュニティのサンプル公開ページ：Open Exchange に公開されているAPIでどなたでも自由にご利用いただけます。

Open Exchangeの検索ボックスに「Workflow rest」と入力すると出てきます。EnsembleWorkflow が対象のサンプルです。

ちなみに、2023年6月2日時点で724のアプリケーションが公開されているようです👀

これは InterSystems FAQ サイトの記事です。

%SYSTEMパッケージには沢山の便利なシステムクラスがあり、Embedded Pythonでも一般クラスと同様に%SYSTEMパッケージ以下クラスを操作できます（iris.cls("クラス名").メソッド名()で呼び出せます）。

ObjectScriptでは、$SYSTEM特殊変数を利用して、%SYSTEMパッケージ以下クラスのメソッドを呼び出すことができますが、Embedded Pythonでは、iris.system を利用して実行することができます。

以下実行例をご紹介します。

現在のネームスペースを取得する

一般クラスと同じ呼び出し方の例

iris.cls("%SYSTEM.SYS"

iris.systemを利用する例

iris.system.SYS.NameSpace()

binディレクトリのパスを返す

一般クラスと同じ呼び出し方の例

iris.cls("%SYSTEM.Util"

iris.systemを利用する例

SQL関連をまとめたSQLクラスの例は以下の通りです。

YYYY-MM-DDから$horolog形式の日付を返す

一般クラスと同じ呼び出し方の例

iris.cls(

iris.systemを利用する例

※ 現時点（2023/5/1）では、%SYSTEM.SQLクラス

これは InterSystems FAQ サイトの記事です。
 

Apache環境でRESTを動かすための設定方法は以下のとおりです。

1. Webゲートウェイをインストールします

添付（Webゲートウェイインストール手順.pdf）の手順に従い、Webゲートウェイをインストールします。
※Webゲートウェイをインストールする前に、Apacheを停止してください。

2. Apache 構成ファイルの設定を行います

/etc/httpd/conf/httpd.conf の末尾に以下を追加します。
追加後、Apacheを再起動してください。

※こちらの設定では、Apacheに対するすべてのリクエストをWebゲートウェイに渡す設定になります。
　<Location />ではなく、<Location /rest> にすると、/rest のみWebゲートウェイに渡すようになります。
　(既に他の目的でApacheを使用している場合、<Location /> の設定にするとそちらが動かなくなりますのでご注意ください)

Apacheの再起動：

# systemctl stop httpd.service           // Apache の停止（開始している場合）

これは InterSystems FAQ サイトの記事です。

IRISではジャーナルファイルが自動的に圧縮される仕組みが導入されています。

ジャーナルファイルの圧縮機能について詳しくは、別の記事「ジャーナル圧縮機能について」をご参照ください。

例えば、CachéからIRISへ移行された後に、念のためIRISで更新されたデータを手動でCachéにも反映させたいことばある場合に、IRISのジャーナルファイルをCachéにリストアすることができます。

手順は以下の通りです。

(手順1) IRISのジャーナルファイル（YYYYMMDD.nnnz） ファイルを解凍する
(手順2,3) 解凍した ジャーナルファイルを Cachéに転送してリストアする

リストアの方法として、以下の2パタンをご紹介

(A) 指定グローバルとデータベースについて、指定ジャーナルから、全エントリをリストア
(B) 指定グローバルとデータベースについて、指定ジャーナルから、特定のアドレスまでリストアする

(A) 指定グローバルとデータベースについて、指定ジャーナルから、全エントリをリストア

(手順1) IRISサーバ上で以下のコマンドにより、ジャーナルを解凍する

IRIS 2022.1 以降、現在実行中のジャーナル以外は、拡張子 z で圧縮されています。

以下のコマンドで解凍し、指定のフォルダにコピーします。

開発者の皆さん、こんにちは！

IRISのInteroperability（相互運用性）機能（Ensembleのプロダクション）を使用してどのようなことができるか、コード例をご覧いただきながら／サンプルを動かしながらご確認いただける記事をまとめてみました。

ぜひご参照ください。

記事一覧：

• インストール環境をお持ちでない方でもお試しいただけるチュートリアル
• ファイル連携を試してみたい
• 常駐プロセスを作りたい
• レコードマップ機能を使いたい
• MQTTを使いたい
• FHIRサーバサイドアプリケーションを試したい
• Interoperabilityを学習したい
• システム連携の自動的な流れの中にユーザからの指示を介入できる「ワークフローコンポーネント」を試したい（2023/6/1 追記）
• REST経由で情報を入力する場合の Interoperability（相互運用性機能）のサンプル（2023/5/30 追記）

すべての永続クラス (%Persistent) およびシリアルクラス(%SerialObject) をコンパイルすると、ストレージ定義 が展開されます。
ストレージ定義には、オブジェクト保存と検索用のグローバル構造情報、ストレージインタフェースによって使用される追加のパラメータや、ストレージクラスを定義する一連のキーワードや値などが含まれます。

スタジオや ObjectScript コマンドを使用して永続クラスをエクスポートする場合、既定では以下のようなストレージ情報が付与された状態でエクスポートされます。

Storage Default
{
<Data name="PersonDefaultData""1"

こちらの記事では、このストレージ定義を除いた状態でクラスをエクスポートする方法をご紹介します。
 

「/skipstorage」というエクスポート修飾子を指定すると、クラスのストレージ情報なしでエクスポートすることが可能です。

コマンドで使用する方法は以下のようになります。

"Sample.Person.cls"

IRIS スタジオで設定する場合は、スタジオの [ツール] > [オプション] より 環境 - 詳細 で以下のように、エクスポートフラグに「/skipstorage」を追加します。

InterSystems IRIS で使用できるユーティリティの一部を一覧でご紹介します。

以下の表の各ユーティリティ名をクリックすると、ユーティリティの詳細情報をご覧いただけます。

これは InterSystems FAQ サイトの記事です。

サブスクリプトレベルマッピングされたグローバルを、トップノードから全体をkillする場合、<SLMSPAN>エラーとなり削除ができません。

これは、サブスクリプトレベルマッピングされたグローバルについては、マッピングを跨いだサブスクリプト範囲の kill コマンドは行えないためです。

// 以下のように、別々のデータベースにサブスクリプトマッピンググローバルが存在する場合：^TESTK

現ネームスペース(データベース)のグローバルのみ削除するには、次のように指定して下さい。

NAMESPACE>

サブスクリプトレベルでマッピングしているグローバルは、データベースに移動して直接Killする必要があります。
データベースに移動する場合は以下のようにします。

set

$system.OBJ.Load でグローバルをインポートする場合は、既定の動作では、インポート対象のグローバルを実施前に kill します。
そのため、対象のグローバルが、サブスクリプトレベルマッピングされている場合、<SLMSPAN>エラーになってしまいます。
この場合は、以下のように $system.

こちらの記事 では、ヘルスモニタのセンサー値を ^%SYSMONMGR ユーティリティを使用して変更する方法をご紹介しました。
今回は、ヘルスモニターセンサー値を コマンド（プログラム）で変更する方法をご紹介します。

ヘルスモニタは、CPUUsage（CPU使用率）、DBLatency（DBからのランダム読取に要する時間）、DiskPercentFull（DBのディスク使用率）などの該当しきい値を超えた場合に、通知を生成します。
※ヘルスモニタのセンサー値（閾値）について

センサーのしきい値を超えると、IRISのシステムログ（messages.log）に以下のようなメッセージが記録されます。

これは InterSystems FAQ サイトの記事です。

InterSystems IRIS では、柔軟でユーザ拡張可能な監視ツールである「システムモニタ」をお使いいただくことが可能です。

システムモニタには、以下の3つのインスタンス監視ツールがあります。

• システムモニタ：システムの状態およびリソースを監視・固定パラメータに基づいて通知 (アラートおよび警告) を生成
• ヘルスモニタ：主要なシステムメトリックおよびユーザ定義メトリックをサンプリング＆ユーザ変更可能パラメータおよび規定の通常値と比較し、該当しきい値を超えた場合に通知を生成
  ※ヘルスモニタは既定では無効となっています。
  　起動するには、^%SYSMONMGR を使用してヘルスモニタを有効にする必要があります。
  　ただし、システムモニタのサブスクライバクラスは、ヘルスモニタが有効でなくても動作します。
• アプリケーションモニタ：重要なシステムメトリックをサンプリング＆ユーザが作成したアラート定義を使用して評価

messages.logに、以下のようなログが記録される場合があります。

[SYSTEM MONITOR] DBLatency(c:\xxx\) Warning: DBLatency = 1510 ( Warnvalue is 1000).
※このメッセージの意味については こちらの記事 をご覧ください。