Re: RCVF in CL

On 09-Feb-2015 15:39 -0600, Mark S Waterbury wrote:

On 2/9/2015 4:09 PM, Rich Loeber wrote:

I have a program that reads a short source physical file during
processing. Over the course of processing, it may need to go back
and re-read the file again and I've hit a brain cramp on how to get
it to start over without ending the program.

Is there a secret here?

OVRDBF with a position, and POSDBF only works if you have not yet
reached the *end-of-file* condition.

At V6R1 and above,there is a new CLOSE command in OS/400 that does
exactly what you want, for use with RCVF.

If you need this to work at V5R4 or earlier, create two CL programs,
one for the first pass over the file, then CALL the second program
to process the second pass.

The OP may have resolved the original concern from this or prior replies, but the following may be of some interest:

Note that prior to the new Declare File (DCLF) support and the CLOSE command, the Position DataBase File (POSDBF) only functioned against an Open Data Path (ODP) with an Open Identifier (OPNID) created with either the Open Database File (OPNDBF) or Open Query File (OPNQRYF) commands; a shared open would be required for the Receive File (RCVF) request, the initial open made previously by one of those other commands. The newer support is desirable, as noted above, to avoid use of any /gimmicks/ to ease effecting the second-pass of the data.

There are numerous means [or "gimmicks"] to enable the second-pass of the [likely presumed-static] data from the ODP without the new support by coding to avoid the CPF0864 End Of File condition [for which all future RCVF get the same error]; a couple have been alluded or noted in other replies. There are many past discussions describing the various means to avoid the EOF and restart a RCVF loop. Using separate programs, as noted above, is indeed an alternative, allowing each program to be defined succinctly as open\process\close wherein effectively only the /process/ changes.

However with regard to allowing the EOF condition to occur within the program while still effecting a second pass of the data [on older releases], creating two separate programs may be considered to be undesirable [at least prior to INCLUDE support], so as to avoid duplicating code. A preferred alternative in that case may be [and many examples can be found showing a choice was made] to use the Transfer Control (TFRCTL) to the same\one program to perform the second-pass; ideally the value of a parameter can be changed to tell the program which /process/ to perform [respective to which pass through the data], rather than the program trying to infer based on some retrieved condition.