So, you need to determine if the contending lock that's being held can be
released safely (I'm assuming not since you previously stated that all the
program's locks are released after updates). If the contending lock can be
released safely, then just do the DBUNLOCK, however, if you need the lock in
force (the update for which the lock is being held is not yet complete),
then you may be able to add your lock after the contending update and
unlock completes, or you may be able to add your lock into the lock
qualifier of the contending lock (if one exists), so that it is done at the
same time the contending lock is issued. If you can't steer clear of (or
around) the current lock, you can add MR to your link of the program, but
do be careful using this (DEADLOCKS can occur, so set deadlock detect on for
the DB if possible).
Well, I hope I haven't confused you more...let me know if you need more
help.
Ray Shahan
"There is so much good in the worst of us,
and so much bad in the best of us,
that it behooves none of us
to talk about the rest of us"
--Robert Louis Stevenson?
> -----Original Message-----
> From: King, John [SMTP:[log in to unmask]]
> Sent: Monday, December 22, 2003 4:29 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] COBOL locking error plain text
>
> Ray Shahan wrote
>
> One way to find the locking error is to put an ACCEPT statement
> prior to your DBLOCK. This will force the program into a pause, Then
> use DBUTIL to determine what lock is in effect for your program (SHOW
> DBNAME LOCKS (where you replace the DBNAME with each DB you have opened
> in your program)). This will show you which DB(s) have the lock in
> force, so you can more easily debug the code.
>
> ------------------------------------------------------------------------
> -----------
> I did what you advised, and put an ACCEPT just before the lock. DBUTIL
> showed one dataset locked in a different database. The locksizelevel
> is set at 6. The program I am testing is a WDS online program using
> forms. It does use another in house database, doing locking at MODE 5,
> and updating existing records.
>
>
> John King
> Programmer Analyst
> GKN Aerospace Chem-tronics
> [log in to unmask]
>
> WARNING- This document may contain technical data whose export is
> restricted by the Arms Export Control Act (Title 22, U.S.C., SEQ 2751 ET
> SEQ) or the Export Administration Act (Title 50, U.S.C., APP 2401-2420).
> Violations of these export laws are subject to severe criminal penalties.
> This e-mail is strictly confidential and intended solely for the
> addressee. It may contain information which is covered by legal,
> professional, or other privilege. If you are not the intended addressee
> you must not use, disclose, or copy this transmission. This E-mail is not
> intended to impose nor shall it be construed as imposing any legally
> binding obligation upon GKN Aerospace Chem-tronics Inc. and/or any of its
> subsidiaries or associated companies. Neither GKN Aerospace Chem-tronics
> Inc. nor any of its subsidiaries or associated companies gives any
> representation or warranty as to the accuracy or completeness of the
> contents of this E-mail. GKN Aerospace Chem-tronics Inc. shall not be held
> liable to any person resulting from the use of any information contained
> in this E-mail and shall not be liable to any person who acts or omits to
> do anything in reliance upon it.
>
> N^SySly...?+ޱZzSlzbz
> ey +"mj vb??Ia
>
>
> ========================================================================
> This e-mail message has been scanned for Viruses and Content and cleared
> by School Specialty's email filtering solution.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
