> -----Original Message-----
> From: Peter Osborne [mailto:[log in to unmask]]
>
> We seem to have a program that is locking a dataset and never 
> unlocks it.

and, I take it, you don't have the source (or for whatever reason cannot make changes to it)?  Usually the first thing to try is :ABORTing the program -- when the database is closed, it implicitly unlocks the datasets.  If it is in a state where you cannot abort it, such as trying to obtain a second [unconditional] lock, then you are getting into the "deadly embrace" situation.  This is where UNDEDLOCK that others have mentioned will help.

IF you can re-write your program, then you need to investigate what it is trying to "lock", whether or not it is getting into a "deadly embrace", and/or if some bozo programmer simply forgot to code a call to DBUNLOCK [it can happen...]

> Other programs start to hang when they go to use that dataset 
> until every user on the system is hung and the user license maxes out.

Likewise, "other programs" should be abortable [press <break>, then type ABORT at the prompt].  If they cannot, then perhaps they are the co-conspirator in the deadlock situation.  Again, if you have access to the source, it is time to look into these to determine why locks are being held for so long. (or why there are two seperate attempts to acquire a lock -- DBLOCK can take multiple lock descriptors and will lock them as "all or nothing", so multiple calls to DBLOCK without intervening DBUNLOCK calls should be rare...)

the way you've described this, it leads me to believe the one that starts this deadlock mess is a "batch" program [running from a job], while the "other programs" are all run by people at workstations [sessions].  "session" oriented programs can (should?) be written to first "attempt" to lock the dataset [in as tight of a loop as you like] until success or xxx seconds have passed, and if it fails, give the user an option to keep retrying or abort [cleanly].

[batch based programs can be written the same way, but rather than prompt the "user", you have to make PRINTOP/PRINTOPREPLY calls to get the decision from the system operator]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *