All good ideas. The original problem does not state if the userids are on the same system.
We had a similar problem: needing to run a command on one system (start the nightly VM:Backups on the system that has tape drives), gracefully shutdown zLinux P.O.C. servers on another system with which we share DASD, wait for the zLinux servers to logoff that system, and when the backups are complete, XAUTOLOG them on the remote system. Each system has CMS servers running WAKEUP. (VMBSYSAD running our NITEBKUP EXEC to supervise the backups on one, something like VMUTIL on the other). Communications between the two is via SMTP e-mail. One NITEBKUP sends the command to the remote system and waits for a reply in the reader. The remote system validates the sender, issues the commands to shutdown the zLinux servers listed in a common file, and sends email back with the return codes when they are logged off. When the NITEBKUP EXEC (home-grown over decades) finishes the backups, it sends e-mail back to the remote system to run a command which XAUTOLOGs the servers that were brought down previously. We get servers backed up with consistent filesystem states all from one VM:Backup server. No extra products. Obviously (don't EVEN go there!), should we ever get into production with zLinux, we'll need a REAL backup product to backup zLinux filesystems. Personally, I'd like that product to work hand-in-hand with our existing VM:Backup product which we z/VM'ers control on our own. (Anyone at CA listening????!!!!) I'm not delighted by the thought of having someone else responsible in a distributed environment for backups of production mainframe zLinux servers. It's not THEIR job if a zLinux server can't be restored quickly after some disaster (perhaps during a small D.R. test window?). It could be in their SLA's, but ultimately, I'd have to answer why that/those servers were down for that time period. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Thomas Kern" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 12/04/2008 06:03 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Starting an exec on a remote machine I can think of two mechanisms off-hand. 1) after X xautologs user B with command EXEC Y, it loops checking for user B being logged on. Once user B is no longer logged on, exec X can continue. 2) after X xautologs user B..., it waits for an SMSG from user B using the WAKEUP program. The EXEC Y needs to send X and SMSG just before logging indicating a successful/unsuccessful completion. /Tom Kern Howard Rifkind wrote: > I'm running exec X on cms user 'A' > > I exec X has to start exec Y running on cms user 'B' and after exec Y > terminates it has to return control to the exec on cms user 'A' > > I could use some suggestions as to the best way to do this. > > Thanks 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
