Re: MVS master consoles
>Hi. I'm learning some things about MVS consoles.I have both the PD >console (SYSCON - aka Operating System Messages task on the HMC) and a >local 3270 console (named MVSMAST) active. Both have all routing codes >assigned. This is in a virtual machine, so SYSCON works with the #CP >VINPUT VMSG command and displays line mode output. I am assuming that SYSCON is the operating system messages console and MVSMAST is the 3270 console interface that can be started on the HMC that acts like a traditional MVS master console. See below. From a z/OS point of view there is no 'master console' necessary anymore. z/OS happily runs without any 3270 console (local non-SNA) attached these days since z/OS 1.6 ore 1.8 (when console restructure was done). That being said, without a 'channel-attached master console' the NIP messages during IPL automatically go to the operating system console until the point in the IPL when the console address space becomes active. At that point all messages are either hardcopy only or go to the HMCS console if it is active. I think if the HMCS is active at NIP that NIP messages go there instead of the SYSCON. The 'operating system messages' console needs to be explicitly activated after NIP (v cn(*),activate) even if you can still see the NIP messages there. It should not stay active for long (v cn(*),deactivate) because it uses the SPI which is comparatively slow and could cause problems in the console address space (like WTO buffer shortages back in the days when customers were able to force CONSOLE to a dispatching priority of 9F instead of FF). Besides, the health checker will nag you to inactivate the SYSCON. The HMCS console acts like a normal MCS console once it is opened (with a rather clumsy keyboard interface - the PFKEY-definitions don't really work, and the enter key is NOT ctrl). Closing the 3270 window will simply deactivate that console without any problems. If your MASTCON is defined in CONSOLxx with a UCB number then that is a regular MCS console (and knowing almost nothing about VM) and acts like a 'master console' of old. If that console gets inactivated via some VM command, then z/OS will just mark it as inactive and go on it's merry way until it is explicitly reactivated from within z/OS (v xxx,console possibly after v xxx,online). If MASTCON is defined in the IODF as a NIP console and it is active at IPL, it will get all NIP messages and all messages after NIP. >Will both receive all messages and can either one respond to system action >messages? If consolxx has the appropriate statements (here are mine from our sandplex): CONSOLE DEVNUM(SYSCONS) INTIDS(Y) LEVEL(ALL) UNKNIDS(Y) ROUTCODE(1-10,12-128) CONSOLE DEVNUM(HMCS) NAME(HMCS) AUTH(MASTER) MSCOPE(*) INTIDS(Y) LEVEL(ALL) UNKNIDS(Y) ROUTCODE(1-10,12-128) PFKTAB(PFKTAB1) then all messages except routcode 11 will appear on these two consoles. RC11 has been excluded because it is a performance hog and z/OS health checker will nag you to remove it from being displayed. If your MASTCON has a similar console statement with DEVNUM(ucb) then it is not the HMCS that I talked about earlier. Same things apply for the routing codes. Action messages appear coloured on both the HMCS and a regular MCS console depending on their descriptor code (unless there are MPF exits that change the DC and possibly the routcode). They are shown on the SYSCON only if it had been explicitly activated before the message was issued. Wait state messages (synchronous destination WTO) definitely appear on the SYSCON regardless of its activity state - *if* the MCS console (the one with a device number in consolxx) is not active. I believe synchdest messages are shown on the first active MCS console z/OS can find. At least that was the case until console restructure (and we have run without true MCS consoles for a long time now, so I don't have operative experience anymore). When we still had active MCS consoles, I seem to remember that they had to be defined a certain way because I still saw the wait state messages on the SYSCON - the blinking icon 'operating system messages' on the HMC was my point in time when I could re-IPL the system. Hope this excurse clears things up a bit. If I got anything wrong, I'm sure Jim Mulder or Peter Fatzinger will chime in. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS master consoles
Every console can receive a message. Every console may be used to REPLY, however SYSCON is handicapped - it cannot be used for RACF-related tasks since it does not support LOGON. Any other console like OSA-ICC or legacy 3270 box attached to 3174 channel attached, or VTAM console, or SYSG console (from HMC) - all of them do support RACF LOGON. -- Radoslaw Skorupka Lodz, Poland W dniu 29.06.2020 o 19:13, Alan Altmark pisze: Hi. I'm learning some things about MVS consoles.I have both the PD console (SYSCON - aka Operating System Messages task on the HMC) and a local 3270 console (named MVSMAST) active. Both have all routing codes assigned. This is in a virtual machine, so SYSCON works with the #CP VINPUT VMSG command and displays line mode output. Will both receive all messages and can either one respond to system action messages? What I really don't want is for use of the 3270 console to interfere with what's going on with SYSCON. Someone DIALs into the 3270 console and all of sudden the PD console stops getting messages or some such. As you can tell, there's a lot about MVS console management I don't grok. I've looked in the books, of course, but all that did was confuse me a bit more. It assumed I already understood various aspects of how consoles work. I know I can vary MVSMAST inactive at system startup and require them to activate it manually via #CP VINPUT VMSG, but that seems like mean thing to do if I can be assured that it's presence won't materially affect messages appearing on the PD console and it's ability to respond to any action messages it sees. (Yup, might be a race between human and machine, but I expect the machine to win that race.) Thanks., Alan Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services Phone: 607-429-3323 | Mobile: 607-321-7556 E-mail: altma...@us.ibm.com Endicott, NY USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS master consoles
Somewhat oversimplified, a console receives anything with matching routing codes and can do anything permitted by its authority. The authority is controlled by the console definition and by security profiles in, e.g., RACF. The issue that may affect you is the VM environment. What happens to the virtual HMC messages if the operator is diconnected? What happens to the 3270 output if nobody is dialed in? What happens if someone does a #CP DISC instead of a #CP RESET on the virtual 3270? See z/OS Version 2 Release 4 MVS Planning: Operations, SA23-1390-40. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Alan Altmark [alan_altm...@us.ibm.com] Sent: Monday, June 29, 2020 1:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MVS master consoles Hi. I'm learning some things about MVS consoles.I have both the PD console (SYSCON - aka Operating System Messages task on the HMC) and a local 3270 console (named MVSMAST) active. Both have all routing codes assigned. This is in a virtual machine, so SYSCON works with the #CP VINPUT VMSG command and displays line mode output. Will both receive all messages and can either one respond to system action messages? What I really don't want is for use of the 3270 console to interfere with what's going on with SYSCON. Someone DIALs into the 3270 console and all of sudden the PD console stops getting messages or some such. As you can tell, there's a lot about MVS console management I don't grok. I've looked in the books, of course, but all that did was confuse me a bit more. It assumed I already understood various aspects of how consoles work. I know I can vary MVSMAST inactive at system startup and require them to activate it manually via #CP VINPUT VMSG, but that seems like mean thing to do if I can be assured that it's presence won't materially affect messages appearing on the PD console and it's ability to respond to any action messages it sees. (Yup, might be a race between human and machine, but I expect the machine to win that race.) Thanks., Alan Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services Phone: 607-429-3323 | Mobile: 607-321-7556 E-mail: altma...@us.ibm.com Endicott, NY USA -- 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
MVS master consoles
Hi. I'm learning some things about MVS consoles.I have both the PD console (SYSCON - aka Operating System Messages task on the HMC) and a local 3270 console (named MVSMAST) active. Both have all routing codes assigned. This is in a virtual machine, so SYSCON works with the #CP VINPUT VMSG command and displays line mode output. Will both receive all messages and can either one respond to system action messages? What I really don't want is for use of the 3270 console to interfere with what's going on with SYSCON. Someone DIALs into the 3270 console and all of sudden the PD console stops getting messages or some such. As you can tell, there's a lot about MVS console management I don't grok. I've looked in the books, of course, but all that did was confuse me a bit more. It assumed I already understood various aspects of how consoles work. I know I can vary MVSMAST inactive at system startup and require them to activate it manually via #CP VINPUT VMSG, but that seems like mean thing to do if I can be assured that it's presence won't materially affect messages appearing on the PD console and it's ability to respond to any action messages it sees. (Yup, might be a race between human and machine, but I expect the machine to win that race.) Thanks., Alan Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services Phone: 607-429-3323 | Mobile: 607-321-7556 E-mail: altma...@us.ibm.com Endicott, NY USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
