Re: DLCOBJ not releasing a member

On 13-Dec-2013 15:06 -0800, Horn, Jim wrote:

In a cl program, I am issuing the following command to lock a member
in a file. In case it matters the srctype of the file is TXT.

ALCOBJ OBJ((&LIBRARY/QTXTSRC *FILE *EXCL &PROGNAME)) WAIT(&WAIT)
monmsg(cpf1002)

If the member is already locked, then the test fails and we have to
release the lock on the member before continuing. All well and good.

If the lock [aka: allocate] fails; with the CPF1002? If so, then no lock exists to be released. No action regarding locking is required; optionally, the allocation can be re-attempted, but no unlocking by the program[mer]\user should occur in response to the CPF1002 exception condition.

Later I issue
DLCOBJ OBJ((&LIBRARY/QTXTSRC *FILE *EXCL &PROGNAME))
/* no monmsg after */

no errors, nothing in the joblog, but the member remains locked.

Work with Member Locks
System:
File . . . . . : QTXTSRC Type . . . . . : PHY
Library . . : INTQAT ASP device . . : *SYSBAS

Lock
Opt Member Job User Type Lock Status Share
JDCPKKKK QCTLD1 JHORN MBR *SHRRD HELD
DATA *EXCL HELD

The lock is not released until I sign off the workstation. As if I
had not issued the DLCOBJ command at all.

Any ideas?

No mention of release... to improve the possibility of a defect search.

Was debug and/or CLP command logging used to verify that the specific and expected DLCOBJ ran? And matching exactly to the ALCOBJ?

Unlikely, because an open should not have the *EXCL data lock. But... Is it possible that the locks exist implicitly due to an /open/ instead of the /allocate/ activity? Check WRKJOB OPTION(*OPNF) to see if the file is opened. The file.mbr would be closed and the lock disappear at signoff. There is a RCDFMTLCK parameter on OVRDBF that enables the noted DATA lock, but I seem to recall that there would be *two* DATA locks; i.e. one *SHRRD and then another *EXCL to implement the so-called Record Format Lock.

If [as I suspect probably] not per the database file member being open in the job:

Do the values of either of the variables (&LIBRARY) and (&PROGNAME) ever change anywhere in the program. Is there ever a Rename Member (RNMM) done in the program? Or less likely, a Rename Object (RNMOBJ) or Move Object (MOVOBJ) against the *FILE object? An effective RNMLIB request? The above output was apparently from a request to WRKOBJLCK INTQAT/QTXTSRC MBR(*ALL), but what does that request with MBR(*NONE) show? If the MBR(*NONE) invocation shows "(There are no locks for the specified object)" and a message "Press F6 to see member locks.", then the lock\unlock requests presumably were unpaired.

Unfortunately the onus is on the programmer\user to deallocate exactly what was allocated; i.e. the Allocate Object (ALCOBJ) and Deallocate Object (DLCOBJ) request must be *identically paired* according to *effect* not according to the *values* specified on the parameters. That means the object named on each request must be the *same* object according to its permanent address, not according to its current name. And because the attempt to deallocate a member that is not allocated generates no error whatsoever, the ability to track the origin of an error is muddled. And worse, if the requests are unpaired against the *same* file, then the *SHRRD lock on the *FILE object is lost, and that breaks the locking protocol for a database file... which can cause assumptions by the OS DataBase (DB) code to fail. While harsh, that has always been considered a permanent restriction and a usage error if encountered.