TPX - Session ManagementVman Session Management for z/OS
The following messages show up in the TPX logs when TPX is started AND during certain user logons:
1- Many TPXL0400 VSAM errors after TPX is started, while opening VSAM DDs NVIFADM1, NVIFADM2, VIEW, NVIFMAIL (VSAM DD NVIFNOTE appears to be ok):
2- Frequent TPXL0400 VSAM errors when select users logon to TPX,
TPXL5131 12/15/17.349 08:08:41.96 CA-TPX CMPL EXIT DRIVEN, RC=00000000, RSN=00000000 TPXL5130 12/15/17.349 08:08:41.96 CF-REQ: Func=0000, Rc=00000000, Rsn=00000000, Lst#=0000, Enty=MMQ965 TPXL0706 12/15/17.349 08:08:41.96 LSERV request failed. Request: ENQ LSERV Subsystem Name: LSVP DDNAME: NVIFADM2 Return Code = 00001740 ACBERFLG = N/A RPLFDBWD = 00400017 Key = UMMQ965 (HEX: E4D4D4D8F9F6F54040) TPXL0400 12/15/17.349 08:08:41.96 VSAM ERROR. KEY = UMMQ965 RTNCD/FDBK = 00400017 REQUEST TYPE = 15 RBA = 0000000000000000 GVRED 12/15/17.349 08:08:41.96 USER RECORD MMQ965 LOCKED; LAST ACCESS 15/12/17 NOT UPDATED GVRED 12/15/17.349 08:08:41.96 USER RECORD MMQ965 LOCKED; DYNAMIC PROFILE LIST NOT UPDATED
TPX 5.4 with VSAM files managed by L-SERV
RTNCD/FDBK = 0040000F = Another user is holding the record lock (issued during TPX startup).
RTNCD/FDBK = 00400017 = The requestor already holds the ENQ for the requested key (occasionally issued after startup).
RTNCD/FDBK = 0040000F = Another user is holding the record lock (issued during TPX startup). It is suspected that multiple copies of TPX are starting at the same time and the ENQ conflict arises. Since no problem occurs this can be ignored.
RTNCD/FDBK = 00400017 = The requestor already holds the ENQ for the requested key (occasionally issued after startup) This conflict arises for some users who have multiple applications defined to automatically start during logon. The ENQ resource when LSERV is used is a generic 9 byte key that consists of 'U' and the user logon ID. These messages should also be ignored. In the case of logon ENQ failures, the only implication is that the record's last reference time stamp in the database would not have the last time recorded (the date of last use does get recorded correctly). This is evidenced by the presence of MRGVRED messages which indicate the user record was locked and that the last access was not updated.