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
