SETLL READE not working?
I am using a partial key (1st field) to read a keyed file (2 fields - both keys - ascending order):
ABCKEY     KLIST                 KFLD         WRKABC (this has a value that I know has at least 1 record in my external file)                                                                         (indicators)
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â ABCKEYÂ Â Â Â Â Â Â Â SETLLÂ Â Â Â Â Â FILEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â 506070
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â ABCKEYÂ Â Â Â Â Â Â Â READEÂ Â Â Â Â FILEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 8090
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â *IN90Â Â Â Â Â Â Â Â Â Â Â DOWEQÂ Â Â *OFF CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 :
I added the indicators on both the SETLL and READE (initially only had 90 in EQ indicator) to see where the problem was. I know for a fact that my WRKABC field has a value that has several records in my FILE. When I debug my program, after the SETLL, 50, 60 and 70 are off. (Shouldn't 70 be on?) After the READE - 90 is on, but I think should be off. When I look to see what record it is reading, it is pointing at the first record AFTER this match: Example: WRKABC = 'A1234' FILE has: A1234 12847258 A1234 38356738 A1234 49384678 A1234 78793867 A1235 94849687 <---- job shows it is on this record Any idea what is happening? I am concerned because we have several existing programs that use these 2 operations. Â
Software/Hardware used:
Iseries OS = V6R1M0
ABCKEY     KLIST                 KFLD         WRKABC (this has a value that I know has at least 1 record in my external file)                                                                         (indicators)
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â ABCKEYÂ Â Â Â Â Â Â Â SETLLÂ Â Â Â Â Â FILEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â 506070
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â ABCKEYÂ Â Â Â Â Â Â Â READEÂ Â Â Â Â FILEÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 8090
CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â *IN90Â Â Â Â Â Â Â Â Â Â Â DOWEQÂ Â Â *OFF CÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 :
I added the indicators on both the SETLL and READE (initially only had 90 in EQ indicator) to see where the problem was. I know for a fact that my WRKABC field has a value that has several records in my FILE. When I debug my program, after the SETLL, 50, 60 and 70 are off. (Shouldn't 70 be on?) After the READE - 90 is on, but I think should be off. When I look to see what record it is reading, it is pointing at the first record AFTER this match: Example: WRKABC = 'A1234' FILE has: A1234 12847258 A1234 38356738 A1234 49384678 A1234 78793867 A1235 94849687 <---- job shows it is on this record Any idea what is happening? I am concerned because we have several existing programs that use these 2 operations. Â
Software/Hardware used:
Iseries OS = V6R1M0
ASKED:
December 8, 2011 8:10 PM
UPDATED:
February 28, 2012 3:23 PM
Answer Wiki:
I figured out the problem. It was my data. In my FILE, my field is defined as 7A, but the value I am searching on is only 5 char. For some reason, when I transferred my data into the file, pos 6 of that field was not a 40. So, in hex, it didn't match up.
To see all answers submitted to the Answer Wiki: View Answer History.
Silly question — but it’s all I got
ABCKEY only has one KFLD defined?
Phil
I read FILE twice using 2 keys – once with just 1 field, then again with both. I assign different hold codes based on 2 scenarios.
And the ABCKEY has only one KFLD?
I did update the question earlier today. It was a data issue. Can you see my answer?
To answer your question, yes. I have 2 keys – one has only 1 field in it (1st in the file); 2nd key has both fields in it (they match the 2 fields in my file).
For that line of code under the circumstances that you describe in your ‘answer’, it makes sense that none of the indicators came on. I was going to ask about the definitions of the fields because there seemed to be only one possibility — that WRKABC was not a 5-character field.
*IN50 didn’t come on because the search key value was not “greater than the highest key or relative record number in the file.”
*IN60 didn’t come on because there was no error.
*IN70 didn’t come on because the search key didn’t match an actual key in the file.
Then for the READE, *IN90 came on because the key of the record it was positioned on was greater than the search key.
Your finding that non-blank characters existed in the key fields fits everything. Good job tracking it down.
Tom
Thanks for the feedback.
Phil
yes, good job tracking it down, and especially for coming back and updating us with what you discovered.