Liaison CICS LU6.2

Le modèle de programmation de liaison CICS LU6.2 est l’un des modèles les plus simples que vous pouvez utiliser pour implémenter la fonctionnalité TI.

La figure suivante résume le workflow qui se produit entre le client, la transaction miroir CICS par défaut 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 that shows a Transaction Integrator sending and receiving parameters with DPL information from a CICS Mirror Transaction.
Transaction Integrator envoyant et recevant des paramètres avec les informations DPL à partir d’une transaction miroir CICS

Le modèle de programmation de liaison CICS LU6.2 fonctionne comme suit :

  1. Une application appelle une méthode dans TI.

  2. Le runtime TI appelle le proxy TI.

  3. Le proxy TI effectue les opérations suivantes :

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

  4. TI envoie la requête CSMI de nom TP spécifiée par la méthode du composant TI à la transaction miroir CICS à l’aide des informations DPL et du protocole LU6.2. (IBM fournit CSMI avec CICS sur les systèmes nécessitant TI.)

    La transaction miroir CICS est un TP spécial CICS qui agit comme une passerelle entre les TP exécutés dans différentes régions CICS, ce qui leur permet d’échanger des données via COMMAREA. TI tire parti de cette méthode de communication standard entre TP CICS pour accéder aux TP de l’ordinateur central. CSMI gère toutes les propriétés APPC et transactionnelles requises sur la communication. Le TRANID pour ce TP est CSMI.

    Distributed Program Link (DPL) est le protocole utilisé pour communiquer avec CSMI. TI utilise DPL pour communiquer avec CSMI.

  5. CSMI (la transaction miroir CICS) prend le contrôle et émet une commande EXEC CICS Link vers le TP serveur demandé dans CICS. (Le nom de ce programme peut être associé à l’environnement distant (RE) et au nom de la méthode dans le Concepteur TI.)

  6. La transaction miroir CICS passe la COMMAREA qui contient les champs d’entrée au TP du serveur.

    Le composant COMMAREA est une zone de communication allant jusqu’à 32 ko contenant toutes les données transmises depuis et vers le programme central. De nombreux TP CICS, écrits en COBOL, utilisent cette zone du code de transaction de l’ordinateur principal pour échanger des données. Lorsque vous utilisez la liaison CICS à l’aide du modèle de programmation LU6.2, le TI apparaît au TP de l’ordinateur central comme un autre TP CISC échangeant des données via la COMMAREA.

    Le TP du serveur est le TP que TI appelle pour le compte de l’application cliente. Il contient la logique métier exécutée et est identifié par son TRANID dans l’appel de méthode de l’application cliente.

    Remarque

    Le terme « TP serveur » est utilisé pour identifier le TP auquel TI accède. Cette clarification est nécessaire, car l’accès aux applications de l’ordinateur central peut, en général, impliquer un certain nombre de TP.

  7. À la fin du traitement du TP du serveur, il émet une commande EXEC CICS RETURN, qui renvoie les données de COMMAREA à la transaction miroir CICS avec tous les champs de sortie mis à jour.

  8. La transaction miroir CICS retourne les données de sortie, le cas échéant, à TI.

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

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

    2. lit le message dans la mémoire tampon

      Le proxy TI Automation :

    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

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

    Seul le modèle de flux est pris en charge avec la liaison CICS. Les jeux d’enregistrements non limités ne sont donc pas pris en charge pour cette classe de TP. Les jeux d’enregistrements à taille fixe (c’est-à-dire les jeux d’enregistrements délimités) sont pris en charge.

    CSMI gère également les interactions de synchronisation de niveau 2 avec l’outil TI, et fournit ainsi de manière transparente la fonctionnalité 2PC pour les programmes de cette classe.

    Les programmes CICS existants peuvent déjà être structurés de cette façon. Au lieu que le TI émette la requête LU6.2, un autre TP CICS peut déjà émettre une liaison CICS EXEC pour exécuter le programme CICS présenté dans l’illustration précédente. Dans ce cas, le TP CICS et le composant TI existants peuvent coexister et exécuter le même programme CICS.

Remarque

CSMI est le nom de la transaction miroir par défaut, mais vous pouvez spécifier un autre nom.

Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation de liaison CICS LU6.2. 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.

Voir aussi

Composants de l’intégrateur de transactions
Conversion de types de données d’Automation en SYSTÈME d’exploitation/390 COBOL]
Conversion des types de données de COBOL OS/390 vers Automation
Composants CICS
Runtime TI
Choisir le modèle de programmation approprié
Modèles de programmation