Solution has been found:
As Rob van Hoboken mentioned that there is no Equivalent for CMDAUTH=NOTIFY.
Investigation and testing has provided the solution for CMDAUTH=USER.
2 Profiles are involved:
CLASS PROFILE
SDSF ISFAUTH.DEST.**
JESSPOOL <nodeid>.**
the
SET SECTRACE ON SDSF command has proven to be very helpfull in analyzing this issue.
Investigation shows if a user is granted/allowed access to (SDSF)
ISFAUTH.DEST.** then SDSF won't check (JESSPOOL)
<nodeid>*.** profiles and therefor grant access to all JES2 elements.
If the user is denied Access to the ISFAUTH.DEST.** then SDSF will check the JESSPOOL <nodeid>*.** profiles. And therefor over this mechanism you can provide security in a granular way.
If you deny a user Access to ISFAUTH,DEST and there is NO profile in <nodeid>*.** for this user, then the user is ONLY granted access to his OWN jes2 elements. SInce a USER ( according to RACF Policy ) is allowed all elements and Datasets he owns. ( In the RACF Access checking is logic built in which compares UTOKEN with RTOKEN ).
So even not specifying JESSPOOL <nodeid>*.** profiles you can protect JES2 elements in a way that Operators are allowed access to
ALL jes2 output elements, and other users
ONLY have access to their own output.
I say Thanks to Rob van Hoboken for his help and support in solving this Issue.
------------------------------
Peter Karel
------------------------------
Original Message:
Sent: Tue March 29, 2022 05:48 AM
From: Rob van Hoboken
Subject: SDSF Security Migration to RACF-SAF
The migration manual states there is no SAF equivalent for CMDAUTH=NOTIFY.
Way back with the first SAF interface for SDSF, we used GLOBAL profiles with &RACUID in the position that should be matched with the current user ID, like
RALTER GLOBAL JESSPOOL ADDMEM(*.*.&RACUID%.**/ALTER)
to implement (very) old fashioned submit/status/cancel rules that allow management of jobnames that start with your user ID.
------------------------------
Rob van Hoboken
------------------------------