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



While I'm almost embarrassed to post this, I figured it might help
somebody else out so it was worth adding to the archives.

I had a SETLL following by a READE that I was having problems with.  The
READE was hitting EOF immediately even though there were records that
should have been found.

I was using a key data structure with 7 subfields on the SETLL.  The 7th
field was loaded with *LOVAL.

After the SETLL, %found(myfile) equaled *ON, %equal(myfile) equaled *OFF
as I was expecting.

I tried setting the 7th field of the DS to the exact value from the
file.

After the SETLL, both %found(myfile) and %equal(myfile) equaled *ON.

However, a READE using only 6 of the 7 subfields of the KDS was hitting
EOF.

What the ????  

%equal(myfile) *ON after the SETLL indicates that SETLL found a record
with the exact match to my specified key so why was the READE hitting
EOF?


Since the SETLL and READE were being done it two separate procedures, I
though something was going on between calls.  Perhaps somehow my KDS was
changing.  Some DSPLY statements proved that not to be the case.

I tried using a READ instead of READE, the record read was the first
record in the file, not the record with the key I wanted.  Was SETLL not
working or was the file position be reset somehow between calls.

I moved the READ to the same procedure and directly after the SETLL.
Still, the record read was the first record in the file.  Proof positive
that the SETLL was not working; even though %found(myfile) = *ON,
%equal(myfile) = *ON, and %status(myfile) = '0000' would seem to have
indicated that the SETLL was working fine.


The problem ended up being that I had forgotten the %kds() on the SETLL.

Instead of having
   setll %kds(mykds) myfileR;
I had
   setll (mykds) myfileR;


Don't ask me how many times I looked at that SETLL line before I
realized what was missing!!


Barbara if you're reading this:
1) Why did the compiler even accept this?  Assuming (mykds) was treated
as a single field, shouldn't the compiler have complained that mykds was
not the same size as the first key field in the file.
2) Assuming that the SETLL was only looking working with the first key
field, why did changing the 7th subfield of the DS from *LOVAL to an
actual value change what %equal() returned?


Hope this helps somebody else.



Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 


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.