Re: WRKOBJLCK automated API ?

[Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>]

I used to do something almost exactly like what you want to do,
Al, but it was on a PC in dBase.  Basically, any call to read a
record went through a subprocedure.  The subprocedure would try
to read the record, setting on locking or not as it was called.

At any time the record was retrieved, the subprocedure would
return with a success flag (0).  If the record was locked, the
subprocedures would display a message to the user such as,
"Record in use, retrying.  Press <Esc> to abort..." and in one
second it would try to read the record again.  The user could
hit <Esc> to abort the try which would return a failure status
to the calling program (1).

I've tried to think of ways to implement this in RPG, and can
think of a few ways, but the biggest problem I see is how to trap
the error condition in the RPG program itself.  I can now see
how to do this pretty much.  Use the error Subroutine to trap
the error condition.  SNDPGMMSG to send a message to the user
that it is retrying.

Things I haven't figured out yet:

How to get the user input to abort the read attempt without 
modifying the program extensively.

What to do in batch jobs if the record remains locked after
an excessive amount of time ( over 1 minute? ).  Thinking of
sending an inquiry message to QSYSOPR waiting for a reply.
Doing this would be a bit of work and would definitely go into
my service programs.  Send message, then loop waiting for 
reply whether to try again or not.

All this could be done in RPG, but it would be a bit of work.  Once
it's written, however, and all the fine points are worked out it
is something that could quickly be added to new programs and even
introduced to old ones.

Also, it would be possible, I assume, to use the APIs to display
what user has the record locked if the user wants to know (perhaps
"Record locked, retrying... Press <F12> to abort, Press <F1) to 
display lock...".  I guess you could always find out who has the
record locked before you even display the message, "User SOANDSO
has record locked..." but I'm not sure I would want to add that
additional processing time to the program if there are going to
be a lot of records locked.

HTH

Jim Langston

<SNIP>

This is not urgent, more like brain storming.  I have some software to
modify, to enhance what it is doing in the form of features, new data
capturing, less hassles for users & so forth, and one worrysome situation
is
risk of conflict updating a heavily used file.  I would like my next
modifications to handle that situation more gracefully.

What happens today is that there is lock up because two people are trying
to
update the same file at the same time, and the end user messages are not
friendly informative.  At best we are told that some other unspecified user

is updating a record in a specific file that this one needs, & usually does

not give a clue as to which one, & when it does it gives record # of the
file, when our users think of the data by item # order # etc., and then
manual usage of WRKOBJLCK to locate who that is can be a royal pain.

Finally we figure out who is the blocking program, and get that out of the
way, then there is the issue of which of IBM's many responses is the least
harmful to the original project ... I usually take GO getin continue if it
was JOBQ & Retry if it was interactive, but tell all my helpers to use Go
because far too often they have done Retry on JOBQ after a bomb on say
transaction 500 & it retries all 500 transactions resulting in duplicate
postings.

I imagine there must be some AS/400 network & other places with examples of

source code to reduce this kind of hassle for the end users.  For the
interactive user, before trying to update some file that MIGHT have some
conflict, I would want code from RPG program to detect whether or not that
record is locked, then send user a better phrased message, including what
response code to take after resolving the case of who is blocking access.

For the batch job in this scenario, what I ideally would like to end up
with
is.

1. Program wants to update a file with a record key, but in addition to the

error message being IIML01 file it should include ITEM MASTER FILE which is

how the users identify it, and it should also say which item # it is trying

to update, in addition to wherever the system gets the record # which
apparently is the only way to communicate through WRKOBJLCK.

2. Perhaps the program that wants to update a locked record calls a
secondary
program to handle the conflict, let's call it MSGAIDIIM if the conflict is
with the IIM file, sending parameters identifying what item is to be
updated
& for what purpose.  The users might like to know the purpose so they can
decide whether to bypass this update or if it is essential to get it done.

3. MSGAIDIIM program would
   a. unless this is the first iteration, check whether the end users had
sent a certain GO message meaning, return control to the calling program
with
instructions to bypass that update.
   b. check whether access to that item is still blocked & if not, return
control to the calling program with instructions to retry the update
   c. use some API (is there one?) to identify from WRKOBJLCK or some other

LCK command precisely what program job etc. is blocking access to the
desired
item # record.
   d. only in the first iteration, create the message place that will be
checked in later iterations to see if the end users sent the GO AROUND
instruction.
   e. craft & send a message saying in effect that
the calling program / user / job needs to update item master item # for
what
purpose but
the blocking program / user / job needs to get out of the way first
can some users please arrange this, or
do whatever
to send the GO AROUND instruction
how
   this message should be sent to the user who owns the batch job that got
stuck
   this message should be sent to the user of the job doing the blocking
   this message should be sent to certain computer department personnel or
the work stations in the computer department
   the logic needs to avoid duplicates, like if the same user is on more
than
one list
   if we write such software then user or work station no longer exists on
our system, the program needs to send a message to QSECOFR or QSYSMSG what
message was tried to be sent by MSGAIDIIM to user or work station that no
longer exists so that current computer department personnel know to make
adjustments

   f if no response to first message there needs to be some loop & wait
some
reasonable time period - perhaps loop on "a & b" more rapidly than on
sending
message again, especially if the job doing the blocking changes.

Again, my need here is not urgent.
It is more that I am brainstorming some ideas.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---