Re: Writing a screen scrolling shell

Fri, 16 Oct 2009 17:45:03 -0700

Colin--It sounds as if you are not really looking for a way to manage or respond to what shows up on a screen.  You "merely" want to handle all of the secuser'd messages that are sent to some collector user.  You said that you had tried VM:Operator, but that there were some problems.  I use IBM's PROP, which is kind of ugly but I have many of our service machines secuser'd to SYSOP, which is where I run PROP.  It will trap any message you specify, using about any kind of filtering or detection as far as message content or sender you can think of, and then, if necessary, execute a routine or exec.  It can or does log everything it sees and you can get to that log anytime.  The LGLOPER, logical operator, can be on a real live screen.  I never run our SYSOP id with a console.  I don't even think you'd see anything on it.  It always is disconnected and the logical operator id has the screen contents that may need to be seen by a real live person (if any real live person ever looks in that direction).

Jim

Colin Allinson wrote: 
This is a multipart message in MIME format.
--=_alternative 0044FA19C1257651_=
Content-Type: text/plain; charset="US-ASCII"

Kris Buelens <[email protected]> Wrote (in part) :-

  
OTTOSCR is an old tool to make fullscreen CMS scroll, don't know if it
still runs.
    

Kris,

Thank you. I will certainly look at OTTOSCR. Even if it does not run "out 
of the box", it may give me a good basis to start from.

To explain a little more - what I am trying to do is quite simple really 
(but, as always,  with a couple of twists). This output screen will not 
need (and should not) wait for any input. The idea is that it will be 
monitored by external automation software looking for specific conditions 
and creating alerts. 

The userids generating the secuser output will, in fact, be TPF guests 
and, as the automation software already monitors the native TPF consoles 
(which scroll) then something that replicates this will eliminate the need 
for new monitoring routines being written.

The only complexity is that this will not be a 'real screen' but a soft 
virtual screen that is doing the monitoring. It is already working, sort 
of, with VM:Operator but there are some issues in the way it handles the 
screen that causes VM:Operator to run out of buffer memory after a couple 
of days (there are also display constraints). 

I really am looking to do something very simple.


Colin Allinson

Amadeus Data Processing GmbH


--=_alternative 0044FA19C1257651_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=1 face="sans-serif"><b>Kris Buelens &lt;[email protected]&gt;</b></font><font size=2 face="sans-serif">
Wrote (in part) :-</font>
<br>
<br><tt><font size=2>&gt; OTTOSCR is an old tool to make fullscreen CMS
scroll, don't know if it<br>
&gt; still runs</font></tt><font size=2 face="sans-serif">.</font>
<br>
<br><font size=2 face="sans-serif">Kris,</font>
<br>
<br><font size=2 face="sans-serif">Thank you. I will certainly look at
OTTOSCR. Even if it does not run &quot;out of the box&quot;, it may give
me a good basis to start from.</font>
<br>
<br><font size=2 face="sans-serif">To explain a little more - what I am
trying to do is quite simple really (but, as always, &nbsp;with a couple
of twists). This output screen will not need (and should not) wait for
any input. The idea is that it will be monitored by external automation
software looking for specific conditions and creating alerts. </font>
<br>
<br><font size=2 face="sans-serif">The userids generating the secuser output
will, in fact, be TPF guests and, as the automation software already monitors
the native TPF consoles (which scroll) then something that replicates this
will eliminate the need for new monitoring routines being written.</font>
<br>
<br><font size=2 face="sans-serif">The only complexity is that this will
not be a 'real screen' but a soft virtual screen that is doing the monitoring.
It is already working, sort of, with VM:Operator but there are some issues
in the way it handles the screen that causes VM:Operator to run out of
buffer memory after a couple of days (there are also display constraints).
</font>
<br>
<br><font size=2 face="sans-serif">I really am looking to do something
very simple.</font>
<br>
<br><font size=2 color=#1a61a9 face="Arial"><b><br>
Colin Allinson</b></font><font size=1 face="Arial"><b><br>
</b></font><font size=1 color=#666666 face="Arial"><br>
Amadeus Data Processing GmbH<br>
</font><font size=2 face="sans-serif"><br>
</font>
--=_alternative 0044FA19C1257651_=--

  

-- 
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
[email protected]

Reply via email to