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



"Well, to be fair, I'm also critiquing the RPG manual for not being clear about it."

There is a "thumbs up" and "thumbs down" button on the right top of every page in the documentation and after clicking one of them you can leave your feedback. I do that occasionally when I find explanations that are either unclear or don't match up with what I experience on usage of the explained functionality. It's your chance to make the documentation better.

Kind regards

Martijn van Breden
lead software architect



-----Oorspronkelijk bericht-----
Van: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> Namens Peter Dow
Verzonden: zaterdag 18 maart 2023 18:43
Aan: rpg400-l@xxxxxxxxxxxxxxxxxx
Onderwerp: Re: SETLL *START and %EQUAL

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



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

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.