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.

Besides all the tips given below, don’t forget you can run your program in debug mode and see exactly what is in the key fields and how they are loaded/built. Sometimes we automatically assume something and it may not be the case.

Discuss This Question: 18  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.
  • CharlieBrowne
    I suggest there may be something wrong in your Key List.
    Try it in freeform: Chain (Fld1 : Fld2 : Fld3) your File
    62,340 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.

    54,090 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.


    62,340 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'.

    9,110 pointsBadges:
    report
  • BigKat
    actually, now that I wrote that, if an OPNQRYF "removed" the record from the file, how did the setll/read work?
    9,110 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,710 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.  
    9,110 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?
    9,110 pointsBadges:
    report
  • stevemukoyi
    I am chaining an AS400 file and i have defined my keylist correctly but still the its not retrieving anything though records are in the database. Can you please assist. below is my code

        ACKEY         CHAIN     SC10LF                             99 
        *IN99         IFEQ      '0'                                   
                      IF        *IN99 = '0'                           
                      Z-ADD     0             AMT1             15 0   
                      MOVEL     ''            STATUSS                 
                      EVAL      AMT1 = SCBAL-SCODL-SCRBA-SCSUM1       
                                       -SCSUM2+SCSUMC+SCSUMD-SCSUML   
                      MOVEL     'Y'           FLAG1             1     
                      IF        AMT1 <= DEBAMOUNT                     
                      MOVEL     'N'           FLAG1                   
                      MOVEL     'Unfunded'    STATUSS                 
                      ENDIF                                           
    30 pointsBadges:
    report
  • ToddN2000
    @stevemukoyi: IT may be possible you have your 99 indicator in the wrong column. In you example you have 3 IF conditions and only one end. Try using the built in %FOUND for your chain test.
    ACKEY         CHAIN     SC10LF                               
                  IF        %FOUND                            
                  Z-ADD     0             AMT1             15 0    
                  MOVEL     ''            STATUSS                  
                  EVAL      AMT1 = SCBAL-SCODL-SCRBA-SCSUM1        
                                   -SCSUM2+SCSUMC+SCSUMD-SCSUML    
                  MOVEL     'Y'           FLAG1             1      
                  IF        AMT1 <= DEBAMOUNT                      
                  MOVEL     'N'           FLAG1                    
                  MOVEL     'Unfunded'    STATUSS                  
                  ENDIF 
    	      ENDIF 
    102,670 pointsBadges:
    report
  • ToddN2000
    @stevemukoyi: Also when creating your keys, if they are being created and not loaded from another file, make sure they are the same length and nothing is getting truncated. You want to make sure that the justification left/right is the same for alpha fields.
    102,670 pointsBadges:
    report
  • stevemukoyi
    Thank you guys!
    30 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.

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

Following

Share this item with your network: