Tutorial Mainframe (site externe) : CICS, COBOL, DB2, IMS, VSAM, JCL

Bonsoir,

Je cherchais un site avec compilateur en ligne pour aider une amie qui souhaite apprendre à développer sans se soucier de l'installation des logiciels...
Et en fouinant je suis tombé sur quelque chose qui me semble super intéressant pour les débutants comme moi sur CICS et autres IMS :
http://www.tutorialspoint.com/mainframe_tutorials.htm

Des experts peuvent valider que les quelques présentations et explications sont correctes ?


Pour les compilateurs en ligne : http://www.tutorialspoint.com/codingground.htm
Il faut savoir utiliser un minimum Linux avec les commandes "gcc, python, ls" pour le C et le Python, mais je confirme qu'ils fonctionnent.

Bonjour Metalman,

"IBM Mainframe and Associated Technologies" --> Bon pour DB2 c'est une présentation LUW et pas z/OS, donc Mainframe pas vraiment ;-)

Pour le reste, en regardant seulement le découpage des sommaires (j'avoue) ça semble plutôt intéressant pour une formation initiale.

Bonjour,

Pour la partie IMS, seul le composant SGBD me semble être présenté (IMS DB). Le composant Gestionnaire de Transactions (IMS TM) est à peine mentionné, sauf erreur de ma part.

Bonjour,

Je viens de survoler la partie COBOL & JCL associé (pratiqué pendant une dizaine d'années il y a 30 ans :aie: ) :
Excellente approche didactique et commentée, à lire avec la section "les bonnes pratiques du développeur".

ps:
Merci Metalman pour ces tutoriels dont certains sont reproductibles dans un autre environnement (cf. "les bonnes pratiques") - j'adore la rigueur du Mainframe, environnements sur lesquels j'ai débuté, ça me sert encore de nos jours sur Unix/Linux, sur un peu de Microsoft aussi, voire à l'occasion lors de projets transversaux impliquant des collègues IT officiant sur Z/Os ;)

Dans le chapitre CICS, la gestion des erreurs est "à l'ancienne" avec utilisation des handle conditions :aie:, il n'est nullement mentionné la possibilité, grâce aux mots clefs RESP et RESP2 que l'on peut intercepter unitairement les diagnostics après chaque ordre CICS. C'est dommage.

Il n'est pas non plus fait mention des containers, l'article doit dater un peu.

Il manque des instructions concernant les fichiers (STARTBR, RESETBR...)

Cela dit, la présentation est de qualité, les principes généraux sont là et l'ensemble est plutôt agréable à utiliser.

Citation:

---

Envoyé par Luc Orient

Bonjour,

Pour la partie IMS, seul le composant SGBD me semble être présenté (IMS DB). Le composant Gestionnaire de Transactions (IMS TM) est à peine mentionné, sauf erreur de ma part.

---

tout à fait, uniqumeent la partie DL1, par contre c'est un excellent tuto

Merci à tous d'avoir lu et validé !

Bon, pour les 3 prochaines années, il est peu probable que je pratique le mainframe, mais je saurai quoi lire pour m'y remettre ou découvrir CICS et ses copains ! :)



Pour ceux qui voudraient se remettre à COBOL, il y a le compilateur en ligne : http://www.tutorialspoint.com/compile_cobol_online.php
Ou du REXX : http://www.tutorialspoint.com/execute_rexx_online.php
...ou pour ceux qui voudraient (re)tenter du FORTRAN (format 95) : http://www.tutorialspoint.com/compil...ran_online.php

Attention à sauvegarder les fichiers/le contenu.

Je suis très réservé concernant la partie COBOL

Section sur les formats des données :
- pas de détail concernant l'alignement sur les frontières de mots des variables de type 01 ou autre, ni sur l'encombrement WSS induit
- pas de détail concernant l'impact du format de données sur les perfs

Section appel aux sous programmes :
- la notion d'appel statique/dynamique est abordée mais il n'est pas indiqué que l'appel avec nom du prog en dur tel que donné en exemple (entre cote) force un appel statique

Section entrées/sortie :
Le bout de code ci-dessous comporte des erreurs graves

Code:

---

1 2 3 4 5 6 7 8

OPEN INPUT STUDENT. PERFORM UNTIL WS-EOF='Y' READ STUDENT INTO WS-STUDENT AT END MOVE 'Y' TO WS-EOF NOT AT END DISPLAY WS-STUDENT END-READ END-PERFORM. CLOSE STUDENT.

---

- si après lecture, le file status est différent de zéro et 10, alors le programme boucle !
- aucun test de file-status n'est fait après open, read, close
- utilisation d'une variable manuelle pour gérer la fin de fichier alors qu Z/OS alimente automatiquement le file status
- utilisation de la clause AT END qui n'a de sens que pour une lecture séquentielle et n'intercepte que la fin de fichier
alors que le file status intercepte tous les codes retour, et est applicable pour toutes les méthodes d'accès (sequentiel, random, dynamic)

:(

Citation:

---

Envoyé par escartefigue

Section appel aux sous programmes :
- la notion d'appel statique/dynamique est abordée mais il n'est pas indiqué que l'appel avec nom du prog en dur tel que donné en exemple (entre cote) force un appel statique


:(

---

sauf si l'option DYNAM est positionné dans le compilateur

Citation:

---

Envoyé par escartefigue

Je suis très réservé concernant la partie COBOL
(...)

---

... On peut toujours se référer / s'initier aux fondamentaux, cf. Les procédures de traitement et leurs données – LCP (Logique de Construction de programmes) du regretté Jean-Dominique Warnier.

Citation:

---

Envoyé par Escapetiger

... On peut toujours se référer / s'initier aux fondamentaux, cf. Les procédures de traitement et leurs données – LCP (Logique de Construction de programmes) du regretté Jean-Dominique Warnier.

---

Excellente référence malheureusement aujourd'hui quasi oubliée :(

Citation:

---

Envoyé par escartefigue

...
Section entrées/sortie :
Le bout de code ci-dessous comporte des erreurs graves

Code:

---

1 2 3 4 5 6 7 8

OPEN INPUT STUDENT. PERFORM UNTIL WS-EOF='Y' READ STUDENT INTO WS-STUDENT AT END MOVE 'Y' TO WS-EOF NOT AT END DISPLAY WS-STUDENT END-READ END-PERFORM. CLOSE STUDENT.

---

- si après lecture, le file status est différent de zéro et 10, alors le programme boucle !
- aucun test de file-status n'est fait après open, read, close
- utilisation d'une variable manuelle pour gérer la fin de fichier alors qu Z/OS alimente automatiquement le file status
- utilisation de la clause AT END qui n'a de sens que pour une lecture séquentielle et n'intercepte que la fin de fichier
alors que le file status intercepte tous les codes retour, et est applicable pour toutes les méthodes d'accès (sequentiel, random, dynamic)

:(

---

Non je ne crois pas que le programme puisse boucler ...

Toutes ces considérations autour du FILE STATUS n'ont pas lieu d'être ici, puisque si l'on regarde la totalité du programme, le aucune déclaration de FILR STATUS n'est associé au fichier. Si une erreur d'entrée / sortie se produit lors de l'exécution, le système d'exploitation prendra la main et fera tout simplement "tomber" le processus en cours d'exécution.

Citation:

---

Envoyé par Luc Orient

Non je ne crois pas que le programme puisse boucler ...

Toutes ces considérations autour du FILE STATUS n'ont pas lieu d'être ici, puisque si l'on regarde la totalité du programme, le aucune déclaration de FILR STATUS n'est associé au fichier. Si une erreur d'entrée / sortie se produit lors de l'exécution, le système d'exploitation prendra la main et fera tout simplement "tomber" le processus en cours d'exécution.

---

Justement c'est dommage d'utiliser AT END qui ne connait que le FS "10" alors que déclarer et utiliser le FS permet de gérer tous les cas, et de restituer les infos sur toutes les entrées sorties, pas seulement le read (open, close etc...)
L'OS ne décide pas tout seul de planter suite à un FS invalide c'est au développeur de déclencher le plantage (on est pas dans un cas de data exception, protection exception etc...)
Ex : si FS=30 le programme boucle

De plus, on est ici dans un guide, qui a pour vocation de montrer l'exemple, c'est pourquoi il faudrait préciser que cette méthode n'est applicable que pour un séquentiel, et donner un exemple avec un fichier indexé avec accès direct ou random, et là, le AT END n'a aucun sens, la gestion du FS devient obligatoire (invalid key ne répondant pas non plus à tous les cas)
La gestion par FS a l'avantage non seulement d'être plus riche, mais aussi d'être applicable quelque soit la méthode d'accès (sequentiel, random ou dynamique)

Citation:

---

Envoyé par escartefigue

L'OS ne décide pas tout seul de planter suite à un FS invalide c'est au développeur de déclencher le plantage (on est pas dans un cas de data exception, protection exception etc...)
Ex : si FS=30 le programme boucle

---

Encore une fois la question ne se pose pas en ces termes, puisqu'il n'y a pas de FILE STATUS de déclaré ici ...

Citation:

---

If you do not code a FILE STATUS key or a declarative, serious QSAM processing
errors will cause a message to be issued and a Language Environment condition to
be signaled, which will cause an abend if you specify the runtime option
ABTERMENC(ABEND).

---

Source;
Enterprise COBOL for z/OS - Programming Guide - V4R2

Citation:

---

Envoyé par Luc Orient

Encore une fois la question ne se pose pas en ces termes, puisqu'il n'y a pas de FILE STATUS de déclaré ici ...

---

Encore une fois JE REGRETTE JUSTEMENT QUE LE FILE STATUS NE SOIT PAS DECLARE !

Qui peut le plus peut le moins, AT END n'apporte rien en comparaison

Concernant l'abend, ABTERMENC(ABEND) n'et pas la valeur par défaut (source https://www-01.ibm.com/support/knowl...a200/metuc.htm).

La question que je me pose, quelle exception serait utilisée sur une erreur I/O non interceptée telle qu'un FS30, parmi le tableau (issu du même lien)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Table 1. Program interrupt abend and reason codes in a non-CICS environment Program interrupts Abend code Abend reason code Operation exception S0C1 00000001 Privileged operation exception S0C2 00000002 Execute exception S0C3 00000003 Protection exception S0C4 00000004 Segment translation exception (note 1) S0C4 00000004 Page translation exception (note 2) S0C4 00000004 Addressing exception S0C5 00000005 Specification exception S0C6 00000006 Data exception S0C7 00000007 Fixed-point overflow exception S0C8 00000008 Fixed-point divide exception S0C9 00000009 Decimal overflow exception S0CA 0000000A Decimal divide exception S0CB 0000000B Exponent overflow exception S0CC 0000000C Exponent underflow exception S0CD 0000000D Significance exception S0CE 0000000E Floating-point divide exception S0CF 0000000F Note: 1.The operating system issues abend code S0C4 reason code 10 for segment translation program interrupts. 2.The operating system issues abend code S0C4 reason code 11 for page translation program interrupts.

---

Execution exception ?

Citation:

---

Envoyé par escartefigue

Encore une fois JE REGRETTE JUSTEMENT QUE LE FILE STATUS NE SOIT PAS DECLARE !

---

Certes, mais des regrets n'ont jamais fait boucler un programme ...

Citation:

---

Concernant l'abend, ABTERMENC(ABEND) n'et pas la valeur par défaut (source https://www-01.ibm.com/support/knowl...a200/metuc.htm).

---

On ne doit pas avoir la même source de documentation ;

Citation:

---

ABTERMENC

z/OS Language Environment Programming Reference
SA38-0683-00

Derivation: ABnormal TERMination of the ENClave

ABTERMENC sets the enclave termination behavior for an enclave ending with an unhandled condition of severity 2 or greater. TRAP(ON) must be in effect.

The default value for non-CICS applications is ABTERMENC(ABEND).

The default value for CICS® applications is ABTERMENC(ABEND).

---

Citation:

---

La question que je me pose, quelle exception serait utilisée sur une erreur I/O non interceptée telle qu'un FS30, parmi le tableau (issu du même lien) OTE]

---

Aucune de celles ci ... pour moi, ça sera un ABEND U4038

J'appuie entierement les propos de Luc lorient, d'ailleurs concernant le choix de coder ou non le File-status c'est un choix d'entreprise.
par exmeple sur mon site, nous interdisons de tester les File-Status le choix fait est de laisser le système le gerer et donc de tomber le Job. c'est beaucoup plus ismple pour le suivi de production de notre prestataire d'avoir en résultat de Job un message standard Z/os indiquant l'erreur fichier que d'avoir des pseudo messages d'erreurs souvent en display qui veulent plus ou moins dire quelques chose ou vu aussi, juste un display du File Status snas plus d'explication, voir parfois le programme qui continue et se fini en RC=0. pas facile de suivre ce genre de chose sur une production..

idem, pour moi le programme ne boucle pas dans ce cas précis.

pour ce qui est de l'exception, je dirais les messages type IECxxxx plus avec le Runtime LE indiqué Abend U4038, plus surement un message type CEE en fin de SYSOUT et aussi un CEEDUMP

:weird: étrange tout de même https://www-01.ibm.com/support/knowl...a200/metuc.htm

Citation:

---

Termination behavior for unhandled conditions
[. . .]
If you are running in a CICS® environment, the IBM-supplied default is to terminate the enclave with an abend for unhandled conditions of severity 2 or greater.

If you are running in a non-CICS environment and you expect the enclave to terminate with a return code and a reason code for unhandled conditions of severity 2 or greater, you can use the ABTERMENC(RETCODE) runtime option and the CEEBXITA assembler user exit. The default version of CEEBXITA for non-CICS environments requests that the enclave terminate with a return code and a reason code.

---

oui. enfin avec la V2R2, les défaut sont ceux ci :

tout d'abord le TRAP(ON), sinon l'ABTERENC n'aura pas d'effet

TRAP(ON) must be in effect for the ABTERMENC runtime option to have effect. This option is similar to options that were offered by earlier versions of COBOL, C, and PL/I runtime libraries:

puis les défaut de ABTERMENC(ABEND) quelque soit le sous système

cf la doc de la V2R2,
Language Environment customisation
Table 7. Runtime options, defaults, and recommendations for Language Environment
Chapter 5. Customizing Language Environment runtime options


voila pour la derniere version. par contre , ça dépend peut etre de quelle doc vous regardez et en quelle version surtout. j'ai des souvenir de pas mal de changement autour des Defaut des RunTime LE au fil des versions

Citation:

---

Envoyé par xfanx

par exmeple sur mon site, nous interdisons de tester les File-Status le choix fait est de laisser le système le gerer et donc de tomber le Job. c'est beaucoup plus ismple pour le suivi de production de notre prestataire d'avoir en résultat de Job un message standard Z/os indiquant l'erreur fichier que d'avoir des pseudo messages d'erreurs souvent en display qui veulent plus ou moins dire quelques chose ou vu aussi, juste un display du File Status snas plus d'explication, voir parfois le programme qui continue et se fini en RC=0. pas facile de suivre ce genre de chose sur une production..

---

J'ai connu un client qui faisait un peu la même chose : la clause AT END était obligatoire (forcée par un générateur maison, dont le code produit était une véritable horreur) et appliquée y compris pour des fichiers à accès direct :mouarf:

D'autres clients utilisent des copy procédure ou des programmes maison pour gérer les exceptions en fonction du contexte et en s'appuyant sur le file-status.
Cette solution a nettement ma préférence : un message clair est bien plus facile à lire qu'un DUMP, et si on est appelé la nuit lors d'une astreinte, on a pas toujours les idées très claires pour débugger.