When doing a chain the (HI) indicator return with ’1′. But if I do a query on the same file I can see that the record is in the file.
I have a program in RPGIII.
In the production environment the users are getting the following error message: RPG1221: (Issued update or delete in SDFBOBS0 without prior READ or CHAIN). I thought i shall put this program in my test environment and try to do the same as what the users have done in the production environment. It was a surprise for me that i didn't get the message RPG1221. Ok I thought I shall debug this programm. There i get another surprise. When doing a chain the (HI)indicator return with '1'. But if I do a query on the same file I can see that the record is in the file. How is this possible that the result of my CHAIN assumes that the record is not found and that the record is there in the file. Help. Greetings Inse.
Software/Hardware used:
Software/Hardware used:
ASKED:
August 29, 2006 11:01 AM
UPDATED:
April 26, 2012 4:05 PM
Answer Wiki:
A few thoughts come to mind, although without seeing the code, it's hard to know for sure.
1. Have you checked the values in the fields that make up the key list used to chain to this file? Perhaps one or more of the fields in the key list is not being loaded with the value you expect it to have.
2. Another possibility is that the fields in the key list could be in the wrong order. That is possible if you have multiple key fields that have the same size and attributes and they are simply specified in the wrong order in the KLIST.
3. Also, since your error is on an attempt to update, it could be that you are chaining with the correct key values but not moving those values into the corresponding fields in the file when you write the record.
4. Then there is the question of whether the write or update is conditioned by the chain resulting indicator being off or on. It should only write if the indicator is on and update if it is off.
Those are just a few ideas. If none of these are the problem, perhaps you could post enough of the code to help us see what the calcs are doing.
Hope this helps,
Teresa
To see all answers submitted to the Answer Wiki: View Answer History.
Assuming that there is no programming error, apply latest PTFs with database and Hypers. Try RPG free, much more fun to code. Best of luck.
also check to see if the logical you are using has any select/omits on it.
Is the file you are chaining to a logical file? If so, it could contain record selection (Include or omit) criteria that excludes the desired record from the file, and therefore results in a not-found condition when you chain — the record exists in the physical file, but does not match the criteria for the logical.
The first thought that comes to my mind is to check your library list. You need to make sure that you are looking at the exact same file in the exact same library at which your users are looking.
A similar thing happened to my coworker about a month ago. The program did a chain via a partial key list and failed to get the record. The key list was set up properly, the logical had no select/omit criteria, it was pointing to the correct library, but failed to get the record, even though the record existed and could be viewed via DBU through the logical being used. We took the code in question into a separate source member, compiled it, ran it, and it worked as intended. We ended up having to program around it.
Check for file overrides.
The file being chained to may not be the actual file you think .
Also, are you sure that the file has K (keyed) in the file spec?
One more shot in the dark. If you have I specs check for any indicators there. I have seen a record indicator coded the same as a chain indicator causing this kind of problem. Change the code to %Found(FileName) and see if this doesn’t fix it.
This happended to a co-worker many years ago.
He chained to a file and it did not get a hit.
The key was setup correctly
We used dbu to look for the record and it was there.
After some time we relised that 1 of the fields that was blank had a hexidecial code of a special character that could not be displayed on the screen and therefore showed as blank. This must have been keyed in by a user and they fat fingerd the keys when entering the data.
Are you debugging interactive, if so press F21 while debugging and check the file in this case.
Check library list
Check for OPNQRYFILE
There is one more consideration. If the programs is writing the record in question; and then the program chains for it soon after to see if it already exists, then the issue could be the system is not writing the output buffer to disk. If this is the case, then set force write ratio to 1 for the file. This forces the system to write the record immed. to disk so it can be found with additional chains to the file.
Setting the force write ratio to 1 will work but this affects every time records are written to this file while trying to overcome one problem in one RPG program, so depending on how many other applications are writing to the file could affect system performance. There is an opcode FEOD(force end of data) which having after your WRITE opcode forces the record to be written to the disk so it does not get buffered and a subsequent chain would then find the record.
Did you check the indicator before the chain. Had this happen many years ago on the Sys36. Turned out the file was defined Input Demand and not Input Full procedural. The Demand option does NOT turn off indicator if chain succesful.
oops – I meant update not input.
Since it’s RPGIII, there is no %FOUND bif, nor can it be coded /free style.
The suggestion to check record ID indicator is good, but it should cause the indicator to be on more often. Still, a detail check through the program to ensure that nothing else can set that indicator on is the best idea so far.
Tom
Hi..
I think it can be because of
1. pgm is not referring to the correct version of the file in the library.
2.The key sequence is not in order..
JUST HAD THIS PROBLEM. I WAS MISSING THE K( KEYED) FILE IN THE F SPECS.
THOUGHT I WOULD PASS THIS ALONG