John,
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.
HTH,
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 1:01 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] COBOL locking error plain text
>
> I've been in touch with Adager, and we confirmed the database and
> datasets are created correctly. I am using DBLOCK to lock the
> dataset in mode 3. All other calls are also DBxxx. I am having to go
> on the presumption that the dataset is being locked somehow without
> me realizing it.
>
> Thanks for all the responses.
>
> John King
> Programmer Analyst
> GKN Aerospace Chem-tronics
> [log in to unmask]
>
>
>
> -----Original Message-----
> From: Emerson, Tom [mailto:[log in to unmask]]
> Sent: Monday, December 22, 2003 10:25 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] COBOL locking error plain text
>
> > From: King, John [mailto:[log in to unmask]]
> >
> > I'm having a problem with locking a dataset in some COBOL
> > programs ... The error I keep getting is:
> >
> > TURBOIMAGE ERROR AT $00247464; RETURN STATUS = -135
> > DBLOCK, MODE 3, ON TABLE-NAME OF SUNLDX.CURRENT
> > DBLOCK CALLED WHEN LOCKS ALREADY IN EFFECT
>
> What "mode" was the database opened with? some of the modes lock the
> entire database for the duration, so locking is unnecessary.
>
> Secondly, are you REALLY calling the DBxxx intrinsics directly, or are
> you passing them through a "wrapper" layer? (i.e., boilerplate code /
> copylib entries / etc) Could one of these "layers" be doing the locking
> on your behalf? [try the put/update without explicitly locking -- do
> you get the error "...called without covering locks"?]
>
> Finally, could there be a "wrapper" layer in an XL or SL?
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> 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 *
|
