Entrée EHLLAPI partielle sur l'écran hôte Z and I Emulator for Windows

Incident
Un texte de commande tronqué a été envoyé à un hôte lors de l'utilisation de HCLZ and I Emulator for Windows.
Cause

Si une application EHLLAPI envoie une clé SYSREQ à l'hôte puis tente de saisir une commande sur l'écran de l'hôte, parfois seule une partie tronquée de la commande est envoyée à l'hôte. Ce problème se produit en raison d'un manque de synchronisation entre le traitement SYSREQ au niveau du côté hôte de Z and I Emulator for Windows et la saisie des commandes de l'application EHLLAPI.

Lorsque l'application envoie une commande SYSREQ à l'hôte, les situations suivantes se produisent :
  • L'OIA est mis à jour pour indiquer que vous êtes dans une session SSCP-LU.
  • La session Z and I Emulator for Windows envoie la commande AO (SYSREQ) à l'hôte 3270.

Dès que l'hôte reçoit la commande SYSREQ, il répond à Z and I Emulator for Windows avec le code 0x15 ou NL (NewLine). Quand Z and I Emulator for Windows traite cette commande NL en remplissant le reste de la ligne avec des valeurs NULL et en déplaçant le curseur au début de la ligne suivante.

Un problème survient lorsque l'application EHLLAPI continue de saisir diverses commandes dans l'écran hôte (via la fonction SendKeys), avant même que la session Z and I Emulator for Windows a reçu la commande NL de l'hôte et l'a traitée. En conséquence, une partie de la commande d'entrée est d'abord saisie à l'écran, tandis que la commande NL est traitée et que le curseur est déplacé vers la ligne suivante. Ensuite, la partie restante de la commande est saisie sur la ligne suivante. Ainsi, seule la deuxième partie tronquée de la commande est envoyée à l’hôte, provoquant des résultats erronés.

Résolution
La solution à ce problème consiste à forcer l'application EHLLAPI à attendre que la commande NL soit reçue et traitée, avant de continuer à saisir les commandes sur l'écran hôte. Une fois que la session a notifié l'application EHLLAPI que la réponse de l'hôte pour SYSREQ a été traitée, l'application EHLLAPI peut alors continuer sa saisie (car la session est désormais dans le bon état pour accepter une nouvelle saisie). Pour ce faire, utilisez les appels de fonction EHLLAPI suivants : 
Start_Host_Notification (23) Pause (18) Set_Session_Parameters (9) Query_Host_Update (24).
Le code possible dans l'application EHLLAPI est le suivant :
  • Appel Sendkeys(@A@H). Cela envoie la commande SYSREQ à la session.
  • Appel StartHostNotify avec l’entrée B, où B indique la notification d’OIA et de PS. Cela indique à la session de notifier l'application EHLLAPI lorsque l'OIA et/ou le PS de la session sont mis à jour par l'hôte.
  • Appel Pause, en spécifiant un délai d'attente suffisant. Cela amène l'application EHLLAPI à attendre que la session la notifie d'une mise à jour de l'hôte vers l'OIA et/ou le PS de la session. Cela se produit lorsque la session reçoit la réponse de l'hôte la plus attendue pour la commande SYSREQ. Notez que si la valeur du délai d'attente a été dépassée et qu'aucune notification de l'hôte n'a été reçue, l'appel de la fonction Pause est toujours renvoyé.

De plus, pour que cet appel Pause fonctionne, vous devez utiliser l'appel de fonction Set_Session_Parameters (9) pour activer l'option IPAUSE. Ceci est nécessaire, car il indique à l'appel d'API Pause de revenir lorsque l'hôte notifie la session d'une mise à jour OIA et/ou PS.

Si Pause est renvoyée en raison d'une mise à jour OIA/PS (notification de l'hôte), sa valeur de retour est de 26. Si tel est le cas, vous êtes prêt à envoyer la commande de l'hôte. Sinon, vous devez attendre à nouveau la réponse de l'hôte.

L'application EHLLAPI peut poursuivre la commande une fois qu'elle sait que l'OIA ou l'espace de présentation (ou les deux) ont été mis à jour par l'hôte. QueryHostUpdate est utilisé pour vérifier ce qui a été mis à jour : c'est-à-dire si l'OIA seul a été mis à jour (code retour 21), ou si le PS seul a été mis à jour (code retour 22) ou si l'OIA et le PS ont été mis à jour (code retour 23).

Par exemple, le code EHLLAPI peut ressembler à la partie suivante : 
Send Keys(@A@H) /* Send SYSREQ command to the host */ Start Host Notification with 'B' in byte 2 /* Enable notification to EHLLAPI application when session's OIA and/or PS are updated */ Set Session Parms with IPAUSE option /* Allow Pause to be interrupted */ Label WW: Pause for 15 seconds /* 15 secs is a sample time-out value */ retVal = Query Host Update /* Store return value of QueryHostUpdate() into retVal */ If (retVal = 21 or 22 or 23) /* OIA and/or PS was updated */ Send Keys("Your Input Command to host") /* Send input command to host */ else goto (Label WW) Stop Host Notification /* Disable host notification */

Il s'agit de la solution la plus appropriée à ce problème, car l'application EHLLAPI attend le temps minimum exact requis pour permettre à la session de recevoir et de traiter la réponse de l'hôte SYSREQ, avant d'envoyer sa commande.

Une autre solution consiste à ajouter un délai [par exemple, Sleep(1000)] dans l'application EHLLAPI entre la commande SYSREQ et la commande suivante, afin que la session dispose de suffisamment de temps pour recevoir et traiter la réponse de l'hôte. Cependant, cette solution n’est pas la meilleure, car le délai peut être trop faible ou excessif.

Reportez-vous à la RFC 2355 (améliorations TN3270) pour plus d'informations sur la fonctionnalité 3270 SYSREQ.