Données utilisateur des messages de l’écouteur amélioré TCP

  • Article

Le modèle de données utilisateur de message de l’écouteur amélioré TCP (ELM) permet de passer directement les données et les paramètres entre le TI et le TP du serveur.

La figure suivante résume le workflow qui se produit entre le client, l’écouteur CICS amélioré, le serveur simultané et le programme transactionnel central. Les nombres entre parenthèses indiquent l’ordre approximatif dans lequel les événements se produisent. Une description plus détaillée des événements est illustrée dans la figure.

Image montrant le flux de travail qui se produit entre le client, l’écouteur CICS amélioré, le serveur simultané et le programme de transaction mainframe.
Workflow résumé pour le modèle de programmation de données utilisateur ELM TCP

Modèle de programmation de données utilisateur ELM TCP

Le modèle de programmation de données utilisateur TCP ELM fonctionne de la manière suivante :

  1. Une application appelle une méthode dans un objet .NET TI.

  2. Le runtime TI appelle le proxy TI.

  3. Le proxy TI :

    1. Lit l’assembly et les métadonnées créés précédemment par le Concepteur TI.

    2. Mappe les types de données .NET Framework aux types de données COBOL.

      Ensuite, le proxy TI :

    3. Appelle les routines de conversion pour convertir les données d’application en types COBOL centraux.

    4. Génère la mémoire tampon aplatie de flux de données qui représente la déclaration ou le copybook COBOL.

    5. Transmet le message au composant de transport TCP.

  4. Le transport TCP TI envoie une requête de connexion à l’écouteur amélioré à l’aide de l’adresse IP (Internet Protocol) de l’ordinateur central et de l’adresse de port de l’écouteur.

  5. L’écouteur amélioré accepte la requête de connexion et indique au runtime TI d’envoyer l’ELM. L’écouteur amélioré attend ensuite l’ELM.

    L’ELM est un enregistrement de données mis en forme qui identifie le TP du serveur à appeler à l’aide de son TRANID. L’écouteur TP est un TP central spécial, dont la fonction principale consiste à recevoir les appels TP de serveur envoyés par les applications clientes exécutant TCP/IP.

  6. Le runtime de TI met en forme l’ELM et l’envoie à l’écouteur amélioré. Le TI contourne ensuite la logique de transport qui attend une réponse ELM et envoie immédiatement les données de requête d’application après l’en-tête de requête. TI attend ensuite la réponse ELM.

  7. L’écouteur amélioré reçoit l’ELM de 35 octets, puis lit le contenu de l’en-tête ELM. L’écouteur amélioré place les 35 octets dans le message d’origine de la transaction (TIM), mais n’agit pas sur son contenu.

    Le TIM décrit l’environnement TCP/IP dans lequel le serveur est en cours d’exécution et contient les informations de socket TCP/IP que le serveur simultané utilise pour communiquer avec le transport TCP TI et l’en-tête de message client que le serveur simultané utilise pour personnaliser son comportement d’exécution. L’en-tête contient le nom du programme de serveur à lier.

  8. L’écouteur amélioré démarre l’exemple d’application de serveur TP simultané (Mscmtics.cbl) identifié par le TRANID dans l’ELM à l’aide d’EXEC CICS Start.

    Mscmtics.cbl est l’exemple de fichier TP Microsoft utilisé pour passer des données entre TI et le TP serveur à l’aide de la COMMAREA. L’exemple Mscmtics.cbl est développé par Microsoft et fourni dans le cadre du logiciel Host Integration Server. Il se trouve dans le dossier $\Microsoft Host Integration Server\SDK\Samples\Comti\ProgrammingSpecifics\Tcp. Il doit être compilé, lié et installé sur l’ordinateur central avant d’utiliser ce modèle.

Notes

Si l’écouteur standard ne parvient pas à démarrer le serveur simultané, l’écouteur met en forme un message d’erreur et le renvoie au transport TCP TI. Les raisons pour lesquelles l’écouteur ne peut pas démarrer sont les suivantes :

  • la connexion rejetée en raison de ressources CICS limitées (par exemple, dépasse le nombre maximal de tâches CICS ou de tâches serveur simultanées)

  • TRANID non valide ou désactivé pour le serveur simultané

  • programme de serveur simultané non valide, désactivé ou non disponible associé à l’ID de transaction

Notes

Le message d’erreur de l’écouteur CICS est basé sur des caractères et commence toujours par les lettres EZY. La longueur du message d’erreur est variable et la fin du message est déterminée par la fermeture du socket par l’écouteur CICS. L’écouteur amélioré appelle l’interface de protocole d’application (API) de socket dans l’environnement hôte. Une fois que l’écouteur amélioré a émis la commande de démarrage pour la transaction de serveur simultanée, l’écouteur amélioré est en dehors de la boucle de traitement de l’application et est libre d’écouter une autre requête entrante.

  1. Une fois que le serveur simultané est en cours d’exécution, il lit le message d’origine de la transaction (TIM) envoyé par l’écouteur standard.

    Le TIM décrit l’environnement TCP/IP dans lequel le serveur est en cours d’exécution et contient les informations de socket TCP/IP que le serveur simultané utilise pour communiquer avec le transport TCP TI et l’en-tête de message client que le serveur simultané utilise pour personnaliser son comportement d’exécution.

  2. Le serveur simultané envoie le TRM à TI et attend les données de requête de l’application.

  3. TI évalue le TRM et transmet les données directement au programme de serveur simultané (Mscmtics.cbl). TI envoie également l’arrêt du socket, puis TI attend les données de réponse.

  4. Une fois les données reçues, le TP du serveur exécute la logique métier sur les données. Toute la logique métier est définie dans le TP du serveur.

  5. Le TP du serveur prépare les données de réponse, puis envoie la réponse directement au client.

  6. Le serveur simultané ferme le socket

  7. Le proxy TI reçoit les données de réponse et traite la réponse. Le proxy TI :

    1. reçoit le message du composant de transport TCP.

    2. lit le message dans la mémoire tampon

      Le proxy TI :

    3. mappe les types de données COBOL aux types de données .NET Framework

    4. appelle les routines de conversion pour convertir les types COBOL centraux en données d’application

  8. Le runtime TI renvoie les données converties à l’application COM ou .NET Framework qui a appelé la méthode.

    Host Integration Server comprend un exemple de code illustrant comment implémenter le modèle de programmation de données utilisateur ELM TCP. L’exemple de code se trouve dans \répertoire d’installation\SDK\Samples\AppInt. Démarrez Microsoft Visual Studio, ouvrez le didacticiel que vous souhaitez utiliser et suivez les instructions du fichier Lisez-moi.

    Pour plus d’informations sur la configuration des applications de serveur central et d’écriture pour TCP/IP, consultez TCP/IP V3R2 pour MVS : Guide d’interface des sockets TCP/IP CICS (Document IBM #SC31-7131).

Voir aussi

Composants de l’intégrateur de transactions
Messages de requête de transaction
Conversion de types de données d’Automation en z/OS COBOL]
Conversion de types de données de z/OS COBOL vers Automation
Composants CICS
Runtime TI
Choisir le modèle de programmation approprié
Modèles de programmation