Revise as informações do toolkit no centro de informações do Host On-Demand . Os manuais do toolkit estão localizados em Host Access Toolkit no quadro de navegação à esquerda. O centro de informações também oferece uma função de procura que permite que você pesquise todo o centro de informações. A função de procura é especialmente útil ao procurar por informações sobre uma API específica.
Revise os problemas comuns listados em Host Access Beans for Java Reference, localizado no Centro de Informações.
Revise as informações sobre as diferentes ferramentas para depuração dos applets e aplicativos do Host Access Beans no Host Access Beans for Java Reference, localizados no centro de informações. As informações disponíveis incluem como incorporar as funções de rastreio do Host On-Demand (Recurso de Rastreio) e como utilizar o Depurador de Espaço de Apresentação.
Um applet fornecido pelo cliente falhou ao ser executado com um navegador ativado para Java 2? Se um usuário executa um applet personalizado com uma sessão do emulador do Host On-Demand (tal como Vídeo 3270) ativado por um cliente do Java 2 Host On-Demand e, se esse applet requer qualquer permissão de Java 2, você deverá seguir uma das seguintes etapas para atender aos requisitos de segurança do Java 2; caso contrário, o applet falhará silenciosamente:
Se você estiver revisando o uso de encadeamentos, verifique se seu código personalizado executou a API necessária para liberar encadeamentos. Por exemplo, você utiliza ECLSession, executa startCommunication() e, em seguida, faz um session.dispose(), todos os encadeamentos não serão liberados até que o stopCommunictions() tenha sido executado.
Todos os encadeamentos do AWT (Abstract Windows Toolkit) são automaticamente geradas por Java como parte da estrutura AWT para gerenciar os elementos da GUI (por exemplo, dispatch de eventos Java GUI). O encadeamento é controlado pelo Java e nenhuma interface está disponível para iniciar ou parar o encadeamento a partir de um programa aplicativo, como o Host On-Demand ou um aplicativo personalizado baseado em HACL.
Embora seus esforços de desenvolvimento podem ser destinados a uma versão específica do Host On-Demand Toolkit, você pode desejar manter versões anteriores da biblioteca do Toolkit para serem utilizadas na resolução de problemas. Por exemplo, se você estiver desenvolvendo com a versão 9.0 do Toolkit e a versão 9.1 estiver disponível, verifique se o problema está presente em ambas as versões das bibliotecas do Toolkit. Você pode, também, decidir comparar releases anteriores, como as versões 7.0 e 8.0.
A comparação do comportamento entre versões diferentes do JVMs é uma etapa importante na resolução de problemas com o Host On-Demand Toolkit. Se você observar diferençaa nos comportamentos com certas versões de JVMs, estará perto de discobrir a origem do problema.
A Sun Microsystems fornece um relatório de erros e um serviço de parada de erros para usuários registrados sem custos. Ela oferece uma base de conhecimentos pesquisável que permite que você encontre erros conhecidos e correções possíveis.
Se você possui uma variável de ambiente do Windows denominada CLASSPATH declarada na estação de trabalho, revise a documentação da API Java da Sun Microsystems para saber como a variável de ambiente interage com a ordem de procura de caminho de classe javac.exe e java.exe. O CLASSPATH pode estar fazendo referência a bibliotecas JVM diferentes que são incompatíveis com o JVM pretendido e as bibliotecas personalizadas.
Outras instalações do produto utilizando Java podem possuir bibliotecas Java instaladas com o mesmo nome para suportar seus aplicativos. Seu aplicativo pode estar utilizando essas bibliotecas inapropriadas inadvertidamente.
Um teste rápido consiste em remover a declaração do CLASSPATH temporariamente. Se isso alterar o comportamento, essa pode ser a causa do problema.
Às vezes, o código personalizado funciona bem ao utilizar o Internet Explorer e o Netscape com seus JVMs (jdk1.1) nativos, mas não funcionam quando o mesmo código de applet é executado em um navegador com plug-in Java 2. Por exemplo, com um plug-in Java 2, o Java Console pode informar um erro inesperado ClassDefNotFoundException ou NullPointerException. Em outros casos, o Java Console do Internet Explorer pode informar uma violação de acesso de segurança.
Se você estiver gravando um applet para ser executado em um navegador, seu código personalizado deve definir os pré-requisitos necessários para acessar recursos fora do modo seguro de proteção (consulte a documentação do Java).
As bibliotecas do HOD Toolkit fazem chamadas de método baseadas em segurança
em vários pontos. As chamadas internas feitas para as APIs do Toolkit utilizam archives assinados digitalmente pela IBM
com as permissões necessárias concedidas.
Seu código personalizado pode ser necessário também para implementar a provisão de segurança.
Esse é um requisito geral do Java e não é específico do Host On-Demand Toolkit.
Estude a documentação Java apropriada.
O exemplo a seguir pode ajudá-lo a determinar se o problema do Java 2 está relacionado ao Security Manager. Crie um arquivo ${user-home-dir}/.java.policy com este conteúdo:
// extensões JBuilder para serem utilizadas com Applets de execução/depuração.
// Utilize apenas para testes.
grant {
permission java.security.AllPermission;
permission java.net.SocketPermission "*","accept, connect, listen, resolve";
};
Se o seu código funcionar de repente, como o faz com um jdk1.1 JVM, você precisará projetar suas permissões de maneira diferente.
De maneira semelhante, se você estiver utilizando o Internet Explorer e o JVM da Microsoft, crie um archive JAR para o seu código personalizado e especifique o caminho para ele na seguinte entrada do Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Java VM\TrustedClasspath
Observe que a especificação de um caminho para um arquivo CAB não-assinado não faz efeito.
Se as violações de segurança desaparecerem, coloque o código personalizado em um archive CAB assinado digitalmente. Se você já fez isso, pode ser necessário assegurar ou conceder permissões ou privilégios de ação de segurança do tempo de execução em certos pontos críticos.
Lembre-se de que uma classe Java ativada pelo java.exe utilizando o ponto de entrada principal(...) pode não possuir um gerenciador de segurança, a menos que você especifique um; no entanto, uma classe de applet sempre será monitorada pelo gerenciador de segurança residente do navegador.
Utilize apenas os métodos e campos da API publicados nos JavaDocs do Toolkit. A utilização de APIs não-publicadas pode resultar em conseqüências inesperadas. Além disso, evite a utilização de quaisquer APIs publicadas cujas etiquetas foram reprovadas.
Conflitos e condições race são comuns em muitas linguagens de programação, incluindo Java. Os sintomas incluem o seguinte:
Verifique se a inclusão de Thread.sleep(...) ou System.out.println(...) afeta os sintomas. Da mesma forma, verifique se o sintoma depende da quantidade de processamentos feitos nas rotinas de tratamento do evento. As rotinas de tratamento do evento devem ser breves, portanto permita um outro encadeamento para processar o trabalho intensivo.
O sucesso do cliente ou do código do driver freqüentemente depende do timing da rede e do ambiente hospedado. Se a execução do código falhar inesperadamente, o problema pode ser que algum elemento no ambiente foi alterado. Algumas alterações que poderiam afetar o timing incluem o seguinte:
O Host On-Demand Toolkit possui dois mecanismos eficientes para ajudá-lo a evitar defeitos devido a dependências de timing implícitas:
Esses dois mecanismos são utilizados em situações diferentes, mas cada um serve ao mesmo fim. Eles são projetados para ajudá-lo a atender as condições necessárias à manutenção de um fluxo interativo entre seu cliente e o host quando ocorrerem alterações dentro da configuração da rede e do host.
Loops infinitos podem consumir uma grande quantidade de recursos de mainframe, especialmente quando vários clientes estão acessando as mesmas rotinas da camada média. Vários loops simultâneos podem até mesmo fazer que seu mainframe trave.
Examine o código para estruturas de controle de fluxo de loop que pode não satisfazer nunca a(s) condição(ões) de saída. Verifique, também, se forneceu contagem de loop com código de escape. Tenha em mente que você pode diagnosticar certos problemas mais facilmente em uma estação de trabalho do cliente do que em um mainframe de produção.
Esteja ciente de que a utilização de chamadas HACL para satisfazer uma condição de saída de loop não é uma boa prática, por exemplo, se você possui uma condição HACL única para satisfazer o término do loop e o sistema host continua a apresentar uma tela variante não-antecipada.
O Toolkit fornece classes de listener que podem alertar seu código da camada do meio quando uma conexão com um host backend tiver sido encerrada espontaneamente. Sem este sinal de alteração, o código da camada do meio pode fluir através de caminhos não apropriados.
Muitas conexões encerradas que não foram explicitamente limpas podem consumir lentamente todo o conjunto de encadeamentos.
Certifique-se de que a GUI foi projetada para manipular ações potencialmente mal intencionadas do usuário. Por exemplo, alguns usuários podem continuar a clicar no mesmo botão várias vezes quando eles não têm certeza de que seu pedido original está sendo processado. Grave o código da camada do meio para bloquear ações redundantes causadas por cliques sucessivos do usuário e projete a GUI para informar aos usuários sobre o status de seus pedidos.
Projete o código com caminhos de fluxo de contingência de fall back ou de roll back no caso de erros. O código da camada do meio deve ser capaz de detectar erros, por exemplo, por meio de rastreio. Sempre verifique se o que você espera visualizar na tela é o que será realmente exibido.
O HACL está na API 'green screen' invisível. O código da camada do meio gravado
com HACL pode receber um controle BELL, ALERT ou BEEP a partir de um
host de backend. Ele é, geralmente, traduzido para o método Java
java.awt.Toolkit.beep(). Esse método não é uma chamada de hardware local
com significado em uma máquina host e pode ser responsável pela paralisação de atualizações de tela. Esse
é um problema genérico que não é específico das bibliotecas do Toolkit HACL.
Uma solução é definir um par de parâmetros de construtor ECLSession : SESSION_QUIETMODE, SESSION_ON ("true"). Da mesma forma, uma biblioteca de ajuda RAWT (Remote AWT) disponível para situações em que o código Java executará muitas chamadas Java centradas na GUI. Essa biblioteca pode ser útil quando você precisar saber que um ALERT do iSeries ocorreu.
Se o código executa e alcança o final da cláusula principal(...) , porém o controle não é transmitido de volta ao sistema depois que o JVM limpar e sair, faça upgrade para o Host On-Demand V8.0.1 para evitar este problema.
Os BEANS do Toolkit estão 'aware of' e operam através das APIs HACL. No entanto, as APIs HACL são APIs separadas e 'unaware of' da camada da API dos BEANS. Isso significa que ações tomadas na camada dos BEANS são estendidas à camada HACL e que ações tomadas na camada HACL nunca são direcionadas de volta à camada dos BEANS. O loop do feedback ocorre através de uma resposta do host.
(Terminal/Session).getECLSession() é a backdoor para as APIs do HACL subjacentes a esses BEANS. Se você tiver gravado um applet/aplicativo baseado nos BEANS limite o seu uso da porta getECLSession() às ações que não são fornecidas em uma das APIs dos BEANS.
Executar o Applet pode implementar a ECLAppletInterface ou a CustomInterface. A CustomInterface é a porta de acesso mais eficiente.
Para sincronizar adequadamente, a chamada do applet deve atender a certas pré-condições ou ela irá ignorar o programa host. Por exemplo, a conexão com o host deve estar ativa e o conteúdo da tela verde antecipada deve ter chegado do host. Certifique-se de que tais condições estão sendo atendidas.
Embora as sessões do emulador do Host On-Demand sejam baseadas nas APIs do BEANS e do HACL no Toolkit, certos elementos são separados e não são incluídos no Toolkit, por exemplo, o desktop do Host On-Demand e o Service Manager. Além disso, a IBM fornece muitas APIs que não são do Toolkit projetadas para fornecer a tecnologia value-add e criar um emulador do desktop do Host On-Demand integrado.
Se ainda não o fez, familiarize-se com a API do Host On-Demand Programável. A API do Host On-Demand Programável é um conjunto de APIs Java que permite aos desenvolvedores integrarem várias partes do código do cliente Host On-Demand, como terminais, menus e barras de ferramentas, em seus próprios aplicativos e applets Java personalizados. A API fornece ao desenvolvedor controle completo sobre o desktop Host On-Demand (o que o usuário vê) sem começar com o Host Access Java Beans encontrado no Toolkit. O código subjacente do Host On-Demand trata de toda a "fiação" dos vários componentes, incluindo salvamento de preferências do usuário, como macros, remapeamentos de teclados e remapeamentos de cores, para o sistema de arquivos locais para uso futuro. O desenvolvedor deve determinar apenas o layout do desktop do Host On-Demand. Para obter informações adicionais sobre a API do Host On-Demand Programável, consulte o manual do Host On-Demand Programável no Centro de Informações do Host On-Demand.
Se você compilar o código do Toolkit com Java 2 e o código falhar ao ser executado com o JVM nativo em seu navegador, observe o seguinte. Desde o Host On-Demand V7, as bibliotecas de archive do Toolkit são apresentadas em duas versões: jdk1.1 e Java 2. As bibliotecas jdk1.1 foram compiladas com ibmdjk1.1.8 e as bibliotecas Java 2 foram compiladas com a versão de Java 2 mais recente suportada pela IBM.
As classes de BEANS do Toolkit que apresentam uma GUI foram transferidas para uma subclasse, que seja baseada em java.awt para a versão jdk1.1 e javax.swing-based para a versão Java 2. Se você compilar o aplicativo personalizado utilizando as bibliotecas da versão jdk1.1, esse aplicativo funcionará em um ambiente de tempo de execução JVM 1.1 ou JVM Java 2. Se você compilar o aplicativo personalizado utilizando as bibliotecas da versão Java 2, ele será compatível para ser executado dentro de, ao menos, um ambiente de tempo de execução JVM Java 2 1.3. Se você tentar executar com um ambiente de tempo de execução JVM 1.1, mesmo com a biblioteca swingall.jar no caminho de classe, você observará exceções irrecuperáveis.
Embora você possa compilar o código utilizando o jdk1.1 ao ser executado em um JVM Java 2, você pode observar certos efeitos colaterais associados à mescla de componentes ampliados e reduzidos. Tais efeitos são mais pronunciados quando beans do Terminal da versão Java 2 forem embutidos em um java.awt.Frame que é criado e descartado repetitivamente. O suporte é muito limitado nesta situação.
O código desenvolvido com as APIs do Personal Communications devem ser capazes de recompilar utilizando as bibliotecas fornecidas pelo Toolkit. No entanto, pode ser necessário codificar alguns parâmetros de configuração da sessão adicionais já que não há equivalente ao arquivo de configuração WS.
Observe que as APIs do Personal Communications são pendentes e equivalentes às APIs do Host On-Demand V4, que é jdk1.1. O Toolkit atual possui muitas extensões e adições, algumas das quais não estavam disponíveis para o Host On-Demand V4. Desde então, a IBM fez modificações importantes no comportamento das classes HACL screenreco, assim a recodificação e a alteração do design são necessárias. Os recursos base do Macro BEAN permanecem, mas o Macro do Toolkit dobrou ou triplicou o número de APIs operacionais disponíveis.
