Version imprimable
Bonjour,
L'appareillage de deux fichiers séquentiels de structures différentes et ayant une même clef de comparaison afin d'en produire un troisième est un exercice fréquent en COBOL.
Vous trouverez ci-joint un petit modèle (éprouvé) qui devrait vous permettre de produire rapidement une solution propre.
Bon courage aux novices.
J'avoue ne pas comprendre l'algorithme sous-jacent à ton programme COBOL
Mon problème est le suivant :
Pourquoi avoir conditionné la sortie de la boucle principale du programme par la seule fin du fichier FICIN001 ?
En effet, si la clé du dernier enregistrement de ce fichier est inférieure à la clé du dernier enregistrement de l'autre fichier (FICIN002) que va-t-il se passer, ou, en d'autres termes, si le premier fichier se termine "avant" le second fichier ?
Notamment, pour le cas particulier où le fichier FICIN001 est vide alors que le fichier FICIN002 ne l'est pas ?
Merci de bien vouloir m'éclairer ...
Bonjour,
Tu as entièrement raison dans l'absolu Luc.
Pour être tout à fait clair, j'aurais dû préciser que, dans tous les cas fonctionnels (banque, assurance, industrie automobile ...) où j'ai eu à utiliser ce type de programme, le fichier FICIN001 était dit "fichier maître" et que le second fichier servait à enrichir les données correspondantes dans le premier. En cas de fichier FICIN001 vide, on plantait la chaîne de traitement ou on laissait courir. Idem dans le cas où FICIN001 se terminait avant FICIN002 : les enregistrements "excédentaires" du second fichier étaient passés aux oubliettes.
Pour être tout à fait exhaustif et propre, il faut conditionner la fin de traitement à la fin des deux fichiers et produire trois fichiers : un avec les enregistrements dont les clefs sont communes aux deux fichiers (le cas de mon exemple), un avec les enregistrements dont les clefs sont présentes dans FICIN001 et pas dans FICIN002 et un avec les enregistrements dont les clefs sont présentes dans FICIN002 et pas dans FICIN001.
Je laisse à chacun le soin d'adapter le modèle de base.
Il y a deux familles de programmes d'appareillage de fichiers :
1) les relations 1 enregistrement maître : 0 à 1 enregistrement secondaire
2) les relations 1 enregistrement maître : 0 à n enregistrements secondaires
Le premier type est simple : en cas d'égalité sur les critères de rapprochement, on relit les deux fichiers, mais le second oblige à gérer une boucle sur le fichier secondaire.
Il y a deux catégories techniques de problèmes à gérer :
1) les fins de fichiers
2) le rapprochement des fichiers sur une données (ou plusieurs données, par forcément contigües)
Il faut penser aux cas spéciaux :
- fichier vide
- secondaire sans principal correspondant
Et que faire
- planter : simple, radical, voire franchement bestial, et peut bloquer à tort des milliers de jobs toute une nuit
- pas planter : faire un fichier des rejets, et pouvoir les traiter; dans ce cas tous les programmes doivent pouvoir gérer le célèbre cas du fichier vide (qui a toussé dans la salle ?)
Exemple de table de vérité pour le second type de rapprochement, sous forme de tableau Excel.
3) les relations 1 à n enregistrements maîtres : 0 à n enregistrements secondaires.
J'ai eu à faire une fois, pour un rapprochement sur clefs partielles.
Pas si dur, il faut juste stocker les enregistrements maitres, et faire une rupture sur changement de clefs, stocker les enregistrements secondaires, faire là aussi une rupture sur changement de clef, puis mouliner le stock.
Bonjour,
Le cas le plus général est celui où il n'y a pas de fichier maitre : les clefs sont facultatives dans l'un et l'autre fichier
(c'est le type full outer join en SQL)
Voici donc un exemple qui répond à tous les besoins
J'ajoute le job de lancement et le résultat :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36000005 //*------------------------------------------------------------------* 000006 //CC0BBR04 EXEC PGM=CC0BBR04 appareillage full outer join 000007 //CEEDUMP DD SYSOUT=* 000008 //SYSOUT DD SYSOUT=* 000009 //SYSUDUMP DD DUMMY 000010 //XACT01 DD SYSOUT=* 000011 //CC001E DD * 000012 00100 000013 00110 000014 00120 000015 00140 000016 00150 000017 /* 000018 //CC002E DD * 000019 00100 000020 00120 000021 00130 000022 00135 000023 /* 000024 //CC001S DD DSN=PFX.CC0BBR04.CC001S, 000025 // UNIT=SYSDA, 000026 // SPACE=(TRK,(005,010),RLSE), 000027 // DISP=(NEW,CATLG,DELETE), 000028 // DCB=(RECFM=FB,LRECL=050) 000029 // ********************************* Top of Data ****** 00100;00100; 00110; ; 00120;00120; ;00130; ;00135; 00140; ; 00150; ; ******************************** Bottom of Data ****
Citation:
Envoyé par escartefigue
La déclaration et l'utilisation d'un indicateur de type FILE STATUS me semblent une bonne chose, mais l'intérêt diminue si c'est pour continuer en séquence lorsque ce dernier retourne une erreur ...Citation:
Code:
2
3
4OPEN INPUT INP001 IF NOT FS-INP001-OK DISPLAY 'ERR001W PB OUVERTURE INP001, FS = ' FS-INP001 END-IF
Voilà un paragraphe, qui, comme son nom ne l'indique pas, a une fin tout à fait "normale" ...Citation:
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14*------------------------------* 980-FIN-ANORMALE. *------------------------------* DISPLAY '*** FIN ANORMALE DU TRAITEMENT ***' MOVE NB-LEC-INP001 TO NB-ED DISPLAY ' LUS DANS INP001 : ' NB-ED MOVE NB-LEC-INP002 TO NB-ED DISPLAY ' LUS DANS INP002 : ' NB-ED MOVE NB-ECR-OUT001 TO NB-ED DISPLAY ' ECRITS OUT001 : ' NB-ED DISPLAY '!!! CANCEL PROVOQUÉ AU §' LAST-PARAG '!!!' MOVE +0 TO ZNU2 DIVIDE ZNU1 BY ZNU2 GIVING ZABEND .
... ou bien, quelque chose m'a échappé ...
En effet, si on utilise les file-status, c'est pour intercepter et gérer proprement les anomalies sur les fichiers. On bien on n'en met pas et on laisse le RUN-TIME gérer : il le fait très bien, mais en anglais :lol:
Dans ce programme, il manque deux choses essentielles :
- La gestion d'un top pour savoir si l'on va ou non saborder le programme après chaque ordre sur chaque fichier.
- La manière de le saborder : si c'est prévu à la fin du paragraphe 980-FIN-ANORMALE, c'est une manière de faire plutôt crade.
Nous avons en effet :
Puis à la fin :Code:
2
3
4*--- DIVISION PAR ZERO POUR CANCEL UTILISATEUR 02 ZNU1 PIC S9(3) COMP-3 VALUE +0. 02 ZNU2 PIC S9(3) COMP-3 VALUE +0. 02 ZABEND PIC S9(3) COMP-3 VALUE +0.
MOVE +0 TO ZNU2 => Inutile, c'est DEJA initialisé à zéro ! :roll:
DIVIDE ZNU1 BY ZNU2 GIVING ZABEND => Une belle division par zéro pour planter un programme : N'IMPORTE QUOI ! On n'est plus dans les années 1970 ! :ptdr:
Je propose d'appeler une routine de fournie par LANGUAGE ENVIRONMENT :
http://pic.dhe.ibm.com/infocenter/zv...800%2Fcall.htm
CEE3ABD—Terminate Enclave with an Abend. Requests Language Environment to terminate the enclave via an abend. The abend can be issued either with or without cleanup.
CEE3AB2—Add a Reason Code to an Abend. Supports the addition of a reason code to the ABEND. This enhances CEE3ABD to allow for more control of diagnostic information collection.
Sinon, un programme assembleur avec SVC DUMP : les sites sérieux en ont un (et souvent plantage avec / sans DUMP, au choix)
Décidément, je verrai toujours les mêmes :aie: jusqu'à ma retraite...Et là, c'est du très léger...
Bien vu ... je n'avais pas noté la division par zéro ...
Même si on peut trouver le procédé un peu curieux, la paragraphe en cause se termine anormalement ...
En effet, c'est curieux mais surtout c'est normal, car le nom du paragraphe est bien "980-FIN-ANORMALE" : ça veut bien dire ce que ça veut dire...:lol:
Il est appelé dans 601-LECTURE-INP001, 602-LECTURE-INP002 et 603-ECRITURE-OUT001 en cas d'anomalie d'E/S.
Citation:
Envoyé par jpiotrowski
Effectivement, c'est d'une rare logique, en cas d'erreur d'E/S on provoque une division par zéro ... chacun appréciera la pertinence de la démarche ...
Et bien je suis surpris par l'agressivité de certains, et je regrette de ne trouver aucune remarque sur le fond, je propose une cinématique qui répond à tous les cas d'appareillage. C'est le but de ce topic.
Concernant les remarques
-1- erreur sur open :
il est normal de ne pas planter, car certains FS différents de zéro lors de l'open permettent de continuer, si toutefois il s'agit d'un FS qui sera bloquant, la première entrée sortie (read ou write) émettra elle aussi un diagnostic, mais aussi et surtout un plantage. Donc pas de souci
-2- utilisation d'un top :
Surtout pas ! non seulement c'est redondant avec la gestion directe du file status mais c'est surtout risqué car on risque d'oublier de l'alimenter alors que le FS lui est systématiquement alimenté par Z/OS.
-3- alimentation d'une variable à zéro alors qu'elle est en value zéro
Ici le but est de montrer que c'est une action volontaire, on ne divise par par zéro par erreur.
N'oubliez pas que les programmes sont maintenus par plusieurs personnes, souvent en condition de stress (genre incident urgent en prod). Dans ce contexte, tout ce qui rend le code facile à lire est le bienvenu.
-4- division par zéro pour provoquer le plantage :
Bien sur qu'il existe des modules de plantage, merci pour le scoop. Le sujet ici est de proposer une cinématique de rapprochement de 2 fichiers qui réponde à tous les cas, c'est l'objet de mon post.
Oui, l'algorithme sous jacent au programme me semble correct.Citation:
Envoyé par escartefigue
Eh bien, c'est très fâcheux. Une erreur sur l'ouverture d'un fichier, doit interrompre absolument le déroulement de la suite du programme puisque le fichier est considéré comme non ouvert. Si l'utilisation d'un FS est telle que décrite, alors ça limite considérablement l'intérêt de cette utilisation.Citation:
-1- erreur sur open :
il est normal de ne pas planter, car certains FS différents de zéro lors de l'open permettent de continuer, si toutefois il s'agit d'un FS qui sera bloquant, la première entrée sortie (read ou write) émettra elle aussi un diagnostic, mais aussi et surtout un plantage. Donc pas de souci
Alors c'est l'utilisation de la clause VALUE qui devient inutile.Citation:
-3- alimentation d'une variable à zéro alors qu'elle est en value zéro
Ici le but est de montrer que c'est une action volontaire, on ne divise par par zéro par erreur.
N'oubliez pas que les programmes sont maintenus par plusieurs personnes, souvent en condition de stress (genre incident urgent en prod). Dans ce contexte, tout ce qui rend le code facile à lire est le bienvenu.
Justement, pourquoi "polluer" le sujet avec ce genre de comportement, qui, je le maintiens, n'est pas à considérer comme une "bonne pratique" de programmation COBOL. Que va penser un débutant de ce type d'écriture ?Citation:
-4- division par zéro pour provoquer le plantage :
Bien sur qu'il existe des modules de plantage, merci pour le scoop. Le sujet ici est de proposer une cinématique de rapprochement de 2 fichiers qui réponde à tous les cas, c'est l'objet de mon post.
Faux, le FS 97 sur un VSAM par exemple est un OPEN réussi, c'est pourquoi il faut continuer et ne planter qu'au read ou writeCitation:
Envoyé par Luc Orient
Non : 2 précautions valent mieux qu'une, il s'agit ici de bien MONTRER qu'on VEUT avoir zéro dans la variableCitation:
Envoyé par Luc Orient
J'ai pratiqué de longues années les astreintes et interventions de nuit, et je peux assurer que quand on est appelé en plein sommeil à cause d'un plantage, il est nettement préférable de voir de suite quel résultat est attendu.
J'ai écrit ce prog rapidement pour répondre au sujet qui rappelons le est comment faire un appareillage, mais oui tu as raison sur ce pointCitation:
Envoyé par Luc Orient
Attention, pour les fichiers VSAM, la définition des file status est différente : http://publib.boulder.ibm.com/infoce...cs/tperr12.htm
Rappel sur les valeurs possibles : http://publib.boulder.ibm.com/infoce...pf.htm#STATKEY
Pour la valeur "97" : For VSAM only: OPEN statement execution successful: File integrity verified.
Le mieux est alors de définir ainsi le FS :
01 NOM-DE-FICHIER-FILE-STATUS PIC X(02) VALUE SPACE.
88 NOM-DE-FICHIER-STATUS-OK VALUE "00", "97".
88 NOM-DE-FICHIER-EOF VALUE "10".
Néanmoins, une valeur "97" montre un problème sur le fichier : typiquement, il n'a pas été fermé correctement, lire https://sites.google.com/site/indusi...status-codes-1
Donc, soit on utilise les FS complètement et proprement, soit on ne les utilise pas du tout.
J'ai déjà vu un programme qui les définissait pour tous ses fichiers mais n'en faisait aucun usage...
J'ai cité 97 pour exemple, d'autres valeurs acceptables sont possibles, par exemple 41 pour l'open d'un fichier déjà ouvert (faut quand même pas être bien réveillé pour ouvrir 2 fois le même fichier mais bon :D), ou 05 pour un fichier "optionnal", le principe est le même, on ne plante pas sur l'open, on affiche seulement le diagnostic, par contre l'entrée sortie en erreur, elle, doit planter.
Bien sur la sévérité des FS d'I/O dépend du contexte, par exemple une clef non trouvée dans un KSDS est selon le cas une erreur grave ou une situation normale.
J'avais lu trop rapidement ton post, aussi je complète ma réponse précédente :Citation:
Envoyé par jpiotrowski
L'examen d'un code retour quelqu'il soit a pour but de savoir si l'on peut ou non continuer le traitement. Le FS 97 (VSAM uniquement) permet de continuer, c'est pourquoi il ne faut pas s'arrêter au seul file status "00" comme on le voit souvent dans les programmes et comme le suggérait d'ailleurs à tort, l'un des intervenants ci-dessus.
La première entrée sortie (lecture ou écriture selon), permettra de vérifier ce qu'il en est, c'est la raison pour laquelle il faut attendre cette lecture ou écriture pour planter si KO.
Je profite aussi de l'occasion pour préciser le bon usage des "noms conditions" variables 88 :
afin de faciliter la recherche et les études d'impact, il est important de nommer avec un préfixe commun les variables de niveau 88
On rencontre souvent dans les programmes des déclaratives de type :
01 FLAG-TRAITEMENT PIC XX VALUE SPACES.
88 TRAITEMENT-OK VALUE '00'.
88 ERREUR-SOUS-PRO VALUE '15'.
88 PLANTAGE-DB2 VALUE '20'.
etc...
ce qui oblige à rechercher FLAG-TRAITEMENT, puis TRAITEMENT-OK puis ERREUR-SOUS-PRO...
à remplacer avantageusement par (en recherchant sur la racine FLAG-TRT on trouve toutes les lignes de code)
01 FLAG-TRT.
88 FLAG-TRT-OK VALUE '00'.
88 FLAG-TRT-ERR-SSPRO VALUE '15'.
88 FLAG-TRT-ERR-DB2 VALUE '20'.
etc..