Brian,
>we would
>like to be able to determine who has what set locked, so that we can
>figure out what is going on. DBUTIL won't work, because the users are
>not logged on as the creator user.
There's an undocumented (afaik) Image call, DBLOCKINFO, that provides some
of the info, and may provide all of it. For example (I'm logged on as
MGR.STUDENT):
-------------
:listf stu,-3
********************
FILE: STU.DATA96.STUDENT
FILE CODE : -400 FOPTIONS: BINARY,FIXED,NOCCTL,STD
BLK FACTOR: 1 CREATOR : MANAGER
</snip>
:comment ^^^^^^^
:comment I'm not the creator
:comment at this point, i ran a program called DBMREQ, which is sort of a
:comment database manager. It has a couple of options in it to call
:comment the 'dbusers' routine. The 'dbusers' routine leaves its results
:comment in a a file called 'zzdbuser'.
:comment I requested who was accessing the database:
:print zzdbuser
JOBNUM LOGON LDEV PROGRAM
------ ----------------------------------- ---- --------------------------
128 1 STUINQ.PROG.STUDENT #S280 5
81 1 STUSCH.PROG.STUDENT #S285 1
113 1 DRFUPD.PROG.STUDENT #S292 1
164 1 STUINQ.PROG.STUDENT #S282 5
116 1 STUINQ.PROG.STUDENT #S288 5
:
:comment headings are bunk. the far right number is the open mode.
:comment now I rerun DBMREQ and request locks. In another session,
:comment I'm running a program holding a lock on a dataset.
:print zzdbuser
JOBNUM LOGON LDEV PROGRAM
------ ----------------------------------- ---- --------------------------
#S295 MGR.STUDENT,PUB 32 TLOCK
:comment below is a snip of the output from dbutil
>>show stu locks
For database STU
PIN/ PROGRAM
LOCKED ENTITY / ( - waiting process ) PATH NAME JOBNUM
------------------------------------------------------- ------- -------- ------
DATA SET TEACHERS . . . . . . . . . . . . . . . . . . . 94/1 TLOCK #S295
----------
DBLOCKINFO has a very unusual calling and return format.
I have an SPL/3000 routine, DBUSERS, that calls this intrinsic, processes
the returned data, and returns a file that can be read or displayed. It
encapulates the call to DBLOCKINFO in a priv mode routine (stick it in an SL
so your users don't need PM) that FOPENs the DB root file, and passes the
fileid to the DBLOCKINFO routine. DBLOCKINFO writes to a regular MPE file
specified in the QUAL parameter. It has two modes (that I used), 1 = locks,
2 = users.
To tell you the truth, I wrote the code in 1991 on a classic, never cleaned
it up for XL/ix, and never explored it further. From distant memory, I
believe I was having some locking problems at the time and needed the same
type of info. It does work on iX (4.0 is what I just ran it on). As you
can see, it doesn't tell you what dataset is locked; but I may have filtered
it out of the output returned from the intrinsic for some reason, or there
may be some other parameters for that. I don't even remember where I found
out about DBLOCKINFO (either the old Robelle Image/3000 book or I
disassembled part of DBUTIL).
Jeff just mentioned SHOWBASE, which will work if you are continuouly
monitoring the problem. DBUSERS() would give a user program a method to log
locking problems. You'd probably have to do your 10 lock tries, then call
DBUSERS() to find out the held locks and append the output to a file
somewhere before you abend.
If you want the code, email me.
Its only about 300 lines of SPL, most of it dealing with massaging the datafile.
Lance
|
