Establish JES Ownership

Protecting Resources › JES Resource Protection › Establish JES Ownership

Establish JES Ownership

JES resources must be owned before being authorized.

Example: establish JES ownership

This example establishes ownership:

TSS ADDTO(USER01) JESSPOOL(USG203ME)

TSS PERMIT(ALL) JESSPOOL(USG203ME.%)

Remove Ownership of JES

CA Top Secret will not remove ownership unless all permissions are revoked.

To remove ownership of any JES resource

Revoke all permissions for the resource. For example:
```
TSS REVOKE(ALL) JESSPOOL(USG203ME.%)
```
You cannot specify an access level or the command will fail.
Remove the ownership of the JES resource. For example:
```
TSS REMOVE(USER01) JESSPOOL(USG203ME)
```

Access to JES in FAIL Mode

When the CA Top Secret address space is down, you cannot determine if the JESSPOOL and OPERCMDS resources are owned. If the system is in FAIL mode and the CA Top Secret address space is down, access to these resources are denied.

If your site is running strictly in FAIL mode, these commands allow access to these resources when CA Top Secret is not running:

TSS ADDTO(deptacid) JESJOBS(SUBMIT.,CANCEL.)

TSS ADDTO(deptacid) JESSPOOL(nodename)

TSS ADDTO(deptacid) OPERCMDS(MVS.,JES2.,JES3.)

TSS PERMIT(ALL) JESJOBS(SUBMIT.,CANCEL.)
                ACCESS(ALL) 
                ACTION(PASSWORD)

TSS PERMIT(ALL) JESSPOOL(nodename.) 
                ACCESS(ALL) 
                ACTION(PASSWORD)

TSS PERMIT(ALL) OPERCMDS(MVS.,JES2.,JES3.) 
                ACCESS(ALL) 
                ACTION(PASSWORD)

Job Submission Restriction

TSS PERMIT allows designated users to access the indicated jobs in an unlimited or a restricted manner. Restrictions are indicated with the PERMIT parameter.

To restrict job submission

Establish ownership of the job using TSS CREATE/ADDTO. For example:
```
TSS ADDTO(DEPT01) JESJOBS(SUBMIT.MYNODE.JOB01)
```

Authorize access to the job. For example:

TSS PERMIT(USER01) JESJOBS(SUBMIT.MYNODE.MYJOB.MYACID)

JES Masking

Masking can be used to group jobs whose names share similar characteristics. These shared patterns can then be used as the operands of the JESJOBS parameter in TSS entries.

A masked job name is treated by CA Top Secret like a generic prefix. Any job that begins with a mask is considered a match by the security validation algorithm, and the associated access authorizations are honored.

JES Access Levels

The access levels that can be specified for jobs are:

ALL: Job can be accessed in any way.
UPDATE: Job can be updated; READ and WRITE access is implied.
READ: (Default) Job can be read.
WRITE: Job can only be written.
CONTROL: Job can be requeued.
NONE: Job cannot be used in any way.

Alternate ACID Job Control

You can give an ACID control of another ACID's job during job submission.

Example: alternate ACID control

This example gives the USER01 control of all jobs belonging to USER02:

TSS PERMIT(USER01) JESJOBS(SUBMIT.MYNODE.*.USER02)

SYSOUT Validation

To process nodes for SYSOUT

Identify the owning userid.
When a node receives a job via NJE, the owning userid is identified first.

If the userid is undefined on the receiving node, the *ALL* record is used to perform the checking.

If the submitting node for the output is the same as the NODES control option the submitting userid is assigned as owner of the output.

After the owner is identified, CA Top Secret generates the resource:
```
nodes.USERS.user
```
nodes

The name of the node where the SYSOUT was created.

USERS

Indicates that the SYSOUT is controlled by the owning userid.

User

The user that created the job.

If the submitting userid cannot be assigned as the owner, a second check is made against the submitting user for this resource:
```
snode.USERS.suser
```
snode

The submitting node.

USERS

Indicates that the SYSOUT is controlled by the owning userid.

Suser

The submitting user.

During the second check:

If the highest access level allowed is CONTROL or higher and NJEACID was specified on the PERMIT, that translated userid is used as the owner of the output.
To assign ACID NODEA to all output received (via NJE) from node NODEA, enter:
```
TSS PERMIT(ALL) NODES(NODEA.USERS.) ACCESS(CONTROL) NJEACID(NODEA)
```
If NJEACID is not specified or has a value of &SUSER., the submitting ACID is assigned as the owner without translation.
To assign the submitting ACID as the owner of the output of any job originally submitted from this node, and the NJEUSR control option for all other output received, enter:
```
TSS PERMIT(ALL) NODES(*.USERS.) ACCESS(READ) NJEACID(&SUSER).
```
To assign the submitting ACID as the owner of the output of any job, no matter what node it was submitted from, enter:
```
TSS PERMIT(ALL) NODES(*.USERS.) ACCESS(CONTROL) NJEACID(&SUSER).
```
If the result of the check indicates any lower access level, including NONE, the NJEUSR control option ACID is assigned as the owner of the output.
To assign the NJEUSR control option ACID to all output received (via NJE) from node NODEA, enter:
```
TSS PERMIT(ALL) NODES(NODEA.USERS.) ACCESS(READ)
```
A check is performed to determine the highest access level the generated resource is allowed. If that access level is:

NONE

The output is purged.

READ

If NJEACID specifies &USER., the submitting node and user is checked. Otherwise, the ACID specified in the NJEUSR control option is used.

UPDATE

If a validated security token exists for the submitting user creating the output, the NJEACID value (or the creating userid if NJEACID was not used) is assigned to the output. Otherwise, READ access is used.

CONTROL or higher

Whether a validated token is available, the NJEACID value or the creating userid is assigned to the output.

In all cases where the access level is greater than ACCESS(NONE), a value of NJEACID(&SUSER). is treated as a special case.