In message <[log in to unmask]>, "Atwood, Tim (DVM)"
<[log in to unmask]> writes
>This is one of those "I don't know how this ever worked in the first place"
>questions. It goes against my 20 plus year experience with Image databases
>and locking. To say the least I am confused as heck. I know how to fix it
>(and have already done so by adding a call to DBLOCK). But I would really
>like to have someone out there in HP land give me a little glimmer of hope I
>am not losing my mind. If I can't figure this out, I think I am going to
>decide I have not learned a thing in those 20+ years, pack up my bags and
>start a peach farm in the Okanogan.
>
>We have a small COBOL program. Creates a report and then updates an Image
>dataset with summary values (DBPUT).
>
>It was previously in Compatibility Mode. A minor change needed to be made.
>We have a policy of converting any program we change to Native Mode at the
>same time. So it was converted to Native Mode.
>
>Suddenly the program starts aborting "DBPUT called without covering lock in
>effect".
>
>I look at the program and dang if it ain't right - There is absolutely no
>call to "DBLOCK". Just a call to DBPUT.
>
>I look at all past versions of the program. Some seven versions extending
>back over the last six years (earlier versions archived off machine). None
>of them have a call to DBLOCK.
>
>The program is opening the database mode 1.
>
>I recompile an old version from before the change in Compatibility Mode
>adding some display statements for debug. The displays verify the database
>is being opened in mode 1. I verify this with a simple DBUTIL SHOW USERS
>while the program is running. The dataset is in fact being updated with the
>new values. So the DBPUT is in fact being executed and is working.
>
>The only calls other than to Image intrinsics are to Suprtool (Suprtool2).
>But I know of no way Suprtool2 could be locking the database for me.
>
>I recompile the program in Native Mode without the original changes. It
>immediately fails because there is not any covering lock for the DBPUT.
>
>So how the bloody 'ell did this thing ever work in the first place? Image
>locking and open mode rules are the same whether CM or NM. What the hey?
>

A real peach of a problem!

Wild guess - in CM it calls a jiggered DBPUT in some long-forgotten SL,
designed to 'simplify' Image access, and the DBPUT code applies its own
DBLOCK before calling the 'real' DBPUT.

In NM, the SL isn't utilised, and no corresponding XL exists for this
purpose.
--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *