Re: RACF - SDSF question

[Shaffer, Terri]

Thanks Rob.  That showed what rules I was hitting.

I think I might have fixed it, but will have to see.  What I found was there 
was an *.* rule and an actual JESNODE.**, which was more specific and allowed 
all users ALTER ac cess

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Wednesday, April 17, 2024 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

[You don't often get email from 0618c90e6fdf-dmarc-requ...@listserv.ua.edu. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


  1.  Invoke SDSF and get to the point just before the user issues the action
  2.  Issue "SET SECTRACE ON"
  3.  Issue the "C" action
  4.  Issue "SET SECTRACE OFF"
  5.  Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES

Re: RACF - SDSF question

[Hayim Sokolsky]

Terri,

This is somewhat of an all or nothing equation, with a twist or two.

In OPERCMDS, the permits should always be "WHEN(CONSOLE(SDSF))" instead of 
permitting their groups. This filters the ability to issue the OPERATOR 
commands - both MVS commands and JES2 commands to be limited to situations 
where SDSF has generated the command for the user. At this point the 
JES2.CANCEL.BAT can only be issued when the user is authorized to the job.

So:
PERMIT JES2.CANCEL.BAT CLASS(OPERCMDS) ID(GROUP1) ACCESS(UPDATE)
 /* not recommended */
PERMIT JES2.CANCEL.BAT CLASS(OPERCMDS) ID(*) ACCESS(UPDATE) WHEN(CONSOLE(SDSF)) 
 /* recommended */

The second part of this equation is the profiles in the JESSPOOL class. If they 
have ALTER to a given job's profiles, they can have SDSF generate the commands 
to cancel or purge the job. If they do not have ALTER, then they cannot.

The interesting twist is how specific or not specific you go in JESSPOOL. SDSF 
gets kind of creative when it comes to issuing checks against JESSPOOL. There 
are separate checks performed on rerouting and purging output files which are 
separate from the normal JESSPOOL profile names.

  *   If the user owns the job, that is the job runs under their UserID, they 
automatically have ALTER. So don't let them run CICS regions under their own 
personal UserIDs.
  *   Assuming you have non-human (surrogate) UserIDs, the JESSPOOL profile 
should always contain the UserID or non-human UserID prefix explicitly, such as 
*.UserID.*.** instead of *.*.jobname.**.

JESSPOOL Profile
Scope
nodeid.userid.jobname.jobid
The job itself. Not used for releasing output or viewing the job output.
nodeid.userid.jobname.jobid.Ddsid.dsname
View individual SYSIN or SYSOUT data sets.
nodeid.userid.jobname.jobid.GROUP.ogroupid
Releasing or purging output groups.

It's all in how well you structure the UserIDs, OPERCMDS, and JESSPOOL profiles.



Hayim Sokolsky (he/him/his)

Director, Software Engineering

Rocket Software, USA



E: hsokol...@rocketsoftware.com<mailto:hsokol...@rocketsoftware.com>

W:RocketSoftware.com


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 08:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT.

Re: RACF - SDSF question

[Rob Scott]

Of course, that should read "UPDATE or ALTER access"

Rob

From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Wednesday, April 17, 2024 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


1. Invoke SDSF and get to the point just before the user issues the action
2. Issue "SET SECTRACE ON"
3. Issue the "C" action
4. Issue "SET SECTRACE OFF"
5. Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.

Re: RACF - SDSF question

[Rob Scott]

You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


  1.  Invoke SDSF and get to the point just before the user issues the action
  2.  Issue "SET SECTRACE ON"
  3.  Issue the "C" action
  4.  Issue "SET SECTRACE OFF"
  5.  Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within 

Re: RACF - SDSF question

[Norbert Gál]

Hello Terri,


How does your JESJOBS class look like?

https://www.ibm.com/docs/en/zos/2.5.0?topic=cujn-controlling-who-can-cancel-jobs-by-job-name





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: RACF - SDSF question

Hi,
  I would like to resurrect this question again, because my issue is back but 
not sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx  command.

$CJ(5138)
CANCEL   C30TCIE2,A=0051
IEE301I C30TCIE2  CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2)  STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G)  NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Ce

Re: RACF - SDSF question

[Shaffer, Terri]

Hi,
  I would like to resurrect this question again, because my issue is back but 
not sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx  command.

$CJ(5138)
CANCEL   C30TCIE2,A=0051
IEE301I C30TCIE2  CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2)  STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G)  NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
http://www.linkedin.com/in/roberthansel
http://www.rshconsulting.com/

-Original Message-
Date:Tue, 7 Feb 2023 13:31:41 +
From:    "Shaffer, Terri" 
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 10

Re: RACF - SDSF question

[Ed Jaffe]

On 2/8/2023 3:10 PM, Lennie Dymoke-Bradshaw wrote:

Ed,


We have NO discrete profiles, but we do have generic profiles with no wildcard 
characters in them.

You can do that with profiles in the DATASET class but I don't think you can do 
it with general classes.


Good point. I should have said we have NO discrete profiles in the 
DATASET class... :-[



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Lennie Dymoke-Bradshaw]

Ed,

> We have NO discrete profiles, but we do have generic profiles with no 
> wildcard characters in them.

You can do that with profiles in the DATASET class but I don't think you can do 
it with general classes. 
There is no GENERIC parameter on the RDEFINE command. 
Or do you use some local code to achieve this?

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: 08 February 2023 02:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

On 2/7/2023 5:14 PM, Seymour J Metz wrote:
> Generic is usually more useful, but you can certainly use specific profiles.

Even discrete profiles can be made generic by specifying GENERIC when created.

That's what we do here. We have NO discrete profiles, but we do have generic 
profiles with no wildcard characters in them.


-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Shaffer, Terri]

Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Froberthansel&data=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7Ca4b8cc465d9d4ac4987c08db09d46b79%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638114580161994985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Em%2B3BnJ2qLn7XTrRRvmVtmo5gWOhCx2xDk%2FCAaEkZUg%3D&reserved=0
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rshconsulting.com%2F&data=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7Ca4b8cc465d9d4ac4987c08db09d46b79%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638114580161994985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NHrWwR8EBpDn81MjpoubOzpQSJr1NGjmwVVmlYYzMjg%3D&reserved=0

-Original Message-
Date:Tue, 7 Feb 2023 13:31:41 +
From:"Shaffer, Terri" 
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.**  then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs,

Re: RACF - SDSF question

[Rob Scott]

Bob makes some very good points here, however a small addition :

“The suggestions to lock down MVS cancel job commands won't help in this 
situation because SDSF is issuing JES2 commands instead of MVS commands, so the 
OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.”

This is true for the action character in question, however be aware that SDSF 
also has actions like “K” from DA that generate MVS CANCEL commands rather than 
JES2.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: 08 February 2023 13:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 30th Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel<http://www.linkedin.com/in/roberthansel>
www.rshconsulting.com<http://www.rshconsulting.com>

-Original Message-
Date: Tue, 7 Feb 2023 13:31:41 +
From: "Shaffer, Terri" 
mailto:terri.shaf...@aciworldwide.com>>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsid

Re: RACF - SDSF question

[Robert S. Hansel (RSH)]

Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Tue, 7 Feb 2023 13:31:41 +
From:"Shaffer, Terri" 
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.**  then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Robert S. Hansel (RSH)]

Ed,

What you suggest only applies to DATASET profiles. With General Resource 
profiles such as those for OPERCMDS, the profile is always Discrete if fully 
spelled out and Generic only if it has masking characters.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Tue, 7 Feb 2023 18:31:46 -0800
From:Ed Jaffe 
Subject: Re: RACF - SDSF question

On 2/7/2023 5:14 PM, Seymour J Metz wrote:
> Generic is usually more useful, but you can certainly use specific profiles.

Even discrete profiles can be made generic by specifying GENERIC when 
created.

That's what we do here. We have NO discrete profiles, but we do have 
generic profiles with no wildcard characters in them.


-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Ed Jaffe]

On 2/7/2023 5:14 PM, Seymour J Metz wrote:

Generic is usually more useful, but you can certainly use specific profiles.


Even discrete profiles can be made generic by specifying GENERIC when 
created.


That's what we do here. We have NO discrete profiles, but we do have 
generic profiles with no wildcard characters in them.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Seymour J Metz]

Generic is usually more useful, but you can certainly use specific profiles.


From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 7:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

I guess this bring up another question, which is probably why I am confused.

This is for MVS cancel

CANCEL jobname  MVS.CANCEL.JOB.jobname  MVS.CANCEL.**   Update  Medium

And

Table 1. RACF profiles and JES2 commands
JES2 CommandResource Name   Generic Profile Access 
Required1Security Risk
$C JJES2.CANCEL.BAT JES2.CANCEL.BAT.**  
Update  Medium
$C 'jobname'JES2.CANCEL.JOB JES2.CANCEL.**  Update  
Medium

So is the ** a generic but is the only option?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile. This is 
why SDSF has the extra JESSPOOL profile check that goes beyond vanilla JES2 
cancel command security.

This extra check is ONLY performed inside SDSF and is made before we build the 
operator command text.

Coincidentally I gave a presentation at virtual GSE today entitled "SDSF 
Security - How does it work under z/OS 2.5?" and the sequence of SAF checks is 
described with a few examples.

If you want, I can forward you the slide deck.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for 
Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7Csmetz3%40gmu.edu%7C3f283823024d48c6dcda08db096d1a96%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638114136431865039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s472XZ5kbcvppUTgo0LkOETS9fYFiwwsrz8qVaGz2U4%3D&reserved=0>

From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 6:10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL




Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here? Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 1

Re: RACF - SDSF question

[Shaffer, Terri]

I guess this bring up another question, which is probably why I am confused.

This is for MVS cancel

CANCEL jobname  MVS.CANCEL.JOB.jobname  MVS.CANCEL.**   Update  Medium

And

Table 1. RACF profiles and JES2 commands
JES2 CommandResource Name   Generic Profile Access 
Required1Security Risk
$C JJES2.CANCEL.BAT JES2.CANCEL.BAT.**  
Update  Medium
$C 'jobname'JES2.CANCEL.JOB JES2.CANCEL.**  Update  
Medium

So is the ** a generic but is the only option?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile. This is 
why SDSF has the extra JESSPOOL profile check that goes beyond vanilla JES2 
cancel command security.

This extra check is ONLY performed inside SDSF and is made before we build the 
operator command text.

Coincidentally I gave a presentation at virtual GSE today entitled "SDSF 
Security - How does it work under z/OS 2.5?" and the sequence of SAF checks is 
described with a few examples.

If you want, I can forward you the slide deck.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for 
Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7C10ce6b661eb8413bb00b08db094d48cb%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638113999777492735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Sdtr7sGuH3Tkti7So%2B2D99AwPzFTNhAjPN8EuNPlHJI%3D&reserved=0>

From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 6:10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL




Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here? Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, 

Re: RACF - SDSF question

[Shaffer, Terri]

Agreed, can you fwd the slide deck?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile. This is 
why SDSF has the extra JESSPOOL profile check that goes beyond vanilla JES2 
cancel command security.

This extra check is ONLY performed inside SDSF and is made before we build the 
operator command text.

Coincidentally I gave a presentation at virtual GSE today entitled "SDSF 
Security - How does it work under z/OS 2.5?" and the sequence of SAF checks is 
described with a few examples.

If you want, I can forward you the slide deck.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for 
Android<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7C10ce6b661eb8413bb00b08db094d48cb%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638113999777492735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Sdtr7sGuH3Tkti7So%2B2D99AwPzFTNhAjPN8EuNPlHJI%3D&reserved=0>

From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 6:10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL




Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here? Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don't want users

Re: RACF - SDSF question

[Ramsey Hallman]

I don't know about others, but I would love to see the slide deck.

Ramsey

On Tue, Feb 7, 2023 at 2:53 PM Rob Scott  wrote:

> Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile.
> This is why SDSF has the extra JESSPOOL profile check that goes beyond
> vanilla JES2 cancel command security.
>
> This extra check is ONLY performed inside SDSF and is made before we build
> the operator command text.
>
> Coincidentally I gave a presentation at virtual GSE today entitled "SDSF
> Security - How does it work under z/OS 2.5?" and the sequence of SAF checks
> is described with a few examples.
>
> If you want, I can forward you the slide deck.
>
> Rob Scott
> Rocket Software
>
> Sent from Samsung Mobile on O2
> Sent from Outlook for Android<https://aka.ms/AAb9ysg>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, February 7, 2023 6:10:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: RACF - SDSF question
>
> EXTERNAL EMAIL
>
>
>
>
> Okay, so not sure I reall understand the way this works?
>
> Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics
> jobname like C30TCI* here? Is this the SDSF command like C, P etc?
>
> Or under OPERCMDS I have
>
> JES2.CANCEL.BAT.C30TCI* (G)
> JES2.CANCEL.BAT.** (G)
>
> And now.
>
> MVS.CANCEL.BAT.C30TCI*.* (G)
> MVS.CANCEL.** (G)
>
> Where does the granularity take place, for certain jobs??
>
> I want the users to be able to cancel some batch jobs and everything they
> submitted, but not CICS, DB2 or other system things.
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide - Telecommuter
> H(412-766-2697) C(412-519-2592)
> terri.shaf...@aciworldwide.com
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Rob Scott
> Sent: Tuesday, February 7, 2023 9:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF - SDSF question
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe.
>
>
> Note that one of the "value add" functions of SDSF is that it can check
> for ALTER access to the JESSPOOL profile for the owner and jobname for
> destructive actions like "C" and "P".
>
> Does not stop them using freeform "slash" to issue the raw operator
> command, but removes the convenience of the action character.
>
> Rob Scott
> Rocket Software
>
> From: IBM Mainframe Discussion List  On Behalf
> Of Roger W Suhr
> Sent: 07 February 2023 14:22
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF - SDSF question
>
> EXTERNAL EMAIL
>
>
>
> Hi Ms. Terri,
>
> The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel
> command.
> I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id
> profile to protect the MVS CANCEL command.
>
> So in your case, that would be something like this: (if your running CICS
> as an STC!)
> MVS.CANCEL.STC.C30TCI* (G)
> MVS.CANCEL.STC.** (G)
>
>
> Roger W. Suhr
>
> suhr...@gmail.com<mailto:suhr...@gmail.com>
>
> -Original Message-
> From: IBM Mainframe Discussion List  IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Shaffer, Terri
> Sent: Tuesday, February 7, 2023 8:32
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: RACF - SDSF question
>
> Hi,
> I know there is a RACF group, but hopefully this is simple and I am just
> missing something I have done 100 times over with no issues.
>
> We run our CICS regions as batch jobs, and I just found out a user instead
> of them issuing a CEMT PERF SHUT command, they are canceling it.
>
> Which then causing a 100 vsam messages on startup with all the verifies,
> and if something goes wrong they call me...
>
> So I tried to stop this habit, I know they are putting a C beside the CICS
> and a $CJ(x) command
>
> So I have 2 rules in RACF under OPERCMDS
>
> JES2.CANCEL.BAT.C30TCI* (G)
> JES2.CANCEL.BAT.** (G)
>
> If I restrict the BAT.** then they cant cancel even their own batch jobs,
> So I always thought more specific is looked at first?
>
> One of my previous co-workers implemented SDSF-RACF rules converted from
> ISFPARMS.
>
> Lastly, I understand this doesn't stop them from canceling any other jobs,
> but since this is a development shop we allow more access than most.
>
> But I don't want users canceling a CICS or DB2 etc.
>
> Any ideas how they are getting the access and not stopped with the more
> specific

Re: RACF - SDSF question

[Rob Scott]

Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile. This is 
why SDSF has the extra JESSPOOL profile check that goes beyond vanilla JES2 
cancel command security.

This extra check is ONLY performed inside SDSF and is made before we build the 
operator command text.

Coincidentally I gave a presentation at virtual GSE today entitled "SDSF 
Security - How does it work under z/OS 2.5?" and the sequence of SAF checks is 
described with a few examples.

If you want, I can forward you the slide deck.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 6:10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL




Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here? Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don't want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg><https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg>>]
 
<http://www.aciworldwide.com<http://www.aciworldwide.com><http://www.aciworldwide.com<http://www.aciworldwide.com>>>
 This email message and any attachments may contain confidential, proprietary 
or non-public info

Re: RACF - SDSF question

[Shaffer, Terri]

Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here?  Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don't want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg>]
 <http://www.aciworldwide.com<http://www.aciworldwide.com>> This email message 
and any attachments may contain confidential, proprietary or non-public 
information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: 
INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: 
INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F

Re: RACF - SDSF question

[Dana Mitchell]

Terri said their CICSs are run as jobs, so it would need to be:

MVS.CANCEL.JOB.C30TCI*  (G)
MVS.CANCEL.JOB.**  (G)

Dana

On Tue, 7 Feb 2023 09:22:19 -0500, Roger W Suhr  wrote:

>Hi Ms. Terri,
>
>The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
>I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
>to protect the MVS CANCEL command.
>   
>So in your case, that would be something like this: (if your running CICS as 
>an STC!)
>MVS.CANCEL.STC.C30TCI* (G)
>MVS.CANCEL.STC.** (G)
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Rob Scott]

Note that one of the “value add” functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like “C” and “P”.

Does not stop them using freeform “slash” to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg>]
 <http://www.aciworldwide.com<http://www.aciworldwide.com>> This email message 
and any attachments may contain confidential, proprietary or non-public 
information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: 
INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF - SDSF question

[Roger W Suhr]

Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.**  then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
<http://www.aciworldwide.com> This email message and any attachments may 
contain confidential, proprietary or non-public information. The information is 
intended solely for the designated recipient(s). If an addressing or 
transmission error has misdirected this email, please notify the sender 
immediately and destroy this email. Any review, dissemination, use or reliance 
upon this information by unintended recipients is prohibited. Any opinions 
expressed in this email are those of the author personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RACF - SDSF question

[Shaffer, Terri]

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.**  then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 

This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN