> CP SEND CP ETPGZ1D DEFINE GRAF FFF
> CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
> I do wonder if this will Just Work at IPL time
The DEFINE GRAF did nothing useful. SECUID is associated with the VM user's
CONSOLE definition. If you look at the z/OS syslog, you will find the V
CN(*),ACT did not come from FFF. It will show the command came from another
console that is either defined in the VM CONSOLE statement or SYSCONS / HWCI.
I'm guessing from the VM CONSOLE defined.
If you IPL z/OS without the use of a CMS exec, then you will need to specify
the SECUID on the VM user's CONSOLE statement. If you use an exec, then issue
the SET SECUID before the CP IPL command.
Keep in mind that VM CP is about hardware emulation (not about an OS). Even a
CMS user requires CONSOLE 009 for the IPL CMS to be successful. Always think
how hardware behaves regardless of the IPL'd os.
Realize that you issued the V CN(*),ACTIVATE from a z/OS console that was not
active. This is not possible in the real world. You would have issued the
command from an active console. The VM CONSOLE is leaving the z/OS console in a
funky state or real consoles are also in this funky state when powered on with
commands enabled but messages disabled.
When you autolog the z/OS user, the VM CONSOLE is in a disconnected state. z/OS
will not send messages to any console that is powered off. In the past, issuing
commands was also disabled but that seems to have changed.
As I said before, you should be able to test this by autologing a CMS user that
runs an exec that displays messages. It should do something similar as z/OS
when disconnected. In the case of CMS, it should go from RUNNING to some sort
of wait.
Adding a SECUID (secondary user) sends all messages (CP and underlying OS
through VM user CONSOLE) to the secondary user. What is the hardware state if
the secondary user is not logged on or disconnected? Does CP simply discard
messages or does the hardware act as if it's disconnected?
If the disconnect is forwarded from the secondary user, then you will need to
start the SECUID running PROP prior to starting the z/OS user.
> "a console command to remove these" - what console command to remote what?
You say z/OS messages are wrapping. "these" refers to additional information
about the message. Unlike VM, z/OS can optionally display more than the message
(e.g. jobname, jobnum and more). z/OS console ignores the hardware definition
and queries the device to format messages according to the device. Since a 3215
is 132 bytes wide, expect lines to wrap on an 80 byte terminal if the line
exceeds 80 bytes. I don't know your requirements but lets say only displayed
the message without anything else, then primary messages would not wrap because
they are 80 bytes or less. Secondaries would still wrap (e.g. D NET command
output). Get help from a z/OS sysprog who is familiar with z/OS syslog /
consoles / messages and discuss what you requirements. Since you probably use
TN3270, why not define your screen with lines longer than 132 bytes.
> I need to define some virtual device at the right address
Your VM CONSOLE address is correct because you saw z/OS messages that can only
come through the VM CONSOLE address. Regardless of the OS, you will not see
anything other than CP and this device from the VM user console. For instance,
DEF GRAF allows you to dial into the GRAF address but has nothing to do with
the VM user console.
> "This terminal"-which terminal?
The underlying OS uses VM user console as defined in the VM CONSOLE definition.
> CMS users don't run with TERMINAL CONMODE 3270.
It's true the VM CONSOLE definition for CMS specifies 3215 but CMS queries the
device. It ignores the hardware definition when required otherwise things like
xedit wouldn't be full screen.
> Sam Cohen wrote:> It sounds like your console address in z/OS is not equal to
> the console
This is an absurd statement unless z/VM now supports virtual HWCI. You said
that z/OS messages were displayed when IPL'd by logging onto the z/OS VM user.
z/OS messages were coming through the VM CONSOLE definition address or through
a virtual HWCI. Virtual HWCI might be a possibility because I think it was the
one exception to issuing z/OS commands from an inactive console.
On Friday, July 21, 2023 at 08:37:50 AM PDT, Phil Smith III
<[email protected]> wrote:
Well, doh: I finally decided to just try it:
CP SEND CP ETPGZ1D DEFINE GRAF FFF
CP SEND CP ETPGZ1D VINPUT VMSG VARY CN(*),ACT
...and now I'm seeing output as SECUSER!
I do wonder if this will Just Work at IPL time, or not until that VARY is
issued. I guess I'll find out when I get a chance.
So presumably the thing that connects this is:
CONSOLE DEVNUM(FFF) ROUTCODE(ALL)
UNIT(3277-2)
AUTH(ALL)
DEL(RD)
RNUM(19)
RTME(1)
MFORM(J,T)
SEG(19)
AREA(NONE)
NAME(S0W10FFF)
It's certainly what led me to try that device address. 03E1 is the "real"
console per z/VM (that's what QUERY VIRTUAL CONSOLE shows on the guest). And
that wants to be in TERMINAL CONMODE 3270, I think. Certainly when it is, and
you log onto it, you get the scrolling full-screen z/OS console.
Wish I understood this better--I'm sure it's all there, just not in terms I
grok as a VMer.
----------------------------------------------------------------------
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
