Partager via


Données utilisateur IMS LU6.2

Le modèle de programmation IMS LU6.2 fournit un accès aux transactions IMS à l’aide de LU6.2.

La figure suivante résume le workflow qui se produit entre le client, l’écouteur IMS 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 montrant l’intégrateur de transactions qui envoie et reçoit lu 6.2 à partir de z/OS/APPC, qui envoie et reçoit ensuite à partir de la file d’attente de messages IMS.
Intégrateur de transactions envoyant et en recevant LU 6.2 à partir de z/OS/APPC, qui envoie et reçoit ensuite à partir de la file d’attente de messages IMS

Diagramme de workflow de synthèse pour le modèle de programmation de données utilisateur IMS LU6.2

Le modèle de programmation IMS LU6.2 fonctionne comme suit : une application appelle une méthode dans un objet .NET TI.

  1. Le runtime TI appelle le proxy TI Automation.

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

  3. Ensuite, le proxy TI Automation :

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

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

    3. Transmet le message au composant de transport SNA.

  4. Le proxy TI Automation envoie la demande d’exécution de transaction (TER) et les données utilisateur à z/OS APPC par le biais de l’application APPC(APPC/z/OS) fournie par IBM.

  5. L’application APPC/z/OS demande à IMS de placer la demande d’exécution de transaction et les données utilisateur dans la file d’attente de messages IMS.

  6. IMS planifie le TP du serveur dans une région de traitement des messages (MPR).

  7. Une fois l’exécution commencée, le TP émet une commande DL/I Get Unique (GU) pour obtenir les paramètres d’entrée qui ont été envoyés par le runtime TI. S’il existe un jeu d’enregistrements d’entrée non lié, le TP effectue également un ou plusieurs Get Next (GN) pour obtenir chaque ligne du jeu d’enregistrements qui a été envoyé.

  8. Une fois que le TP a traité les entrées et effectué des appels de base de données, il effectue un ou plusieurs appels d’insertion (ISRT) pour placer les paramètres de sortie et éventuellement un jeu d’enregistrements de sortie ou de retour sans limite dans la file d’attente de messages IMS à empaqueter et à renvoyer au runtime TI via l’application APPC/z/OS.

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

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

  11. lit le message dans la mémoire tampon

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

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

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

    Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation de données utilisateur IMS LU6.2. L’exemple de code se trouve dans le \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 z/OS COBOL]
Conversion de types de données de z/OS COBOL vers Automation
Composants IMS
Runtime TI
Choisir le modèle de programmation approprié
Modèles de programmation