(Wow, this thread is getting long! Sorry about that) Jon Perryman is still endeavoring to help me, which is appreciated:
>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. Right, I never thought the VARY came from FFF. 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. >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. Of course. I'm doing that. >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. As I've said, I've been using VM for over 40 years, so I know this; what I don't understand is how z/OS deals with consoles, since it has its own full-screen support. >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. OK, what does "active" mean in a z/OS context? Remember, what I'm trying to do is to "connect" (or perhaps "activate") a z/OS console at IPL such that system log output is copied there in line mode so the SECUSER sees it. So this seems like a key bit of understanding. I keep reading z/OS doc but it's full of assumptions and short on examples. >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. "powered off"? As in, not active? >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. Yes, of course. I know how that works, have written and supported many products that use SECUSER. But they weren't z/OS, weren't running in CONMODE 3270. >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? What is the hardware state of...what? If the userid is not logged on at all (disconnected *is* logged on as far as VM is concerned, just not connected), the virtual console is still there, is still used. But I don't think that's what you meant. >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. Again, not sure what this means--does "disconnect is forwarded" mean "a CP DISCONNECT command is issued by the SECUSER"? >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. Well, I'm not worried about ME seeing the lines, I meant that it seemed like they weren't going to come to the SECUSER as separate lines. But as I said (somewhere), I might should tinker with that more. This: >Get help from a z/OS sysprog ...is of course the real solution here. I don't have one handy, alas. Though I have asked our service provider for their thoughts, no response yet (I just asked, had thought this would be easier than it's turned out to be). >> 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. >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. True. But VM full-screen mode is not CONMODE 3270. Those are different things. VM does full-screen via DIAG 58, with CP doing the hard part. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
