![[z/OS]](../images/ngzos.gif)
Conditions de délai d'expiration : Analyse des données de diagnostic
Les instructions suivantes vous permettent de rechercher des données de diagnostic dans un vidage SVC ce qui peut vous aider à déterminer quelle expiration de délai s'est produite :
- Formatez le résumé TCB pour le servant qui a expiré en entrant la commande suivante :
ip summ format asid(x' address ')
où address est l'ID de l'espace adresse du servant.
Recherchez le TCB avec le code achèvement EC3. Ignorez tous les codes achèvement EC3 sur l'unité d'exécution "principale", 4è TCB répertorié dans le format récapitulatif (le premier après les 3 TCB MVS). La principale unité d'exécution WebSphere est en attente dans BBO_BOA::impl_is_ready. Aucune demande d'application n'est jamais distribuée sur cette unité d'exécution, par conséquent il ne peut pas y avoir de délai d'expiration. Pendant le traitement du délai d'expiration, l'unité d'exécution principale de la région du serveur rencontre également une fin anormale EC3 tel qu'un mécanisme de désactivation de l'espace adresse. C'est la raison pour laquelle le code achèvement EC3 est susceptible d'apparaître sur l'unité d'exécution principale. Ce n'est jamais en raison d'un délai d'expiration, seulement le résultat d'un traitement de délai d'expiration.
- S'il n'y a aucun code achèvement EC3 dans le résumé TCB, recherchez dans systrace. Formatez systrace en heure GMT vu que les autres horodatages auxquels vous allez le comparer sont en heure GMT. Pour formater en heure GMT, entrez la commande suivante :
ip systrace all time(gmt)
Il se peut que vous ne voyiez pas la fin anormale EC3 dans systrace même lorsque systrace peut couvrir une petite durée.
- Vous pouvez également rechercher dans ip verbx mtrace ou syslog pour voir quand la fin anormale EC3 s'est produite. Vous aurez besoin de cette heure pour déterminer l'heure de "fin" de la demande, heure GMT atteinte par la valeur de délai d'expiration.
Code motif | Explication |
---|---|
04130002 | Le contrôleur a émis un ABTERM pour cette région serviteur car une expiration du délai de la transaction s'est produite. Le code en cours de distribution aurait pu se trouver dans une boucle serrée. |
04130003 | Le contrôleur a émis un ABTERM pour cette région serviteur car elle s'était bloquée en essayant de déplacer une demande du contrôleur dans la région serviteur. La demande cible avait expiré mais le serviteur était en train de la copier. Le contrôleur a vérifié la progression du serviteur à intervalles réguliers avant d'agir en émettant un ABTERM. |
04130004 | Le contrôleur a émis un ABTERM pour cette région serviteur car un délai de mise en file d'attente de WLM s'est produit. Le code en cours de distribution aurait pu se trouver dans une boucle serrée. |
04130005 | Le contrôleur a émis un ABTERM pour cette région serviteur car une expiration du délai de la transaction s'est produite. La transaction a expiré mais aucune demande en cours associée à la transaction n'a été trouvée. Le serviteur associé à la transaction va être arrêté. |
04130006 | Une unité d'exécution du contrôleur a rencontré un incident pendant le traitement d'une demande. La demande a été mise en file d'attente dans WLM et associée à la région serviteur. Il est nécessaire d'arrêter la région serviteur pour effectuer le nettoyage de la demande. |
04130007 | Le contrôleur a émis un ABTERM pour cette région serviteur car un délai d'expiration HTTP OUTPUT s'est produit. Le code en cours de distribution aurait pu se trouver dans une boucle serrée. |
httpRequest,
httpsRequestor
DispatchbyURI
protocol_http_output_timeout(HTTP) et
protocol_https_timeout_output(HTTPS) ne constitueront pas un facteur. En d'autres termes, lorsque la demande est une méthode
DispatchbyURIla demande est reçu via le protocole RMI/IIOP, les *variables
protocol_httpn'ont donc aucune incidence.
Utilisez l'IPCS verbexit LEDATA, avec les options CEEDUMP ou NTHREADS pour obtenir la pile de rappels de cette requête.