Discussion :

[Luc Orient]

Le programme n'est pas plus court.

C'est pas en soi le but. Mais je le trouve plutôt compact et ramassé.

Il utilise l'infâme GOTO, l'ennemi des programmes "structurés".

J'ai simplement "simulé" une structure de haut niveau (la boucle infinie) qui n'existe pas dans le COBOL par une structure de plus bas niveau le (branchement inconditionnel)
En ADA, ça pourrait être du LOOP / END LOOP (je cite de mémoire ...)

Il oublie de fermer les fichiers.

ça c'est vrai et c'est bien un oubli ... je corrige ... le système d'exploitation, sympa, les avait fermé pour moi ... ce qui explique que je n'avais rien vu aux tests ...


Avantages :

= > pas de "fausse" boucle infinie car cette dernière est aussi "infâme", sinon plus, que le GO TO

= > un seul test au lieu de deux

= > et surtout, il est juste, c'est à dire qu'il marche aussi pour 1 000 001 d'enregistrements et davantage ...


Quitte à être "puriste" de la programmation structurée (ce que je ne suis pas on l'aura compris), je signale qu'avec cette dernière on s'interdit de sortir d'une boucle autrement que par un seul chemin (la condition de sortie de la boucle), et c'est d'ailleurs pour ça qu'on utilise une variable de contrôle de fin de fichier ...

La version avec la "pseudo" boucle infinie ne respecte pas cette règle ...

[el_slapper]

"Simplicité et concision dans l'écriture ne s'acquièrent pas du jour au lendemain."

Et ne vont pas toujours de pair avec la lisibilité. J'insiste : xfanx a loupé ta sortie, et moi aussi au début. Sur 3 lecteurs, 2 n'ont pas compris tout de suite(et un pas du tout) la subtilité de ton programme.

Pour el_slapper :
J'ai "ressorti" cette moulinette générique des milliers de fois sans problèmes.
Je n'ai jamais pris d'aspro pour l'adapter, il suffit d'insérer son traitement entre le end-read et le write.
Ce programme n'est pas plus sale qu'un programme truffé de variables inutiles.

"il suffit de", à condition de le savoir. Tu connais ta moulinette par coeur, tu ne te tromperas pas. Le jour ou un débutant arrive(genre la posteuse originale, qui ne doit plus être débutante depuis), tu lui dis "récupère ça", et il/elle va galérer parcequ'il/elle aura loupé plein de détails.

Ma "variable inutile" prend peut-être 5 lignes, mais elle saute à la gueule. Et comme quelqu'un qui lit le programme ne lit jamais la working en même temps, il n'en aura que 2 en plus à lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET W-LECTURE-EN-COURS TO TRUE

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET W-LECTURE-TERMINEE TO TRUE

. Tout ça pour avoir une vraie programmation structurée, et pas un STOP RUN au milieu de nulle part. Qui va sans doute provoquer un warning à la compilation.

Pour Luc Orient :
Le programme n'est pas plus court.
Il utilise l'infâme GOTO, l'ennemi des programmes "structurés".
Il oublie de fermer les fichiers.

ça fait deux ans environ que je n'ai pas codé un GO TO, pour autant, je ne me l'interdit pas. Dans certaines circonstances, ça peut éviter des IF ou des EVALUATE aux conditions particulièrement tordues et à l'imbrication illisible. Dans ce cas, j'écarte tous les cas non passants par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GO TO PARAGRAPHE-FIN

Et ensuite, je traite les cas passants, avec des conditions déjà exotiques et des imbrications déjà complexes. Mais j'évite d'avoir 50 paragraphes(mêmes structurés, si on en fait trop, ça devient illisible aussi), et je garde un code lisible. Bon, ici, je n'ai pas de fonctionnel nécéssitant delà, donc pas un GO TO.

Evidemment, quand on commence à sortir des horreurs du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
01  A1-FG PIC X VALUE SPACE. 
01  B1-FG PIC X VALUE SPACE. 
01  C1-FG PIC X VALUE SPACE. 


    PERFORM A 
    IF A1-FG EQUAL TO "Y" 
        DISPLAY "DO" 
        GO TO G6 
    END-IF 
    . 
G1. 
    PERFORM B 
    IF B1-FG EQUAL TO "Y" 
        DISPLAY "DOO" 
        GO TO G5 
    END-IF 
    . 
G2. 
    PERFORM C 
    IF C1-FG EQUAL TO "Y" 
        DISPLAY "IN DEEP" 
        GO TO G4 
    END-IF 
    . 
G3. 
GO TO C5 
. 
G4. 
GO TO B5 
. 
G5. 
GO TO A5 
. 
G6. 
MOVE +11 TO RETURN-CODE 
STOP RUN 

A SECTION. 
    GO TO G1 
    . 
A5. 
    MOVE "Y" TO A1-FG 
    . 
A9. 
    EXIT. 
B SECTION. 
    GO TO G2 
    . 
B5. 
    MOVE "Y" TO B1-FG 
    . 
B9. 
    EXIT. 
C SECTION. 
    GO TO G3 
    . 
C5. 
    MOVE "Y" TO C1-FG 
    . 
C9. 
    EXIT. 
.

le GO TO devient tout de suite moins séduisant(euphémisme). Mais c'est un outil dans la boite, il faut en connaitre les dangers(massifs, cf mon exemple), mais je trouve dommage de se l'interdire, pour des cas spécifiques ou il est vraiment utile.

[minosubb]

Voici le programme de Luc tel que je l'aurais sorti stucturé
J'accorde que dans ce cas, le PERFORM TRT THRU TRT-F est abusif, mais si demain j'ai besoin de faire d'autre traitement avec l'enregistrement que j'ai lu, il me suffit juste de le mettre dans le paragraphe TRT et le tour est joué

J'ai mes differents paragraphes principaux :

INIT : Initialisation du programme avec l'ouverture des fichier et initialisation des divers compteurs.
TRT : traitement général du programme.
FIN : Fin général du programme avec fermeture des fichiers et edition du compte rendu d'execution.

Le paragraphe de lecture ne fais rien d'autre que lire
et pour l'ecriture, meme chose, un paragraphe unique.

Et si je met autant de paragraphe qu'il y a d'action unitaire a faire
C'est que je considère chaque action comme un objet.
Comme la pièce d'un puzzle dont le programme est l'image finale.

C'est sur que c'est plus long en tant que nombre de ligne, mais une fois que la gestion des fichiers est ecrite et testée, je n'ai plus du tout a m'en occuper, et je n'ai plus qu'à me concentrer sur le paragraphe TRT qui contient ce pourquoi le programme existe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
IDENTIFICATION DIVISION.
PROGRAM-ID. xxxxxxxx.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.

FILE-CONTROL.
    SELECT F1 ASSIGN F1.
    SELECT F2 ASSIGN F2.

DATA DIVISION.

FILE SECTION.

FD  F1 LABEL RECORD STANDARD RECORDING F.
 01 F1E          PIC  X(7).

FD  F2 LABEL RECORD STANDARD RECORDING F BLOCK 0.
01 F2E          PIC  X(7).

WORKING-STORAGE SECTION.
01 IO-FIC       PIC  X(7).

* (EOF = END OF FILE)
01 FLAG-LECTURE PIC  X(1)  VALUE 'N'.
   88 EOF-F1     VALUE 'O'.
   88 PAS-EOF-F1 VALUE 'N'.

01 N            PIC S9(15) COMP-3.
01 N-EDITE      PIC -Z(14)9.

PROCEDURE DIVISION.

    PERFORM INIT THRU INIT-F.

    PERFORM LECT-F1 THRU LECT-F1-F.

    PERFORM WITH TEST BEFORE
      UNTIL EOF-F1
       PERFORM TRT  THRU TRT-F
       PERFORM LECT-F1 THRU LECT-F1-F
    END-PERFORM.

    PERFORM FIN THRU FIN-F.
    
    GOBACK.


INIT.

    PERFORM OPEN-FICHIERS THRU OPEN-FICHIERS-F.
    MOVE ZERO TO N.

INIT-F.
    EXIT.


FIN.

    MOVE N TO N-EDITE.
    DISPLAY 'NB LECTURE : ' N-EDITE.

    PERFORM CLOSE-FICHIERS THRU CLOSE-FICHIERS-F.

FIN-F.
    EXIT.


TRT.

    PERFORM ECRIT-F2 THRU ECRIT-F2-F.

TRT-F.
    EXIT.


OPEN-FICHIERS.

    PERFORM OPEN-F1 THRU OPEN-F1-F.
    PERFORM OPEN-F2 THRU OPEN-F2-F.

OPEN-FICHIERS-F.
    EXIT.


OPEN-F1.

    OPEN INPUT  F1.
    SET PAS-EOF-F1 to TRUE.

OPEN-F1-F.
    EXIT.


OPEN-F2.

    OPEN OUNPUT F2.

OPEN-F2-F.
    EXIT.

CLOSE-FICHIERS.

    PERFORM CLOSE-F1 THRU CLOSE-F1-F.
    PERFORM CLOSE-F2 THRU CLOSE-F2-F.

CLOSE-FICHIERS-F.
    EXIT.


CLOSE-F1.

    CLOSE F1.

CLOSE-F1-F.
    EXIT.


CLOSE-F2.

    CLOSE F2.

CLOSE-F2-F.
    EXIT.


LECT-F1.

    READ F1 INTO IO-FIC
    NOT AT END
       ADD 1 TO N
    AT END
       SET EOF-F1 TO TRUE
       GO TO LECT-F
    END-READ.

LECT-F1-F.
    EXIT.


ECRIT-F2.

    WRITE F2E FROM IO-FIC.

ECRIT-F2-F.
    EXIT.

[JIVARO]

"Le pragmatisme en programmation n'est pas une tare, mais une qualité"

Luc ORIENT

= > pas de "fausse" boucle infinie car cette dernière est aussi "infâme", sinon plus, que le GO TO

Pas d'exagération, l'expression 1 = 2 n'est pas infâme, ce n'est qu'une pauvre égalité, jamais vérifiée,
permettant de pallier l'absence de la notion de boucle infinie en COBOL.

perform until 1 = 2 est donc une vraie boucle infinie parfaitement fiable ! (Même si ça donne des boutons).

= > et surtout, il est juste, c'est à dire qu'il marche aussi pour 1 000 001 d'enregistrements et davantage ...

On a raté une étape, voir mon post #17 du 19, 10:16

Rien n'empêche en cas de forte volumétrie de le remplacer par :

... perform 100000000000000000 times (pour dormir tranquille)
ou perform 999999999999999999 times (le maximum pour les puristes)
ou perform until 1 = 2 (pour les experts !)

Quitte à être "puriste" de la programmation structurée (ce que je ne suis pas on l'aura compris), je signale qu'avec cette dernière on s'interdit de sortir d'une boucle autrement que par un seul chemin (la condition de sortie de la boucle), et c'est d'ailleurs pour ça qu'on utilise une variable de contrôle de fin de fichier ...

La version avec la "pseudo" boucle infinie ne respecte pas cette règle ...

On ne sort pas de la boucle, (il eût fallu un exit perform), on sort du programme !

el_slapper

"il suffit de", à condition de le savoir. Tu connais ta moulinette par coeur, tu ne te tromperas pas. Le jour ou un débutant arrive(genre la posteuse originale, qui ne doit plus être débutante depuis), tu lui dis "récupère ça", et il/elle va galérer parcequ'il/elle aura loupé plein de détails.

Il suffit de rajouter quelques commentaires, et le tour est joué !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
26
27
28
29
30
31
  ID DIVISION.
  PROGRAM-ID. recopie.
 *>>                   Moulinette minimaliste générique : Entrée-->Traitement-->Sortie   
  INPUT-OUTPUT SECTION.
  FILE-CONTROL.
       select  f1 assign "D:\FICHIER-ENTREE.dat".  
       select  f2 assign "D:\FICHIER-SORTIE.dat". 
  DATA DIVISION.
  FILE SECTION.

  FD  f1 LABEL RECORD STANDARD.   01  f1e  pic x(07).
  FD  f2 LABEL RECORD STANDARD.   01  f2e  pic x(07).

  PROCEDURE DIVISION.

      open input f1 output f2.
      
 *>>  Boucle infinie grâce à la condition 1 = 2 jamais vérifiée ! 
      perform  until 1 = 2

 *>>                 Le programme se termine en fin de fichier ...          
          read  f1   end   close f1 f2 stop run
          end-read
          
 *>>      Insérez ci-après votre traitement...
          display f1e 
 *>>      Ne pas toucher à ce qui suit (jusqu'au end-perform inclus)

          write  f2e  from  f1e

      end-perform.

La partie générique de la PROCEDURE DIVISION est torchée en 6 lignes.

Tout ça pour avoir une vraie programmation structurée, et pas un STOP RUN au milieu de nulle part. Qui va sans doute provoquer un warning à la compilation.

Le stop run n'est pas au milieu de nulle-part, il est logiquement dans le premier bloc READ .. END-READ de la boucle et met fin au programme
après avoir traité tout le fichier.

ça fait deux ans environ que je n'ai pas codé un GO TO, pour autant, je ne me l'interdit pas.

Je ne suis pas faché avec les go to, j'en utilise aussi dans les cas difficiles:
- Sortie dune série de tests alambiqués
- Sortie d'une imbriquation de boucles (notamment de la plus profonde).

minosub
NO COMMENT


MAJUSCULES/minuscules
Les minuscule sont moins agressives et plus aérées que les majuscules et améliorent ainsi la lisibilité.
La grande majorité des langages modernes utisisent quasiment exclusivement les minuscules.
En outre, le MIX majuscules/minuscules améliore considérablement la compréhension :
ShowException est plus clair que SHOWEXCEPTION
InsertNewLineAfter est plus clair que INSERTNEWLINEAFTER ou insertnewlineafter
DateDuJour est plus clair que DATEDUJOUR ...... etc...

[el_slapper]

"Le pragmatisme en programmation n'est pas une tare, mais une qualité"
On ne sort pas de la boucle, (il eût fallu un exit perform), on sort du programme !

Certes, mais je n'appelle pas ça du pragmatisime, juste de la fainéantise.

Il suffit de rajouter quelques commentaires, et le tour est joué !
La partie générique de la PROCEDURE DIVISION est torchée en 6 lignes.

Et? c'est un concours?

Pour les commentaires, je suis très "sexycoder" : le code soit pouvoir être compris sans les commentaires. Tout simplement parce qu'avec les évols, les commentaires peuvent devenir faux. Si le code derrièrre est incompréhensible..... Je mets quand même des commentaires, mais jamais sur le "comment", toujours sur le "pourquoi". Le "comment" doit se déduire du code, sinon le code n'est pas bon.

Le stop run n'est pas au milieu de nulle-part, il est logiquement dans le premier bloc READ .. END-READ de la boucle et met fin au programme
après avoir traité tout le fichier.

Logiquement? Argh. La fin du programme, c'est quand on a tout fait. Pas au milieu d'une boucle. Pour moi, c'est vraiment au milieu de nulle part. Le jour ou on veut ajouter un compte-rendu de sortie, on le met ou? Au milieu du READ? Je me tire une balle! Non, un PERFORM TRAITEMENT suivi d'un STOP RUN est le strict minimum de structuration. Quitte à mettre un AT END GO TO FIN-TRAITEMENT.

Je ne suis pas faché avec les go to, j'en utilise aussi dans les cas difficiles:
- Sortie dune série de tests alambiqués
- Sortie d'une imbriquation de boucles (notamment de la plus profonde).

là on est d'accord.

MAJUSCULES/minuscules
Les minuscule sont moins agressives et plus aérées que les majuscules et améliorent ainsi la lisibilité.
La grande majorité des langages modernes utisisent quasiment exclusivement les minuscules.
En outre, le MIX majuscules/minuscules améliore considérablement la compréhension :
ShowException est plus clair que SHOWEXCEPTION
InsertNewLineAfter est plus clair que INSERTNEWLINEAFTER ou insertnewlineafter
DateDuJour est plus clair que DATEDUJOUR ...... etc...

ça, c'est une question d'habitude, simplement. FlagFinFichier n'est ni plus ni moins lisible que FLAG-FIN-FICHIER. Et si en VB6 j'écris comme toi, en COBOL je me plie à la tradition, qui est justifiée par le fait que certains compilateurs ne passent pas en minuscules.

[tpii44119]

Si je peux me permettre la pauvre Fatima à vous lire doit être un peu perdue.

Elle avait écrit un programme somme toute assez bien structuré, lisible. Son problème était l'écriture en double en fin de traitement. Et plutôt que de l'orienter vers la solution (qui est de conditionner l'écriture en fonction de la lecture), gràce à JIVARO elle se retrouve avec un programme illisible et qui boucle !! Ce qui est totalement inadmissible en environnement de production.

JIVARO il suffit que le fichier soit vérolé pour que le programme boucle ... la condition AT END n'est jamais rencontrée. Il est facile de le provoquer dans une chaine batch en utilisant auparavant le programme de Luc Orient qui ne ferme pas le fichier !

Après on peut la conseiller sur l'utilisation ou pas du PERFORM ... THRU selon qu'elle utilise SECTION ou pas pour ses paragraphes. Le GOTO est à proscrire même s'il peut être utilisé dans les cas extrèmes (correction urgente ne permettant pas la refonte du code sans GOTO). Il est même interdit dans certains AGL (engendre des boucles infinies !).

Fatima avait fait un poste sur la manipulation des fichiers. Il aurait sans doute été préférable de l'orienter sur l'utilisation des zones en FD ou en Working, des problèmes sur les fichiers en FIXE ou VARIABLE ...

[Luc Orient]

Si je peux me permettre la pauvre Fatima à vous lire doit être un peu perdue.

Le sujet a évolué vers une problématique un peu différente de sa question d'origine puisqu'il s'agit de débattre sur la façon le plus concise et rapide de coder une copie de fichier en COBOL sans trop se soucier de règles de programmation parfois bien rigides. JIVARO a proposé une solution et j'en ai proposé une autre.

Et plutôt que de l'orienter vers la solution (qui est de conditionner l'écriture en fonction de la lecture), gràce à JIVARO elle se retrouve avec un programme illisible et qui boucle !! Ce qui est totalement inadmissible en environnement de production.

Non le programme de JIVARO ne boucle pas ... on peut critiquer sa façon de simuler une boucle infinie en COBOL mais on ne peut pas dire que son programme boucle.

JIVARO il suffit que le fichier soit vérolé pour que le programme boucle ... la condition AT END n'est jamais rencontrée. Il est facile de le provoquer dans une chaine batch en utilisant auparavant le programme de Luc Orient qui ne ferme pas le fichier !

ça c'est une vue de l'esprit ... dans un environnement de production, justement, et avec la qualité des systèmes de stockages modernes (RAID quelquechose ... ) les erreurs d'entrée-sortie sont devenus rarissimes et au pire le job plante à l'allocation du fichier et pas à la fin ... Et puis si on suppose qu'une condition AT END ne marche pas, ça va invalider n'importe quel programme qu'il soit structuré ou pas.
Pour mon programme qui avait "oublié" de fermer les fichiers (corrigé depuis) le système d'exploitation (enfin au moins celui que j'utilise ...) répare de lui-même l'erreur.

... Le GOTO est à proscrire même s'il peut être utilisé dans les cas extrèmes (correction urgente ne permettant pas la refonte du code sans GOTO). Il est même interdit dans certains AGL (engendre des boucles infinies !).

Encore une fois, la programmation structurée n'est pas l'absence de GOTO, c'est juste que comme on peut faire n'importe quoi avec, on interdit au programmeur débutant de l'utiliser.
Quant aux AGL autour du COBOL, la plupart sont désormais au cimetière ou pas très loin ...

[tpii44119]

Si c'était une vue de l'esprit les analystes d'exploitation ne mettraient pas en place des sauvegardes temporaires de tous les fichiers dans les chaines pour pouvoir redémarrer les jobs au step.

Justement pour les débutants (ce que semblait être Fatima avec les fichiers) il est préférable de leur donner de bons réflexes. Le premier de ne pas leur proposer un programme avec une boucle potentielle (surtout quand on n'indique pas le b-a-ba qui est de tester le file-status après chaque opération sur un fichier). Elle déclarait un fichier fixe dans son 1er programme et variable dans le 2eme. Si elle n'a pas modifié la structure de son fichier physique entre les 2, elle obtiendra une erreur à l'ouverture (invalid DCB), pas de test de file-status, boucle infinie sur la copie du fichier !!

La programmation structurée (autrement appelée Algorihmique il y a 25 ans quand j'ai fait mon DUT) ne permetait pas les GOTO puisque la mise en application se faisait avec PASCAL qui ne connait pas cette instruction ! Au passage à COBOL, cette instruction était retirée du compilateur. Le programme de JIVARO oublie une des trois notions de l'algorithmique qui est la "Terminaison". Citation d'un professeur à l'époque : "un algorithme qui conduit à un GOTO est un analyste qui a choisi de s'engager dans une impasse, il lui faudra faire demi tour".

En environnement professionnel, un programme est générallement crée pour résoudre une problématique et pas se faire plaisir en programmation. Il doit répondre à des normes (éprouvées) et être maintenable. C'est pour cela que des AGL existent et qu'ils sont loin d'avoir disparus (des millions de lignes de code sont encore générées de par le monde).

[BernardBZH]

Bonjour,

Personnellement, j'ai tendance (depuis 20 ans) à coder comme minosubb, les "THRU" en moins, sans "TEST BEFORE" (puisque c'est pris par défaut) et avec des noms de paragraphes le plus parlant possible.

Je ne veux pas jeter la pierre à Jivaro et autres adeptes de rédaction plus "ramassée", mais quand je code j'essaie de me dire que je ne suis pas éternel (surtout en SSII) et que ceux qui viendront après apprécieront peut-être d'avoir un programme dont la structure saute rapidement aux yeux.

Et tant que j'y pense, moi non plus je n'aime pas les GO TO

[EDELH]

J'ai reécrit le programme; il marche !

Ma façon de programmer peut ne pas plaire à tout le monde; mais c'est comme cela que je programme depuis 20 ans !

Si tu as des questions, tu peux me les poser. J'y répondrai, du moins si cela ne demande pas trop de développements.

Bonne continuation.

PS. Le répertoire "d:\acs40" est simplement celui d'une de mes applications !
Attention: du au fait que la taille du caractère est en 'proportionnel', il se peut que le (sacro-sain !?) respect des colonnes du Cobol ne soit pas correct.

1234567890123456789012345678901234567890123456789012345678901234

id division.
program-id. exemple.
author. fatima-ezzahra.
date-written. 22/06/2010.
date-compiled. 22/06/2010.
*====================================================
* Ce programme Sert à Recopier les enregistrements
* de FICHIER-ENTREE à FICHIER-SORTIE
*====================================================
environment division.
*--------------------------------------------------------
configuration section.
*--------------------------------------------------------
input-output section.
file-control.
select fichier-entree assign "d:\ACS40\FICH-E.TXT"
organization line sequential
file status fe-statut.

select fichier-sortie assign "d:\ACS40\FICH-S.DAT"
organization binary sequential
file status fs-statut.

*=====================================================
data division.
*--------------------------------------------------------
file section.
fd fichier-entree.

01 fe-record pic x(7).

fd fichier-sortie.

01 fs-record.
02 fs-data pic x(7).
*>>> Pas vraiment nécessaire !
02 fs-crlf pic xx.

*--------------------------------------------------------
working-storage section.
01 crlf pic xx value x"0D0A".

01 fe-statut pic xx.
88 fe-ok value "00".
88 fe-eof value "10".

01 fs-statut pic xx.
88 fs-ok value "00".

*====================================================
procedure division.
*--------------------------------------------------------
declaratives.
000-declaratives section 1.
use after standard error procedure fichier-entree
fichier-sortie.
0009. exit.
end declaratives.

*000=================================================
000-main section.
000-start.
perform 010-ouverture-fichiers.

perform 020-copie until fe-eof.

perform 030-fermeture-fichiers.
0009-eoj.
exit program.

*000=================================================
010-ouverture-fichiers.
perform 011-ouverture-fe-entree.

perform 012-ouverture-fs-sortie.

perform 015-lecture-premier-record.

*011-----------------------------------------------------
011-ouverture-fe-entree.
open input fichier-entree.

*012-----------------------------------------------------
012-ouverture-fs-sortie.
open output fichier-sortie.

*015-----------------------------------------------------
015-lecture-premier-record.
read fichier-entree.

*020=================================================
020-copie.
* display e-fichier

move fe-record to fs-data.
move crlf to fs-crlf.

write fs-record.

*>>> Lecture record suivant
read fichier-entree.

*030=================================================
030-fermeture-fichiers.
close fichier-sortie
fichier-entree.

*--------------------------------------------------------
end program exemple.
*====================================================