|
On Mar 18, 2023, at 1:43 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:
Well, to be fair, I'm also critiquing the RPG manual for not being clear about it.
And another point of view is that *START is indeed a specific key, the key of the first record in the file (if keyed), or simply the first record in the file (if arrival sequence). If you were accessing a file in arrival sequence, and used SETLL *START, and there was a record in the file, would you argue that there is no specific starting record?
I would also say that *LOVAL and *HIVAL are also specific keys, and I would expect %equal to be set on only if there were actually a record with *LOVAL or *HIVAL as its key value, which is pretty unlikely but not impossible.
On 3/18/2023 10:00 AM, Jon Paris wrote:
But you're using your own definition of what SETLL is supposed to do and then critiquing it for not doing what you think it should.--
SETLL is intended to position the read cursor - period. As a courtesy RPG also tells you if it positioned you exactly in front of the specific key you requested. Note "specific key" and *Start is _not_ a specific key.
It has always worked this way and any change would cause chaos.
Jon P.
On Mar 17, 2023, at 4:24 PM, Peter Dow<petercdow@xxxxxxxxx> wrote:
Hi Alan,
If the question became "Equal to what, exactly?", I would say equal to the key in the *START (or first) record.
I don't like it, but I can accept that %equal is only *ON if a particular key was specified and it exists. But in my mind, when I say "SETLL *START MyFile;" I'm specifying the key of the starting record in the file, and if the file is not empty, there must be a starting record.
Similarly with %found, why would it be *OFF if a record exists in the file? "SETLL *START MyFile;": couldn't find anything in a non-empty file? The manual actually says
"The resulting indicators reflect the status of the operation. You can specify an indicator in positions 71-72 that is set on when the search argument is greater than the highest key or relative record number in the file. This information can also be obtained from the %FOUND built-in function, which returns '0' if no record is found, and '1' if a record is found."
which is not accurate when using SETLL *START.
On 3/17/2023 3:30 AM, Alan Cassidy wrote:
I would rephrase Jon's explanation this way.--
When you use SETLL using the key field values for the file you're reading, you get %equal = '1' if it finds a record with keys that match those values. If you key field "valules" is *START, you aren't giving the statement any arguments to match against the key fields. "Whatever you get" is meaningless, because the question becomes, "Equal to what, exactly?"
--Alan Cassidy
On 3/16/2023 6:21 PM, Jon Paris wrote:
I don't think $equal should be set here as it used to indicate that it detected a record in the file with a key equal to that of the value specified. But no valid key was specified!
Remember that SETLL is attempting to position the read cursor _before_ the first record with the desired key. Telling you that it was able to exactly match (i.e. %equal) is basically just a useful courtesy. If you think of it that way the failure to set %equal may make more sense.
As to the second part of your question, I'm not sure where it is documented - but as a general rule parens mean "this key may not be in the exact right format - please deal with it." - so a packed number will be accepted for a zoned key for example. In the case of *Start they are meaningless.
Jon P.
On Mar 16, 2023, at 5:19 PM, Peter Dow<petercdow@xxxxxxxxx> wrote:
I have a program that has
SETLL *START MyFile;
IF %EQUAL();
READ MyFile;
ELSE;
do something different;
ENDIF;
In debug, I discovered that it does something different. My first thought was that maybe it's because the file is empty, but it wasn't.
After reading the manual, the closest thing I can see to saying why %EQUAL was *OFF was this:
"You can specify an indicator in positions 75-76 that is set on when a record is present whose key or relative record number is equal to the search argument. This information can also be obtained from the %EQUAL built-in function, which returns '1' if an exact match is found."
I guess there's an argument to be made that *START is not an exact match with whatever is in the first record, but one could also say that the first record is always a match for the first record.
I also noticed that the manual does not say what the effect of () around the search argument is. My assumption there is that the () define a list of values that are converted to match the related key fields, but the manual does not say that.
Where is this stuff actually stated?
--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx
pdow@xxxxxxxxxxxxxx
/
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email:RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/rpg400-l
or email:RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/rpg400-l.
Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email:RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/rpg400-l
or email:RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/rpg400-l.
Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
