CA IDMS IUA EIUA

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

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

    Posted 03-09-2010 02:19 PM
    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