Bonsoir,
Ah ! IMS... Ancien combattant, je me resitue bien des années en arrière... En ce temps-là :
IMS est caractérisé par essentiellement deux composants, en ces temps reculés on l'appelait IMS DB/DC, « DB » pour « Data Base » et « DC » pour « Data Communication ».
Je ne sais pas comment IMS a évolué et donc je dois être un tantinet obsolète, mais temporibus illis les choses se passaient en gros ainsi :
Quand l’utilisateur Tartempion sollicite IMS par le truchement d’un code transaction (TRX dans l’exemple ci-dessous), le composant DC place la demande de Tartempion dans une file d’attente, comme quand on attend à la Sécu ou à la préfecture (avec quand même un système de priorités...), et son tour venu, charge en mémoire le programme associé à ce code transaction et lui transmet le contrôle (en notant que les collègues de Tartempion peuvent évidemment eux aussi envoyer une transaction TRX ou TRY au même moment).
Des souvenirs me remontent en mémoire... Extrait d’un cours que j’avais bâti dans les années soixante-dix, du temps des cartes perforées (mais on avait quand même des terminaux...) :
Le composant DC permet aux programmes d’échanger avec IMS au moyen d’une paire d’instructions, ENTRY et CALL.
Exemple : IMS passe le contrôle à mon programme à un point d’entrée convenu (ici en COBOL) :
ENTRY 'DLITCBL' USING IOPCB, PCBING
où DLITCBL signifie DLI TO COBOL (« moi, IMS/DL1 je te passe le contrôle à toi, programme Cobol Px »). Depuis toutes ces années l'instruction ENTRY a peut-être disparu au profit d’un autre, mais pas le principe.
IOPCB contient quelques données d’échange entre IMS et le programme Px, tel que le code retour (transaction terminée/pas terminée, erreur unetelle, etc.) et PCBING (PCB = Program Communication Block)correspond à la structure logique de la base de données partie prenante dans cet échange (ici la base de données des ingénieurs de l’entreprise).
Avant d’accéder à la base de données, le programme sollicite IMS au moyen d’une instruction CALL pour lire les messages de l’utilisateur Tartempion et donc savoir ce qu’il veut (en l’occurrence tout savoir sur l’ingénieur Gérard à partir de son matricule, parce que par convention Tartempion a codé 'GP' en regard du champ MATRIC, prédéfini dans l’écran de saisie) :
CALL 'CBLTDLI' USING FONCTION, IOPCB, IOAREA
FONCTION : la fonction que je veux exécuter : lire une ligne du message (qui peut être multi-lignes) qu’IMS me sous-traite ;
IOPCB : idem ci-dessus ;
IOAREA : le contenu de la ligne du message (ici : MATRIC = GP, disons). L’écran correspondant est structuré en champs (outre le nom de l’ingénieur, sa date naissance, les logiciels pour lesquels il est compétent, etc.)
Le programme exploite ce contenu et part à l’assaut de la base de données en conséquence (toujours par CALL 'CBLTDLI', mais au composant DB), pour récupérer les données concernant le camarade Gérard et les transmettre à IMS (par CALL au composant DC).
Merci de me signaler les erreurs que j'ai pu commettre, car depuis le temps, j'ai beaucoup oublié...
IMS est fait pour traiter les accès concurrents, donc gérer les conflits en mise à jour, y compris les étreintes fatales (dead locks), la sécurité (qui a le droit de faire quoi), les reprises à chaud ou à froid (recovery), la journalisation, permettant ainsi de remonter dans le temps (très loin au besoin, quand par exemple les bases sont « vérolées »). IMS fournit bien sûr un tas d’outils sophistiqués de chargement de base de données, de sauvegarde et de réorganisation orientés très grandes bases de données. Etc. En 2011, la panoplie a dû bougrement s’étoffer depuis ces temps héroïques...
Envoyé par
zOS19
IMS n'utilise pas DB2 donc n'utilise pas le sql
Heu... Extrait de IBM DATABASE 2 Reference, Release 1.0 (November 6th, 1984) :
Il y a 27 ans, DB2 communiquait donc avec IMS. Manifestement, en 2011 (DB2 V10) cela paraît être toujours vrai...
Partager