Hi Phil,

I need you to stop overthinking z/OS console. It's become very simple since IBM 
rewrote it several years ago. When running on a 3215 console printer, lines are 
printed and when running on a 3270, it's a fullscreen interface (like every 
other fullscreen application such as xedit). Forget that it is a z/OS console.


You've only asked us how to use z/OS console with VM SECUID but never mentioned 
the problem you are trying to solve. I don't think it solves your problem. 
Console in 3270 mode is somewhat like xedit. Xedit deals with files whereas 
console deals with system messages which can be massive on an active z/OS. Like 
xedit, consoles in 3270 mode can scroll, exclude, split screen, issue commands 
to products on z/OS and much more. Very useful for someone controlling z/OS.

You want to use z/OS console as a 3215 which is a printer console and forward 
each line to a user using CP SECUID. With thousands of messages on a z/OS 
system, the user will be constantly clearing their screen. This is why I kept 
asking about PROP. If you don't filter the messages, you will just pissed off. 
Worse yet, because these messages will be formatted for a 3215, they won't be 
easily readable because of line wrap and other formatting problems. 

> 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.


V CN(*),ACTIVE could not possibly be related to FFF. It was sent to the 
emulated hardware console and activated (enabled) it for z/OS messages. If this 
solves your problem, I can tell you how to solve this in z/OS but it will miss 
the beginning messages. 

At this point, you need to decide if this solves your problem. If not, maybe we 
can give you alternatives if you provide some details on the problem you want 
to solve. Let me know if you want me to answer your other questions as an fyi.

I forgot about CMS using a DIAG for full screen. 

Regards, Jon.    On Friday, July 21, 2023 at 04:45:15 PM PDT, Phil Smith III 
<li...@akphs.com> wrote:  
 
 (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 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

Reply via email to