Great suggestions! And yes - I agree this probably isn't worth automating - that's why I was looking for a 'native' solution.
But this has all given me some ideas about how to provide the Linux teams administering the Linux servers a way to easily restart servers: Example: Give a guest used by Linux support authority to do CP SEND .. then they can issue 'vmcp send cp guestid ipl 200 clear' on Linux to restart the guestid server.. I know I was looking for a complete restart.. but a way to reIPL the guests might be useful more of the time. (this has some security issues, I know ;-) Thanks! Scott On Thu, Oct 30, 2008 at 12:01 AM, Bruce Hayden <[EMAIL PROTECTED]> wrote: > Change your step that says "go into a loop" to say to wait for a > message from the *VMEVENT system service telling you the userid has > logged off. Once you get that message, then you can autolog.. > > I think an improvement would be to tell the "RECYCLVM" the Linux id > that is going to be recycled (it could be from Linux itself) and then > have the Linux id issue a signal shutdown to itself and the service > machine would wait for the VMEVENT information as before. That way, > you wouldn't have to set up some kind of authorization scheme so > unauthorized people could recycle your Linux servers. Since the Linux > server shuts itself down, you presume a root user did it. > > Pipelines can connect to *VMEVENT, but a better option would be to use > the support in VM operations manager to do it and have it manage the > whole thing. But, if you have the operations manager, you could just > have it watch the console for a certain message to appear (Linux > executed echo "$$$RECYCLE ME$$$" > /dev/console) and then just do the > shutdown and restart in an action routine... > > Personally, I think this is a rare enough event that it isn't worth > automating. You can dynamically add about anything now (CPUs, disks, > memory in the future) so the need for a recycle because of a directory > change would be more and more rare. > > On Thu, Oct 30, 2008 at 12:51 AM, Scott Rohling <[EMAIL PROTECTED]> > wrote: > > I didn't explain something very well in my initial post.. > > > > In the 2nd paragraph, where I talk about a CMS guest.. > > > > I meant to say that I could have a guest running CMS who could captures > MSGs > > or SMSGs sent to it -- and have a RECYCLE EXEC it ran if it received a > > message of 'recycle' from a Linux (or any other type of) guest.. The > > RECYCLE EXEC would: > > > > - Accept an argument of the userid to be recycled > > - Issue a CP SIGNAL SHUTDOWN userid (userid = the userid who sent > the > > msg) > > - Go into a loop and wait for CP Q USERID userid to get an RC45 > > (either the Linux guest will logoff or the SIGNAL timeout will log it > off) > > - CP XAUTOLOG userid once the above loop ends > > > > Let's say we set up a user called RECYCLVM who is a CMS guest who waits > for > > a MSG of 'RECYCLE'... (via WAKEUP) .. it would call RECYCLE EXEC > passing > > the userid of the user who sent the message. > > > > So now a Linux guest can issue: 'vmcp msg recyclvm recycle' > > > > I know I can do that fairly easily - but I think z/VM itself could do it > > fairly easily too. Whether it's worth the development effort -- umm..... > > Maybe the process above is cheapest ;-) > > > > Thanks - Scott > > -- > Bruce Hayden > Linux on System z Advanced Technical Support > IBM, Endicott, NY >
