Discussion :

[JauB]

Bonjour,
Voilà tout est dans le titre : je cherche l'expression, si elle existe, qui permet de lire le dernier enregistrement d'un fichier séquentiel (donc je n'ai pas de fichier logique). Ce ci dans le but de parcourir le fichier à partir du denrier enregistrement et monter en haut

Merci.

[Hédhili Jaïdane]

Bonjour.

- Il y a bien le READ...LAST et le READ...PRIOR mais ton fichier doit être INDEXE et assigné à DATABASE avec un accès DYNAMIC.

- Sinon, tu triches un peu en déclarant ton fichier assigné à DATABASE avec ORGANIZATION RELATIVE, ACCESS DYNAMIC ou RANDOM et RELATIVE KEY.
Tu initialises ta RELATIVE KEY avec le nombre des enregistrements alloué récupéré par la commande RTVMBRD et que tu passes à ton programme. En faisant un READ direct, tu lis l'enregistrement dont le RRN est dans la RELATIVE KEY, pour lire les enregistrements précédents, tu décrémentes ta RELATIVE KEY jusqu'à 1.

[Mercure]

Oui, c'est aussi ce que ferais mais au lieu d'utiliser la commande RTVMBRD toujours un peu embêtante à cause du débranchement obligatoire vers un programme CL, dans mon programme j'utiliserais directement l'API QUSRMBRD qui est équivalente à la commande. Elle va me renvoyer le nombre d'enreg. contenus dans le membre du fichier. En voici d'ailleurs un exemple écrit en Cobol de Papa :

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
       ID DIVISION.
       PROGRAM-ID. MONPGM.
       ENVIRONMENT DIVISION.
       Configuration Section.
       Source-computer. IBM-AS400.
       Object-computer. IBM-AS400.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT MyFile ASSIGN TO DATABASE-MyFile 
             ORGANIZATION relative
             ACCESS IS dynamic
             RELATIVE KEY RRN-MyFile 
             FILE STATUS MYFS.
       DATA DIVISION.
       FILE SECTION.
       FD MyFile 
           LABEL RECORD STANDARD.
       01  MyFile-Enr.
           copy dds-all-formats of MyFile.

       WORKING-STORAGE SECTION.
       01  MYFS pic xx.
       01  RRN-MyFile  pic 9(5) comp-3.
       01  Fini pic x value "0".

      * API QUSRMBRD : le nbre d'enregistrements du fichier
      * se trouve dans la variable "NbrRcds".
       01  Rcvv.
           05  filler  pic x(252).
           05  NbrRcds pic s9(5) binary.
       01  RcvvL pic s9(5) binary value 256.
       01  FmtName pic x(10) value "MBRD0200".
       01  QFName.
           05  FName pic x(10) value "MYFILE".
           05  LName pic x(10) value "*LIBL".
       01  MName pic x(10) value "*FIRST".
       01  OvrProc pic x value "0".
       01  API-Err.
           05  BytesPvd pic s9(5) binary value 144.
           05  BytesAvl pic s9(5) binary.
           05  API-MsgId pic x(7).
           05  Filler    pic x.
           05  API-MsgDta pic x(128).

       PROCEDURE DIVISION.

       000-MAIN.
           OPEN input MyFile .
           CALL "QUSRMBRD" using Rcvv RcvvL FmtName
                                   QFName MName OvrProc API-Err.
           MOVE NbrRcds to rrn-MyFile .
           START MyFile  key not less RRN-MyFile 
                                       invalid display "IK".
           MOVE "0" to Fini.
           PERFORM 001-ReadFile Until Fini Not = "0".
           CLOSE MyFile .
           STOP RUN.

       001-ReadFile.
           READ MyFile  Invalid MOVE "2" to Fini.
           ... Traitement du record ici ...
           SUBTRACT 1 FROM rrn-MyFile .
           IF rrn-MyFile  <= 0 MOVE "1" to Fini.

[Hédhili Jaïdane]

Personnellement je ne considèrerais pas la condition INVALID comme critère d'arrêt, les enregistrements supprimés ou un RRN supérieur à celui du dernier enregistrement provoqueront l'arrêt du traitement séquentiel.
- des enregistrements supprimés (ou flagués comme tels) peuvent exister dans un fichier séquentiel par héritage de copie
- cette méthode est aussi applicable sur des fichiers indexés qui peuvent donc contenir des enregistrements supprimés.

[JauB]

Je comprends alors qu'il n'y a pas de manière native pour se positionner sur le dernier enregistrement !
Bon j'utilisera l'une vos manières (peut être )
Merci

[Mercure]

Personnellement je ne considèrerais pas la condition INVALID comme critère d'arrêt...

J'ai publié ce programme fait à la va-vite pour montrer la séquence d'instructions à développer pour lire un fichier non indexé à reculons. Je n'ai pas cherché à gérer les cas d'erreur car ce n'était pas l'objet de la question de l'OP.

Je comprends alors qu'il n'y a pas de manière native pour se positionner sur le dernier enregistrement !
Bon j'utilisera l'une vos manières (peut être )

Non, en effet, il n'existe pas à ma connaissance une instruction Cobol "native" ni pour se positionner, ni pour lire un fichier non indexé en commençant par la fin, mais, je ne comprends pas le "peut-être" ?

[JauB]

J'ai dit peut être parce que là j'ai déjà commencé à développer mon programme de façon à parcourir le fichier dès le début jusqu'à la fin et une fois j'arrive à une condition sur un champ je sais que le reste du fichier est à traiter (donc là je ne parcours par le fichier dans le sens inverse), et si cela me poserait des problèmes de performances alors je basculerais vers l'une de vos manières, d'où le peut être

J'ai publié ce programme fait à la va-vite pour montrer la séquence d'instructions à développer pour lire un fichier non indexé à reculons. Je n'ai pas cherché à gérer les cas d'erreur car ce n'était pas l'objet de la question de l'OP.



Non, en effet, il n'existe pas à ma connaissance une instruction Cobol "native" ni pour se positionner, ni pour lire un fichier non indexé en commençant par la fin, mais, je ne comprends pas le "peut-être" ?

[Hédhili Jaïdane]

J'ai publié ce programme fait à la va-vite pour montrer la séquence d'instructions à développer pour lire un fichier non indexé à reculons. Je n'ai pas cherché à gérer les cas d'erreur car ce n'était pas l'objet de la question de l'OP.

Désolé, mille excuses, cette remarque était destinée à notre ami Jaub au cas où il utiliserait cette méthode, mais comme il semble s'en désintéresser...

[Mercure]

Aucune importance en ce qui me concerne et... bonne année 2011 !

[el_slapper]

Après, c'est une question de philosophie. Moi, arrivé au "switch", je créérais un nouveau fichier, puis je le trierais en descendant(par JCL), avant de le concaténer(toujours par JCL). Pour moi, soit il faut travailler en séquentiel(ça peut d'ailleurs être fait par paquets d'enregs mis en mémoire), soit en fichiers indexés(comme Mercure ou Hédhili Jaïdane), mais mélanger les genres, c'est risquer gros.

De toutes façons, lire un fichier, c'est rapide de nos jours. Faire juste un "lire fichier, tester condition", même un million de fois, c'est pas méchant. un accès séquentiel, pour le coup, risque de flinguer les performances(ça depend du pourcentage de données utiles, en fait).

[Mercure]

Et créer un nouveau fichier puis le trier, ça ne flingue pas les perfs peut-être ?

[el_slapper]

Et créer un nouveau fichier puis le trier, ça ne flingue pas les perfs peut-être ?

Par rapport à une lecture aléatoire VSAM? Pas sur. Mais évidemment, ça dépend des volumétries respectives attendues. Suivant que le "switch" est à 1% du fichier ou à 99%, l'optimum de performances ne nécéssite sans doute pas la même architecture. S'il est à 1%, effectivement, prendre 99% du fichier de départ et l'inverser, c'est douteux. S'il est à 99%, de toutes façons, il faudra quasiment tout lire, et autant le lire sans s'embarrasser d'une clef.

[Mercure]

L'OP n'est pas sur IBM z/OS mais sur IBM System i (OS/400) et VSAM n'existe pas sur ce système.