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