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

Hi, Ken:

> >> >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.

This is wrong.  The following code snippet will work very well for what
you're asking:
    OVRDBF FILE1 POSITION(*RRN FMT1 12)
    RCVF
    RCLRSC *CALLER
    OVRDBF FILE1 POSITION(*RRN FMT1 8)
    RCVF

The above will read the twelfth record, and then the eighth record of the
file.  (Try it before you argue.)  I will cite again the following quote
from the CL Reference (the text has not changed at least since V4R4....

<QUOTE>The Open Database File (OPNDBF) command opens a database file
member. Processing of records is done later by application programs that do
shared open operations. If the file is opened by the OPNDBF command, this
open operation is not used by the Receive File (RCVF) command. The RCVF
command performs its own open operation. More information on database files
is in the Database Programming topic in the Information Center</QUOTE>

> >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).

This was not in your example code.  If you change the question enough, you
might well change the answer.  But I'll still hold that OPNDBF is not
*REQUIRED* by CL in order to cause an OVRDBF to have an effect on your
RCVF.

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

The following should look very familiar to you:
> Initially I tried with
>         OVRDBF POSITION(*START)
>         ...loop1...
>         DLTOVR
> and the same for the second loop. Then I tried with
>         OVRDBF POSITION(*START)
>         OPNDBF
>         ...loop1...
>         CLOF
>         DLTOVR
> but I still get the same results.

> >Finally, as I said, reclaiming resources and issuing another read will
> >cause the program to read FROM THE BEGINNING OF THE FILE.
>
> 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.

Granted.  And they can be significant.  This would not be an issue in the
problem you stated.

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

This documentation is freely available to all who would care to look it up.
Do you need the link to the publications?

> 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.

YOU CAN DO THIS WITHOUT OPNDBF.  OPNDBF has NO effect on RCVF (with the
POSSIBLE exception of SHARE(*YES) files, which you had omitted from your
previous problem)

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

And so the purpose of your question was ???????

Dennis




|---------+-------------------------------------------------->
|         |           Ken Sims <mr3111@xxxxxxxxx>            |
|         |           Sent by:                               |
|         |           midrange-l-bounces+dlovelady=dtcc.com@x|
|         |           idrange.com                            |
|         |                                                  |
|         |                                                  |
|         |           06/20/2003 09:43 PM                    |
|         |           Please respond to Midrange Systems     |
|         |           Technical Discussion                   |
|         |                                                  |
|---------+-------------------------------------------------->
  
>---------------------------------------------------------------------------------------------------------|
  |                                                                             
                            |
  |        To:      midrange-l@xxxxxxxxxxxx                                     
                            |
  |        cc:                                                                  
                            |
  |        Subject: Re: re-reading records in CL (not after EOF!)               
                            |
  
>---------------------------------------------------------------------------------------------------------|




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.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.