Retrieval Lock Removal - Process and Benefits

[Margaret Sliming]

The following email explains the process of removing retrieval locks from an update dialog that was being executed 200,000 per day.  If anyone wants to try this on one of your high usage dialogs, I will be happy to help with the coding.  You will see the results immediately without paying a dime.  Keep in mind also, many programs were written by inexperienced programmers.  Those that are running long, compare database I/O to input I/O.  If the database I/O is many times larger, the access path may need to be changed.  I reduced the runtime of a program from 17 hours to one hour by changing the access path.

Feel free to reach out if you have any questions.

From: "Rozeboom, Kay [DAS]" <[e-mail]>
To: <[e-mail]>

Subject: Retrieval Locks - a success story

Date: Tuesday, January 24, 2006 8:35 AM 

I am passing on a success story from one of our applications groups.

This one small change reduced our total daytime mainframe CPU use by 5%.

I would like to join Scott in thanking Margaret Sliming for the

suggestion.

 

> ______________________________________________

> From:         [e-mail] [mailto:[e-mail]]

>

> Sent: Monday, January 23, 2006 2:33 PM

> To:   Rozeboom, Kay [DAS]

> Subject:      Retrieval Locks

>

> During our current cost savings/tuning initiative we took advantage of

> Margaret Sliming's experience with the use, or in this case the non

> use, of Retrieval Locks, and have a success story to report.

>

> We had a dialog that we knew was used 98% of time as a retrieval only

> dialog.  This dialog was using an update subschema and retrieval

> locking basically for the other 2%.  We moved the updating functions

> of the dialog to a separate dialog which we link to when needed.  We

> also modified the original dialog to use a retrieval subschema and

> turned the retrieval locks off.  The resulting CPU savings has been

> dramatic.  The CPU time used by the dialog has been cut in half.  (.02

> seconds before .01 after)  it doesn't seem like much but the number of

> executions per day is right at 200,000 so we are very happy.

>

> Thank you Margaret for you help and encouragement.  This has been a

> painless way to help our system load and save our department some

> money. 

 

 

-------------------------------------------

[Margaret Sliming]

One requirement not mentioned in the email is that when linking to the update dialog, a 'LINK NOSAVE' is required so currencies aren't passed to the update dialog.  Instead, you have to pass the record keys to the update dialog and reestablish currency there.

For those who did not work with IDMS prior to Release 12.0 / around 1992, Retrieval locks have always been there.

I went from a company that was still on Release 10.0 to one on release 12.0 and that's how I discovered the problem because I had started coding my dialogs the suggested way two years prior.  When I got a bizarre error about an application thread, I called Computer Associates.  
The very young man I spoke with told me they thought they were fixing a bug (I'm sure IBM had to be involved) with their 'dirty read' terror threats.  It caused deadlocks but with the wrong error codes.  We were getting the feared '0361' error on deadlocks.  Most of the symptoms are gone but IDMS has slowed considerably.  I'm guessing architecture for IDMS now includes a restart program like IBM's Program Restart Facility (PRF) which slows things even more. This 'feature' locks every record it touches that updates are performed on, not just the record actually being updated. Also, it's the whole page that gets locked and not just the record.  This keeps other run units from accessing totally different records on the locked page. Pretty soon deadlocks start occurring, jobs are backing up and the online applications come to a crawl.  If you are experiencing any of these symptoms call me.  I've been an IDMS developer for almost 40 years so I've actually debugged these problems in DB2 and IMS as well as IDMS.  I helped the State of Iowa for free and will help you also.  However, it's twenty years later and I could really use help with some contributions to my retirement fund.  Also, I can train your developers while we're fixing problems.  

-------------------------------------------

[Felicia Collins]

Great connection Margaret!

Please feel free to contact me for any Education/Training opportunities on this. 

Felicia Collins, Instructional Designer III

Texas | USA

-------------------------------------------