Transactions in CICS can be submitted through one of two mechanisms:
Two acids are involved in job submission: the submission originating user (the user signed on to CICS who initiates the job submission request); and the region acid (the user who manages the interface to JES on behalf of the originating user).
When either of the two mechanisms is used, CA Top Secret analyzes the JOB card USER parameter to determine if the originating user and the region acid are cross‑authorized to submit the job. Such permission must be granted to the originating user explicitly as follows:
TSS PERMIT(subacid) ACID(jobacid)
The region acid can have explicit permission granted through a similar explicit command, or the administrator can grant global submission to the region acid on behalf of any acid through the following:
TSS ADDTO(regacid) NOSUBCHK
Granting global job submission to the region ACID is an administrative advantage, except for the loss of explicit control of job submission by the region acid. The advantage of granting explicit permission is precisely in maintaining this extra level of control. CA Top Secret leaves The choice of strategy is left up to the individual administrator.
When using these methods of job submission, the USER and PASSWORD parameters on the JOB statement might be omitted. If present, the USER and PASSWORD parameters are checked as written; if omitted, CA Top Secret will add the USER and PASSWORD from the currently active acid at the time that the EXEC WRITEQ or EXEC SPOOLWRITE commands (respectively) were issued. If no active user can be determined, the region acid is used as the active acid.
Note: If you do not wish to allow the region acid to be used as a default USER for job submission, then CICS must be run as a started task and the region acid should not be allowed to the BATCH facility.
The associated DDNAME for the DCT must be in the form:
//ddname DD SYSOUT=(class,INTRDR)
For additional information on defining DCT extra‑partition destinations, consult the appropriate IBM documentation. In this guide, additional information on DCT security is found in the section, Bypassing Security for Specific Resources, in the chapter, “Control Option Requirements,” and the section, Administering Resource Level Security, in the chapter, “Implementing Security.”
In CICS, there is an SPI check to determine if the user has permission to open the SPOOL data set. To bypass this check, issue the following command:
F TSS,FACILITY(cicsprod=BYPADD(SPI=JESSPOOL))
If you do not want to place the user ID on the job card that is being submitted through SPOOLWRITE, issue the following command:
F TSS,FACILITY(cicsprod=BYPADD(SPI=SPOOLSUB))
If you do not wish to grant facility‑wide access to job submission, these SPI resources might also be protected and controlled through TSS ADD and TSS PERMIT commands.
For example, the following command protects the use of the SPOOL data set:
TSS ADDTO(deptacid) SPI(JESSPOOL)
The command shown next restricts an individual from job submission except on FRIDAYs:
TSS PERMIT(user) SPI(JESSPOOL) FRI
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|