Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La figure suivante montre la méthode permettant de recevoir des messages à partir du module d’accès dynamique (DMOD).
Réception de messages à l’aide d’une procédure de routage
Après l’initialisation DMOD, l’émulateur 3270 inscrit la procédure de routage en appelant sepdrout. Lorsque le DMOD reçoit un message, il appelle la procédure de routage de l’émulateur 3270, qui peut ensuite traiter le message.
Avec cette approche, il n'y a aucun changement de contexte entre le thread DMOD et celui de l'émulateur 3270. Toutefois, la procédure de routage doit retourner rapidement le contrôle au DMOD. Par exemple, il ne peut pas interrompre l’attente d’une entrée de clavier.
L’application doit déterminer si le message reçu est destiné à cette application ou pour une autre application. Si le message n’est pas destiné à cette application, la procédure de routage doit retourner, indiquant que le message n’a pas été traité. Si l’application traite le message, elle est chargée de libérer la mémoire tampon lorsque le traitement est terminé.
Dans certains cas, la procédure de routage peut traiter le message jusqu'à son terme. Une autre solution consiste à placer le message dans une file d’attente d’applications, puis à effacer un sémaphore d’application. L’application peut ensuite traiter le message.
Les performances peuvent être améliorées en envoyant un message Status-Resource (pour renvoyer le crédit au nœud local, en lui permettant d’envoyer des données supplémentaires) à partir de la procédure de routage lorsqu’un message est reçu, plutôt que d’attendre que le message soit traité jusqu’à la fin. Cette utilisation est illustrée dans l’exemple de code : initialisation et procédure de routage. Pour plus d’informations sur le contrôle de crédit et de flux, consultez Pacing and Chunking.
Une fois que l’application a reçu un message, l’application est responsable de la mémoire tampon dans laquelle le message a été reçu. L’application doit réutiliser la mémoire tampon pour envoyer un message (à l’aide de sbpusend) ou le libérer (à l’aide de sepdburl). Si la mémoire tampon à réutiliser ne contient pas le nombre correct d’éléments à envoyer pour le message, l’application peut obtenir des éléments supplémentaires (à l’aide de sbpibegt) ou libérer des éléments existants (à l’aide de sbpiberl). Dans ce cas, l’application doit également s’assurer que le champ numelts dans l’en-tête de mémoire tampon indique le nombre correct d’éléments.