クラウド環境では、割当てられたvCPU数に関わらず1CPUとしてカントされます。

Nextra runtimeにはアプリケーション・クラスタリング機能が実装済みであり、以下の障害に対応します。 1. Process ダウン 2. N/W ダウン 3. OS ダウン 当該Processがダウンしていた場合、かつ同じセットのサーバプロセスが起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。 当該サーバプロセスに到達できない場合、かつ同じセットのサーバプロセスが別ルートで到達できるサーバマシン上で起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。 当該OSがダウンしていた場合、かつ別サーバマシン上に同じセットのサーバプロセスが起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。

はい。 1つクライアントプロセスは複数のサーバプロセスにアクセスできます。 また、サーバプロセスも複数のクライアントプロセス要求に応答できます。

Nextra は、標準 SQL に若干手を加えて使用します。 （詳細は『リファレンス』を参照のこと）

コマンドラインにて以下を発行します。 > broker -v 例） > broker -v Inspire International Inc. Broker Version 6.0-0.0R ハイフンより前、この場合 6.0 が製品のバージョンとなります。

RPC完了前に、クライアントとサーバの接続が切断された。サーバまたはネットワークのいずれかがダウンしました。 [対処方法] サーバのホストマシンをpingすることによって、ネットワークをテストしてください。ネットワーク接続が確立できていてもRPCが完了できない場合には、サーバプロセスがダウンしているものと考えられるので、サーバの再起動が必要になります。RPCを繰り返し呼び出しても問題がない場合には、クライアントコードを編集して、ユーザがRPCを再実行できるようにしてください。 弊社サポート依頼の本件に対する質問の多くが、DEDICATED SERVER （デディケイテッド・サーバ）を採用し、子プロセス内にて処理されるユーザロジックが正常に終了していない場合が多数を占めます。 この場合の対応としては、サーバ環境ファイル内「DCE_DEDICATED」 環境変数をコメントアウトし、ユーザー様記載のビジネスロジックが正常に処理されることを確認することをお薦めします。

[エラーコード: 29] DCE_READFAIL [現象の説明] ODE ERROR: <29>は、Winsock のエラーコード 10054 を受けてログに出力されます。 10054 エラーは、通信確立後、TCP/IPレベルでRSTフラグが立ったパケットを受信した場合に発生します。 RSTフラグが立ったパケットを受信すると通信が切断され、ODE ERROR: <29> がログ出力されます。 サーバ側が、クライアントからのRPCの処理を受け付けましたが、その最中にダウンした。 又は、TCP/IP のコネクッションが、クライアントへのRPC返答前に、セッションが切られた可能性もあります。 何らかの外的要因によってセッションが切断された可能性があります。 ルーティング・経路内の機材（スイッチ、ハブ、NIC）、その他ファイアウォールやウィルスチェックソフトの干渉が考えられます。

『Nextra Tuning Guide（英語のみ）』、および 『運用／設定ガイド』をご覧下さい。 　

Windows 2003 SP2 に於いて、 TCP/IP オフロード機能の不具合が報告されております。 Windows Server 2003 ベースおよび Small Business Server 2003 ベースのコンピューターの既定の SNP 機能をオフにする更新プログラム を参考にして下さい。

通常、クライアントプログラムが終了すると、デディケイテッド・サーバ子プロセスは終了します。 クライアントプログラムから確実に終了するには、dce_dedDisconnect関数をクライアントプログラムから呼び出し、デディケイテッド・サーバ子プロセスを終了させます。

定期的に削除してください。

NIX プラットホームでは fork 関数、Windows では CreateProcess 関数です。

Linux OS上で、COBOL アプリケーションをデディケイテッド・サーバ（環境ファイルで、DCE_DEDICATEDを指定）として設定し、クライアントからアクセスした際、親サーバが以下の標準出力で終了します。 > rts64 : Error 96 encountered in child process これは、MicroFocus Visual COBOL の制限により、システムコールである fork() 使用が不許可となったことに由来します。Nextraは内部的に、デディケイテッド・サーバ子プロセスを生成する際、fork()を使用しております。 参考資料：rts64 : Error 96 encountered in child process 回避策としては、デディケイテッド・サーバを使用せず、並列サーバを使用します。並列サーバについては、「運用／設定ガイド」の「並列サーバ」を参照願います。

dce_remove_all_server()は、クライアントプログラムから呼び出され、サーバ（インタフェース）名を持つサーバ（インタフェース）全ての位置情報をブローカのキャッシュから削除します。 このAPIを、.NETやJavaクライアントから利用することも可能ですが、その場合はサポートにお問い合わせください。 その他、クライアントプログラムで現在使用しているサーバの位置情報を削除するAPIも用意しております。 dce_remove_bad_server()は、クライアントからRPC呼び出し後に呼び出され、使用したサーバ（インタフェース）名を持つサーバ（インタフェース）の位置情報をブローカのキャッシュから削除します。 尚、これらのAPIは、Nextra5にてサポートされるようになりました。 また、broklist ユーティリティーを使用することで、起動していないサーバのエントリーをbrokerキャッシュより削除したり、特定のエントリーを削除することができます。

Nextraサーバ内ユーザプログラム内で、dce_set_exit() を呼び出します。 Nextraリファレンスマニュアル「第5章 Nextra API」の「dce_set_exit()」を参考にしてください。

公開された API ファンクションとしては、残念ながら存在しません。

short, long, integer, float, double precision, character, void, object（Java言語のみ）。 Nextra マニュアル 「リファレンス」 のデータ型情報 3-1 を参照して下さい。

AmViewer（ビューア）上で、「Edit」ボタンをクリックし"Use Explicit Port"をチェックして任 意の Port 番号を入力してください。 Port 番号を指定したアプリケーション・サーバを AppMinder から起動すると、この TCP/IP Port を使用して起動します。

当該.cfgファイルが、ファイル内指定のフォルダパスと不一致の可能性が原因と考えられます。 以下の操作をお願いします。 AmViewer （ビューア）より、File メニューより Save As を選択し .cfg ファイルを １）別フォルダに保存、または ２）別名で同じフォルダに保存の何れかの操作を行います。 １）または２）の何れの場合も、次回利用の際は .cfgファイル内の path、及び file 指定を再確認し、必要な修正を加えてご利用ください。 以下が確認方法となります。 当該 .cfgファイルを Notepad などのテキストエディタで開き、ファイルの最後の方に以下のような記述を探します。 [path=C:/App/Nextra/Appminder] [file=nextra.cfg] [version=Version 3.3]

あるホスト上におけるサービスの起動または停止を指示すると、モニタは、そのホストで動作しているエージェントに要求を送ります。そのあと、エージェントは、この要求を実行します。各エージェントは、エージェントのホスト上で動作しているすべてのサービスに関する情報が格納されたローカルファイルを保守します。エージェントのローカルファイル（appmagt.cdb）は、絶対に手動で変更しないでください。 又、 -recover のオプションを付けて起動する場合は、このローカルファイルが必要となりますのでご注意ください。

ammon.ini（モニタ初期化ファイル）内の以下の行を削除した後、再起動願います。 AMMON_ACTIVE=,C:/Nextra/appminder/ammon.cfg 注意点としては、AppMinderにてアプリケーションを終了する場合には、 コマンドラインユーティリティー amuldsvr AmViewer（ビューア） の何れかより、アプリケーションの終了を行ってください。 何れかの操作無しに ammon（モニタ）を強制終了すると、AMMON_ACTIVE 属性が ammon.ini ファイルに残留することなり、次回起動時にこのエラーが発生します。

brokerやアプリケーションに対して"Edit"ボタンから "File"をクリックして"Error File Name"に「nuｌｌ」と指定してください。 "Error File Directory"は任意で構いません。 指定先がUnixの場合は、"Error File Name"に「nuｌｌ」と指定し、"Error File Directory"には、「/dev」と指定してください。

この状態は、通常 ammon（モニター）がサーバマシン上で監視を行っている agent（エージェント）との通信で待ちになっている可能性があります。 その agent（エージェント）自体も、実際には、アプリケーションの起動、アプリケーションプロセスへのPING、更にはブローカ（アプリケーション用）との通信でBusy（ビジー）の状態にある可能性があります。ですので、暫く待ててば、AmViewer（ビューア）は応答するようになるでしょう。 ただし、どうしても待てない場合や、最悪の場合は、以下を行ってください。 AmViewer（ビューア）をタスクマネージャで強制終了する。プロセス名は、amviewer.exeです。 そして、AmViewer（ビューア）が繋ぎに行っている ammon（モニター）も強制終了してください。プロセス名はammon.exe（Unixでは ammon ）です。 その後、ammon（モニター）の起動、AmViewer（ビューア）を立ち上げ、繋ぎ直せば、アプリを再度監視することができます。

amlodsvr コマンドユーティリティーをご利用ください。停止する場合は、amuldsvr になります。

appmagt.ini ファイルの中の AMAGENT_PROC_START_PAUSE の値を変更してください。 初期値は100（秒）です。

appmagt.ini ファイルの中の AMAGENT_MGMTINTERVAL の値を変更してください。初期値は120（秒）です。

起動できます。詳しくは、『運用／設定ガイド』「第3章アプリケーションの設定」を参考にしてください。

『AppMinder マニュアル』第4章にある「プロセスのステータスシンボル」を参照してください。

一度 AppMinder 環境を再設定してから、AppMinder プロセスを起動してください。 *.lst, *.mem, *.ini, *.cdb ファイルを削除して、ammon と appmagt の ini ファイルを再作成してください。 また、AppMinderを利用してアプリケーションの起動を行ったが、AmViewerやamuldsvr コマンドユーティリティーを使用せずにアプリケーションを強制終了させてた場合、*.lst, *.mem,?*.cdb ファイルの削除後、ammon.ini に「AMMON_ACTIVE=」の行が存在した場合はその行を削除してから、再度 ammon, appmagt の起動を行ってください。

上限は 24:00 です。それ以上の時間を設定すると(たとえば 24:10 と設定すると) 24:00 とみなされます。

AppMinder のコンポーネント間でやり取りされている情報は、常に暗号化されているため、この情報がログに書き出されると意味不明な情報にみえてしまいます。 モニタの環境ファイルのログレベルを「warning, debug」にしておけば、情報が書き出されなくなります。

月単位でのスケジューリング機能は現在サポートされていません。

可能です。 以下のいずれかの方法で対応してください。 AmViewer のスケジュール機能を使用する。 AppMinder で用意されている、API ファンクションを利用して AppMinder クライアントを作成し、タイムスケジュールに従ってこのクライアントを実行する事によって行えます。

ありません。

クライアントからブローカにサーバの IPアドレスが要求されたとき(①)、DCE_EXTCLIENT に記述された IP_client1(②)と、問合せクライアントの IP アドレスが一致した場合、且つ現在ブローカに動的に登録されているサーバIPアドレス(③)と、DCE_TRANSCRIPTの IP_server1が一致する場合に、アドレス変換表に記述されている IP_server2 をクライアントに返します。 例： DCE_EXTCLIENT=211.168.0.255 DCE_TRANSCRIPT=192.168.0.112, 211,168.0.112 問合せクライアントの IP アドレスが211.168.0.100であった場合で、かつ当該サーバプロセスのIPアドレスが、192.168.0.112としてbrokerのキャッシュにサーバのIPアドレスが登録されていた場合、サーバプロセスのIPアドレスは、211.168.0.112としてクライアントプロセスに渡されます。

dce_querybroker() をコールして、アクセス可能なサーバプロセス一覧を取得する。これにより、1) の判断が可能となります。

Nextra では、ブローカのポート番号は運用者が環境ファイルに書き込むことにより指定することが出来ます。 サーバプロセスのポート番号は OS がサーバ起動時にアサインするのですが、環境ファイルの DCE_SERVERPORT で運用者が指定することが出来ます。 その為、ブローカ、サーバプロセスを FireWall 内に置くような設定は可能です。

MicroFocus COBOL のユーザで、かつ Server Express では、CBL_DEBUGBREAK ルーチンを使用して、サーバ上で別プロセスから起動されている COBOL プログラムをダイナミックにアニメートする機能が追加されています。 サーバーコードの PROCEDURE DIVISION でデバッグを始めたい個所に CALL "CBL_DEBUGBREAK" を挿入し、コンパイル時に cob -xeg "RPCMAIN" でコンパイルすることで、クライアントや別プロセスから呼び出しがかかった時点でアニメータが自動的に起動されてデバッグができます。

Linux OS上で、COBOL アプリケーションをデディケイテッド・サーバ（環境ファイルで、DCE_DEDICATEDを指定）として設定し、クライアントからアクセスした際、親サーバが以下の標準出力で終了します。 > rts64 : Error 96 encountered in child process これは、MicroFocus Visual COBOL の制限により、システムコールである fork() 使用が不許可となったことに由来します。Nextraは内部的に、デディケイテッド・サーバ子プロセスを生成する際、fork()を使用しております。 参考資料：rts64 : Error 96 encountered in child process 回避策としては、デディケイテッド・サーバを使用せず、並列サーバを使用します。並列サーバについては、「運用／設定ガイド」の「並列サーバ」を参照願います。

クライアントがサーバと同じマシン（同じIPアドレス）上に於いてRPC通信を行うにも係わらず、DCE_EXTCLIENT環境 ファイル属性にて指定された範囲の場合、DCE_TRANSCRIPT環境ファイル属性にて指定された変換後IPアドレスが ブローカよりクライアントへ返信され、クライアントは、変換後のIPアドレスを利用してサーバへのセッションを確保 しておりました。 Nextra6に於ける本例外処理追加により、 クラスCルール（255.255.255.0）のクライアントからのアクセスの場合、変換後サーバ IPアドレスではなく、変換前、つまり元来のサーバIPアドレスがクライアントへ返信されることとなりました。

Nextra v6 IPv6サポートに inet_pton 関数が利用されております。この関数は、WS2_32.dll システムDLLに存在し、XP及びWindows2003ではサポートされておりません。 inet_pton 関数を利用しないNextra v6 を用意しておりますので、弊社サポートにお問い合わせください。

DCE_MYIPADDRESS 環境ファイル属性に利用したいインタフェースのIPアドレスしてください。 指定例） DCE_MYIPADDRESS=211.168.1.100 v5.2-2.1以降で利用可能です。

Tuning Guide（英語のみ）を用意しておりますのでそちらをご覧ください。

Nextra の全てのサービスは、 TCP/IP ポートを通じて通信しますが、大量に Nextra サービスを起動する場合には、以下のレジストリの変更、または追加が必要になります。 TcpTimedWaitDelay MaxUserPort

クライアント環境ファイルに、「DCE_EXTSEARCH=1」を指定してください。DCE_BROKER属性に複数のブローカが登録されていて、例えば１番目のbrokerと接続できたが、そのbrokerに目的のサーバが登録されていない場合、次に登録されているbrokerに目的のサーバを探しに行きます。この属性が設定されていない場合、最初のbrokerにサーバが登録されていない時点でエラーとなります。

brokerに大量のサーバを同時に登録する場合や、Nextraアプリケーションサーバに対して大量の同時アクセスが発生した場合に、TCP/IP PortでBacklog Queue（バックログ・キュー）に入ることができなかったリクエストは、Queue（キュー）溢れ（Time Out）になります。 これが発生した場合、Nextra/RPCライブラリでは、並列サーバなどに迂回する機能を備えておりますが、Queue溢れになる状況は好ましくありません。 参考までに、Queue溢れが起こった場合は、Unixでは"ETIMEOUT" 、Windowsでは"WSATIMEOUT"のシステムエラーとなり、Nextra環境ファイルで指定したログファイルに記録されます。 これを回避するために、Nextraランタイムでは、環境変数「LISTEN_QUEUES」 をご提供しております。 実行する環境にて、この環境変数を適切に設定してください。 設定有効値は １～INT_MAX でデフォルト値は 5 となっています。 この環境変数「LISTEN_QUEUS」で指定した値は、Queueのサイズを指定するもので、実際のBacklog Queueの数ではありません。 各プラットフォームでのBacklog Queue数は、LISTEN_QUEUES指定値のおおむね1.5～2倍になります。同時並列処理が必要なアプリケーションの場合には、並列サーバを利用するか、デディケイテッド・サーバ（Dedicated Server）を利用してください。

WAN環境で利用の場合、PCクライアントとの接続が突然切れる場合などが考えられます。Nextra/RPCライブラリでは、そういった状況に対応するために、以下の環境ファイル属性をご提供しております。 DCE_CLN_TIMEOUT DCE_SVR_TIMEOUT DCE_RECEIVETIMEOUT DCE_CLN_TIMEOUTは、クライアント側RPCにて、データを受信する際に通信がTOする時間を指定します。DCE_SVR_TIMEOUTは、サーバ側RPCにて、データを受信する際に通信がTOする時間を指定します。DCE_RECEIVETIMEOUTに値を設定すると、DCE_CLN_TIMNEOUTとDCE_SVR_TIMEOUT両方にこの値が設定されます。brokerのデフォルト値は、全て10秒となっております。詳しくは『リファレンス』「環境ファイル属性」を参照してください。 その他、サーバマシンのTCP/IP Kernel パラメータにおける、TCP/IPメッセージ送信のトータルの再送タイムアウト(RTO)の値の設定が必要な場合があります。 この再送時間を短縮するには、各OSのTCP Kernel パラメータのチューニングが必要になります。 Solaris/HP-UXでは、tcp_ip_abort_intervalがそのパラメータになります。

broklistユーティリティーの "-add"オプションを使用することにより、再度登録することができます。

クライアントプログラムからのアクセスにより、ブローカ（broker）キャッシュにあるサーバ位置情報が更新され、古い情報は自動的に削除されます。強制的にブローカ（broker）キャッシュにあるサーバ位置情報を更新したい場合は、broklist ユーティリティーを利用してください。 >broklist -update HOST_NAME PORT

可能です。 方法としては、ブローカの階層化の機能を使用して、並列ブローカにサーバを登録し、それぞれのクライアントがそれぞれのブローカにサーバプロセスの照会を行うようにするというものです。その時、DCE_LOCAL を環境ファイルにセットして、親ブローカに行かないようにするという方法もあります。 また、クライアントのコードを共用したいのであれば、例えば、サーバはバリアブルネームド サーバにしておきます(名称は"サーバ A_srv1"のようにするとわかり易いでしょう)。 クライアントが srv1 を呼び出す際にアクセスするサーバプロセス名を判断するようなロジックをクライアントに組み込んでおき"サーバをコールする方法がとれます。