Re: Starting an exec on a remote machine
One could also use the CMS Multitasking queues as mechanism. For the exec logic itself it would be transparent if the both users are on different systems or not. For cross-system, non SNA, support this would be required: TCP/IP line driver for CMS distributed queues. http://www.vm.ibm.com/download/packages/descript.cgi?TLD Instead of sockets, one'd code things like at the client: call csl 'QueueOpen mtrc mtre qn qnl sv svl qh el' call csl 'QueueSend mtrc mtre qh cmscmd cmdlen ko kl' and at the server; call csl 'QueueCreate mtrc mtre qn qnl vm_ipc_nlevel qh' call csl 'QueueReceiveBlock mtrc mtre qh ', 'matchkey matchkeylen timeout ', 'cmscmd rcvbuflen cmdlen ', 'ko kl suid spid rt' I've got a QDEMO/QCLIENT/QSERVER example created by Brian Wade that sends a CMS command for execution, but I no longer remember where I got them from. I can send them. 2008/12/5 Rempel, Horst [EMAIL PROTECTED]: Hello Howard, I use execa in usera that will start an execb in cms-userb or a shellscript in Linux. When you do it in a pipe the execa will wait until the end of execb (or shellscript) before continuing. The pipe will write the output of execb in a file. So execa can continue depending on the content of this file. | 'pipe cms rexec ... !', 'console !', ' 'remote_exec' output a' | This logic works well for me every night. If execb is a long running exec its possible that you have to code a timeout for rexec. But plan carefully ! REXEC can be a security risk ! I do it in a completly isolated network. Von: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Im Auftrag von Howard Rifkind Gesendet: Freitag, 5. Dezember 2008 00:52 An: IBMVM@LISTSERV.UARK.EDU Betreff: Starting an exec on a remote machine 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 _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- Kris Buelens, IBM Belgium, VM customer support
Re: Starting an exec on a remote machine
On Thursday, 12/04/2008 at 06:54 EST, Howard Rifkind [EMAIL PROTECTED] 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. If you're on the same VM system, REXEC is the best way to do that, assuming that user 'B' is not already logged on. REXEC has all the function to autolog a user, run a command, watch the console for output, send the output back to user A (as output from the 'rexec' command, trappable by a Pipe), and then logoff the user B. Use LOGON BY support so that User A doesn't have to know User B's password, just his own. (You can't do it using rexec without authentication. Well, you can, but then anyone could run the program in User B, not just User A.) If you're not on the same system, life gets more difficult since rexec isn't appropriate for open network connections as it isn't encrypted. One might be tempted to rexec into a local Linux guest that uses ssh to reach the remote system and use rexec over there, piping the response all the way back to you. This all assumes you're not wanting to write a remote execution solution yourself. If you do, just remember that you will need some sort of authentication and authorization. Alan Altmark z/VM Development IBM Endicott
Re: Starting an exec on a remote machine
Thanks Alan, After spending some time last night I found some processess, like you suggest below, which are run daily on our system to drag output from z/VM Rexx execs over to z/OS. Thanks again... Alan Altmark [EMAIL PROTECTED] 12/5/2008 9:34 AM On Thursday, 12/04/2008 at 06:54 EST, Howard Rifkind [EMAIL PROTECTED] 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. If you're on the same VM system, REXEC is the best way to do that, assuming that user 'B' is not already logged on. REXEC has all the function to autolog a user, run a command, watch the console for output, send the output back to user A (as output from the 'rexec' command, trappable by a Pipe), and then logoff the user B. Use LOGON BY support so that User A doesn't have to know User B's password, just his own. (You can't do it using rexec without authentication. Well, you can, but then anyone could run the program in User B, not just User A.) If you're not on the same system, life gets more difficult since rexec isn't appropriate for open network connections as it isn't encrypted. One might be tempted to rexec into a local Linux guest that uses ssh to reach the remote system and use rexec over there, piping the response all the way back to you. This all assumes you're not wanting to write a remote execution solution yourself. If you do, just remember that you will need some sort of authentication and authorization. Alan Altmark z/VM Development IBM Endicott _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Starting an exec on a remote machine
Kris, the QDEMO/QCLIENT/QSERVER demo package of Brian's can be downloaded off of his VM web page here: http://www.vm.ibm.com/devpages/BKW/ Look for the IPCSAMP package. BTW, that's an intriguing idea to use CMS multitaskings queues as the transport mechanism Kris Buelens wrote: One could also use the CMS Multitasking queues as mechanism. For the exec logic itself it would be transparent if the both users are on different systems or not. For cross-system, non SNA, support this would be required: TCP/IP line driver for CMS distributed queues. http://www.vm.ibm.com/download/packages/descript.cgi?TLD Instead of sockets, one'd code things like at the client: call csl 'QueueOpen mtrc mtre qn qnl sv svl qh el' call csl 'QueueSend mtrc mtre qh cmscmd cmdlen ko kl' and at the server; call csl 'QueueCreate mtrc mtre qn qnl vm_ipc_nlevel qh' call csl 'QueueReceiveBlock mtrc mtre qh ', 'matchkey matchkeylen timeout ', 'cmscmd rcvbuflen cmdlen ', 'ko kl suid spid rt' I've got a QDEMO/QCLIENT/QSERVER example created by Brian Wade that sends a CMS command for execution, but I no longer remember where I got them from. I can send them. 2008/12/5 Rempel, Horst [EMAIL PROTECTED]: Hello Howard, I use execa in usera that will start an execb in cms-userb or a shellscript in Linux. When you do it in a pipe the execa will wait until the end of execb (or shellscript) before continuing. The pipe will write the output of execb in a file. So execa can continue depending on the content of this file. | 'pipe cms rexec ... !', 'console !', ' 'remote_exec' output a' | This logic works well for me every night. If execb is a long running exec its possible that you have to code a timeout for rexec. But plan carefully ! REXEC can be a security risk ! I do it in a completly isolated network. Von: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Im Auftrag von Howard Rifkind Gesendet: Freitag, 5. Dezember 2008 00:52 An: IBMVM@LISTSERV.UARK.EDU Betreff: Starting an exec on a remote machine 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 _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Starting an exec on a remote machine
CA ARCServe Backup for Mainframe Linux works with VM:Tape, but not VM:Backup. I'm not allowed to endorse products (or unendorse them?). I can say that we don't use the product. A reliable product that works with VM:Backup would at least get looked at here. Our current plan is to back z/VM up with VM:Backup, and back Linux guests up with the same product that we use for midrange Linux. Dennis We have awakened a sleeping giant, and we have instilled in him a terrible resolve. -- Admiral Yamamoto, following the attack on Pearl Harbor -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, December 04, 2008 17:33 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Starting an exec on a remote machine 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) Yes, what he said! Marcy 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.
Re: Starting an exec on a remote machine
A couple of options come to mind: 1) Use REXEC to have user B execute EXEC Y 2) Use XAUTOLOG to log on the user and specify the EXEC Y as one of the operands, so that it starts automatically. Have EXEC Y either send an SMSG or file to user A to notify him that EXEC Y is done. Let's see what the REAL gurus come up with. David Wakser From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Thursday, December 04, 2008 6:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Starting an exec on a remote machine 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 _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
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
Re: Starting an exec on a remote machine
Instead of WAKEUP, a Pipe using the starmsg driver would also work. If I am only waiting for 1 thing and the process has to be synchronous, I usually use a structure like: 'CP SET SMSG IUCV' 'PIPE (end ? NAME SMsg)', '? starmsg *msg cp xautolog userB #EXEC Y', if this is the is the correct message then end the program, '| cons' The stages implied by the ... would presumably end with a pipestop stage when the expected message is received.. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, December 04, 2008 4:03 PM To: IBMVM@LISTSERV.UARK.EDU 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
Re: Starting an exec on a remote machine
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.
Re: Starting an exec on a remote machine
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) Yes, what he said! Marcy 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.
Re: Starting an exec on a remote machine
On Dec 4, 2008, at 7:32 PM, Marcy Cortes wrote: 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) Yes, what he said! If anyone on the list is interested in building a solution around Bacula on your Linux guests talking to VM:Backup (or DFSMS) on the back end and using its catalog, well, you know where to find us. Adam
Re: Starting an exec on a remote machine
You can look at RSCLIENT and RSSERVER EXEC's on your 190 disk for examples of how to use REXX SOCKETS to do what you want.. All you need is TCP/IP and a little REXX coding. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Howard Rifkind Sent: Thursday, December 04, 2008 5:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Starting an exec on a remote machine 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 _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
