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
