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

By: TomLiotta

TomLiotta — Fri, 01 Mar 2013 02:01:37 +0000

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

By: aceofdelts

aceofdelts — Thu, 28 Feb 2013 17:45:24 +0000

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.

By: philpl1jb

philpl1jb — Mon, 25 Feb 2013 14:34:21 +0000

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.

By: SemiTechieGeo

SemiTechieGeo — Mon, 25 Feb 2013 13:25:55 +0000

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.

By: TomLiotta

TomLiotta — Sat, 23 Feb 2013 22:33:45 +0000

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

By: philpl1jb

philpl1jb — Sat, 23 Feb 2013 16:49:24 +0000

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.

By: philpl1jb

philpl1jb — Sat, 23 Feb 2013 16:45:12 +0000

Or the logicals could be in different libraries for each office and the user library list determines what rows they see.

By: philpl1jb

philpl1jb — Sat, 23 Feb 2013 16:43:26 +0000

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.

By: SemiTechieGeo

SemiTechieGeo — Sat, 23 Feb 2013 16:05:51 +0000

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.

By: philpl1jb

philpl1jb — Sat, 23 Feb 2013 13:56:04 +0000

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.