The Devil is in the details. There are relevant factors on both the CP and MVS side.
On the MVS side you have console definitions; you are probably only concerned with MCS and HMCS. An HMCS console uses a special interface to the HMC. Since your VARY command specified CN(*), it activated the HMCS console. On the CP side, it looks like VINPUT passes the text via the virtual HMC to the HMCS console; check with the VM folks whether I've gotten that right. The type of virtual device at a virtual address must match the console definition for that address. Note that while it is best practice for the console name to include the address, that is in principle an unrelated third value. So the CONMODE must match the console definition for the console virtual address. If the SECUSER sees traffic to the HMCS console then just set the routing codes on that consoles appropriately. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Saturday, July 22, 2023 6:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question Jon Perryman wrote: >I need you to stop overthinking z/OS console. It's become very simple >since IBM rewrote it several years ago. When running on a 3215 console >printer, lines are printed and when running on a 3270, it's a >fullscreen interface (like every other fullscreen application such as >xedit). Forget that it is a z/OS console. OK. So it *will* IPL with TERMINAL CONMODE 3215? I'll go back and tinker with that again. That might be the key. >You've only asked us how to use z/OS console with VM SECUID but never >mentioned the problem you are trying to solve. I don't think it solves >your problem. Console in 3270 mode is somewhat like xedit. Xedit deals >with files whereas console deals with system messages which can be >massive on an active z/OS. Like xedit, consoles in 3270 mode can >scroll, exclude, split screen, issue commands to products on z/OS and >much more. Very useful for someone controlling z/OS. Apologies--it was clear to ME (of course!): I want to be able to watch the IPL remotely. It's a dev system, quite quiet: normally nobody is looking at the console at all. So when we do IPL, we're used to doing it from a VM console: XAUTOLOG ... < Wait for "IEE389I MVS COMMAND PROCESSING AVAILABLE", then issue> CP SEND CP ETPGZ1D VINPUT VMSG V CN(*),ACT >You want to use z/OS console as a 3215 which is a printer console and >forward each line to a user using CP SECUID. With thousands of >messages on a z/OS system, the user will be constantly clearing their >screen. This is why I kept asking about PROP. If you don't filter the >messages, you will just pissed off. Worse yet, because these messages >will be formatted for a 3215, they won't be easily readable because of >line wrap and other formatting problems. There aren't thousands of messages, not on this system. I just left it overnight and there were fewer than 10 screens of them. Of course on a "real" system your comment would apply. >>I thought (and still believe) the VARY made FFF "active" in some >>sense, since without it, no SECUSER info; with it (after the VARY), >>SECUSER info. >V CN(*),ACTIVE could not possibly be related to FFF. It was sent to >the emulated hardware console and activated (enabled) it for z/OS >messages. If this solves your problem, I can tell you how to solve >this in z/OS but it will miss the beginning messages. Well...if I bring the guest up, the SECUSER (not "SECUID", that's not a VM thing) sees no messages until I issue the VARY. Repeatable. So it's doing *something*. Right, it misses the messages until the VARY, which is the current problem I'm trying to solve. >At this point, you need to decide if this solves your problem. If not, >maybe we can give you alternatives if you provide some details on the >problem you want to solve. Let me know if you want me to answer your >other questions as an fyi. See above? Thanks for bearing with me here, ...phsiii ---------------------------------------------------------------------- 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