top of page

Q&A

アンカー 1
  • クラウド環境に於けるライセンス体系を教えて下さい。
    クラウド環境では、割当てられたvCPU数に関わらず1CPUとしてカントされます。
  • Nextraの障害回避機能について
    Nextra runtimeにはアプリケーション・クラスタリング機能が実装済みであり、以下の障害に対応します。 1. Process ダウン 2. N/W ダウン 3. OS ダウン 当該Processがダウンしていた場合、かつ同じセットのサーバプロセスが起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。 当該サーバプロセスに到達できない場合、かつ同じセットのサーバプロセスが別ルートで到達できるサーバマシン上で起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。 当該OSがダウンしていた場合、かつ別サーバマシン上に同じセットのサーバプロセスが起動していた場合は、そのサーバプロセスを使用するようにNextra runtime内でルーティングします。
  • 1つのクライアントプロセスは複数のサーバプロセスにアクセスできますか?
    はい。 1つクライアントプロセスは複数のサーバプロセスにアクセスできます。 また、サーバプロセスも複数のクライアントプロセス要求に応答できます。
  • SQL 文は標準フォーマットで記述されますか?
    Nextra は、標準 SQL に若干手を加えて使用します。 (詳細は『リファレンス』を参照のこと)
  • サーバ内にインストールされている Nextra のバージョンを確認する方法はありますか?
    コマンドラインにて以下を発行します。 > broker -v 例) > broker -v Inspire International Inc. Broker Version 6.0-0.0R ハイフンより前、この場合 6.0 が製品のバージョンとなります。
  • DCE_ERRNUM to <ODE ERROR: <24> Problems with peer during transaction> from <dce_rpc_receive>
    RPC完了前に、クライアントとサーバの接続が切断された。サーバまたはネットワークのいずれかがダウンしました。 [対処方法] サーバのホストマシンをpingすることによって、ネットワークをテストしてください。ネットワーク接続が確立できていてもRPCが完了できない場合には、サーバプロセスがダウンしているものと考えられるので、サーバの再起動が必要になります。RPCを繰り返し呼び出しても問題がない場合には、クライアントコードを編集して、ユーザがRPCを再実行できるようにしてください。 弊社サポート依頼の本件に対する質問の多くが、DEDICATED SERVER (デディケイテッド・サーバ)を採用し、子プロセス内にて処理されるユーザロジックが正常に終了していない場合が多数を占めます。 この場合の対応としては、サーバ環境ファイル内「DCE_DEDICATED」 環境変数をコメントアウトし、ユーザー様記載のビジネスロジックが正常に処理されることを確認することをお薦めします。
  • パフォーマンスを改善したいのですが、どうしたらよろしいでしょうか?
    『Nextra Tuning Guide(英語のみ)』、および 『運用/設定ガイド』をご覧下さい。  
  • Windows 2003 SP2 サーバを利用しているのですが、RPCのレスポンスが異常に遅く困っております。
    Windows 2003 SP2 に於いて、 TCP/IP オフロード機能の不具合が報告されております。 Windows Server 2003 ベースおよび Small Business Server 2003 ベースのコンピューターの既定の SNP 機能をオフにする更新プログラム を参考にして下さい。
  • デディケイテッド・サーバ子プロセスを終了させるには、どうしたらよろしいでしょうか?
    通常、クライアントプログラムが終了すると、デディケイテッド・サーバ子プロセスは終了します。 クライアントプログラムから確実に終了するには、dce_dedDisconnect関数をクライアントプログラムから呼び出し、デディケイテッド・サーバ子プロセスを終了させます。
  • デディケイテッド・サーバを使用するとたくさんログファイルが作成されてしまいます。どうしたらよろしいでしょうか?
    定期的に削除してください。
  • デディケイテッド・サーバを使用する場合、子プロセスの生成は具体的に何と言う関数で生成されるのでしょうか?
    NIX プラットホームでは fork 関数、Windows では CreateProcess 関数です。
  • COBOL アプリケーションとデディケイテッド・サーバ
    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 回避策としては、デディケイテッド・サーバを使用せず、並列サーバを使用します。並列サーバについては、「運用/設定ガイド」の「並列サーバ」を参照願います。
  • broker(ブローカ)キャッシュにあるサーバ位置情報を、クライアントプログラムから削除できますか ?
    dce_remove_all_server()は、クライアントプログラムから呼び出され、サーバ(インタフェース)名を持つサーバ(インタフェース)全ての位置情報をブローカのキャッシュから削除します。 このAPIを、.NETやJavaクライアントから利用することも可能ですが、その場合はサポートにお問い合わせください。 その他、クライアントプログラムで現在使用しているサーバの位置情報を削除するAPIも用意しております。 dce_remove_bad_server()は、クライアントからRPC呼び出し後に呼び出され、使用したサーバ(インタフェース)名を持つサーバ(インタフェース)の位置情報をブローカのキャッシュから削除します。 尚、これらのAPIは、Nextra5にてサポートされるようになりました。 また、broklist ユーティリティーを使用することで、起動していないサーバのエントリーをbrokerキャッシュより削除したり、特定のエントリーを削除することができます。
  • プロセス kill 以外に、Nextraサーバプロセスを終了する方法はありますか?
    Nextraサーバ内ユーザプログラム内で、dce_set_exit() を呼び出します。 Nextraリファレンスマニュアル「第5章 Nextra API」の「dce_set_exit()」を参考にしてください。
  • クライアントプロセスがアクセスしようとしているサーバプロセスの立ち上がっているサーバマシンの IP アドレスとサーバプロセスのポート番号を知る API ファンクションはありますか?
    公開された API ファンクションとしては、残念ながら存在しません。
  • IDL 定義ファイルで指定できるデータタイプは?
    short, long, integer, float, double precision, character, void, object(Java言語のみ)。 Nextra マニュアル 「リファレンス」 のデータ型情報 3-1 を参照して下さい。
  • AppMinderを使用しています。サーバプロセスの起動TCP/IP ポート番号の指定方法を教えて下さい。
    AmViewer(ビューア)上で、「Edit」ボタンをクリックし"Use Explicit Port"をチェックして任 意の Port 番号を入力してください。 Port 番号を指定したアプリケーション・サーバを AppMinder から起動すると、この TCP/IP Port を使用して起動します。
  • AmViewer(ビューア)上でFile メニューより Save を選択した際、「File doest not exist」のポップアップメッセージ画面に表示され、且つコンフィギュレーション(.cfg)ファイルに設定が保存されませんでした。どうしたらよいでしょうか?
    当該.cfgファイルが、ファイル内指定のフォルダパスと不一致の可能性が原因と考えられます。 以下の操作をお願いします。 AmViewer (ビューア)より、File メニューより Save As を選択し .cfg ファイルを 1)別フォルダに保存、または 2)別名で同じフォルダに保存の何れかの操作を行います。 1)または2)の何れの場合も、次回利用の際は .cfgファイル内の path、及び file 指定を再確認し、必要な修正を加えてご利用ください。 以下が確認方法となります。 当該 .cfgファイルを Notepad などのテキストエディタで開き、ファイルの最後の方に以下のような記述を探します。 [path=C:/App/Nextra/Appminder] [file=nextra.cfg] [version=Version 3.3]
  • agent(エージェント)のローカルファイル(appmagt.cdb)について
    あるホスト上におけるサービスの起動または停止を指示すると、モニタは、そのホストで動作しているエージェントに要求を送ります。そのあと、エージェントは、この要求を実行します。各エージェントは、エージェントのホスト上で動作しているすべてのサービスに関する情報が格納されたローカルファイルを保守します。エージェントのローカルファイル(appmagt.cdb)は、絶対に手動で変更しないでください。 又、 -recover のオプションを付けて起動する場合は、このローカルファイルが必要となりますのでご注意ください。
  • ammon(モニタ)を起動しようとすると、以下のようなエラーが発生し起動できません。 Syntax error in configuration file: ammon.ini
    ammon.ini(モニタ初期化ファイル)内の以下の行を削除した後、再起動願います。 AMMON_ACTIVE=,C:/Nextra/appminder/ammon.cfg 注意点としては、AppMinderにてアプリケーションを終了する場合には、 コマンドラインユーティリティー amuldsvr AmViewer(ビューア) の何れかより、アプリケーションの終了を行ってください。 何れかの操作無しに ammon(モニタ)を強制終了すると、AMMON_ACTIVE 属性が ammon.ini ファイルに残留することなり、次回起動時にこのエラーが発生します。
  • AppMinderを使用すると、brokerやアプリケーションのエラーフィル(Error File)が生成されますが、本番稼動ではリソース確保のためエラーファイルを生成しないようにしたいのですが、可能ですか ?
    brokerやアプリケーションに対して"Edit"ボタンから "File"をクリックして"Error File Name"に「null」と指定してください。 "Error File Directory"は任意で構いません。 指定先がUnixの場合は、"Error File Name"に「null」と指定し、"Error File Directory"には、「/dev」と指定してください。
  • AmViewer(ビューア)が応答しない時はどうしたらよいでしょうか?
    この状態は、通常 ammon(モニター)がサーバマシン上で監視を行っている agent(エージェント)との通信で待ちになっている可能性があります。 その agent(エージェント)自体も、実際には、アプリケーションの起動、アプリケーションプロセスへのPING、更にはブローカ(アプリケーション用)との通信でBusy(ビジー)の状態にある可能性があります。ですので、暫く待ててば、AmViewer(ビューア)は応答するようになるでしょう。 ただし、どうしても待てない場合や、最悪の場合は、以下を行ってください。 AmViewer(ビューア)をタスクマネージャで強制終了する。プロセス名は、amviewer.exeです。 そして、AmViewer(ビューア)が繋ぎに行っている ammon(モニター)も強制終了してください。プロセス名はammon.exe(Unixでは ammon )です。 その後、ammon(モニター)の起動、AmViewer(ビューア)を立ち上げ、繋ぎ直せば、アプリを再度監視することができます。
  • AmViewer(ビューア)を使用せずに、自動的にアプリケーションの起動、停止を行うことはできないでしょうか?
    amlodsvr コマンドユーティリティーをご利用ください。停止する場合は、amuldsvr になります。
  • AppMinderにて「Begin Managing」を実行した場合に、全てのプロセスが「Pinged」になるまでの時間を変更することは可能でしょうか? 設定ファイル等で処理時間を短縮する方法があれば教えてください。
    appmagt.ini ファイルの中の AMAGENT_PROC_START_PAUSE の値を変更してください。 初期値は100(秒)です。
  • エージェント(appmagt)の管理サイクルを短くするにはどうしたらよいのですか?
    appmagt.ini ファイルの中の AMAGENT_MGMTINTERVAL の値を変更してください。初期値は120(秒)です。
  • 一つのマシン上に複数のエージェント(appmagt)は起動できますか?
    起動できます。詳しくは、『運用/設定ガイド』「第3章アプリケーションの設定」を参考にしてください。
  • AmViewer でプロセスを監視する際に、プロセスのステータスで黄色い三角印や、緑色の三角印が出てきますが、それぞれの意味を教えてください。
    『AppMinder マニュアル』第4章にある「プロセスのステータスシンボル」を参照してください。
  • AmViewer を使用してサーバプロセスを起動しようとすると、エラーになってしまいます。(一番上のマスターブローカが赤丸表示になってしまいます。)エラーを改善し、サーバプロセスを起動する方法を教えてください。
    一度 AppMinder 環境を再設定してから、AppMinder プロセスを起動してください。 *.lst, *.mem, *.ini, *.cdb ファイルを削除して、ammon と appmagt の ini ファイルを再作成してください。 また、AppMinderを利用してアプリケーションの起動を行ったが、AmViewerやamuldsvr コマンドユーティリティーを使用せずにアプリケーションを強制終了させてた場合、*.lst, *.mem,?*.cdb ファイルの削除後、ammon.ini に「AMMON_ACTIVE=」の行が存在した場合はその行を削除してから、再度 ammon, appmagt の起動を行ってください。
  • AppMinder のスケジュール画面で設定時間の上限が 23:59 となっているがそれ以上の設定は可能ですか?
    上限は 24:00 です。それ以上の時間を設定すると(たとえば 24:10 と設定すると) 24:00 とみなされます。
  • モニターのログに意味不明なデータが書き出されるのですが、これは必ず出力されてしまうのでしょうか?
    AppMinder のコンポーネント間でやり取りされている情報は、常に暗号化されているため、この情報がログに書き出されると意味不明な情報にみえてしまいます。 モニタの環境ファイルのログレベルを「warning, debug」にしておけば、情報が書き出されなくなります。
  • AppMinder で月単位でのスケジュールはどのように行うのですか?
    月単位でのスケジューリング機能は現在サポートされていません。
  • AppMinder が起動・監視している特定のサーバプロセスを自動で停止し、起動するような事は可能でしょうか。
    可能です。 以下のいずれかの方法で対応してください。 AmViewer のスケジュール機能を使用する。 AppMinder で用意されている、API ファンクションを利用して AppMinder クライアントを作成し、タイムスケジュールに従ってこのクライアントを実行する事によって行えます。
  • AppMinder で監視できるサーバ数に制限があるのでしょうか?
    ありません。
  • Nextra を NAT の外から使用するにはどうすればよいですか?
    クライアントからブローカにサーバの 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としてクライアントプロセスに渡されます。
  • クライアントがサーバプロセスにアクセスした時に、Error No = 5 が返されるが、1) サーバプロセスに対してアクセス権がない(セキュアサーバ)、2)サーバプロセスが起動していないの区別ができない。 これを判断する方法はないのでしょうか?
    dce_querybroker() をコールして、アクセス可能なサーバプロセス一覧を取得する。これにより、1) の判断が可能となります。
  • Nextraで、GUI層をFireWallの外に、それ以外のブローカ・サーバプロセス・その他を FireWall内に置くような設定は可能でしょうか?
    Nextra では、ブローカのポート番号は運用者が環境ファイルに書き込むことにより指定することが出来ます。 サーバプロセスのポート番号は OS がサーバ起動時にアサインするのですが、環境ファイルの DCE_SERVERPORT で運用者が指定することが出来ます。 その為、ブローカ、サーバプロセスを FireWall 内に置くような設定は可能です。
  • サーバ上で別プロセスから起動される COBOL プログラムを、Debugger でデバッグできますか?
    MicroFocus COBOL のユーザで、かつ Server Express では、CBL_DEBUGBREAK ルーチンを使用して、サーバ上で別プロセスから起動されている COBOL プログラムをダイナミックにアニメートする機能が追加されています。 サーバーコードの PROCEDURE DIVISION でデバッグを始めたい個所に CALL "CBL_DEBUGBREAK" を挿入し、コンパイル時に cob -xeg "RPCMAIN" でコンパイルすることで、クライアントや別プロセスから呼び出しがかかった時点でアニメータが自動的に起動されてデバッグができます。
  • Linux OS上での、デディケイテッド・サーバの使用制限。
    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_EXTCLIENT、DCE_TRANSCRIPT例外追加について。
    クライアントがサーバと同じマシン(同じIPアドレス)上に於いてRPC通信を行うにも係わらず、DCE_EXTCLIENT環境 ファイル属性にて指定された範囲の場合、DCE_TRANSCRIPT環境ファイル属性にて指定された変換後IPアドレスが ブローカよりクライアントへ返信され、クライアントは、変換後のIPアドレスを利用してサーバへのセッションを確保 しておりました。 Nextra6に於ける本例外処理追加により、 クラスCルール(255.255.255.0)のクライアントからのアクセスの場合、変換後サーバ IPアドレスではなく、変換前、つまり元来のサーバIPアドレスがクライアントへ返信されることとなりました。
  • broker(ブローカ)を起動した際、 プロシージャエントリポイント inet_pton がダイナミックリンク ライブラリ WS2_32.dll から見つかりませんでした。 とのエラーが表示され起動できません。
    Nextra v6 IPv6サポートに inet_pton 関数が利用されております。この関数は、WS2_32.dll システムDLLに存在し、XP及びWindows2003ではサポートされておりません。 inet_pton 関数を利用しないNextra v6 を用意しておりますので、弊社サポートにお問い合わせください。
  • 複数NIC(Network Interface Card)を備えるサーバマシン上に於いて、どのインタフェースを利用するか指定できませんか?
    DCE_MYIPADDRESS 環境ファイル属性に利用したいインタフェースのIPアドレスしてください。 指定例) DCE_MYIPADDRESS=211.168.1.100 v5.2-2.1以降で利用可能です。
  • パフォーマンスに関して参考になるマニュアルはありませんか?
    Tuning Guide(英語のみ)を用意しておりますのでそちらをご覧ください。
  • Windows サーバ上にて、大量の Nextra サービスを起動するシステムにおける、 Windows レジストリの設定
    Nextra の全てのサービスは、 TCP/IP ポートを通じて通信しますが、大量に Nextra サービスを起動する場合には、以下のレジストリの変更、または追加が必要になります。 TcpTimedWaitDelay MaxUserPort
  • サーバ位置情報が、2つ目に指定したbrokerに登録されていた場合
    クライアント環境ファイルに、「DCE_EXTSEARCH=1」を指定してください。DCE_BROKER属性に複数のブローカが登録されていて、例えば1番目のbrokerと接続できたが、そのbrokerに目的のサーバが登録されていない場合、次に登録されているbrokerに目的のサーバを探しに行きます。この属性が設定されていない場合、最初のbrokerにサーバが登録されていない時点でエラーとなります。
  • Backlog Queue(バックログ・キュー)の設定について
    brokerに大量のサーバを同時に登録する場合や、Nextraアプリケーションサーバに対して大量の同時アクセスが発生した場合に、TCP/IP PortでBacklog Queue(バックログ・キュー)に入ることができなかったリクエストは、Queue(キュー)溢れ(Time Out)になります。 これが発生した場合、Nextra/RPCライブラリでは、並列サーバなどに迂回する機能を備えておりますが、Queue溢れになる状況は好ましくありません。 参考までに、Queue溢れが起こった場合は、Unixでは"ETIMEOUT" 、Windowsでは"WSATIMEOUT"のシステムエラーとなり、Nextra環境ファイルで指定したログファイルに記録されます。 これを回避するために、Nextraランタイムでは、環境変数「LISTEN_QUEUES」 をご提供しております。 実行する環境にて、この環境変数を適切に設定してください。 設定有効値は 1~INT_MAX でデフォルト値は 5 となっています。 この環境変数「LISTEN_QUEUS」で指定した値は、Queueのサイズを指定するもので、実際のBacklog Queueの数ではありません。 各プラットフォームでのBacklog Queue数は、LISTEN_QUEUES指定値のおおむね1.5~2倍になります。同時並列処理が必要なアプリケーションの場合には、並列サーバを利用するか、デディケイテッド・サーバ(Dedicated Server)を利用してください。
  • broker(ブローカ)やNextraサービスのレスポンスが突然悪くなります。WAN環境で利用していますが、何か関係ありますか?
    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がそのパラメータになります。
  • broker(ブローカ)キャッシュにあるサーバ位置情報を間違って削除してしまいました。どうしたらよいですか?
    broklistユーティリティーの "-add"オプションを使用することにより、再度登録することができます。
  • Nextra サーバプログラム(A とします)を夜間に起動・停止しているのですが、翌朝、ブローカに Aプロセスの古い位置情報が残ります。どうしたらよろしいでしょうか?
    クライアントプログラムからのアクセスにより、ブローカ(broker)キャッシュにあるサーバ位置情報が更新され、古い情報は自動的に削除されます。強制的にブローカ(broker)キャッシュにあるサーバ位置情報を更新したい場合は、broklist ユーティリティーを利用してください。 >broklist -update HOST_NAME PORT
  • あるクライアントプログラムを複数個同一マシン上で動かす際、ソースコードを変えずに、異なるサーバマシンに rpc することは可能でしょうか? (クライアントAと B は同じプログラム。共に srv1 と言うサービスをコールするが、クライアントAからはサーバAの srv1 に、クライアントBからはサーバBの srv1 に rpc したい。)
    可能です。 方法としては、ブローカの階層化の機能を使用して、並列ブローカにサーバを登録し、それぞれのクライアントがそれぞれのブローカにサーバプロセスの照会を行うようにするというものです。その時、DCE_LOCAL を環境ファイルにセットして、親ブローカに行かないようにするという方法もあります。 また、クライアントのコードを共用したいのであれば、例えば、サーバはバリアブルネームド サーバにしておきます(名称は"サーバ A_srv1"のようにするとわかり易いでしょう)。 クライアントが srv1 を呼び出す際にアクセスするサーバプロセス名を判断するようなロジックをクライアントに組み込んでおき"サーバをコールする方法がとれます。

Inspire International Inc.

bottom of page