<https://www.vm.ibm.com/library/720pdfs/72626811.pdf#page=70> is ATTACH, but DIAL is more useful for MVS guests.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Tuesday, July 25, 2023 10:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ignorant z/OS question To my understanding, that sounds correct. Explicitly removing the NIP *console* definition, though leaving the address defined/intact in the IODF for later use by MVS console services (CONSOLxx), would have the same effect as making the device inaccessible, either through (presumably) bad cabling in my case, or through VM detach that you describe, which sounds more dynamic. Just out of curiosity, is there such a thing as VM "attach" to reconnect a device at a later time? On Tue, Jul 25, 2023 at 7:20 PM Jon Perryman <jperr...@pacbell.net> wrote: > > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein < > steve.hor...@gmail.com> wrote: > > This is what I was referring to, relating to NIP and IODF: > > Phil, you can ignore this topic. > > Steve, does it make a difference if the NIP address doesn't exist versus > clearing the NIP address in the IODF? I thought both caused the hardware > console to be used. updating the NIP address might not be something Phil > is comfortable with. Phil understands VM detach and it should achieve the > same results. Detaching all consoles ensures things like problem > determination mode and more doesn't affect hardware console activation. > Phil gets 1 chance on the weekend and I'm just ensuring we cover the most > possibilities in 1 try. > > Am I wrong? If this works, then recommending the deletion of the NIP > address becomes a trivial change. > > > On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein < > steve.hor...@gmail.com> wrote: > > This is what I was referring to, relating to NIP and IODF: > > https://www.ibm.com/docs/en/zos/2.4.0?topic=configuration-working-operating-system-consoles > > > The topic mentions both MVS and VM, so there may be some useful > information. > > While I mentioned my request to have "...the NIP *device *be removed from > IODF", I should have stated to have "... the NIP *CONSOLE* be removed from > IODF". > Yes, the device should be defined to allow CONSOLxx to make use of it once > MVS has been initialized, but an IODF defined NIP CONSOLE is not > required, making use of the hardware console in its absence. > > Maybe you're saying the same thing, just in VM speak?! > > On Tue, Jul 25, 2023 at 10:43 AM Jon Perryman <jperr...@pacbell.net> > wrote: > > > > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein < > > steve.hor...@gmail.com> wrote: > > > The only time I have seen NIP messages (those messages prior to VARY > > > > > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP > > device > > > > > > Hi Phil, Sorry for the long delay.but I had other things to do. Steve may > > have a possible solution. Let me put it into terms you can understand. > > > > Steve says there is 1 exception to the hardware console requiring V > > CN(*),ACT to become the first active console during IPL. He says if you > > disable all z/OS DEV(###) consoles, then the hardware console will > > automatically activate because there is no other console available. I > > believe this to be true but I have never tried this. There may be a > couple > > caveats that can be discussed later if it solves your problem. > > This is simple to test. From the z/OS VM user, detach all devices > > specified in PARMLIB(CONSOL##). At the moment, forget he mentions "NIP" > > device because this is almost always included in PARMLIB(CONSOL##) which > > means you would have detached it. This is so simple it's worth a try. > > > > > > > > On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein < > > steve.hor...@gmail.com> wrote: > > > > The only time I have seen NIP messages (those messages prior to VARY > > CN(*),ACTIVATE being accepted) on a native MVS LPAR was when the NIP > device > > defined in the IODF was not available, I believe due to some cabling > > issues. In that situation, all NIP messages were routed to the SE/HMC > > System Console. I had requested the NIP device be removed from IODF years > > before, for that exact purpose, to assist with automation that uses > > SYSCONS, and/or for diagnostics, but due to Fear/Uncertainty/Doubt, the > > request was flatly denied. > > > > https://www.ibm.com/docs/en/zos/2.4.0?topic=system-nip-console > > "If no NIP console is defined and ready, MVS™ will use the system console > > as the NIP-time console." > > > > I have zero experience with zVM, so I do not know if that NIP message > > behavior is the same when MVS is running as a guest. I just figured I > would > > pass along my anecdotal observations. > > > > ---------------------------------------------------------------------- > > 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 > > > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
