Liaison de messages de demande de transaction TCP
Le modèle de liaison des messages de requête de transaction TCP (TRM) permet de transmettre des données et des paramètres entre l’TI et le TP du serveur via le COMMAREA. Le modèle permet également à un serveur simultané de créer une liaison vers un programme CICS DPL. L’écouteur standard pour TCP/IP utilise deux échanges réseau pour exécuter un programme transactionnel unique et nécessite que le client effectue les actions suivantes :
Envoyer un message de requête de transaction (TRM) à l’écouteur standard.
Recevoir une réponse TRM du programme d’application.
Envoyer le flux de données de requête de l’application au programme transactionnel du serveur.
Recevoir les données de réponse de l’application à partir du programme transactionnel du serveur.
Le modèle de liaison TCP TRM est basé sur le modèle de serveur simultané CICS. Le modèle de liaison TCP TRM est une variante Microsoft qui prend en charge l’exécution de programmes d’application serveur DPL au sein de l’environnement CICS et maintient la compatibilité avec le modèle de programmation de liaison CICS LU 6.2.
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 mainframe. 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.
Processus par lequel le client démarre l’écouteur par défaut, qui transmet l’appel au serveur simultané, qui envoie et reçoit des données à partir du client, que le serveur transmet ensuite au programme CICS DPL pour le traiter par la logique métier
Récapitulatif du workflow pour le modèle de programmation de liaison TCP TRM
Le modèle de programmation de liaison TCP TRM fonctionne comme suit :
Une application appelle une méthode dans un composant TI configuré dans les Services de composants ou .NET Framework.
Le runtime TI appelle le proxy TI Automation.
Si l’application est un composant COM+, le proxy TI Automation :
lit dans la bibliothèque de types créée précédemment par le Concepteur TI,
mappe les types de données Automation aux types de données COBOL.
Si l’application est un assembly .NET Framework, le proxy TI Automation :
lit l’assembly et les métadonnées créés précédemment par le Concepteur TI,
mappe les types de données .NET Framework aux types de données COBOL.
Ensuite, le proxy TI Automation :
appelle les routines de conversion pour convertir les données d’application en types COBOL de mainframe.
génère la mémoire tampon aplatie du flux de données qui représente la déclaration ou le copybook COBOL.
transmet le flux de données au composant de transport TCP.
Le transport TCP TI envoie une requête de connexion à l’écouteur standard à l’aide de l’adresse IP (Internet Protocol) du macroordinateur et de l’adresse de port de l’écouteur.
L’écouteur standard accepte la requête de connexion et indique au runtime TI d’envoyer le TRM. L’écouteur standard attend ensuite le TRM.
Le TRM 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 de macroordinateur spécial, dont la fonction principale consiste à recevoir les appels TP de serveur envoyés par les applications clientes exécutant TCP/IP.
Le TRANID di TP de l’écouteur standard fourni par IBM est CSKL. Le nom TP du TP de l’écouteur tel qu’il apparaît dans la table de contrôle de programme (PCT) est EZACIC02.
Le runtime TI formate un TRM standard ou personnalisé et l’envoie à l’écouteur standard. Le runtime TI attend ensuite la réponse TRM.
L’écouteur standard reçoit le TRM, envoie une confirmation de réception au runtime TI, puis lit le contenu du TRM. L’écouteur interprète les informations dans le TRM et extrait l’ID de transaction du programme de serveur simultané qui doit traiter la requête.
L’écouteur standard démarre le programme du TP de serveur simultané identifié par TRANID dans l’exemple d’application TRM (Mscmtics.cbl) avec EXEC CICS Start.
Mscmtics.cbl est l’exemple de fichier TP Microsoft utilisé pour transmettre 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 le macroordinateur 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 COMTI. 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 standard appelle l’interface de protocole d’application (API) de socket dans l’environnement hôte. L’écouteur standard ne peut pas envoyer la réponse TRM. La réponse TRM représente un processus de synchronisation qui permet de démarrer le programme transactionnel avant que l’application demande l’envoi de données par le client. Ce processus de synchronisation est nécessaire en raison de la prise en compte de l’architecture CICS interne (il n’y a aucune garantie quant au moment où un programme transactionnel est démarré une fois la requête effectuée).
Une fois que l’écouteur CICS standard a émis la commande de démarrage pour la transaction de serveur simultanée, l’écouteur standard n’est plus nécessaire pour le traitement de l’application et est libre d’écouter une autre requête entrante.
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 COMTI 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.
Le serveur simultané :
met en forme la réponse TRM standard ou personnalisée,
envoie une réponse TRM au transport TCP TI pour lui indiquer qu’il peut désormais envoyer les données de requête de l’application.
émet une réception et attend les données de requête de l’application.
L’envoi de la réponse TRM termine la première partie de la séquence d’échange de l’écouteur standard.
Le runtime TI évalue le TRM et transmet les données au programme serveur simultané par le biais de l’éditeur de COMMAREA CICS à l’aide d’un appel de liaison EXEC CICS standard. Le runtime TI envoie également un arrêt de socket (c’est-à-dire 2 octets), puis attend les données de réponse.
Une fois que le serveur simultané a reçu les données de demande de l’application, il est lié au programme d’application de service qui a été spécifié dans l’en-tête de message client TRM. La commande CICS EXEC CICS LINK est utilisée pour démarrer l’application serveur réelle. La commande Liaison transmet les données d’application reçues du transport TCP COMTI à la zone commune de mémoire (COMMAREA) et exécute la logique métier sur les données. Toute la logique métier est définie dans le TP du serveur.
Une fois que le programme d’application serveur a terminé de traiter la requête et de formuler la réponse, il émet une commande EXEC CICS RETURN pour redonner le contrôle au programme serveur simultané (mscmtics.cbl). Le TP du serveur prépare les données de réponse avec un TRM standard ou personnalisé, accepte les données du COMMAREA, puis renvoie les données de réponse de l’application au transport TCP TI via le COMMAREA. L’exécution du traitement des données d’application signale la fin de la deuxième séquence d’échange.
Le serveur simultané ferme le socket.
Le proxy TI Automation reçoit les données de réponse et traite la réponse. Le proxy TI Automation :
reçoit le message du composant de transport TCP,
lit le message dans la mémoire tampon.
Si l’application est un composant COM+, le proxy TI Automation :
mappe les types de données COBOL aux données Automation,
appelle les routines de conversion pour convertir les types COBOL mainframe en données d’application.
Si l’application est un assembly .NET Framework, le proxy TI Automation :
mappe les types de données COBOL aux types de données .NET Framework.
appelle les routines de conversion pour convertir les types COBOL mainframe en données d’application.
Le runtime TI renvoie les données converties à l’application COM ou .NET Framework qui a appelé la méthode.
Pour implémenter ce modèle, vous devez fournir à TI une adresse IP, un numéro de port et un nom de programme CICS pour exécuter l’application transmise par le programme de serveur simultané (Mscmtics.cbl). Le modèle nécessite l’installation, dans CICS, de l’écouteur par défaut fourni par IBM (EZACIC02). L’écouteur CICS par défaut d’IBM utilise les paramètres par défaut fournis par IBM.
Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation TCP TRM Link. L’exemple de code se trouve dans le \répertoire d’installation\SDK\Samples\AppInt. Démarrez Microsoft Visual Studio, ouvrez le didacticiel de votre choix et suivez les instructions du fichier Lisez-moi.
Pour plus d’informations sur la configuration des applications de macroordinateur et serveur 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
Choisir le modèle de programmation approprié
Modèles de programmation