Re:Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?

Discussion created by ca.portal.admin on Mar 9, 2010
hen perhaps the real question becomes:=20 =20 does Ms Kline need this
nformation real time as it happens, or can=20 daily reports suffice=20 =20
f the latter, then certainly the log can be interrogated and all=20
ecessary information can be retrieved=20 if the former - good luck - even
f you sat all day executing lockmon=20 you MIGHT see stalls building, but
any deadlocks could come and go=20 between two hits of the ENTER key=20 =20

The information transmitted is intended only for the person or entity to
hich it is addressed and may contain CONFIDENTIAL material. If you receive
his material/information in error, please contact the sender and delete or
estroy the material/information.
IDMS 3rd-party providers forum


Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?

A notify lock won't lock anyone else out of the record. The purpose of a
notify lock is to allow the response process to tell if someone else has
done anything to the record; touched, modified, deleted. CAS did this
because in high volume shops, if records are retrieved in the premap, then
displayed for update on the map, we had no way to know if someone else would
come in, update the record, hence the notify lock. TSTLCK95 was a standard
CAS routine that checks the results of the notification lock results. If
the record was just obtained by another run unit, then the notify lock would
have its first bit turned on and TSTLCK95 would allow the program to
continue. If any subsequent bits in the lock were turned on, someone did
something and we want to throw out the changes made to the record and

From the IDMS Documentation (I'm using the 16.0 version)


Releases the longterm lock for the record identified by longterm-id or all
record locks (ALL) owned by the logical terminal associated with the current
task. RELEASE also releases the information associated with a previous KEEP

The key here is LTERM....... The dialog that's abending is not the one
who's holding the lock, it's another LTERM.

Unreleased long term locks placed on records stay intact until the user who
set the lock either signs off the system or specifically issues a release
which would include a release all. So, if your client added KEEP EXLUSIVE
on a record occurrence and in the process did not release the lock, it would
be held until explicitly released by the task/user that set it on or the
user who executed the code signed off the CV. Putting a release all into
the program you are having trouble with will only clear up your problem if
this is the offending dialog also.

The systems tasks and operations guide does say that OPER WATCH LTERM shows
the LONGTERM KEPT by the LTERM. Anyone else out there that is more
proficient at this for 15.0 might be able to help more on that front.

So, if you are sure that the record you're having trouble with is the
PURCHASE-ORDER, a quick scan of the code might help to see if in some other
dialog there is issuing a KEEP LONGTERM EXCLUSIVE against the PO record.
Then again, it might not.


Linda J. Casey, PMP, CSM
Managing Member
Run Right, LLC