Risoluzione dei problemi delle applicazioni Java

Se si ha un problema con un'applicazione Java™ , è possibile utilizzare la diagnostica fornita da CICS® e dalla JVM per determinare la causa del problema.

1. Se non è possibile avviare un server JVM, verificare che la configurazione dell'installazione Java sia corretta.
   Utilizzare i messaggi CICS e gli errori nel file stderr per la JVM per determinare la causa del problema.
   1. Verificare che sia installata la versione corretta di Java SDK e che CICS abbia accesso ad esso in z/OS UNIX.
      Per un elenco di SDK supportati, vedi Supporto del compilatore e del linguaggio di alto livello.
   2. Verificare che il parametro di inizializzazione del sistema USSHOME sia impostato nella regione CICS .
      Questo parametro specifica la home per i file in z/OS UNIX.
   3. Verificare che il parametro di inizializzazione del sistema JVMPROFILEDIR sia impostato correttamente nella region CICS .
      Questo parametro specifica l'ubicazione dei profili JVM in z/OS UNIX.
   4. Verificare che la regione CICS disponga dell'accesso in lettura ed esecuzione alle directory UNIX z/OS che contengono i profili JVM.
   5. Verificare che la regione CICS abbia accesso in scrittura alla directory di lavoro della JVM.
      Questa directory viene specificata nell'opzione WORK_DIR del profilo JVM.
   6. Verificare che l'opzione JAVA_HOME nei profili JVM punti alla directory che contiene Java SDK.
   7. Verificare che SDFJAUTH si trovi nella concatenazione STEPLIB del JCL di avvio di CICS .
   8. Se si utilizzano file DLL WebSphere® MQ o DB2® , verificare che le versioni a 64 bit di tali file siano disponibili per CICS.
   9. Se si modifica DFHAXRO per configurare l'enclave Language Environment ®, assicurarsi che le opzioni di runtime non superino i 200 byte e che siano valide.
      CICS non convalida le opzioni specificate prima che vengano inoltrate a Language Environment. Controllare SYSOUT per eventuali messaggi di errore da Language Environment.
2. Se la configurazione è corretta, raccogliere informazioni diagnostiche per determinare cosa sta accadendo all'applicazione e alla JVM.
   1. Per ottenere la diagnostica, è necessario utilizzare PRINT_JVM_OPTIONS=TRUE. Il valore predefinito per questa opzione è PRINT_JVM_OPTIONS=FALSE, quindi se viene lasciato al valore predefinito, non viene presentata alcuna opzione per la diagnostica. Quando si specifica PRINT_JVM_OPTIONS=TRUE, tutte le opzioni che vengono inoltrate alla JVM all'avvio, incluso il contenuto dei percorsi classe, vengono stampate in SYSPRINT. Le informazioni vengono prodotte ogni volta che una JVM viene avviata con questa opzione nel profilo.
   2. Controllare i file dfhjvmout e dfhjvmerr per informazioni e messaggi di errore dalla JVM.
      Questi file si trova nella directory specificata dall'opzione WORK_DIR/applid/jvmserver nel profilo JVM. I file potrebbero avere nomi diversi se le opzioni STDOUT e STDERR sono state modificate nel profilo JVM.
3. Se l'applicazione ha esito negativo o ha prestazioni scarse, eseguire il debug dell'applicazione.
   • Se si ricevono errori java.lang.ClassNotFoundException e la transazione termina in modo anomalo con il codice AJ05 , l'applicazione potrebbe non essere in grado di accedere a IBM o alle classi fornitore nel framework OSGi. Per ulteriori informazioni su come risolvere questo problema, consultare Aggiornamento dell'ambiente Java.
   • Utilizzare la transazione CEDX per eseguire il debug della transazione dell'applicazione. Per un server JVM Liberty, se si utilizza una mappa URI per mettere in corrispondenza la richiesta dell'applicazione in entrata con una transazione dell'applicazione, eseguire il debug di tale transazione. Se si utilizza la transazione predefinita CJSA, è necessario impostare l'attributo MAXACTIVE su 1 sulla classe di transazione DFHEDFTC (o sulla classe di transazione DFHEDFTO se si utilizza CEDY). Questa impostazione è richiesta perché è possibile che un certo numero di attività CJSA sia in esecuzione e che si esegua il debug della transazione non corretta. non utilizzare CEDX sulla transazione CJSA in un ambiente di produzione.
   • Per utilizzare un programma di debug con il server JVM, è necessario impostare alcune opzioni nel profilo JVM. Per ulteriori informazioni, consultare Debug di un'applicazione Java.
   • Se si desidera determinare lo stato dei bundle e dei servizi OSGi, utilizzare la console OSGi. Impostare le seguenti proprietà nel profilo JVM: -Dosgi.file.encoding=ISO-8859-1e -Dosgi.console=host:port dove host è il nome host del sistema su cui è in esecuzione il server JVM e port è una porta libera sullo stesso sistema. Mentre la proprietà osgi.console.encoding è stata progettata per consentire alla console OSGi di utilizzare una codifica preferita senza inserire l'intera JVM in tale codifica, un bug in sospeso nel framework Equinox OSGi ne impedisce l'uso, è necessario impostare il valore file.encoding su una codifica basata su ASCII. Se si utilizza un server JVM OSGi, aggiungere OSGI_CONSOLE=TRUE al profilo JVM. Se si sta utilizzando un server JVM Liberty, aggiungere la funzione osgiConsole-1.0 a server.xml. Collegarsi alla console OSGi utilizzando una sessione Telnet con le proprietà host e porta specificate nel profilo JVM.
     Nota: se si immette il comando exit nella console OSGi, verrà immessa una chiamata system.exit(0) all'ambiente in cui viene eseguito JVMSERVER. Il comando per disconnettere il terminale dalla console OSGi è disconnect. system.exit(0) è un arresto improvviso di tutti i thread e del carico di lavoro e, se lasciato per continuare l'elaborazione, può lasciare JVM e CICS in uno stato indeterminato. CICS è progettato per eseguire un arresto immediato in questa eventualità per evitare complicazioni successive. Per questo motivo, è importante controllare l'accesso in scrittura sia al profilo JVM che a server.xml. Un server JVM Liberty offre un'ulteriore protezione richiedendo l'inclusione della funzionalità osgiConsole-1.0 prima che la console OSGi sia in grado di essere eseguita. La console OSGi è principalmente un aiuto per lo sviluppo e il debug e non è previsto che venga eseguito in un ambiente di produzione.
4. Se si verificano errori di memoria esaurita, è possibile che lo spazio di indirizzo JVM o CICS non disponga di memoria sufficiente, che l'applicazione abbia una perdita di memoria o che la dimensione heap non sia sufficiente.
   1. Utilizzare le statistiche CICS o uno strumento come IBM Health Center per monitorare la JVM. Se l'applicazione presenta una perdita di memoria, la quantità di dati attivi che rimane dopo la raccolta dati inutilizzati aumenta gradualmente nel tempo fino a quando l'heap non viene esaurito.
      Le statistiche del server JVM riportano la dimensione dell'heap dopo l'ultima raccolta dati inutilizzati e la dimensione massima e massima dell'heap. Per ulteriori informazioni, consultare Analisi delle applicazioni Java utilizzando IBM Health Center.
   2. Eseguire i report di memoria per Language Environment per determinare se la quantità di memoria è sufficiente.
      Per ulteriori informazioni, vedi Language Environment enclave storage for JVMs.
5. Se si ricevono errori di codifica quando si installa o si esegue un'applicazione Java, è possibile che si configuri una combinazione di codepage in conflitto o non supportata.
   Le JVM su z/OS generalmente utilizzano una codepage EBCDIC per la codifica dei file; il valore predefinito per i server JVM non Liberty è IBM1047 (o cp1047), ma la JVM può utilizzare altre codepage per la codifica dei file, se necessario. CICS richiede una codepage EBCDIC per gestire i dati carattere e tutte le chiamate JCICS devono utilizzare una codepage EBCDIC. La codepage è impostata nel parametro di inizializzazione del sistema LOCALCCSID per la region CICS .
   1. Controllare i log del server JVM per vedere se sono stati emessi messaggi di avviso relativi al valore di LOCALCCSID.
      Se questo parametro è impostato su una codepage non EBCDIC, una codepage non supportata dalla JVM o una codepage EBCDIC non supportata (come 930), il server JVM utilizza cp1047.
   2. Le chiamate JCICS utilizzano la codepage specificata nel parametro di inizializzazione del sistema LOCALCCSID .
      Se l'applicazione prevede una codepage differente, si ricevono errori di codifica. Per utilizzare una codepage differente per JCICS, impostare il parametro -Dcom.cics.jvmserver.override.ccsid= nel profilo JVM.
   3. Se si utilizza il parametro -Dcom.cics.jvmserver.override.ccsid= nel profilo JVM, assicurarsi che il CCSID sia una codepage EBCDIC. L'applicazione deve utilizzare EBCDIC quando utilizza chiamate JCICS.
   4. Se si sta eseguendo l'elaborazione SOAP su un server JVM Axis2 , assicurarsi che la proprietà JVM -Dfile.encoding specifichi una proprietà EBCDIC.
      Se si specifica una codepage non EBCDIC, come ad esempio UTF-8, la richiesta del servizio Web ha esito negativo e la risposta contiene dati danneggiati.
6. Se si verificano timeout di avvio o timeout sotto il carico di lavoro, è possibile ottimizzare vari parametri per risolvere il problema. Di seguito viene riportata un'indicazione dei valori che è possibile regolare:
   • Modificare l'impostazione -Dcom.ibm.cics.jvmserver.threadjoin.timeout per controllare il tempo di attesa di una richiesta HTTP per ottenere un thread del server JVM.
   • Aumentare il valore THREADLIMIT sulla risorsa JVMSERVER.
   • Se THREADLIMIT è già impostato sul valore massimo consentito, è possibile che si stia tentando di eseguire più lavoro di quanto un singolo server JVM possa gestire. Considerare la possibilità di bilanciare il carico di lavoro tra più server JVM o più regioni.

     In alternativa, il sistema CICS potrebbe non rispondere a causa di altri vincoli. Seguire le procedure standard per diagnosticare i problemi di prestazioni. Consultare Miglioramento delle prestazioni di un sistema CICS.