hen perhaps the real question becomes:=3D20 =3D20 does Ms Kline need this
formation real time as it happens, or can=3D20 daily reports suffice=3D20=
=3D20
the latter, then certainly the log can be interrogated and all=3D20
cessary information can be retrieved=3D20 if the former - good luck - even
you sat all day executing lockmon=3D20 you MIGHT see stalls building, but
ny deadlocks could come and go=3D20 between two hits of the ENTER key=3D20=
=3D20
ris=3D20
The information transmitted is intended only for the person or entity to
ich it is addressed and may contain CONFIDENTIAL material. If you receive
is material/information in error, please contact the sender and delete or
stroy the material/information.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: Access to Lock Data Used in PMRM?
"Cindy,
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
re-obtain.
From the IDMS Documentation (I'm using the 16.0 version)
RELEASE
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
LONGTERM NOTIFY request.
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.
L
Linda J. Casey, PMP, CSM
Managing Member
Run Right, LLC