To have parameter SYSSYM set to ALLOW as default instead of DISALLOW.

Thank you for sharing your request for an update with us. Unfortunately, this requirement does not fit with the design of the system symbol substitution for batch jobs.

Prior to z/OS 2.1, system symbol substitution was never done for batch jobs (an MVS converter restriction). This restriction was because symbol substitution in JCL is done during JCL conversion processing and may occur on a different system from where the job will run. Thus customers may be confused when a job submitted and converted on "SY1" but run on "SY2" has &SYSNAME set to "SY1". For started tasks and TSO logon PROCs, system symbols were allowed, since by definition, they must convert on the system where they were started (thus everything occurs on the same system).

Since you mentioned JES3, note that JES3 has code designed to ensure started task and TSO logon symbols work for CI FSS even when converting on a system that is not the execution system. This does/did not help processing for batch jobs.

When working some customers, they correctly pointed out that though the original system symbols were used for system specific value like system name, over time symbols been updated to include concepts that were not system specific (including dynamic symbols like the &LYYMMDD symbol mentioned). One customer shared a use case where they had an environment with two SYSPLEXes, one for production and one for test. They wanted to use the same JCL without modification in both environment, having data set names that started with PROD in one and TEST in the other. Nothing system specific was required (just SYSPLEX level information).

To address this requirement, code in z/OS 2.1 was updated to add the SYSSYM= keyword to the JOBCLASS statement. This allowed the system symbolic substitution in batch JCL for the specified JOBCLASS. The default was defined as DISALLOW because that was how it worked in prior releases and due to the limitation on where substitutions were done (conversion vs execution system). The recommendation was to use only system independent symbols when working with batch jobs.

Note that since the SYSSYM setting is on the JOBCLASS statement it has the same properties as other JOBCLASS settings. JOBCLASS settings are maintained across the JESPlex. The settings are stored in the JES2 checkpoint data set and changes made on one member are copied to all members. Also, when a JES2 member initializes, the value read from the checkpoint is always used in preference to what was specified in the initialization data set. This implies that a single $T JOBCLASS(A),SYSSYM=ALLOW command will set the SYSSYM value on all members and that setting will persist until the next cold start.

For dynamic job classes (multiple character job classes that can be added via $ADD JOBCLASS or initialization statements ), the default is SYSSYM= DISALLOW. However, you can specify SYSSYM= on the $ADD JOBCLASS (eg $ADD JOBCLASS(BRUNO),SYSSYM=ALLOW).

You can also update all JOBCLASSes to SYSSYM= ALLOW with the single command $T JOBCLASS(*),SYSSYM=ALLOW. This only needs to be done once in the JESPlex and will persist until the next cold start. For cold starts, you can add a JOBCLASS(*) SYSSYM=ALLOW statement to your initialization stream to ensure this is always set.

Furthermore, if the default were updated to ALLOW, it would only impact the setting after a cold start and dynamically added JOBCLASSes. Existing JOBCLASSes have a value that can only be changed via operator command.

Because of the above explanation, this request for change is being declined. If you have any questions you can contact us. Thank you for sharing your requirement with us.