Z and I Emulator for Web インフォメーション・センターにある Toolkit 情報を確認してください。Toolkit 資料は、左ナビゲーション・フレームの「ZIE Host Access Toolkit」 の下にあります。また、インフォメーション・センターには検索機能も備わっていて、インフォメーション・センター内の全体を検索できます。この検索機能は、特定の API に関する情報を検索するときに特に役立ちます。
インフォメーション・センターにある『Host Access Beans for Java Reference』 にリストされている共通問題を確認してください。
インフォメーション・センターにある『Host Access Beans for Java Reference』 で Host Access Beans のアプレットおよびアプリケーションをデバッグするための各種ツールに関する情報を確認してください。Z and I Emulator for Web トレース機能を取り込む方法や、表示スペース・デバッガーを使用する方法などの情報があります。
Java 2 対応のブラウザーでアプレットが実行されませんでしたか? ユーザーが、Java 2 Z and I Emulator for Web クライアントから開始された Z and I Emulator for Web エミュレーター・セッション (3270 ディスプレイなど) を使用して、カスタマイズされたアプレットを実行する場合に、このアプレットが Java 2 許可を要求するのであれば、以下のいずれかのステップを実行して、Java 2 のセキュリティー要件を満たす必要があります。そうしないと、そのアプレットは暗黙的に失敗します。
スレッドの使用状況を確認している場合は、自分でカスタマイズしたコードが、 スレッドの解放に必要となる API を実行していることを確認してください。例えば、ECLSession を使用して startCommunication() を実行し、さらに session.dispose() を実行する 場合は、stopCommunictions() が実行されるまでスレッドはいずれも解放されません。
Abstract Windows Toolkit (AWT) スレッドはすべて、GUI エレメントを管理する (例えば、Java GUI イベントを ディスパッチするなど) ための AWT フレームワークの一部として Java によって自動的に spawn されます。そのスレッドは Java ランタイムによって制御されます。 Z and I Emulator for Web や HACL ベースのカスタム・アプリケーションなどのアプリケーション・プログラムからそのスレッドを開始したり停止したりするインターフェースはありません。
開発努力のターゲットを特定バージョンの Z and I Emulator for Web Toolkit にしていても、 トラブルシューティング時に使用する旧バージョンの Toolkit ライブラリーを保守しなければならない場合があります。例えば、バージョン 9.0 の Toolkit を使用して開発を行っているときに、バージョン 9.1 が使用可能な場合は、 問題が両方のバージョンの Toolkit ライブラリーに存在するかどうかを確認します。また、バージョン 7.0 や 8.0 などの旧リリースを比較することもできます。
各種 JVM バージョン間で動作を比較することは、Z and I Emulator for Web Toolkit に関する問題をトラブルシューティングするときの重要なステップです。特定の JVM バージョンで動作に違いがある場合は、さらに踏み込んで問題の原因を見つけます。
Oracle は、登録ユーザーに無償でバグ報告サービスおよびバグパレード・サービスを提供しています。Oracle は検索可能な知識ベースを提供しているため、既知のバグや使用可能な修正を見つけることができます。
ご使用のワークステーションで Windows 環境変数 CLASSPATH が宣言されている場合は、Oracle の Java API 資料を参照して、その環境変数が javac.exe と java.exe のクラスパス検索順序にどのように相互作用するのかを確認してください。対象となる JVM やカスタム・ライブラリーと互換性がない各種 JVM ライブラリーを CLASSPATH が参照している可能性があります。
Java が使用されている他の製品のインストール済み環境では、そこで使用されているアプリケーションをサポートするために、 同じ名前の Java ライブラリーがインストールされている可能性があります。ご使用のアプリケーションが、その不適切なライブラリーを偶然に使用している可能性があります。
素早くテストするには、CLASSPATH にある宣言を一時的に除去します。これで動作が変わるのであれば、これが問題の原因の可能性があります。
ネイティブ JVM (jdk1.1) がインストールされた Internet Explorer や Netscape を使用しているときに正常に動作する カスタム・コードが、Java 2 プラグインが有効になっているブラウザーで同一アプレット・コードが実行されるときに動作しないことがあります。例えば、Java 2 プラグインが有効になっている場合に、 予期しないエラー ClassDefNotFoundException または NullPointerException が Java コンソールから報告されることがあります。また、他のケースでは、Internet Explorer Java コンソールからセキュリティー・アクセス違反が報告されることがあります。
ブラウザーで実行されるアプレットを作成する場合は、保護されているサンドボックスの外側にあるリソースにアクセスするために必要となる前提条件が カスタム・コードでセットアップされなければなりません (Java の資料を参照してください)。
ZIEWeb Toolkit ライブラリーでは、さまざまなポイントでセキュリティー・ベースのメソッドが呼び出されます。Toolkit API の内部で行われる呼び出しでは、HCL によってデジタル署名されたアーカイブが、必要な許可が付与された状態で使用されます。
また、カスタム・コードにセキュリティー・プロビジョニングを実装しなければならない場合もあります。 これは一般的な Java 要件であり、Z and I Emulator for Web Toolkit に固有のものではありません。適切な Java の資料を調べてください。
次の例は、Java 2 問題がセキュリティー・マネージャーに関係しているかどうかを判断するときに役立つ可能性があります。以下の内容でファイル ${user-home-dir}/.java.policy を作成してください。
// JBuilder extensions for use with running/debugging Applets. // Use for testing purposes only. grant {
permission java.security.AllPermission;
permission java.net.SocketPermission "*","accept, connect, listen, resolve";
}; コードが突然、jdk1.1 JVM で動作するように動作する場合は、別の許可を設計する必要があります。
同様に、Internet Explorer と Microsoft JVM を使用している場合は、カスタム・コード用の JAR アーカイブを作成して、そのアーカイブへのパスを次のレジストリー項目で指定します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Java VM\TrustedClasspath
未署名 CAB ファイルへのパスを指定しても効果はないことに注意してください。
セキュリティー違反がなくなったら、デジタル署名された CAB アーカイブに自分のカスタム・コードを組み込みます。この操作を既に行っている場合は、特定のクリティカル・ポイントでランタイム・セキュリティー・アクションをアサートしたり ランタイム・セキュリティー・アクションに許可や特権を付与したりしなければならないことがあります。
main(...) エントリー・ポイントを使用して java.exe によって有効にされた Java クラスでは、 セキュリティー・マネージャーは指定されるまで実行されない可能性があります。 ただし、アプレット・クラスはブラウザーの常駐セキュリティー・マネージャーによって常にモニターされます。
Toolkit JavaDoc で公開されている API メソッドおよびフィールドのみを使用してください。公開されていない API を使用すると、予期しない結果になることがあります。また、非推奨となっている公開済み API はいずれも使用しないでください。
Java を含め、多くのプログラミング言語でデッドロックおよび競合状態は共通です。症状には以下のものがあります。
Thread.sleep(...) または System.out.println(...) を追加すると症状に影響があるかどうかを確認してください。また、イベント・ハンドラーでの処理量によって症状が変わるかどうかも確認してください。イベント・ハンドラーは簡素なものでなければなりません。 そのため、大量の作業は別のスレッドに処理させるようにしてください。
多くの場合、クライアントやドライバーのコードが正常に実行されるかどうかは、ネットワークとホスト環境のタイミングによって決まります。コードが突然実行されなくなる場合は、ご使用の環境において何らかのエレメントが変更されたことが問題として考えられます。タイミングに影響を及ぼす可能性のある変更には以下のものがあります。
Z and I Emulator for Web Toolkit には 2 つの強力なメカニズムがあり、暗黙のタイミングの依存関係が原因で発生する障害を回避するのに役立ちます。
これら 2 つのメカニズムはさまざまな状態で使用されますが、どちらも同じ目的を果たします。これらのメカニズムは、ネットワークやホストの構成内で変更が行われたときにクライアントとホストの間の 対話式フローを維持するために必要となる条件を満たすことができるように設計されています。
無限ループが発生すると、メインフレームのリソースが大量に消費される可能性があります。 これは、複数のクライアントが同一の中間層ルーチンにアクセスしているときに顕著です。複数の同時ループであっても、メインフレームが最終的にクラッシュする原因となる可能性があります。
出口条件を満たさない可能性のあるループ・フロー制御構造がないか、コードを調べてください。また、エスケープ・コードを使用したループ・カウントを指定していないかどうかも確認してください。特定の問題に関しては実動メインフレームよりもクライアント・ワークステーションで診断する方が簡単だということに留意してください。
HACL screenreco 呼び出しを使用してループ出口条件を満たすことは推奨されないことに注意してください (例えば、 ループ終了を満たす HACL screenreco 条件が 1 つの場合にホスト・システムで不測の可変画面が表示され続けるときなど)。
Toolkit には、バックエンド・ホストへの接続が突発的に切断されたときに中間層コードに警報を出すことができるリスナー・クラスが用意されています。この警報シグナルがないと、中間層コードが不適切なパスを通る可能性があります。
多くの場合、切断された接続が明示的にクリーンアップされていないと、スレッド・プール全体が徐々に消費される可能性があります。
潜在的に有害なユーザー・アクションを処理するように GUI が設計されていることを確認してください。例えば、ユーザーによっては、元の要求が処理されているかどうかが不確かなときに同じボタンを何度も繰り返してクリックし続けることがあります。中間層コードは、連続するユーザー・クリックによって引き起こされる重複アクションをブロックするように作成します。 GUI は、ユーザーの要求の状況をそのユーザーに知らせるように設計します。
コードを設計するときは、エラーの発生時に不測の事態をフォールバックしたりロールバックしたりするフロー・パスを用意してください。中間層コードは、トレースなどによってエラーを検出できるようになっていなければなりません。画面上に表示されるものと期待したものが実際に表示されることを必ず確認してください。
HACL は、不可視の 'グリーン・スクリーン' API です。HACL を使用して作成された中間層コードは、バックエンド・ホストから制御コード BELL、ALERT、または BEEP を受け取ることができます。通常、これは Java メソッド java.awt.Toolkit.beep() に変換されます。このメソッドは、ホスト・マシンでは意味をなさないローカル・ハードウェア呼び出しです。 このメソッドが原因で画面の更新が停止することがあります。これは一般的な問題であり、Toolkit HACL ライブラリーに固有のものではありません。
解決策の 1 つとして、ECLSession コンストラクター・パラメーター・ペア SESSION_QUIETMODE, SESSION_ON ("true") を設定する方法があります。また、Java コードにより GUI 中心の Java 呼び出しが多数実行される状態では、RAWT (リモート AWT) ヘルパー・ライブラリーも使用できます。このライブラリーは、iSeries の警告が発行されたことを知る必要があるときに役立つ可能性があります。
<
Toolkit BEAN は HACL API を '認識' し、その API を使用して作動します。ただし、 HACL API はスタンドアロンの API であり、BEAN API レイヤーを '認識しません'。つまり、BEAN レイヤーで実行されたアクションは HACL レイヤーに拡張されますが、HACL レイヤーで実行されたアクションは BEAN レイヤーに 返されることはありません。フィードバック・ループはホスト応答によって行われます。
(Terminal/Session).getECLSession() は、BEAN の基底をなす HACL API へのバックドアです。BEAN ベースのアプレット/アプリケーションを作成した場合は、getECLSession() ポートの使用を、いずれの BEAN API でも提供されない アクションに制限してください。
「アプレットの実行」では、ECLAppletInterface または CustomInterface を実装できます。CustomInterface は、より強力なアクセス・ポートです。
正しく同期が行われるようにするには、アプレット呼び出しが特定の前提条件を満たしていなければなりません。 さもないと、その呼び出しはホスト・プログラムの後に実行されます。例えば、ホスト接続がアクティブになってから、予期されるグリーン・スクリーン・コンテンツがホストから送信されなければなりません。このような条件が満たされていることを確認してください。
Toolkit では Z and I Emulator for Web セッションは BEAN および HACL の API に基づいていますが、 特定のエレメント (Z and I Emulator for Web デスクトップやサービス・マネージャーなど) はスタンドアロンであり、Toolkit には含まれていません。また、HCL では、統合 Z and I Emulator for Web デスクトップ・エミュレーターを生成する付加価値テクノロジーをもたらすように設計された多くの非 Toolkit API を提供しています。
Java 2 を使用して Toolkit コードをコンパイルしたにもかかわらず、ご使用のブラウザーでネイティブ JVM を使用してコードが実行されない場合は、 以下のことに留意してください。
GUI を提供する Toolkit BEAN クラスは継承されたため、Toolkit アーカイブ・ライブラリーは jdk1.1 フレーバーの場合は java.awt ベースであり、Java 2 フレーバーの場合は javax.swing ベースです。jdk1.1 フレーバーのライブラリーを使用してコンパイルされたカスタム・アプリケーションは、JVM 1.1 ランタイム環境でも JVM Java 2 ランタイム環境でも 機能します。Java 2 フレーバーのライブラリーを使用してコンパイルされたカスタム・アプリケーションは、少なくとも Java 2 1.3 JVM ランタイム環境内で 実行する分には互換性があります。JVM 1.1 ランタイム環境で実行使用とすると、クラスパスに swingall.jar ライブラリーが含まれていても、 リカバリー不能な例外が発生します。
コードを jdk1.1 でコンパイルして Java 2 JVM で実行することは可能ですが、重量コンポーネントと軽量コンポーネントが混在することに関係する 特定の副次作用が発生する可能性があります。このような副次作用は、Java 2 フレーバーの端末 Bean が、繰り返し構成されたり処理されたりする java.awt.Frame に組み込まれたときに非常に明白となります。この状態では、サポートは非常に限られたものになります。
Z and I Emulator for Windows API を使用して開発されたコードは、Toolkit に付属のライブラリーを使用して再コンパイルできます。ただし、一部の追加セッション構成パラメーターに関しては、WS 構成ファイルに同等のものがないため、コーディングしなければならない場合があります。
