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
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.
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.