Hi Bob, Thanks for your answer, I get
COLIN 00000290 CANCEL AAAA TSU03272 00000090 IEE341I AAAA NOT ACTIVE COLINX 00000290 CANCEL AAAA TSU03273 00000090 IEE341I AAAA NOT ACTIVE There is no * on the front of my console-name I like your profile MVS.MSCOPER.&RACUID*/READ I haven't used that before ... I'll add it to my list of useful commands. I'll use your words in my blog if I may. Colin On Wed, 2 Jul 2025 at 13:09, Robert S. Hansel <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected] > > > 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 <[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 > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
