Colin,

How does it behave if you put your ID COLIN in place of SYS1 on your URL? Does 
it show your ID as is or does it show your ID prefixed with an asterisk? Then 
try putting COLINX on your URL. What then does it show? I'm guessing it will be 
*COLINX.

I typically create profile OPERCMDS in the GLOBAL class with an entry of 
MVS.MSCOPER.&RACUID*/READ to enable all users to establish consoles with names 
prefixed with their own USERID. If strict control over the use of console names 
is desired, I then create and permit access to OPERCMDS profiles 
MVS.MSCOPER.console-name to permit select users access to specific consoles 
whose names don't match their USERID and, lastly, create OPERCMDS profile 
MVS.MCSOPER.* with no permissions to prevent the use of all other console names.

Most installations do not restrict the use of console names and have OPERCMDS 
profile MVS.MCSOPER.* with UACC(READ) or ID(*) READ. I don't see this as a 
significant risk provided there is an OPERCMDS catchall profile of * or ** to 
ensure all operator commands are protected and the AUTH setting is not used for 
allow operator command access. That said, I nonetheless think it wise to create 
MVS.MCSOPER.mcs/smcs-console-name profiles with no permissions so they can't be 
specified as their use may cause confusion.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-----Original Message-----
Date:    Tue, 1 Jul 2025 07:48:05 +0100
From:    Colin Paice <colinpai...@gmail.com>
Subject: Re: setting up user and operator commands.

Bob,

Thank you for your very helpful description....  Can I reuse it in my blog
( and give you credit for it?)

Following on....

If I use the z/OSMF console support with URL url=
10.1.1.2:10443/zosmf/restconsoles/consoles/SYS1

In SDSF the command is displayed as

*SYS1*     00000290  CANCEL AAAA
TSU03076 00000090  IEE341I AAAA              NOT ACTIVE

so it looks like the userid that issued the command is SYS1!

Is there a way to have the userid - not the console name here?

I could define a profile MVS.MCSOPER.COLIN*, and give userid COLIN access
to only this profile etc.  This way I would have to specify COLINxx as my
console name, and so it would appear as COLINxx.   Is there a better way?

Colin






On Mon, 30 Jun 2025 at 19:11, Robert S. Hansel <r.han...@rshconsulting.com>
wrote:

> Hi Colin,
>
> Here's my understanding as to how it works. To start a console with a
> specific name, you must be permitted READ access to the OPERCMDS resource
> MVS.MCSOPER.console-name, assuming OPERCMDS is active. If (a) the OPERCMDS
> class is active, (b) there is a USERID matching the console-name, (c) the
> USERID has an OPERPARMS segment, and (d) the OPERPARMS segment specifies an
> AUTH setting (INFO,MASTER,ALL,SYS,IO,CONS), your console will get the
> specified AUTH setting. AUTH defaults to INFO. If these conditions are not
> met, your console will only get AUTH(INFO). Similarly, if you specify the
> name of an inactive MCS or SMCS console, you will get its AUTH setting as
> specified in PARMLIB CONSOLxx.
>
> The AUTH setting governs access to operator commands that are _not_
> protected by OPERCMDS profiles. If all OPERCMDS resources are protected by
> profiles (e.g., catch-all **), AUTH is moot and the user who started the
> console requires OPERCMDS access. As an aside, AUTH governs the authority
> of MCS consoles when no user is logged onto the console; OPERCMDS is
> ignored.
>
> OPERCMDS is a default Return Code 4 class. It can be activated without
> harm (assuming there are no pre-existing profiles). If an operator command
> is not protected (RC=4), z/OS uses the console's AUTH setting to govern
> access.
>
> One more thing. This is relatively new. When you execute the CONSOLE
> command, you can now include ACTIVATE(OPERPARM(attributes)) to specify your
> own console attributes without having to have an OPERPARM segment,
> including an AUTH setting. To use this operand, you need READ access to
> TSOAUTH resource CONOPER. There are no restrictions on what attributes you
> specify.
>
> Regards, Bob
>
> Robert S. Hansel
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> www.rshconsulting.com
>
> -----Original Message-----
> Date:    Sun, 29 Jun 2025 17:29:25 +0100
> From:    Colin Paice <colinpai...@gmail.com>
> Subject: setting up user and operator commands.
>
> I'm struggling to understand the set up for userid and console permissions,
> I can specify a console-name for example z/OSMF
> https://10.1.1.2:10443/zosmf/restconsoles/consoles/*EMCS003*, or the TSO
> command CONSOLE NAME(*EMCS003*).
>
> My userid needs read access to the profile MVS.MCSOPER.EMCS003.
> As I read the documentation the console name is not important - it does not
> contain any configuration information it is just a name.  I could create a
> console-name COLIN1, and give only userid COLIN access to it.      This
> stops other people trying to use COLIN1.  If other people had access to it
> I might get "COLIN1" in use.
>
> Am I missing something?
> ______________________
>
>
> The documentation for Extended MCS user, implies an EMCS is different to a
> userid.
> Defining the user profile of an extended MCS console
> <
> https://www.ibm.com/docs/en/zos/3.1.0?topic=racf-defining-user-profile-extended-mcs-console#racuse
> >
>
> It feels like an EMCS is just an existing TSO userid.    The doc says an
> EMCS userid needs to have an OPERPARM segment.  My userid doesnt have this
> segment, and I can still use TSO CONSOLE command, and cancel jobs etc.  The
> doc
> <
> https://www.ibm.com/docs/en/zos/3.1.0?topic=consoles-defining-console-attributes-extended-mcs
> >
> implies the default AUTH(INFO)  so I should not be able to cancel jobs.
>
> Is there a good write up on EMCS ?
>
> Colin
>
> ----------------------------------------------------------------------
> 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

Reply via email to