COBOL - Flat to Indexed : transformation d'un fichier séquentiel en fichier séquentiel indexé

Présentation
Transformation d'un fichier séquentiel en fichier séquentiel indexé dédié au compilateur COBOL associé.

Deux sources sont mises à disposition :
- L'une avec seulement la transformation "normal" vers "indexé"
- L'autre avec un tri interne COBOL

Ce code est très utile sous Windows ou Linux pour obtenir des formats de fichiers nativement disponibles sur z/OS ou System i.
Nos ressources disponibles
Pour que l'indexation soit réellement efficace il est conseillé de trier, mais sur certains systèmes des programmes plus optimisés sont disponibles (DFSORT sur z/OS par exemple).
L'indexation d'un fichier peut "aussi" être naturelle via le format d'enregistrement : toujours sur z/OS, des VSAM de type KSDS (Key Sequenced DataSet) permettent d'indexer à l'écriture et COBOL sera en mesure d'utiliser ces index.

L'intérêt de ce programme se situe surtout dans le fait que les systèmes d'exploitations moins spécialisés ne proposent pas ces options, et qu'il devient donc nécessaire de laisser COBOL (et surtout son compilateur) générer un fichier indexé avec le format adapté à celui-ci.

Le fichier utilisé dans le code est fourni en exemple.

Attention aux niveaux des variables en WORKING-STORAGE SECTION !
Mes 2 compilateurs (OpenCOBOL 1.1 et TinyCOBOL) obligent à utiliser des niveaux 01, 66 ou 77 pour les structures ou variables simples.
Si vous aviez l'habitude d'utiliser d'autres niveaux avec d'autres compilateurs : n'hésitez pas à modifier mon code.

Merci à Hédhili Jaïdane, el_slapper, Pico----- et Luc Orient pour leurs conseils.
Téléchargement
Compatibilité
Linux Windows
1  0 
Téléchargé 30 fois Voir les 17 commentaires
Détails
Catégories : Codes sources Cobol
Voir tous les téléchargements de l'auteur
Licence : BSD
Date de mise en ligne : 19 mars 2014




Avatar de xfanx xfanx - Membre averti https://www.developpez.com
le 02/07/2015 à 14:53
Citation Envoyé par escartefigue Voir le message
Parfaitement décrit, certes
Parfaitement connu certainement pas

Il ne faut pas oublier la réalité du terrain, les développeurs sont de moins en moins formés, de plus en plus mis sous pression dans des plates formes de développement off-shore et ce pas uniquement dans le monde mainframe

Du coup, tout ce qui peut sécuriser la maintenance et faciliter les interventions de nuits ou le WE en urgence est bon à prendre

Dans ce contexte et pour toutes les multiples raisons que j'ai déjà indiquées plus haut le read into s'impose
entierement d'accord, pour avoir eu comme principale occupation le support mainframe pendant plusieur années, les erreurs du à la nom utilisation du READ INTO et WRITE FROM sont très fréquentes.
d'ailleurs c'est une norme aujourd'hui dnas les CookBook internes de ma boite. bon cela dit, Cookbook écrit par moi même, ça explique
En plus du theme fichier variables évoqué ici, j'ai frequement rencontré des abends aléatoires suite à références dans le programme de champs décrit dnas une structures de la FD après un CLOSE du fichier. abend Alléatoire de plus selon l'état des buffers d'I/O.
je sais bien qu'il y a des programmeurs "normaux" ou en tout cas avec suffisament d'expériences et de connaissances ne serait ce que des systèmes d'adressages pour comprendre et éviter de coder n'importe quoi, c'est malheureusement de moins en moins le cas .
Avatar de Metalman Metalman - Membre expert https://www.developpez.com
le 14/02/2014 à 12:02
Ce sujet a été généré automatiquement...
Il est lié aux nouvelles sections de codes sources mis à disposition :
http://www.developpez.com/telecharger/Codes-Sources
Il est maintenant possible d'uploader du COBOL et du JCL ! (Le REXX viendra peut être plus tard)
Les topics associés seront automatiquement générés dans les forums alloués.

Bonjour,

Je vous propose un nouvel élément à utiliser : Flat to Indexed : transformation d'un fichier séquentiel en fichier séquentiel indexé

Deux sources sont mises à disposition :

- L'une avec seulement la transformation "normal" vers "indexé"

- L'autre avec un tri interne COBOL

Pour que l'indexation soit réellement efficace il est conseillé de trier, mais sur certains systèmes des programmes plus optimisés sont disponibles (DFSORT sur z/OS par exemple).

L'indexation d'un fichier peut "aussi" être naturelle via le format d'enregistrement : toujours sur z/OS, des VSAM de type KSDS (Key Sequenced DataSet) permettent d'indexer à l'écriture et COBOL sera en mesure d'utiliser ces index.

L'intérêt de ce programme se situe surtout dans le fait que les systèmes d'exploitations moins spécialisés ne proposent pas ces options, et qu'il devient donc nécessaire de laisser COBOL (et surtout son compilateur) générer un fichier indexé avec le format adapté à celui-ci.

Attention aux niveaux des variables en WORKING-STORAGE SECTION !

Mes 2 compilateurs (OpenCOBOL 1.1 et TinyCOBOL) obligent à utiliser des niveaux 01, 66 ou 77 pour les structures ou variables simples.

Si vous aviez l'habitude d'utiliser d'autres niveaux avec d'autres compilateurs : n'hésitez pas à modifier mon code.

Merci à Hédhili Jaïdane, el_slapper, Pico----- et Luc Orient pour leurs conseils.

Qu'en pensez-vous ?
Avatar de Darkzinus Darkzinus - Expert éminent https://www.developpez.com
le 02/07/2015 à 10:22
Citation Envoyé par Luc Orient Voir le message
Pour régler définitivement le point concernant la lecture d'un fichier variable par un READ simple (extrait du COBOL LANGUAGE REFERENCE IBM) :

Donc, ce comportement est parfaitement décrit et connu et il suffit juste d'en tenir compte lors de la programmation.
Franchement c'est quand même très souvent mal géré et non connu ... J'ai découvert des rustines datant de 10 ans pour by passer ça salement alors que le VBA était mal codé.
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 05/07/2015 à 14:37
Citation Envoyé par escartefigue Voir le message
... Dans ce contexte et pour toutes les multiples raisons que j'ai déjà indiquées plus haut le read into s'impose
Ben non ... Il y a au moins un cas où le READ INTO est déconseillé, et ce n'est pas moi qui le dit, mais M. IBM lui même ...

COBOL Performance Issue with READ INTO of Variable length record File

Technote (troubleshooting)

Problem(Abstract)

The performance numbers will vary depending on the record size, variation and distribution.

There may be slow performance using READ...INTO coding.

The situation evaluated involved a Variable Blocked QSAM file where there was a large variation in the size of the records. RECFM=VB.
In the case described, the variable file contained records varying from around 250 bytes to 30,000 bytes with the majority around 250 bytes.

Symptom

The test programs run did only a READ and no processing vs a READ .... INTO a 30,000 byte work area.

The READ .... INTO version took 800%-1000% more CPU time with similar increases in clock time.

Here is a sample of the READ ... INTO code involved:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
FD  INPUT-FILE
    BLOCK CONTAINS 0 RECORDS 
    RECORD IS VARYING IN SIZE FROM 100 to 30000.
01  INPUT-REC    PIC X(30000).
01  INPUT-REC100 PIC X(100).
01  INPUT-REC250 PIC X(250).
    (etc. or a PIC X OCCURS.... )
WORKING-STORAGE SECTION.
01  WS-AREA  PIC X(30000). 
             .......
PROCEDURE DIVISION.
             .... 
    READ INPUT-FILE INFO WS-AREA AT END
Cause

If a 250 byte record is read, the length is captured and the READ....INTO moves 250 bytes from the file buffer to the work area. Then the remainder of the work area is padded with blanks, consuming CPU cycles.

Resolving the problem

Modify as follows:

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
FD  INPUT-FILE
    BLOCK CONTAINS 0 RECORDS 
    RECORD IS VARYING IN SIZE FROM 100 to 30000 
    DEPENDING ON REC-LEN.
01  INPUT-REC    PIC X(30000).
01  INPUT-REC100 PIC X(100).
01  INPUT-REC250 PIC X(250).
    (etc. or a PIC X OCCURS.... )
WORKING-STORAGE SECTION.
01  WS-AREA  PIC X(30000). 
01  REC-LEN  PIC 9(5) COMP.
             .......
PROCEDURE DIVISION.
             .... 
    READ INPUT-FILE AT END .......
    MOVE INPUT-REC(1:REC-LEN) TO
           WS-AREA (1:REC-LEN).
REC-LEN will be set to the length of each record when it is read.
By using the length of the data read, then coding with the Reference Modification (1:REC-LEN) for both the MOVE from and to fields will restrict the number of bytes moved from the buffer to the correct record size and prevent the padding of the entire unused part of the work area.
The READ....INTO took about 700-800% more CPU cycles than this method in the test environment..

However, if the variable input file contains records that are all similar in size to the work area, then READ INTO would not experience the performance situation described above.
La référence citée est disponible ici

700 à 800 % de plus en coût CPU, je crois qu'il y a de quoi réfléchir ...

CQFD.
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 31/07/2015 à 21:00
Citation Envoyé par escartefigue Voir le message
bonjour,

Les avantages sont multiples :
- en cas d'utilisation d'un debugger, les données lues sont accessibles, alors que la FD ne l'est pas

...
Une collègue a fait l'essai pour moi.

Avec DEBUG TOOL d'IBM, l'outil de DEBUGGING utilisé sur notre site de développement, les données en FD (donc lues par un READ simple) sont parfaitement accessibles.
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 10/08/2015 à 22:10
Je viens de faire l'essai moi même. Avec DEBUG TOOL d'IBM, j'obtiens bien le contenu des enregistrements lus par READ simple.

Donc à part consommer du CPU pour rien, le READ INTO ne présente qu'un intérêt marginal, voir aucun intérêt du tout ...

CQFD.
Avatar de escartefigue escartefigue - Expert éminent sénior https://www.developpez.com
le 23/06/2015 à 16:52
Je découvre tardivement ce post, si ce petit programme est sans doute utile pour les développeurs linux ou Windows, il est dommage que le source ne respectent pas les préconisations suivantes :

- Ne pas décrire les fichiers en FD mais seulement un filler + la clef qui est obligatoire si fichier indexé.
Cette habitude, une fois prise, évite que lors de maintenances, le développeur utilise ses zones dédiées à l'OS et qui sont source d'abend
en cas d'utilisation avant ou après ouverture des fichiers. Sans compter que le contenu des zones FD est inaccessible des outils de debugging,
et qu'il n'est pas formaté en cas de fichier de format variable

- Faire un read into c'est très bien, mais la zone réceptrice doit être en working storage
je doute qu'en l'état, le compilateur accepte, mais si ca passait à la compil, on perd tout intérêt d'un read into !

- Utiliser des file status, c'est très bien, mais alors pourquoi gérer une fin de fichier manuellement par un "AT END" autant aller jusqu'au bout de la démarche
et utiliser la valeur FS="10" qui est alimentée automatiquement par l'OS alors qu'on peut oublier le move manuel lors du AT END

- Initialiser la zone réceptrice d'un read into avant lecture ne sert à rien, le read into s'en chargera

- c'est dommage, en cas d'erreur grave, de faire un stop run plutôt qu'un cancel, de même, si clef en double, il est judicieux d'afficher non seulement
la valeur de cette clef, comme c'est le cas, mais aussi le rang de l'enregistrement, ce qui évite de chercher dans un fichier parfois très volumineux.

- tant qu'à faire de donner des noms parlants aux paragraphes, ce qui est très bien, il faut que ça corresponde au contenu, or, le paragraphe 200-OPEN-RATE
fait non seulement les open, mais aussi l'appel à la procédure principale, puis les close...

- il ne faut pas considérer tout statut différent de zéro comme une erreur lors d'un open : les valeur "97" (VSAM) et "41" sont acceptables à l'open
le plus simple est d'afficher un message + le FS si différent de zéro lors de l'open sans planter, puis de planter lors du read ou write si KO
(en affichant a nouveau un message et le file status)

- des balises de début et fin de working sont toujours les bienvenues en cas de plantage (01 filler pic x(nn) value 'deb working monprog"

- enfin, mais la je chipote, c'est dommage de déclarer des variables locales d'un ou deux octets sur des lvl 01 qui s'alignent sur 16, on charge inutilement la WSS
autant regrouper sous un 01 filler.

Je me doute que ce petit programme a été écrit rapidement pour rendre service, mes remarques ne sont donc pas une attaque en règle envers celui qui fait l'effort de proposer cet outil, mais plutôt des conseils à destination des développeurs peu expérimentés.
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 28/06/2015 à 17:25
Citation Envoyé par escartefigue Voir le message
...
- Ne pas décrire les fichiers en FD mais seulement un filler + la clef qui est obligatoire si fichier indexé.
Cette habitude, une fois prise, évite que lors de maintenances, le développeur utilise ses zones dédiées à l'OS et qui sont source d'abend
en cas d'utilisation avant ou après ouverture des fichiers. Sans compter que le contenu des zones FD est inaccessible des outils de debugging,
et qu'il n'est pas formaté en cas de fichier de format variable

- Faire un read into c'est très bien, mais la zone réceptrice doit être en working storage
je doute qu'en l'état, le compilateur accepte, mais si ca passait à la compil, on perd tout intérêt d'un read into !
En rien convaincu par cette affirmation ( la première surtout ) qui gagnerait a être étayé par quelques références techniques ...

Je ne vois pas en quoi ça serait mieux de faire des READ INTO plutôt que des READ simples ... Mais je ne demande qu'à changer d'avis ...
Avatar de escartefigue escartefigue - Expert éminent sénior https://www.developpez.com
le 29/06/2015 à 8:56
bonjour,

Les avantages sont multiples :
- en cas d'utilisation d'un debugger, les données lues sont accessibles, alors que la FD ne l'est pas
- si l'on utilise des fichiers de format variable, les données sont automatiquement formatées correctement
- la zone WSS est accessible quelque soit la phase d'exécution du programme, alors que si l'on utilise une zone FD avant ou après open, le cancel est garanti
- si l'on fait un read simple, puis un move, on réinvente ce que fait très bien COBOL grace au read into, on ajoute inutilement une instruction, mais surtout il faut s'assurer que le move est immédiat, pour etre sur de rendre dispo les données lues aux outils de debugging
- en cas de dump, c'est plus facile de retrouver ses petits

Faire un read sans utiliser into est donc une erreur

Il en va de même pour le write : write from est recommandé, pour les mêmes raisons
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web