Re:No SHRUPD but still file locked--->changing S36 options -- MIDRANGE-L

Hello, all:

Various techniques to avoid OS record locks have been around for many
years, on the S/3x, AS/400, and mainframes.

The "IBM System/36 Concepts and Programmers Guide" (SC21-9019) has a
section devoted to avoiding record locks.

The "big idea" is to read a record, save the fields in other working storage
fields or a data structure, and then immediately release the record lock,
before
performing any workstation I/O, so the program does not hold onto any record
lock for more than a few milliseconds.

Then, after the display of any record update screen, you read the record
again,
compare the values with the saved values, and if the record has not changed,
copy the new values (from the screen fields) and update the record.
Otherwise,
release the record lock, display a message to tell the user someone else has
updated the same record, and ask them to "try again" and repeat the process.

If you want to avoid having to save all the fields each time, and you can
add a
new field to each file that needs to avoid record locks ("soft" record
locking),
just add one field, of say one or two bytes, at the end of the record, and
let's
say we call this field UPD@ID for "update ID". It can be used as a binary or
zoned or packed decimal number. The idea is, when you read a record, you
save the current value in this field, then immediately release the record
lock.
After any screen I/O to update the record, read the record again (to lock
it),
and compare the saved value of UPD@ID with the current value. So long as
the saved and current UPD@ID values are the same, it is "safe" to update the
record; copy the values from the screen to the record and update it.
Otherwise,
as before, release the record lock and inform the user that someone else has
updated the record and ask them to try again, and repeat the whole process.
Also, whenever you update a record, you MUST be sure to increment the
value contained in this field, and allow for "overflow" -- if it reaches the
maximum value that will "fit" in the field, reset it to zero again (allow it
to
simply "wrap around").

In RPG II, apparently, the "trick" to releasing a record lock is to declare
an
O-spec for say, @RLSx which has no fields defined, and do an EXCPT to
this O-spec - that will release the record lock without doing any I/O to the
file. To update the record, you would use the usual O-spec with fields,
e.g.:

    FFILEA    UC    512R 7A1    4 DISK
    ...
    OFILEA   E                @RLSA
    ...
    C            EXCPT@RLSA

(It may make it easier to modify your existing RPG II programs if you can
isolate the actual I/O to your files in subroutines, and use EXSR to
actually
call the relevant "READA" or "UPDA" subroutines...)

If you can find older copies of News34/38 magazine, you will find some
articles that describe this technique in more detail. Or, try the book:

    News 3X/400 Desktop Guide to the S/36, from Penton Technology Media,
    (formerly Duke Press or 29th Street Press) ISBN 0-9628743-5-3

See also:
    "S/36 Power Tools", also from Penton, ISBN 0-9628743-0-2, which has
    a utility to display what users/jobs are holding record locks on what
files,
    with source code published in the book. If you are really lucky, you may
    find a copy (around the office or in a library) with the diskette
containing
    the source code in machine-readable form. ;-)

They may be "out of print" now, so you may need to check with local
libraries,
etc., or ask around the office.

Hope that helps,

Mark S. Waterbury

----- Original Message -----
> From: "Shields, Ken" <kenshields@xxxxxxx>
> To: "'Midrange Mailing LIst'" <Midrange-L@xxxxxxxxxxxx>
> Sent: Friday, January 23, 2004 8:28 AM
> Subject: Re:No SHRUPD but still file locked--->changing S36 options
>

> File 'deadlock' situations were common on the S36, and all the parameters
in the world will not change the functional
> shortcomings in the 36EE or M36 environments.
>
> What you must do to avoid these scenarios in the 36 environment, is , for
Files opened for update,
> on every random read of the file, build your own 'unlock' procedure, which
simply does a random read on the file
> based on a non existent key.
> ......
> What would typically happen, and this was an Achilles heel in the /36 ,
was one operator would open a
> Customer master for update, say customer 001, (walk away for a coffee),
while another operator would
> key in the same customer for another function.
> Both processes would 'lock' up.
>   It was a rare occurrence, but depending on the activity going on at the
time, could be a huge headache..
> Of course, clearing up one problem, now introduces other problems of data
integrity, etc....
> The inherent intelligence in the Operating systems since the /36 days, has
been vastly improved.
>
> I personally don't believe for a minute that checking off an option to
share files in this environment works.
> and it can be tested, to wit, you already checked of shared files using
CHGS36!.
>
>
> Ken Shields
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>