Se connecter à IMS

Le modèle de programmation IMS Connect donne accès aux transactions IMS (Information Management Systems) à l’aide de TCP/IP. Ce modèle utilise la file d’attente de messages IMS pour traiter les données.

La figure suivante résume le workflow qui se produit entre le client, l’écouteur IMS par défaut, 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.

Processus par lequel le client transmet des données d’entrée à l’écouteur ITOC et le HWSIMSO0 donne accès au programme IMS, qui remet les données de réponse au client

Diagramme de workflow de synthèse pour le modèle de programmation IMS Connect

Le modèle de programmation IMS Connect fonctionne comme suit :

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

2. Le runtime TI appelle le proxy TI Automation.

3. Si l’application est un assembly .NET Framework, le proxy TI Automation :

   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 aux types de données COBOL.

      Ensuite, le proxy TI Automation :

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

   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 runtime TI envoie un message de requête initial (IRM) à IMS Connect, soit HWSIMSO0, soit HWSIMSO1, à l’aide de l’adresse IP de l’ordinateur central et de l’adresse de port IMS Connect, qui sont stockées dans le jeu de données de profil TCP/IP (hlq.PROFILE.TCPIP) fourni par IBM.

   HWSIMSO0 et HWSIMSO1 sont des routines de sortie de serveur web hôte (HWS) fournies par IBM qui définissent les protocoles de requête et de réponse entre le serveur TI Automation (application TI .NET Framework) et ITOC. Le HWS s’exécute dans un espace d’adressage z/OS distinct des régions IMS et exécute les services d’écouteur pour la connexion IMS.

5. La routine de sortie IMS Connect prend le contrôle de l’application IMS (appelée connexion IMS TCP/IP OTMA (Open Transaction Management Architecture) (ITOC)).

6. Le runtime de TI envoie un en-tête de requête ITOC à ITOC et HWSIMSO0.

7. La routine de sortie HWSIMSO0 :

   • Valide l’en-tête de requête ITOC

   • Reçoit toutes les données de requête du runtime de TI

   • Communique avec les routines de sécurité

   • Pilote le processus OTMA pour se connecter à un magasin de données IMS

   • Place et récupère des segments de message dans et à partir de la file d’attente de messages IMS via OTMA

   • Envoie tous les segments de données de réponse au runtime de TI

   • Contrôle les opérations de récupération dans IMS

8. ITOC lit les informations d’en-tête ITOC, localise la bonne région IMS et planifie l’exécution d’une transaction IMS dans cette région IMS. L’en-tête ITOC doit contenir les informations suivantes :

   • Identificateur de routine de sortie ITOC HWS (par défaut '*IRMREQ*')

   • Identificateur du magasin de données IMS

   • Identificateur de la transaction

   • Informations sur le contrôle de flux

   • Informations d’identification de sécurité d’IBM Resource Access Control Facility (RACF)

   • Indicateurs de contrôle de protocole

9. HWSIMSO0 planifie la bonne file d’attente de messages IMS

10. Le runtime de TI envoie les segments de données de la requête à ITOC

11. Le runtime de l’TI envoie EOM

12. La région de contrôle IMS l’envoie à la région de traitement des messages (MPR)

13. Une fois que toutes les données de requête sont placées dans la file d’attente de messages IMS, l’exécution de la transaction est planifiée

14. Le programme d’application de serveur IMS utilise les commandes d’interface d’appel CBLTDLI Get Unique (GU), Get Next (GN) et Insert (INSRT) standard pour extraire les données de la requête et placer les données de réponse dans la file d’attente de messages IMS.

15. MPR retourne les données à TI. ITOC envoie EOM-CSMOKY, ITOC renvoie les informations suivantes au runtime TI :

    • Message de modification de requête

    • Segments de données de réponse

    • Segment de fin de message

    • Segment CSMOKY

16. ITOC et la routine de sortie ITOC suppriment ensuite les données de réponse de la file d’attente de messages et les remet à nouveau au runtime de TI.

17. Le proxy TI Automation 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 TCP.

    2. lit le message dans la mémoire tampon

       Si l’application est un assembly .NET Framework, 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 de données COBOL en données d’application

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

    Pour plus d’informations sur la configuration du mainframe et l’écriture d’applications serveur pour TCP/IP, consultez TCP/IP V3R2 pour z/OS : IMS TCP/IP Application Developers Guide (IBM Document #SC31-7186) et IMS Connect Guide and Reference V1R2 (IBM Document #SC27-0946).

    Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation IMS Connect. L’exemple de code se trouve dans le \répertoire d’installation\SDK\Samples\AppInt. Démarrez Visual Studio, ouvrez le didacticiel de votre choix 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