Re: SETLL *START and %EQUAL

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.