Monitor for Record Lock Condition

[NYCountryGal]

Okay I have question ... but before you all "holler" at me to check the forum - I did already which is why I'm asking the question.

Here's the problem first: I have a batch program that updates fields in a master file from our imaging system. Occasionally, we get record locks because one of the users is looking at an image when the update program goes to update the fields (the image index fields).

I want to monitor for the record lock condition and have the program retry the update but upon searching the forum - I'm second guessing myself. With a batch program when you have a record lock - what's the best way to handle the issue?

[MichaelCatalani]

Re: Monitor for Record Lock Condition

You have several options, but I'm wondering why a record would be locked for the entire time a user is viewing an image? I would probably opt to look at changing that first, if possible. In other words, does the record really need to be locked and held for the duration of the image viewing process?

[NYCountryGal]

Re: Monitor for Record Lock Condition

I honestly didn't think about that but I can tell you why --- in the document imaging package we use, when the user goes in to view the image they have the ability to manually update the same fields - if they have been granted the authority to do so.

And, we don't have the source for the software package so I can't make any changes. But just you asking your question has gotten me thinking and I need to add a couple of "checks and balances" to my update program and the issue will go away on its own.

Thanks for helping.... I knew I just needed to bounce this off someone else.

[MichaelCatalani]

Re: Monitor for Record Lock Condition

No problem, the reason I brought it up is because it will become more and more of an issue over time. One of the things I loathe is to have a record "locked" for an unspecified period of time. And any time we are dependant upon a user, it becomes an unspecified amount of time.

[jamief]

Re: Monitor for Record Lock Condition

take a peek here....

http://www.code400.com/locked.php

jamie

[B.Hauser]

Re: Monitor for Record Lock Condition

Just try the following:

  /Free
     DoU %Status <> 1218
         Chain(E) (Key1: Key2 ...) MyFileF;
     EndDo;
     
  /End-Free

Status 1218 = Record Lock.
If an error occurs %Error and %Status are updated at least if the previous RPG statement has an extender (E).
This little loop tries to read/chain the record until it will be free and can be accessed.
DoU checks the condition at the end of the loop.

Birgitta

[Billw]

Re: Monitor for Record Lock Condition

Perhaps take this loop a little further and tell someone if the program is waiting on a record:

 /Free
     DoU %Status <> 1218
         Chain(E) (Key1: Key2 ...) MyFileF;
          If %Status = 1218;
              Cnd =+ 1;
                 If Cnt = 1 or Cnt =-15;
                     SndQsysMsg("Record locked in program xxx for file yyyyy");
                 Endif;
           Endif;
     EndDo;
     
  /End-Free 

[MichaelCatalani]

Re: Monitor for Record Lock Condition

And just in case the file Record Wait Time has been changed or overridden to *IMMED, I like to include a short pause in the program right after receiving a record lock condition, and before checking for it again. This keeps the program from burning a lot of CPU time by looping without pausing in case the file's record wait time is set to *Immed.

  /Free
     DoU %Status <> 1218
         Chain(E) (Key1: Key2 ...) MyFileF;
[COLOR=red]        if %status =1218;[/COLOR]
[COLOR=red]          Time_DelayJobUntil( %time + %seconds( 1 ) );[/COLOR]
[COLOR=red]        endif;[/COLOR]
     EndDo;
 
  /End-Free

The above code pauses the program for one second if a record lock is encountered.

This function can be found here: http://provatosys.com/TimeFunctions.html

[JonBoy]

Re: Monitor for Record Lock Condition

Might be a nice idea with all of these lock check loops to actually have some limit in there on the number of times to retry. Otherwise you can loop in there forever - or what will feel like it. Always a bad idea to hold a lock while data is displayed for update for just this reason. Operator pulls up record for update and goes off for coffee, meets friend in kitchen, chats for 10, decides it is time for a bathroom break ...

[jamief]

Re: Monitor for Record Lock Condition

@jon - I can see some of that happening but here we dont allow anyone to becomes friends..we have closed the kitchen to employees, no one is allowed to make eye contact and pee on your own time at home or starbucks!

[MichaelCatalani]

Re: Monitor for Record Lock Condition

@jon - I can see some of that happening but here we dont allow anyone to becomes friends..we have closed the kitchen to employees, no one is allowed to make eye contact and pee on your own time at home or starbucks!

If you guys are going to be that strict, then you should also outfit your users with electro-shock devices. Then, if they hold a record lock for too long, execute the electro shock service program:

Electro_SendShock( User );

[tomholden]

Re: Monitor for Record Lock Condition

If you guys are going to be that strict, then you should also outfit your users with electro-shock devices. Then, if they hold a record lock for too long, execute the electro shock service program:

Electro_SendShock( User );

wouldn't it be more aptly named Send_ElectroShock()???

[MichaelCatalani]

Re: Monitor for Record Lock Condition

wouldn't it be more aptly named Send_ElectroShock()???

I thought about that, but I have other functions in the Send service program that I allow anyone else to use. I have the Electro service program locked down so that only I can access it. It loses all the fun and usefulness as a training tool if just anyone can call it.

[kitvb1]

Re: Monitor for Record Lock Condition

Infor's System 21 has a pop-up window that appears (on the majority of pgms, but not all) and displays the user name of the person locking it and from when. Just an idea...

[kausix777]

Re: Monitor for Record Lock Condition

I thought about that, but I have other functions in the Send service program that I allow anyone else to use. I have the Electro service program locked down so that only I can access it. It loses all the fun and usefulness as a training tool if just anyone can call it.

I'm sure a SOFT electric shock (in the form of a BIG, BAD window message) can be given if the record is held for a pre-specified period of time.