klist chain not finding existing record

55 pts.
Tags:
AS400 RPGLE Debug
CHAIN
I've got a logical keyed on field 1, field 2 and field 3. In my RPG I've got a chain to that logical with a key list where the values appear to match those in Field 1, 2 and 3. The chain fails to locate the record. A setll followed by a reade fails to find it. But a setll followed by a read does find it. I'm using the full key for all lookups so any suggestions why it isn't finding the record would be well received

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 14  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • CharlieBrowne
    I suggest there may be something wrong in your Key List.
    Try it in freeform: Chain (Fld1 : Fld2 : Fld3) your File
    41,380 pointsBadges:
    report
  • philpl1jb

    The way you've described it the chain should work.

    There are three fields in the klist

    The field types and sizes are the same in the klist and the first three keys in the logical

    All three fields in the key list are populated with values that are virtually identical to the values in the first three keyfields on the logical file.

    49,960 pointsBadges:
    report
  • mrwilf
    Will try in free and will try %kds instead of a klist - if that makes a difference I will be mostly pulling hair out to understand why as that will mean mixing fromtas in a legacy pgm which makes me unhappy.
    55 pointsBadges:
    report
  • mrwilf
    Also, after the chain has failed, the file i/o is showing that it is sitting on the correct record (rrn match), but hasn't found it!
    55 pointsBadges:
    report
  • CharlieBrowne

    I was suggesting you use the actual values in the chain. Not %kds

    My thoughts center around the klist not being setup properly with the actual access path of the file.


    41,380 pointsBadges:
    report
  • mrwilf

    Yes, didn't write the reply very well - tried both and still no joy.

    I've also written a dummy prog to check there is nothing wrong with the file setup and it writes, updates okay so problem is within the real prog.

    Prog uses two logicals with different keys to access the pf - could this be causing issues?  No record locks reported and all set to share?

    Put a dow read loop in there and set to kick out when my record came up - but it never did - yet when I shwfc the file I can see it there

     

    Making my brain bleed now.

    55 pointsBadges:
    report
  • mrwilf

    Turns out there is an undocumented opnqryf removing some records based on one of the fields not being updated in this prog.  Status gets set to R in a callp and R is not in the opnqryf file so the record "doesn't exist" for the main prog.

    Thanks for your input

    55 pointsBadges:
    report
  • BigKat
    well, I know we found the answer, but for anyone searching in the future, I was going to suggest looking at the key fields values (in the file) IN HEX.  Perhaps one of the values wasn't actually a match because of a non-displaying character like x'00' instead of blank x'40'.

    8,210 pointsBadges:
    report
  • BigKat
    actually, now that I wrote that, if an OPNQRYF "removed" the record from the file, how did the setll/read work?
    8,210 pointsBadges:
    report
  • mrwilf
    That's a very good question!  Didn't investigate further once the opnqryf was found and now can't remember precisely.
    55 pointsBadges:
    report
  • WilsonAlano
    BigKat,

    Remember that SETLL positions file pointer on a record with key value less or equal to klist value! If result not points to EOF, a READ (not a READE) will find a record that exists in file but not necesarilly with the same key.

    That's why READE do not works. There is no key in file with the exact same klist value.

    2,485 pointsBadges:
    report
  • BigKat
    Hi Wilson,

    I still think there was more going on than meets the eye.  He said the OPNQRYF "removed" the record, so the SETLL/READ still should not have found the record.  Perhaps when he tested the SETLL/READ, he did not run the whole process and so the OPNQRYF was not setup.  
    8,210 pointsBadges:
    report
  • RamvishakRamesh
    OPNQRYF might have removed the particular record which exactly matches with the key that he was looking for. But there may be another records with key values greater than that. So SetLL read might have entered into the DoW Not%Eof() loop. But defenitley setll/read also will not find the exact record match.
    2,505 pointsBadges:
    report
  • BigKat
    ...A setll followed by a reade fails to find it. But a setll followed by a read does find it...

    But he didn't say it found ANOTHER record, he said it found THE record that the OPNQRYF removed.  Or am I reading more into than was meant?
    8,210 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following