TBOPEN CAWAALAT error
Article ID: 125163
Updated On:
Products
File Master Plus for IMS
File Master Plus for DB2 for z/OS
Issue/Introduction
users are getting following errors:
...
@MIM1038I CLS... TSU33543 A=0100 T=9D7000 contention with CLSPSS1 A=0100 T=9D7000 OWNS EXCL on POC10000
@MIM1039I CLS... TSU33543 A=0100 T=9D7000 needs SHR SPFEDIT DSN.ISPTLIB(CAWAALAT)
ALAI/Build - TBOPEN CAWAALAT error 12
ALAI/CheckEnv - Build_TEMPALAT_Table RC = 12
GETALAE - Check_Environment RC = 12
...
@MIM1038I CLS... TSU33543 A=0100 T=9D7000 contention with CLSPSS1 A=0100 T=9D7000 OWNS EXCL on POC10000
@MIM1039I CLS... TSU33543 A=0100 T=9D7000 needs SHR SPFEDIT DSN.ISPTLIB(CAWAALAT)
ALAI/Build - TBOPEN CAWAALAT error 12
ALAI/CheckEnv - Build_TEMPALAT_Table RC = 12
GETALAE - Check_Environment RC = 12
Environment
Release:
Component: FMMVS
Component: FMMVS
Resolution
One solution could be to provide update access to DSN.ISPTLIB for all users.
However, using the same ISPTABL is not recommended. Usually there is no ISPTABL or the ISPTABL points to a user-specific data set.
The reason for the latter is that each user would have his/her own table content. With an ISPTABL that points to a common data set, each user would overwrite an already existing the table. The net result is that a user who starts an ISPF application (like CA File Master Plus) would get the content of the last user who saved the table. That's undesirable behavior.
In an environment without ISPTABL, tables are saved to ISPPROF.
ISPF tables are similar in nature to ISPF profiles. In other words, each user of an application that creates an ISPF table should get his/her own copy.
We recommend to work with one of these 2 scenarios:
1. without an ISPTABL DD: in the case, tables are saved to ISPPROF
2. with a user-specific ISPTABL DD, similar to the ISPPROF DD.
With that, ISPF applications that create tables won't run into conflicts if 2 users are updating the same table.
The allocation of ISPTABL is site-specific. However, in most cases, it's done in the TSO logon procedure.
However, using the same ISPTABL is not recommended. Usually there is no ISPTABL or the ISPTABL points to a user-specific data set.
The reason for the latter is that each user would have his/her own table content. With an ISPTABL that points to a common data set, each user would overwrite an already existing the table. The net result is that a user who starts an ISPF application (like CA File Master Plus) would get the content of the last user who saved the table. That's undesirable behavior.
In an environment without ISPTABL, tables are saved to ISPPROF.
ISPF tables are similar in nature to ISPF profiles. In other words, each user of an application that creates an ISPF table should get his/her own copy.
We recommend to work with one of these 2 scenarios:
1. without an ISPTABL DD: in the case, tables are saved to ISPPROF
2. with a user-specific ISPTABL DD, similar to the ISPPROF DD.
With that, ISPF applications that create tables won't run into conflicts if 2 users are updating the same table.
The allocation of ISPTABL is site-specific. However, in most cases, it's done in the TSO logon procedure.
Additional Information
The IBM documentation provides an example, see https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54pc00/isppctsolog.htm. It shows that the ISPTABL data set is user-specific.
Feedback
Yes
No
Powered by
