> On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz
> <[email protected]> wrote:
> Wrong again. When running z/OS under VM for production, multiple 3270
> consoles is the norm.
See-more Putz. What are you saying is wrong with my second sentence that says
"z/OS has many consoles." which applies to native and z/VM. Can you stop with
the non-stop nonsense.
On Saturday, July 29, 2023 at 02:10:11 PM PDT, Seymour J Metz
<[email protected]> wrote:
Wrong again. When running z/OS under VM for production, multiple 3270 consoles
is the norm.
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Jon
Perryman <[email protected]>
Sent: Saturday, July 29, 2023 5:04 PM
To: [email protected]
Subject: Re: Ignorant z/OS question
> On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III
> <[email protected]> wrote:
> After changing the virtual console address from 03E1 to 0009
> linemode output went to SECUSER without artifacts
Congrats Phil. Here is what you need to know:
1. z/OS has many consoles. You don't have any consoles activated. The hardware
console is DEV(SYSCONS) in PARMLIB(CONSOL##) which has nothing to do with
DEV(3E1) in CONSOL##.
2. DEV(SYSCONS) will stop working if a DEV(###) regardless how the terminal is
defined (DEF CONS, DEF GRAF or ATTACH). If someone decides they need a console
located next to the tape drives and another console next to printers, then
DEV(SYSCONS) will no longer be automatically activated.
3. Virtual CONSOLE DEV(###) should never be used for z/OS. The default for
screen full with non-autoscroll messages requires a real person clear the
screen. This VM user typically would not be logged on. It could be days or
weeks before someone notices the message backlog.
On Saturday, July 29, 2023 at 01:24:04 PM PDT, Phil Smith III
<[email protected]> wrote:
After changing the virtual console address from 03E1 (matching the CONSOLE
entry in CONSOLxx) to 0009 (matching no z/OS console definition) and reIPLing
the guest, the linemode output went to SECUSER without artifacts, as it did on
our old hosting environment.
I'm convinced based on the evidence that:
* The old environment had the virtual console at 0009
* The old environment had the z/OS CONSOLE definition at 03E1
* The folks who ported our system over for us had logon access to the old
environment, but did NOT have access to the VM directory entry for the guest
* They thus made the logically correct decision to define the virtual
console at 03E1
That was the "right thing to do", except it turned out to change the behavior
in an unintuitive way. Now we know.
Thanks 10**6 for all the thoughts and advice here! It was a bit of an odyssey
but we got there.
And this might be due an IBM-MAIN award for the longest thread without
significant topic drift, at least in a while. No idea why, but that's rare here!
...phsiii
----------------------------------------------------------------------
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
