DLCOBJ not releasing a member (Mark S Waterbury)

Thank you both. Egg on my face.

The 1 program was issuing 2 identical alcobj commands and only 1 dlcobj
command. The 2 identical alcobj commands put 2 locks on the object which
required 2 identical dlcobj commands to release them both. Just never
caught it on the wrkobjlck screen that there were 2 sets of locks.

Thanks again

Jim

------------------------------

message: 3
date: Fri, 13 Dec 2013 18:30:05 -0500
from: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: DLCOBJ not releasing a member

Jim:

(You did not state what version / release of OS/400 or IBM i (i5/OS)
this was running on.)

What is your CL program doing, in between the ALCOBJ and the
corresponding DLCOBJ?

Sign-off, sign-on, and run the following experiment in an interactive job:

1. create a test member "A" in your QTXTSRC file, e.g. using SEU
2. issue "ALCOBJ ((library/QTXTSRC *FILE *EXCL A))"
3. issue DSPJOB and take option 12. Display locks
4. next to the line that shows the file level lock for QTXTSRC, type a
5=Display member locks
5. issue "ALCOBJ ((library/QTXTSRC *FILE *EXCL A))" again
6. issue DSPJOB option 12, then type a 5 next to the file "QTXTSRC"
* notice there are now "two" sets of locks for the MBR and DATA
7. issue "DLCOBJ ((library/QTXTSRC *FILE *EXCL A))
8. issue DSPJOB option 12, then type a 5 next to the file "QTXTSRC"
* notice there is now only one set of locks for the MBR and DATA
9. issue "DLCOBJ ((library/QTXTSRC *FILE *EXCL A))" again
10. issue DSPJOB, option 12 - there should be no more QTXTSRC locks

Do you know see how you might have somehow encountered a scenario that
could have left a lock on that member?

For example, perhaps your program encountered an unmonitored error
between the ALCOBJ and DLCOBJ and exited, without removing the lock...

Hope that helps,

Mark S. Waterbury




> On 12/13/2013 6:06 PM, Horn, Jim wrote:

Hi All

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 all ready locked, the the test fails and we have to
release the lock on the member before continuing. All well and good.

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?

Jim

------------------------------

message: 4
date: Fri, 13 Dec 2013 15:59:28 -0800
from: CRPence <CRPbottle@xxxxxxxxx>
subject: 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.

--
Regards, Chuck