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 L 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? J > > > > 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: [EMAIL PROTECTED] > * 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
