× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

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

You seem to be having trouble reading. I never said that OPNDBF was required to use OVRDBF or vice versa. Read the quote above. I said that OPNDBF (or OPNQRYF) is required to use *****POSDBF*****.


So show me where you are using ******POSDBF***** without using OPNDBF (or OPNQRYF) before you tell me that I'm wrong.

The above will read the twelfth record, and then the eighth record of the
file.  (Try it before you argue.)

As I pointed out in a section that you chose not to quote, you can use this method of position (OVRDBF with POSITION) without the need for RCLRSC by using a shared ODP, OPNDBF, and CLOF.


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

Yes, I would VERY MUCH like a link to an IBM OS/400 publication that states that this is supported behavior because all I could find (in the documentation for the RCLRSC command), the section on "Restrictions" is ...


"2. Do not specify LVL(*CALLER) on this command if it is used in a CL program that also uses the Send File (SNDF), Receive File (RCVF), or Send Receive File (SNDRCVF) commands. Specifying RCLRSC LVL(*CALLER) in such a program causes unpredictable results when the SNDF, RCVF, or SNDRCVF commands are used after the program runs."

That quote is from the V4R4 manual, but V5R2 has the same thing:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/cl/rclrsc.htm

It seems to me that IBM is saying very clearly that RCLRSC LVL(*CALLER) with RCVF should *****NOT***** be used and that any particular behavior is not guaranteed.

So why use something that is NOT supported and specifically said to have "unpredictable results" when there is another method (a shared ODP) that is supported.

Ken, you mention that:

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

I apparently never saw that code, and I cannot find it in the archives.
Hence my confusion.

I didn't have any trouble finding it: http://archive.midrange.com/midrange-l/200306/msg01032.html

I cannot properly address, then, the question posed by you, that is unless
you re-post.

I didn't have a question. I had an answer, which you have been continually disputing.


With regards to the original question, the code I have supplied, and whose
integrity I defend, should work nicely for you, Martin.

See my quote above from IBM.


I goofed in my reply, thinking that Ken was the originator of this thread.
Some of my comments were specific to the original question, rather than one
that may have been posed by Ken.

You have made quite a number of goofs. So far as I am concerned, this discussion with you is over.


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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.