Données utilisateur des messages de demande de transaction TCP

Le modèle de programmation de données utilisateur TRM TCP permet d’échanger des données et des paramètres directement entre TI et le TP hôte. Le modèle de données utilisateur TCP TRM est basé sur le modèle de serveur simultané CICS. L’écouteur standard 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 serveur

  Recevoir les données de réponse de l’application à partir du programme transactionnel serveur

  L’illustration suivante résume le workflow qui se produit entre le client, l’écouteur CICS standard et le serveur simultané. 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 passe l’appel au serveur simultané, qui envoie et reçoit des données à partir du client

Diagramme de workflow de synthèse pour le modèle de programmation de données utilisateur TCP TRM

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

1. Une application appelle une méthode dans un objet .NET TI configuré dans les Services de composant ou dans .NET Framework.

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 standard à l’aide de l’adresse IP (Internet Protocol) de l’ordinateur central et de l’adresse de port de l’écouteur.

5. 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 CICS 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.

   Le TRANID 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.

6. Le runtime TI met en forme le TRM et l’envoie à l’écouteur standard. TI attend la réponse TRM.

7. 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 demande.

8. 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 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.

• 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

1. 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 est en dehors de la boucle de traitement de l’application et est libre d’écouter une autre requête entrante.

2. 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.

3. Le serveur simultané :

   1. Met en forme la réponse TRM.

   2. 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.

   3. É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.

4. TI évalue le TRM et transmet les données au serveur simultané. TI envoie également l’arrêt du socket, puis TI attend les données de réponse.

5. Une fois que le serveur simultané a reçu les données de demande d’application, le serveur exécute la logique métier sur les données.

6. Une fois que le serveur a terminé de traiter la requête et de formuler la réponse, il prépare les données de réponse, puis envoie la réponse directement au client. L’exécution du traitement des données d’application signale la fin de la deuxième séquence d’échange.

7. Le serveur simultané ferme le socket.

8. 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.

9. Le runtime TI renvoie les données converties à l’application .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 passée 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 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