In release 12.0 of XCOM the ASM#TBLS member is no longer used. So, how does one go about creating default table under r12.0 so the started XCOM task picks up the default table?
XCOM r12.0 no longer gets it's default and configuration settings from a load module or a load library. Instead, XCOM reads a PDS member (typically called XCOMDFLT and typically from the CBXGPARM library).
Clients upgrading from prior releases of XCOM should place a copy of their prior release XCOM default load module into their 12.0 CBXGLOAD library "prior to" starting the XCOM r12.0 started task.
Upon starting the XCOM r12.0 started task for the very first time, we will read their prior release module out of the 12.0 CBXGLOAD library and using the values in it, will CREATE and PUNCH a new XCOMDFLT member into the CBXGPARM library being pointed to by the //XCOMCNTL DD statement in the r12.0 XCOM started task proc. This new XCOMDFLT member will include the new 12.0 parameters. You should consider reviewing these new parameters as you may want to take advantage of them under r12.0.
Going forward, the XCOM STC, XCOM panels and XCOM batch transfer jobs will read this new XCOMDFLT member out of the CBXGPARM library to determine the default parameter and configuration settings.
This new method of reading the configuration settings out of a PDS member instead of out of a load module has caused additional considerations for clients who do not specifically have a XCOMCNTL dataset specified for their ISPF panels. And, for clients who do not have //XCOMCNTL DD statements coded in the JCL of the batch jobs that they use to perform file transfers.
Additional considerations regarding installation of the CONFIGDSN symbol:
It is for these clients, who do not want to have to define a CNTL dataset for their ISPF panels or add //XCOMCNTL DD statements into all of their batch transfer jobs JCL, that we recommend installation of the CONFIGDSN symbol using the CAIRIM job. Execution of CAIRIM loads the CONFIGDSN symbol as a structure that resides in MVS common storage where it is then available to the batch transfer jobs.
Please refer to your XCOM r12.0 Release Notes manual where we document the section entitled "Default Options Enhancements" (Chapter 2: Enhanced Features on page 23).
Then review member FXC0RIM in the XCOM 12.0 CBXGSAMP library for sample JCL used to install the CONFIGDSN symbol. Execution of CAS9 with the control statements in the FXC0RIM member only loads the DATASET and MEMBER name into MVS common storage. It does NOT load the actual configuration parameters into common storage.
As a followup to the above, our recommendation is to permanently add loading of the CONFIGDSN (FXC0INIT) to the normal CAIRIM/CAS9 process that runs on these LPARS at IPL time.
Program CAIRIM with the command to run FXC0INIT needs to be run on each and every LPAR where you expect program XCOMJOB to dynamically allocate an XCOMCNTL library WITHOUT having XCOMCNTL DD coded in the JCL.
- If changes are made to the XCOMDFLT PDS member in the CBXGPARM library, the changes can be picked up by the XCOM STC by recycling the task.
- If you were going to change the name of the LIBRARY or the name of the CONFIG MEMBER that you wanted the ISPF panels or batch jobs that do not have a //XCOMCNTL DD statement to use, you would have to run RIM with PARM(DELETE), relevant to the CONFIGDSN, to delete the old library and member name out of common storage. You would then need to run RIM again to add the NEW library and/or member name back into storage.
- With Installation of the CONFIGDSN symbol into MVS storage under r12.0, if no XCOMCNTL dataset is specified for ISPF panel functions, the functions will still work normally since the XCOM STC and batch transfer jobs that do not have a //XCOMCNTL DD statement coded in their JCL will get their config settings from MVS storage.