Hi Jon,
You said: "...Detaching a "console" requires a "DEFINE CONSOLE" ..."
AFAIK, (since VM R6.0) this statement has never been true.
Regards,
David
On 2023-07-26 23:37, Jon Perryman wrote:
> On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein
<[email protected]> wrote:
Just out of curiosity, is there such a thing as VM "attach" to reconnect a
device at a later time?
Phil would need to verify what I'm saying. "detach" is a generic command that eliminates a virtual address regardless of how the
virtual address was defined. "attach" is for attaching real VM addresses to a user at a virtual address. Detaching a
"console" requires a "DEFINE CONSOLE". Detaching a "GRAF" requires a "DEFINE GRAF". I think there
are several variations of DEFINE specific to the virtual device type.
On Tuesday, July 25, 2023 at 07:14:21 PM PDT, Steve Horein
<[email protected]> wrote:
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 <[email protected]> wrote:
> On Tuesday, July 25, 2023 at 04:14:48 PM PDT, Steve Horein <
[email protected]> 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 <
[email protected]> 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 <[email protected]>
wrote:
> On Sunday, July 23, 2023 at 08:25:34 PM PDT, Steve Horein <
[email protected]> 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 <
[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
