How to reset file pointer in a CL program?

Question

I am currently working on a CL program which needs to read some records from a file. The file is overridden to itself for one of its members. Then there are some RCVF operations to retrieve the records of that particular member. When the end of file message is received the overridden file is delete. Then another OVRDBF is performed with a different member in this file. This time when a RCVF operation is conducted it immediately hits the end of file - the message is received straight after it. Is there anyway to reset the file pointer so the subsequent RCVF operations can retrieve the content in the second member?

Post the code you have right now. – Pete Wilson Dec 14 '11 at 12:47 — Pete Wilson, Dec 14 '11 at 12:47

James Allman · Answer 1 · 2011-12-14T14:43:28.297

3

You will have to manually open the file with OPNDBF and close it with CLOF as well as specify the open file identifier on the RCVF command.

            PGM

            DCLF       FILE(TESTFILE) OPNID(TESTFILE)

            /* CRTSRCPF   FILE(QTEMP/TESTFILE) */
            /* ADDPFM     FILE(QTEMP/TESTFILE) MBR(MBR1) */
            /* ADDPFM     FILE(QTEMP/TESTFILE) MBR(MBR2) */

            OPNDBF     FILE(TESTFILE) OPTION(*INP) MBR(MBR1)
MBR1:       RCVF       OPNID(TESTFILE)
            MONMSG     MSGID(CPF0864) EXEC(GOTO CMDLBL(MBR2))
            GOTO       CMDLBL(MBR1)

MBR2:       CLOF       OPNID(TESTFILE)
            OPNDBF     FILE(TESTFILE) OPTION(*INP) MBR(MBR2)
LOOP:       RCVF       OPNID(TESTFILE)
            MONMSG     MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDPGM))
            GOTO       CMDLBL(LOOP)

ENDPGM:     ENDPGM

edited Dec 14 '11 at 14:43

answered Dec 14 '11 at 13:48

James Allman

40,573
11
57
70

Even when there is no OPNQRYF? – God_of_Thunder Dec 14 '11 at 14:01
Does this method have any potential conflict with OVRDBF? And is it necessary to have this ADDPFM statement before OPNDBF? – God_of_Thunder Dec 14 '11 at 14:31
You don't need the OVRDBF when using the OPNDBF command. The ADDPFM statement was just for the test case. – James Allman Dec 14 '11 at 14:32
I tried this today, and it seems that the program opened the file twice with two different members each time. Looking at WRKJOB when I ran the program under debug mode, there were two of the declared file displayed. One of the opened with the member described in the OPNDBF command, the other opened with the default member which has the same name as the file. So when RCVF was conducted the records from both members would be retrieved. Why? First I must say that in this file there IS a member with the same name as the file, and this cannot be avoided. – God_of_Thunder Dec 15 '11 at 15:30
The example program won't work for reading the second member. The program "works", but it will throw CPF0864 immediately upon attempting RCVF on MBR2. It will **seem** to work because of the way it's written. However, if a source line is entered into the two members and the CL sends the text back out with SNDPGMMSG, it'll be clear that no record is read from MBR2. – user2338816 Apr 05 '14 at 12:40

score 2 · Answer 2 · answered Apr 05 '14 at 13:04

There have historically been two methods of re-reading a file in CL.

First is to use RTVMBRD to retrieve the number of records in the member. Loop through the file counting records and stop when the record count reaches the last record. This avoids getting CPF0864 thrown, so the problem is avoided.

Second is to write two programs. The first performs any needed overrides, then calls the second program to do the read loop. Upon return to the first program, the CPF0864 is cleared. A new override can be applied, and the second program can then be called again. Since it's a new invocation, it can read the same file again without problem.

In V5R3, a partial solution was provided by allowing up to five DCLFs in a single CL program. That could easily work for this case. Simply use one DCLF for the first member and a second DCLF for a different member. It can also be used to re-read the same member. (If more than five members are needed, this won't help.)

However, it still doesn't clear a CPF0864 condition for a particular DCLF.

But in i 6.1, a much more complete solution is provided. The CLOSE command was added and it will clear CPF0864. It performs a full-close, so files can easily be reused in a single CL program.

How to reset file pointer in a CL program?

2 Answers2