RPGLE SETLL / READE for update getting record lock on different key

70 pts.
Tags:
READE
Record lock
RPGLE
We are encountering sporadic unexpected record locks with update files using: setll (Key1) MasterFile; // Partial key. dou %eof(MasterFile); reade (Key1) MasterFile; if not %eof(MasterFile); // [Stuff] update MasterFmt; endif; enddo; Looking at the problem record by RRN, its key does not match Key1. It's not even the next sequential key value in the file. We are fixing programs as the locks appear by using: setll (Key1) MasterFile; // Partial key. dou %eof(MasterFile); reade(N) (Key1) MasterFile; if not %eof(MasterFile); chain (Key1 : Key2) MasterFile; // Full unique key. // [Stuff] update MasterFmt; endif; enddo; We are using V7R1. The manual (SC09-2508-08) says "occasionally a READE operation will be forced to wait for a temporary record lock for a record whose key value does not match the search argument." We would prefer something a bit more predictable. We've had -no- success duplicating the problem in a controlled test environment. The challenge is that we have 20+ years of legacy code, new programs being written in the typical style of the first example, and hundreds of users. We've only recently added logic to log the locks, so we don't know how long it's been happening. We see at least one each day. Any insight that would help us avoid updating all of our update programs and retraining our staff would be appreciated. [HOW DOES ONE GET THIS TO DISPLAY WITH LINE BREAKS???]

Software/Hardware used:
ISeries V7R1, RPGLE

Answer Wiki

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

REPOSTED IN EDITOR TO FORMAT TEXT:


We are encountering sporadic unexpected record locks with update files using:

setll (Key1) MasterFile; // Partial key.
dou %eof(MasterFile);
reade (Key1) MasterFile;
if not %eof(MasterFile);
// [Stuff]
update MasterFmt;
endif;
enddo;

Looking at the problem record by RRN, its key does not match Key1. It’s not even the next sequential key value in the file. We are fixing programs as the locks appear by using: 

setll (Key1) MasterFile; // Partial key.
dou %eof(MasterFile);
reade(N) (Key1) MasterFile;
if not %eof(MasterFile);
chain (Key1 : Key2) MasterFile; // Full unique key.
// [Stuff]
update MasterFmt;
endif;
enddo;

We are using V7R1. The manual (SC09-2508-08) says “occasionally a READE operation will be forced to wait for a temporary record lock for a record whose key value does not match the search argument.” We would prefer something a bit more predictable.


We’ve had -no- success duplicating the problem in a controlled test environment.


The challenge is that we have 20+ years of legacy code, new programs being written in the typical style of the first example, and hundreds of users.


We’ve only recently started logging the locks, so we don’t know how long it’s been happening. We see at least one each day.


Any insight that would help us avoid updating all of our update programs and retraining our staff would be appreciated.

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
  • philpl1jb
    I don't believe there is anything wrong with your original code.  Also, I don't believe that your fix improves the issue.  In my experience either this job or some other job has locked a record that this program is trying to access throough some access path. 
    50,425 pointsBadges:
    report
  • TomLiotta
    The problem is not clear. Are you showing us the code that causes the lock or the code that has trouble because it runs into a lock? That is, does this code fail or does some other program fail because of this code? -- Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    It's very odd, I had no idea 7.1 had this issue.  
    
    ahhh here's some more about READE  
    
    For duplicate keyed files, the ILE RPG language performs 
    a READ NEXT operation and compares the key of the 
    returned record to determine if the record qualifies. 
    If so, the record is returned to the program; 
    if not, an end-of-file indication is returned  
    
    So your fix is the recommended fix in the manual..
    I think you need to contact IBM and see if they have a fix 
    coming out.  I don't believe that this was the way previous
    versions worked.
    50,425 pointsBadges:
    report
  • TomLiotta
    The same issue is in earlier releases, though the documentation wording has changed. In V5R3, for example, the word "occasionally" is not included. The implication would be that it always happened in the past, but now it only happens "occasionally". I asked about what program sees the error because it wasn't clear if the 'temporary' lock was seen to interfere with another program or if this.program was reporting that it was unable to set the 'temporary' lock. -- Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    I agree, though, that checking with IBM is a good idea. If the behavior really changed in 7.1, then related PTFs might already exist. If not, one might need to be created. -- Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Wow -- there's a lot of bad code out there .. I've certainly created my share.Always thought that READE was a database function .. instead of a shortcut for a READ and an RPG compare.
    50,425 pointsBadges:
    report
  • philpl1jb
    oddly enough I ran into problems a few versions ago with READ(N) where it appeared that the process was actually a read with lock followed by an unlock.  At that time READ(N) would get record locks.  Obviously, IBM doesn't think that's the case, since they recommend a READE(N) in the solution to the locked record case.
    50,425 pointsBadges:
    report
  • SemiTechieGeo
    Thanks for your help.  We'll follow-up with IBM as suggested. To answer a couple of questions...The first code sample is typical of what encounters a lock.  The joblog identifies the locked RRN.  The record turns out to have a non-matching key.  Logging shows that the second code sample resolves the problem.  (We see no new unexpected log entries for a given program after it is revised.)  It is consistent with the manual, but the idea of fixing 20+ years of programs is daunting.  Maybe we've just been coding wrong for our entire careers and didn't realize it.  Maybe that is the question I'm really asking.It has become an issue because we have branch offices in several states.  Many of our programs monitor for locks and display a message when one occurs, giving the user the opportunity to retry. Legitimate locks typically happen within a single branch and users can sort them out without calling the help-desk. A problem scenario goes like this:  Ohio calls to report that Florida has an Ohio account locked.  Ohio wants to know what Florida is up to.  Looking at the specific RRN, the record is a Florida account with completely different key values.  Using a service job to debug the Ohio program, we see nothing odd -- the READE key values match the Ohio account.  We can't understand why it wants the Florida record. Florida releases the lock, Ohio retries, the READE completes, and EOF is on.  (Again, consistent with what the manual says can happen occasionally, but something we don't recall having issues with.)Maybe it has to do with sheer volume.  Our main order-entry driver is called about 10,000 time per day on average.  Unexpected locks within that system occur between 1 and 10 times a day.  Even at once per day, it's not fun trying to reassure Ohio that Florida is innocent.
    70 pointsBadges:
    report
  • philpl1jb
    That's consistant with the manual .. it reads the last record of the set, processes that record and then attempts to read the next record in the file which it will then discard as the wrong key.One answer (also lousy maybe worse) .. logical files - one for each office .. and override to the logical.  Since the logical selects only for the records of that office it reaches EOF, instead of trying to get the record from a different office.
    50,425 pointsBadges:
    report
  • philpl1jb
    Or the logicals could be in different libraries for each office and the user library list determines what rows they see.
    50,425 pointsBadges:
    report
  • philpl1jb
    Change the names of the physical filesCreate logical files with the original name of each physical file in each office library and a select to just that offices data.  Logicals must have same format as physical.Programs won't need to be changed at all, no overrides will be necessary.
    50,425 pointsBadges:
    report
  • TomLiotta
    Looking at the specific RRN, the record is a Florida account with completely different key values.   Can you describe the specific steps involved in going through that process? Include steps that can and cannot be automated. There might be a way to handle the non-automated steps that could be acceptable to users with condition handlers. A little creative designing might allow insertion into job streams with limited code changes.   Tom
    125,585 pointsBadges:
    report
  • SemiTechieGeo
    Thanks again.  
    
    What we are seeing appears to be a fact-of-life for RPG programming as described in the manual.
    
    We wish we better understood what causes those -occasional- occurrences.   We will try to learn what we can from IBM.
    
    At this point, we plan to revise programs as they appear in the logs. 
    70 pointsBadges:
    report
  • philpl1jb
    From the various things we've gathered, I would be looking for a lock on the very first record of the next key.  But I would thnk that you would have already discovered that .. if that's what is happening.
    50,425 pointsBadges:
    report
  • aceofdelts
    I think you could lessen the problem if you could resequence your data (I'm not trying it now, but I believe RGZPFM will physically resequence). So doesn't fix anything but might give you fewer of the errant locks.
    1,930 pointsBadges:
    report
  • TomLiotta
    The problem doesn't seem related to physical sequence. The code indicates (partial) key, so access is for indexed sequence. It does seem odd, though. Why does RPG need a 'record' when it has access to the 'index'? The index entry should be enough for RPG (via DB2) to know that it shouldn't even try to read the non-matching record. Too bad we don't have a DB2 internal developer here. Is this an index on the physical file or from a logical file? -- Tom
    125,585 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