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 <[email protected]>
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 [email protected] with the message: INFO IBM-MAIN

Reply via email to