Hello Fred,
I hope that you (eventually) find this useful, but I'm going to 
unhelpfully start by suggesting that you take a step back and delete from
 
your mind the idea that VM has a, "console".

The VM paradigm is fundamentally different to the OS paradigm - in VM, an
y 
appropriately privileged userid can issue any CP command from any 
location. Period. The idea of a, "system console" is not part of the mode
l.

Asynchronous system status messages are directed to the VIRTUAL console o
f 
the currently-logged on userid that is designated as SYSTEM OPERATOR. If 

there is no logged-on and currently-designated SYSTEM OPERATOR then the 

asynchronous messages are simply discarded. The SYSTEM OPERATOR may be 

logged-on-connected or it may be be logged-on-disconnected - CP just 
doesn't care.

So ... I'll now attempt to redefine what I think is the problem that 
you're trying to solve - it'll be helpful to the list if you would confir
m 
or refine this definition so that we can then suggest pragmatic solutions
.

I think that your, "problem" is that you wish to display all (or some 
subset of) the asynchronous system status messages on several real displa
y 
devices. Possibly you also wish to allow provileged commands that alter 

the system status to be entered from several real display devices.

Both of these capabilities are quite straightforward to implement in a 

basic form using nothing other than the essential VM capabilities - the 

challenges come once one starts imposing all those, "real life" 
constraints such as subsetting of function, logging, authorisation, 
readability, usability, automation of routine events and the such.

So - to summarise - in the VM paradigm there is a single, "touchpoint" 

(SYSTEM OPERATOR) through which all asynchronous system status messages 

are channelled. This touchpoint is programmable and the end-capability is
 
therefore limited only by our imaginations and our ability to develop 
suitable code. As you have suggested, much commercial code is available 

that makes use of this touchpoint, but at a monetary cost. However, all 

the interfaces are documented and there is nothing to stop you from 
developing your own code that uses the touchpoint. (Note well that PROP i
s 
NOT the touchpoint - it's an example of a user of the touchpoint.)

Hope that helps - please publish a bit more background on what you're 
trying to achieve and then we can better advise you regarding what's 
already, "out there" and what you might have to, "roll yourself".

Regards,
Jeff Gribbin

Reply via email to