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



Maybe the proper wording should be:

*..the file specified in factor 2 must be repositioned (for example, by a
CHAIN or SETLL operation) before a subsequent read operation can be done *
*accurately **on that file....*

Or some other word that means you can do it, but the results may not be
what you expect.

-doug

On Fri, Dec 18, 2015 at 12:05 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Just for fun I looked back to a really early manual - V2R1 - for RPG/400 -
here is the same paragraph -

When the CHAIN operation is successful, the file specified in factor 2 is
positioned such that a subsequent read operation retrieves the next
sequential record following the retrieved record. When the CHAIN operation
does not complete successfully (for example, an error occurs or no record
is found), the file specified in factor 2 must be repositioned (for
example, by a CHAIN or SETLL operation) before a subsequent read operation
can be done on that file.


Now as John suggests, maybe the behavior has changed - I hope not!!

To me, the wording suggests that if one tries a read operation after a
failed chain, one should get an error.

I do admit that this is a situation that would rarely be done this way,
but there are sometimes reasons to understand what COULD happen even when
the craziest programmer is at work!!


Regards
Vern

On 12/18/2015 10:33 AM, Kurt Anderson wrote:

It's totally ok to disagree with my take. ;)

However, I disagree with this statement:
"The docs are absolutely clear and unequivocal, and the behavior clearly
does not match the docs."

IMO it is not clear. The SetLL documentation is very clear about what
happens when no record is found. The Chain documentation is not. It talks
about reading a record after a chain. Now it's in example territory. Who
cares about performing a Read after a Chain, I just want to know what
happens in regard to the file positioning after a failed Chain. The
documentation does not explicitly state what happens as it does with SetLL.

I say the documentation is in "Example" territory because what happens
with a failed Chain is completely unrelated to any statement that comes
after the Chain. It seems like the documentation is trying to be helpful
in saying that if you Chain first, and then Read, and your Chain failed,
you'll need to position the file before the read. When are you reading
after a Chain? I suppose if you code your read loops to start with a
Chain, then read at the end of the loop, that's a time you would do that.
Personally I'm not a fan of that method and prefer to SetLL prior to a read
(generically speaking).

Given what Vern is seeing, and that the documentation isn't stating
explicitly what happens on a failed Chain, I extrapolated what does happen
on a failed Chain. I could be wrong, but given the information presented
I'm pretty confident in my guess.

Kurt Anderson
Sr. Programmer/Analyst - Application Development, Service Delivery
Platform


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John
Yeung
Sent: Friday, December 18, 2015 10:12 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: CHAIN not found and subsequent READ - docs wrong?

On Fri, Dec 18, 2015 at 9:36 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

So the docs are at least confusing, right?

Actually, I think the docs are just plain wrong, now.

I disagree with Kurt, because the manual in fact very carefully and
explicitly goes over both the successful and unsuccessful cases, and spells
them out very clearly, even mentioning specifically that "no record found"
is in the "not completed successfully" case. I mean, it's a model of Chuck
Pencian thoroughness and precision.

The docs are absolutely clear and unequivocal, and the behavior clearly
does not match the docs. (I tested it just now, and was surprised by the
result.)

The reason I use the word "now" when I say the docs are wrong is that I
could have sworn, back in the day, that I encountered the behavior that the
docs are describing. Namely, immediately following an unsuccessful chain,
the next read was unsuccessful.

Either the behavior was changed sometime between V5R2 and 7.1, or I am
just imagining that I encountered the doc-described behavior. Which is
entirely possible - I have been a rule-follower for most of my life, as
well as someone who reads all available instructions before doing anything.
With the docs so utterly, unmistakably clear, I may well have just taken it
as a given that the read would fail in that situation, and simply never
allowed it to happen in my code.

John Y.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.