I leave on vacation tomorrow and will not return to the office until Aeptember 19, so there is no great rush.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, August 30, 2007 10:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles I'll look into publishing it, but -if no time next week- if will be after September 17. 2007/8/30, Schuh, Richard <[EMAIL PROTECTED]>: And there is no VMSTAT in the Download Library :-( That sounds like something that could be useful. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto: [EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, August 30, 2007 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles It's not a product, it is named VMSTAT. 2007/8/30, Schuh, Richard <[EMAIL PROTECTED] >: That sounds nice. What is the name of your product? :-) Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Wednesday, August 29, 2007 11:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles My customer has 18 VM systems... A problem with managing many VM systems is that operators need to see that there is a problem. Problems can go away automatically too (e.g. a queue on a RSCS link). We had a central VM:OPER console where problems got listed as HOLDMSG, and these messages can be removed when the automation procedures detect the problem is gone, so problems need a unique identifier. The standard HOLDMSG procedure is not good enough for this, so we started an extra VM:OPER process that grabs our own HOLDMSG/REMOVEMSG messages. But, even then it was not perfect yet. So, I wrote a CMS/GUI application with a screen where all important problems are displayed, VM systems can get green/yellow/red state, depending on the worst message for that system. It is an RxServer based server that collects the messages and maintains the system states; the CMS/GUI is only the nice front-end. Each message there has a severity and a key too, plus timing information. The key allows processes to set and remove the problem state (hence remove the message when the problem is gone), the timing info (when present) can make that the message goes automatically away after that many minutes (eg if you measure an RSCS queue every 5 minutes, you code "6 minutes" as timing info; the key could be "linkeid%QUEUE": our server then knows that it will remove the problem with that key if after 6 minutes there is no new message arrived for "linkid%QUEUE" To the key, operator help information can be linked so that with a double mouse click the operator can see what he has to do to fix the problem. More information as well as the code can be sent. 2007/8/29, Schuh, Richard <[EMAIL PROTECTED] >: Thanks, Mike. I had not seen your previous post before I responded to Bob. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, August 29, 2007 2:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles Yep, again. See "Chapter 10". Mike Walter ________________________________ ----- Original Message ----- From: "Schuh, Richard" [EMAIL PROTECTED] Sent: 08/29/2007 04:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles I was thinking more along the lines of operating all systems from one terminal. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Bates Sent: Wednesday, August 29, 2007 2:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OPERATOR Consoles Sure. If you can logon to the system, VM:Operator can have a console there. The OPERATOR id can be anywhere. Authorized users can be defined to logon and run VMYIAMOP to get a copy of the console. The definition of the user within VM:Operator says what screens the user can see and what commands if any they can execute. Bob Bates Enterprise Hosting Services - z/VM and z/Linux <http://ehs.homestead.wellsfargo.com/C1/MOBS/WebPart%20Pages/zVM.aspx> w. (972) 753-5967 c. (214) 907-5071 "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 29, 2007 4:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: OPERATOR Consoles In the not too distant future, we will possibly have VM systems scattered almost as widely as we have datacenters. What products are available that would allow the operations of these systems to be handled from a single location, if such exist? For example, can VM:Operator be used across a span of 2000 miles in the continental US? Between the US and Japan? Are there other products that can do the job? Regards, Richard Schuh ________________________________ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
