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
