Re: re-reading records in CL (not after EOF!)

[Ken Sims <mr3111@xxxxxxxxx>]

Hi Dennis -


> > >Elimiate the OPNDBF command - you don't need it.  On first read, RCVF will
> > >implicitly open the file
> >
> > The OPNDBF is required to be able to use POSDBF to reposition the file.
> Ummm... not unless they've changed the rules.

You do need OPNDBF (or OPNQRYF) to use POSDBF.  Your method doesn't require 
OPNDBF because your method doesn't use POSDBF.

> If the file is opened by the OPNDBF command, this open operation is not
> used by the Receive File (RCVF)

It isn't automatically, but it is if you use OVRDBF with SHARE(*YES).

> First off, OVRDBF POSITION(*START) has always seemed like a silly value to
> me.  Where else would one expect it to begin processing?

You are correct that POSITION(*START) is not required.  My OVRDBF did not 
show POSITION(*START), only SHARE(*YES).

> Secondly, you don't have to use explicit open in order to effectuate your
> OVRDBF command.

I don't know what you mean by "effectute".  If you don't use OPNDBF and 
POSDBF then you don't need the override with SHARE(*YES) at all.

> Finally, as I said, reclaiming resources and issuing another read will
> cause the program to read FROM THE BEGINNING OF THE FILE.  (If I didn't say
> it, I meant it.....)

I've never heard that before, but I wouldn't use that method anyway for at 
least three reasons that I can think of right now:

1. RCLRSC *CALLER may have unintended consequences.

2. Unless this is documented, it could change in a future release, whereas 
using a shared ODP won't.

3. That method only allows you start at the beginning of the file.  If you 
want to get creative, you can use OVRDBF with SHARE(*YES) and different 
POSITION values with OPNDBF and CLOF to give you the CL equivalent of SETLL.

Of course personally I wouldn't do this kind thing of CL at all.  I'd do it 
in RPG IV.

Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of 
my employer or anyone in their right mind.