Re: Writing a screen scrolling shell
I've done similar things in the past but in different ways: - routed all messages to z/OS where it was handled by the automation pack age there - used SA IOM (formerly AF/Remote) which would allow you to do all that a nd more, including the automation side of things. A very nice tool - possibly you could use ISPF which allows for the display to hold until a new message is received whereupon it is updated. Never tried it under VM but have done similar under z/OS numerous times Seb.
Re: Writing a screen scrolling shell
Jim Bohnsack jab...@cornell.edu wrote:- Colin--It sounds as if you are not really looking for a way to manage or respond to what shows up on a screen. Yes, absolutely, I need a look but not touch facility for external monitoring You merely want to handle all of the secuser'd messages that are sent to some collector user. Yes, this will be an automation PC that will generate alerts on a central alert console. 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. I did look at PROP, and I am still thinking about it, but it may be a little over the top in this case because I simply want everything received to appear on the screen (with no manipulation or processing or selection of the message) . . . The LGLOPER, logical operator, can be on a real live screen. Yes, that is a good point. . . . Jim Jim (and everyone else who responded to this), Thank you for your replies and thoughts on this. The key issue here is that it will not be a human that responds to this screen and there will not even be a real screen that anyone can see. As a result, the extra goodies like highlighting and holding messages on the screen are not only not needed but are exactly what can cause the problem with VM:Operator. (The buffering of held messages that never get cleared, because it is not a real screen, is almost certainly what causes it to run out of memory and stall). The process that is using these virtual screens will not be exactly a screen scraper but near enough to make no difference. What I was trying to do was produce something like the TPF consoles (that scroll like a teletype) so that the same automation can be used. I was trying to avoid having to deal with issues like MORE... HOLDING (even though they could be set to 0 0 the automation process would see it happening). As this is an external monitoring and alert process, the input of commands is not something that needs to be considered. The SECUSER we are want to deal with already goes to a VM:Operator instance so I suspect that what I am looking at is an action routine to echo the required console output to a dumb terminal of some type. I will certainly look at the three options mentioned (PROP, Perfkit OTTOSCR) to see if any of these can provide a base for what I need.. Colin Allinson Amadeus Data Processing GmbH IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees. It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws. If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system. Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Writing a screen scrolling shell
I have a simple fullscreen display program which can get its display data from rexx variables LINE.1 LINE.2 etc. You could update the stem suffixes by -1 and redisplay every time you get a new incoming message. The program is pretty basic, no colors or extended attributes, and only supports 24 lines. It really waits for input after each screen is displayed, but also has an option to 'timeout' after x seconds. Happy to share if you want it. Shimon Original message I need to get a screen to behave in a slightly different way to the standard 3270 screen. I need to collect SECUSER messages and get them to push up the screen, (so the oldest fall off the top), rather than filling the screen to MORE... and starting again with a clear screen.
Re: Writing a screen scrolling shell
OTTOSCR is an old tool to make fullscreen CMS scroll, don't know if it still runs http://www.vm.ibm.com/download/packages/descript.cgi?OTTOSCR With ROI, you'd have to write the new line with VSCREEN WRITE and linenumber 0, then maybe some WINDOW command to position the window at the end (if the VSCREEN is larger than the WINDOW But, very easy in my eyes: you could use XEDIT, basically a loop doing :1 DEL 1 * INSERT newLine :1 I don't know what your code will be waiting for. If you need to wait for either a message comming in either a SCIF message: there are no easy, REXXish, ways to get this done: For example: with XEDIT you have READ to wait for user action or WAKEUP to wait for a timer or messages, but the end-user's action on the XEDIT screen get lost. At my customer's installation we solved this by using WAKEUP for enable screen updates, when the operator wanted to do something, he had to press enter or some other key, causing WAKEUP to exit with RC 6. But our REXX code could now know what the operator did, so some prompting popup was displayed. Another operator tool used CMS/GUI, where the GUI generated a timer interrupt to VM every 2 seconds and the REXX code then checked for new messages with WAKEUP +0 (xxx. Consequently the operator diod not have to hit two keys to get something done. 2009/10/16 Colin Allinson cgallin...@amadeus.com: I need to get a screen to behave in a slightly different way to the standard 3270 screen. I need to collect SECUSER messages and get them to push up the screen, (so the oldest fall off the top), rather than filling the screen to MORE... and starting again with a clear screen. I did look to see if there was any way I could do this with Fullscreen CMS and I could not see how (although I have never really got to grips with this tool and there may be some configuration option that may make it possible. We have tried using VM:Operator and this, sort of, does what we want but there are some complexities caused by the fact that it is a far more general tool with many more functions. I could, of course, write my own shell but, before I set about this, it would be helpful to know if there is already something out there that will do this (or, at least, provide a base on which to work). Any ideas would be greatly appreciated Colin Allinson Amadeus Data Processing GmbH -- Kris Buelens, IBM Belgium, VM customer support
Re: Writing a screen scrolling shell
On Fri, Oct 16, 2009 at 1:42 PM, Colin Allinson cgallin...@amadeus.com wrote: I did look to see if there was any way I could do this with Fullscreen CMS and I could not see how (although I have never really got to grips with this tool and there may be some configuration option that may make it possible. Yes, we can ... I recall using the CMS PIpelines fullscr stage to build one that imitated the NetView style where the insertion point for the new line is rolling over the screen (to save bandwidth). With some extra effort you could also do something like MVS where a subset of the lines (the replies) stack at the top. If you want to insert the new line at the bottom (thus scroll the remaining lines up) you need to rewrite it all every time you add a line (which we found very intrusive on the termulators in those days). Don't have the code handy anymore, but could give it a try if it helps you out. Rob
Re: Writing a screen scrolling shell
Kris Buelens kris.buel...@gmail.com 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
Re: Writing a screen scrolling shell
Rob van der Heij rvdh...@gmail.com Wrote :- Yes, we can ... I recall using the CMS PIpelines fullscr stage to build one that imitated the NetView style where the insertion point for the new line is rolling over the screen (to save bandwidth). With some extra effort you could also do something like MVS where a subset of the lines (the replies) stack at the top. If you want to insert the new line at the bottom (thus scroll the remaining lines up) you need to rewrite it all every time you add a line (which we found very intrusive on the termulators in those days). Don't have the code handy anymore, but could give it a try if it helps you out. Rob I am not trying to do anything complicated like hold lines on the top of the screen (as with MVS) but one thing I had not considered is the point that you, correctly, make about having to rewrite the full screen all the time. That could majorly confuse the automation monitoring tool !! I am just having a reality check and wondering if it is not a lot simpler than I had been thinking. If I could remember how to define the screen (which would be virtual) as a (no)glass teletype then that should really do just what I want (I think). Colin Allinson Amadeus Data Processing GmbH
Re: Writing a screen scrolling shell
On Fri, 16 Oct 2009 13:42:58 +0200, Colin Allinson cgallin...@amadeus.co m wrote: I need to get a screen to behave in a slightly different way to the standard 3270 screen. I need to collect SECUSER messages and get them to push up the screen, (so the oldest fall off the top), rather than fillin g the screen to MORE... and starting again with a clear screen. I have a demo that does this using IBM Operations Manager for z/VM if you 'd like to contact me off-list. It also allows you to change the color of certain messages, hold some messages at the top (letting others scroll by ), etc. Tracy Dean IBM
Re: Writing a screen scrolling shell
I have an exec that uses OTTOSCR from the download site, I think it does pretty much what you are looking for. I wrote this several years ago when I had several VM's all running PROP and sending messages to this secondary user. It allows scrolling backward and forward and logging. If you want this exec you can have, no gaurentees. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Colin Allinson Sent: Friday, October 16, 2009 7:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Writing a screen scrolling shell Rob van der Heij rvdh...@gmail.com Wrote :- Yes, we can ... I recall using the CMS PIpelines fullscr stage to build one that imitated the NetView style where the insertion point for the new line is rolling over the screen (to save bandwidth). With some extra effort you could also do something like MVS where a subset of the lines (the replies) stack at the top. If you want to insert the new line at the bottom (thus scroll the remaining lines up) you need to rewrite it all every time you add a line (which we found very intrusive on the termulators in those days). Don't have the code handy anymore, but could give it a try if it helps you out. Rob I am not trying to do anything complicated like hold lines on the top of the screen (as with MVS) but one thing I had not considered is the point that you, correctly, make about having to rewrite the full screen all the time. That could majorly confuse the automation monitoring tool !! I am just having a reality check and wondering if it is not a lot simpler than I had been thinking. If I could remember how to define the screen (which would be virtual) as a (no)glass teletype then that should really do just what I want (I think). Colin Allinson Amadeus Data Processing GmbH
Re: Writing a screen scrolling shell
If you have PERFKIT, set up an additional virtual machine that has all data collection turned off, and use it in basic mode. It does a very nice job of being a scrolling operator display, and has nice message filtering and highlighting already built in.
Re: Writing a screen scrolling shell
I have two systems with PROP in OPERATOR sending messages to OP1. The real operators log onto OP1 for interaction with the systems. One system uses Full-Screen CMS with OTTOSCR and the second system uses the PERFKIT program to manage the console traffic. The PERFKIT setup does a better job. /Tom Kern /U.S. Dept of Energy /301-903-2211 David Boyes wrote: If you have PERFKIT, set up an additional virtual machine that has all data collection turned off, and use it in basic mode. It does a very nice job of being a scrolling operator display, and has nice message filtering and highlighting already built in.
Re: Writing a screen scrolling shell
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 kris.buel...@gmail.com 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" brfont size=1 face="sans-serif"bKris Buelens lt;kris.buel...@gmail.comgt;/b/fontfont size=2 face="sans-serif" Wrote (in part) :-/font br brttfont size=2gt; OTTOSCR is an old tool to make fullscreen CMS scroll, don't know if itbr gt; still runs/font/ttfont size=2 face="sans-serif"./font br brfont size=2 face="sans-serif"Kris,/font br brfont size=2 face="sans-serif"Thank you. I will certainly look at OTTOSCR. Even if it does not run quot;out of the boxquot;, it may give me a good basis to start from./font br brfont 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 brfont 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 brfont 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 brfont size=2 face="sans-serif"I really am looking to do something very simple./font br brfont size=2 color=#1a61a9 face="Arial"bbr Colin Allinson/b/fontfont size=1 face="Arial"bbr /b/fontfont size=1 color=#66 face="Arial"br Amadeus Data Processing GmbHbr /fontfont size=2 face="sans-serif"br /font --=_alternative 0044FA19C1257651_=-- -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
