Record Lock Time

[ehillbama57]

We have a job monitor program running at client sites that email us if a job is in a MSGW or a LCKW status. I'm wanting to end a job if it has been in a LCKW status for a certain amount of time. I am having a hard time determining this. I've tested using the QUSRJOBI API and using the "Time spent on database locks wait" parameter but that seems to keep sending the same value each time I run it against a job in LCKW status.

Anyone have any ideas on this one?

Thanks!!!!

[Scott Klement]

Eric,

Have you considered doing something like this to your files:

CHGPF FILE(myfile) WAITRCD(5)

This means that programs will only wait for a record lock for 5 seconds, after which they'll get an error. If you don't want to change it on the file (which would affect everything that uses that file) you could also do it with an OVRDBF... (Like any OVRDBF, you need to make sure it is in place before the file gets opened by the program, etc, etc.)

OVRDBF FILE(myfile) WAITRCD(5)

Back when I did a lot of this type of programming, I would always use small values for WAITRCD, and my programs would check for errors when reading a record in a file that's open for update. If it got an error, it would tell the user who is locking the record, and then go back and re-try. This way, my user could call whomever is locking the record and say "hey, can I get into order XYZ, you're locking it?" and work out the problems themselves without calling IT for help.

Of course, I would also try to eliminate any situation where there were record locks and didn't need to be. So locks were only used to enforce rules like "only one person can change an order at a time" (which was a business rule where I worked). So eliminate as many locks as possible, but sometimes I found locking useful -- as long as programs properly checked for locks and handled them properly.

Hope that helps.

[tomliotta]

We have a job monitor program running at client sites that email us if a job is in a MSGW or a LCKW status.

Can we see the code that does the checking? Is the "job monitor program" running in a separate job and checking multiple other jobs?

[ehillbama57]

Tom,

The program is a standalone RPG/free program that I did not write. It uses the QUSLJOB API to roll through the active jobs on our client systems to see if anything needs responses. Looks like it was actually taken from something posted here some time ago:

http://www.code400.com/forum/showthread.php/1123-Use-the-QUSLJOB-API-to-whip-thru-WRKACTJOB

I have attached the source for the program. It is quite jumbled up but I think you can see how it works:

monactjob.txt

[EmmanuelW1]

Scott Klement wrote:

"If it got an error, it would tell the user who is locking the record, and then go back and re-try. This way, my user could call whomever is locking the record and say "hey, can I get into order XYZ, you're locking it?" and work out the problems themselves without calling IT for help."

Interesting - we've developed a similar utility, except that it notifies the lock holder directly, then sends a retry to the error message after a short delay.

Also, instead of a monitor which cycles through looking for jobs in MSGW, our utility monitors the QSYSOPR message queue and reacts as above to any RNQ1218/RPG1218 messages.

Cheers,

Emmanuel

[tomliotta]

It uses the QUSLJOB API to roll through the active jobs on our client systems to see if anything needs responses.

Yes, I wanted to be sure of some details you might consider if this is running on client systems where almost anything can also be running.

I was curious for a couple reasons.

First, jobs can go into and out of both MSGW and LCKW status normally, maybe for split seconds or for a few seconds; and for those, I'd think you wouldn't want to be sending any kind of e-mail nor alert. Ideally it would only be if the status remained unchanged beyond some threshold. It's not clear how the QUSLJOB API can directly help with that. It only returns the status at the instant a job in the list is materialized, and the status could even change by the time your program gets to process the entry in the space.

For MSGW, there are (at least) two conditions that cause it. Your program should only respond to one of them. A program that is monitoring a *MSGQ, e.g., a monitor for condition messages in the QSYSMSG *MSGQ can be in MSGW status 99.999% of its run-time, but you wouldn't want any indication sent out for it. I'd think you really only want alerts sent for jobs that have been waiting for a reply to an *INQUIRY message that was sent by the job. It can take some extra code to dig the difference out of a job.