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.

5 pts.
Tags:
Application development
AS/400
RPG
RPGLE
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.

Answer Wiki

Thanks. We'll let you know when a new response is added.

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

Discuss This Question: 16  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
  • Dynamic
    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.
    0 pointsBadges:
    report
  • BigKat
    also check to see if the logical you are using has any select/omits on it.
    7,935 pointsBadges:
    report
  • Arosmus
    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.
    0 pointsBadges:
    report
  • Vatchy
    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.
    1,410 pointsBadges:
    report
  • BXSGolfer
    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.
    0 pointsBadges:
    report
  • Serg1u
    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?
    0 pointsBadges:
    report
  • StanZG
    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.
    0 pointsBadges:
    report
  • Ddune3566
    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.
    0 pointsBadges:
    report
  • Michlw
    Are you debugging interactive, if so press F21 while debugging and check the file in this case. Check library list Check for OPNQRYFILE
    30 pointsBadges:
    report
  • Kbarnette
    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.
    0 pointsBadges:
    report
  • Atgidm
    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.
    0 pointsBadges:
    report
  • BobbyS40
    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.
    10 pointsBadges:
    report
  • BobbyS40
    oops - I meant update not input.
    10 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Supriyob2
    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..
    165 pointsBadges:
    report
  • 9053303479
    JUST HAD THIS PROBLEM. I WAS MISSING THE K( KEYED) FILE IN THE F SPECS. THOUGHT I WOULD PASS THIS ALONG
    10 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