Discussion :

[JTyvelines]

Soit les fichiers EFIC en entree et SFIC en sortie.

FILE SECTION

FD EFIC
01 ENR-EFIC
05 echamps PIC X(132)

FD SFIC
01 ENR-SFIC
05 schamps PIC X(132)

WORKING-STORAGE SECTION.
01 W-Variable
05 wchamps PIC X(132).

Ma question est la suivante : peut-on faire directement WRITE ENR-SFIC FROM ENR-EFIC ? Ou fautil passer par la variable de travail W-variable :

MOVE echamps TO wchamps
WRITE ENR-EFIC FROM W-VARIABLE.

[Hédhili Jaïdane]

Bonjour.

Oui, on peut faire un WRITE FROM directement voire même un READ INTO sans passer par un MOVE vers une zone de travail intermédiaire.

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
FILE SECTION

FD  EFIC
    01 ENR-EFIC
        05 echamps PIC X(132)

FD  SFIC
    01 ENR-SFIC
        05 schamps PIC X(132)

WORKING-STORAGE SECTION.
     01 W-Variable
          05 wchamps PIC X(132).
* .../...

* On peut faire : 
READ EFIC ...
WRITE ENR-SFIC  FROM ENR-EFIC ...

* ou 
READ EFIC INTO ENR-SFIC ....
WRITE ENR-SFIC ...

* ou 
READ EFIC ....
MOVE ENR-EFIC TO ENR-SFIC
WRITE ENR-SFIC ...
* toutes ces formes sont équivalentes.

Un petit coup d'oeil sur la documention est grandement nécessaire. Et rien ne vaut un petit test.
Ne pas hésiter à utiliser les balises code.

[escartefigue]

Non seulement on peut, mais c'est même fortement recommandé

L'essentiel est de ne pas utiliser les zones de FD mais celles de working

le mieux, pour éviter l'usage des buffers de FD est de ne décrire qu'une zone groupe en FD (plus la clef obligatoire si fichier indexé et accès par clef),
et ne découper les zones des fichiers qu'en WSS (via des copy).

[Hédhili Jaïdane]

Non seulement on peut, mais c'est même fortement recommandé

L'essentiel est de ne pas utiliser les zones de FD mais celles de working

le mieux, pour éviter l'usage des buffers de FD est de ne décrire qu'une zone groupe en FD (plus la clef obligatoire si fichier indexé et accès par clef),
et ne découper les zones des fichiers qu'en WSS (via des copy).

Personnellement je ne vois pas trop ce qui milite en ce sens et je n'en suis nullement convaincu, la seule raison qui nous obligerait à passer par la WSS est quand on veut sauvegarder et préserver, pour traitement ultérieur, les données obtenues dans une lecture précédant la toute dernière lecture. C'est le cas par exemple des maps d'écran ou en vue de rapprochement, rupture, etc.., ou quand voudrait encore utiliser des champs d'un buffer en sortie après son écriture effective.

[Darkzinus]

Personnellement je ne vois pas trop ce qui milite en ce sens et je n'en suis nullement convaincu, la seule raison qui nous obligerait à passer par la WSS est quand on veut sauvegarder et préserver, pour traitement ultérieur, les données obtenues dans une lecture précédant la toute dernière lecture. C'est le cas par exemple des maps d'écran ou en vue de rapprochement, rupture, etc.., ou quand voudrait encore utiliser des champs d'un buffer en sortie après son écriture effective.

Pour les fichiers VB typiquement, ne passer que par la FD peut occasionner quelques surprises ...

[Hédhili Jaïdane]

Pour les fichiers VB typiquement, ne passer que par la FD peut occasionner quelques surprises ...

Peut être mais je n'ai aucun soucis avec ce genre de fichier lorsqu'il est correctement structuré en type et en longueur, aussi bien en Cobol/2 et MF/MS qu'en Cobol OPM/ILE sur AS/400 (et suivants). Pour ce qui est des autres plateformes, aucune idée.
Ceci dit, il faudrait bien s'adapter à son environnement de développement et adopter les meilleures solutions pour éviter les accros même minimes et peu fréquents.

Merci pour ta remarque.

[xfanx]

Personnellement je ne vois pas trop ce qui milite en ce sens et je n'en suis nullement convaincu, la seule raison qui nous obligerait à passer par la WSS est quand on veut sauvegarder et préserver, pour traitement ultérieur, les données obtenues dans une lecture précédant la toute dernière lecture. C'est le cas par exemple des maps d'écran ou en vue de rapprochement, rupture, etc.., ou quand voudrait encore utiliser des champs d'un buffer en sortie après son écriture effective.

je suis plutôt d'accord avec escartefigue sur ce sujet: passer systématiquement par la working.
les FD sont des buffer d'I/O, ce qui signifie que physiquement pour les fichiers de sortie , ce n'est pas quand tu fais le WRITE que ton enregistrement est écrit dans le fichier mais uniquement quand le Buffer d'I/o est plein ou que tu passe sur le CLOSE.
je ne sais pas si c'est toujours d'actualité avec les versions du compilateur actuel, mais j'ai des souvenir de Bug applicatifs bien tordu à cause de l'utilisation direct sur des fichiers output du buffer d'I/O.
par exemple, tu WRITE (sans FROM) un enregistrement directement via la zone de la FD, puis, pour je ne sais quelle raison tu modifies une des données de cette FD, cette dernière modification sera appliqué quand même sur ton fichier de sortie même si tu ne fais plus de WRITE

[Hédhili Jaïdane]

...les FD sont des buffer d'I/O, ce qui signifie que physiquement pour les fichiers de sortie , ce n'est pas quand tu fais le WRITE que ton enregistrement est écrit dans le fichier mais uniquement quand le Buffer d'I/o est plein ou que tu passe sur le CLOSE.

Nous sommes d'accord, bien que les enregistrements logiques soient considérés comme écrits mais ils ne sont pas disponibles pour une lecture par un autre programme, sauf on si on les force.

...par exemple, tu WRITE (sans FROM) un enregistrement directement via la zone de la FD, puis, pour je ne sais quelle raison tu modifies une des données de cette FD, cette dernière modification sera appliqué quand même sur ton fichier de sortie même si tu ne fais plus de WRITE

Par contre là je suis un peu étonné, mais je fais confiance à ton expérience.
La seule contrainte que je connaisse pour les WRITE est que un buffer écrit peut très bien être déplacé par l'OS et que par conséquent il peut contenir des données bien différentes de celles qui y étaient avant le WRITE, mais dès qu'on l'initialise à nouveau, les données sont disponibles jusqu'au nouveau WRITE.

[escartefigue]

Il faut aussi mentionner que en cas d'utilisation du buffer de FD après fermeture des fichiers, le cancel est garanti

[Hédhili Jaïdane]

Il faut aussi mentionner que en cas d'utilisation du buffer de FD après fermeture des fichiers, le cancel est garanti

En effet, il ne faut jamais toucher à la moindre zone des FD quand les fichiers associés ne sont pas ouverts ou viennent d'être fermés (donc non ouverts). Les pointeurs ne seront pas résolus, exception faite des fichiers de tri et des fichiers en USING et GIVING de ce même tri dont les OPEN/CLOSE sont gérés par les routines du SORT, mais là c'est une autre paire de manche.

Un plaisir de discuter avec des connaisseurs.

[escartefigue]

Il faut voir aussi comment est enseigné le cobol de nos jours

Plus personne n'enseigne les fondamentaux et de nombreux développeurs ont été élevés à la sauce générateur de code dont le produit est d'une très piètre qualité.

[escartefigue]

Autre argument en faveur du write from (et du read into) :
en cas d'utilisation d'un debugeur (orthographe non garantie ) genre intertest ou expeditor, on a dans la working exactement ce qu'on écrit (ou lit) alors que la zone FD est inaccessible, et si move il y a, il n'est pas forcément exactement contigu au write ou move, il a donc pu être altéré (exemple courant : par un dépassement de capacité d'un tableau à occurrences ou d'une zone d'appel d'un sous-programme)

[Darkzinus]

D'ailleurs je parlais de la gestion du VB sur ce sujet. Et bien j'ai encore vu un cas cette semaine de programme mal écrit avec la description fichier en FD avec un joli plantage. Je vois également régulièrement des fichiers VB qui passent d'un "vrai" format d'un enregistrement, par exemple du VB 1300, qui en sortie se trouvent au format VB 5000 du fait de la mauvaise gestion de ceux-ci.