Téléchargé 7 fois
Vote des utilisateurs
1 
0
Détails
Licence : BSD
Mise en ligne le 19 mars 2014
Plate-formes :
Linux, Windows
Langue : Français
Référencé dans
Navigation
COBOL - Flat to Indexed : transformation d'un fichier séquentiel en fichier séquentiel indexé
COBOL - Flat to Indexed : transformation d'un fichier séquentiel en fichier séquentiel indexé
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.
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.
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.
Envoyé par escartefigue
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
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
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 .
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 ?
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 ?
Envoyé par Luc Orient
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.
Donc, ce comportement est parfaitement décrit et connu et il suffit juste d'en tenir compte lors de la programmation.
Envoyé par escartefigue
... Dans ce contexte et pour toutes les multiples raisons que j'ai déjà indiquées plus haut le read into s'impose
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:
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:
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.
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 |
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). |
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.
700 à 800 % de plus en coût CPU, je crois qu'il y a de quoi réfléchir ...
CQFD.
Envoyé par escartefigue
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
...
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
...
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.
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.
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.
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.
- 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.
Envoyé par escartefigue
...
- 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 !
- 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 !
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 ...
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
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.