Re: COPY RDR to another machine
No, TRANSFER is what it says, the object is transferred, not copied/cloned/xxx As you do not have the privilege to use DIAG D4 to set the origin, you could create a service machine that has the privilege, it could perform the copies of the spool files x times. 2009/9/22 Gonen Shoham gone...@sapiens.com TRAN RDR does it ok, but deletes the file from my reader. Is there anyway to keep the RDR after TRAN RDR ? The reason is that I need to TRAN the RDR many times . Thanks -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Thursday, September 17, 2009 10:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: COPY RDR to another machine I doubt that COPYRDR keeps *all* the properties, e.g. creation time will be changed. For an exact copy: SPXTAPE to dump the RDR file to tape, then restore on the target system. If you only need to set the origin userid: use Diagnose D4 to set the alternate userid of the copying user to the sender's userid. As this is cheating, one needs a special CP class to be able to use Diag D4; and if an ESM is installed, extra permissions are required in the ESM (for RACF that is in class VMBATCH). My RxServer package contains a DIAGD4 MODULE, you would use this sequence: DIAGD4 copier sender EXEC COPYRDR DIAGD4 copier OFF 2009/9/17 Gonen Shoham gone...@sapiens.com Hi I have the COPYRDR exec (from long time ago) which sends RDR file from one machine to another - keeping ALL the original RDR file properties. I found out that the USER which sent the original RDR file is not kept when the RDR is copied to another user. Can someone suggest a better way to replicate RDR file from one machine to another with keeping the original user ? many thanks -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: COPY RDR to another machine
On Tuesday, 09/22/2009 at 03:10 EDT, Gonen Shoham gone...@sapiens.com wrote: TRAN RDR does it ok, but deletes the file from my reader. Is there anyway to keep the RDR after TRAN RDR ? The reason is that I need to TRAN the RDR many times . No. A spool file exists only once in the system. That will drive the design of your spool file sprayer application. If you want spool files to appear as though they are from someone else, then you must have the authorization to use DIAGNOSE 0xD4 and use it as Kris showed. If your application is willing to do some more work, then it can use DIAGNOSE 0xF8 to establish and determine the origin of the spool file. While it doesn't require class D, it nonetheless requires SETORIG authorization in the sprayer's directory entry. (By the way, Diagnose 0xD4 can be moved to some other privclass, e.g. N, and given to those who need it, without giving all the power of class D.) Virtual machines are not allowed to tell lies about themselves unless they are authorized to do so. Alan Altmark z/VM Development IBM Endicott
Re: COPY RDR to another machine
If you're trying to impersonate someone else, that's privileged. If, however, you have a business need and own the process (archiving a copy of mail on a service machine, for instance) then save the origin node and userid in one of the unused Options (that will allow it) and let the SM pick them out. Les Rob van der Heij wrote: On Fri, Sep 18, 2009 at 1:42 PM, Gonen Shoham gone...@sapiens.com wrote: I do not know why, but I am almost sure that COPYRDR really maintained the original userid. It could only if it was authorized to do so. It is an exposure if you can create spool files that appear to originate from someone else (for example in the days of PROFS). Nothing guarantees that your COPYRDR program did not modify the contents in the process. My guess is they used Alan's trick to transfer the original and keep a copy. Rob
Re: COPY RDR to another machine
Thanks I do not know why, but I am almost sure that COPYRDR really maintained the original userid. Anyone has the most current code of COPYRDR ? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Friday, September 18, 2009 12:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: COPY RDR to another machine On Thursday, 09/17/2009 at 05:20 EDT, Gonen Shoham gone...@sapiens.com wrote: I cannot use a tape for this. I need it to work like TRAN RDR except that I do not have the ability to get the privilege required... If you don't have the needed privileges, then you are not permitted to send files that appear to be from someone else. There are no tools that get around that. If *you* don't mind having the origin user ID changed, then you can spool the *copy* to yourself and TRANSFER the original to the other person. Alan Altmark z/VM Development IBM Endicott
Re: COPY RDR to another machine
On Fri, Sep 18, 2009 at 1:42 PM, Gonen Shoham gone...@sapiens.com wrote: I do not know why, but I am almost sure that COPYRDR really maintained the original userid. It could only if it was authorized to do so. It is an exposure if you can create spool files that appear to originate from someone else (for example in the days of PROFS). Nothing guarantees that your COPYRDR program did not modify the contents in the process. My guess is they used Alan's trick to transfer the original and keep a copy. Rob
COPY RDR to another machine
Hi I have the COPYRDR exec (from long time ago) which sends RDR file from one machine to another - keeping ALL the original RDR file properties. I found out that the USER which sent the original RDR file is not kept when the RDR is copied to another user. Can someone suggest a better way to replicate RDR file from one machine to another with keeping the original user ? many thanks
Re: COPY RDR to another machine
I doubt that COPYRDR keeps *all* the properties, e.g. creation time will be changed. For an exact copy: SPXTAPE to dump the RDR file to tape, then restore on the target system. If you only need to set the origin userid: use Diagnose D4 to set the alternate userid of the copying user to the sender's userid. As this is cheating, one needs a special CP class to be able to use Diag D4; and if an ESM is installed, extra permissions are required in the ESM (for RACF that is in class VMBATCH). My RxServer package contains a DIAGD4 MODULE, you would use this sequence: DIAGD4 copier sender EXEC COPYRDR DIAGD4 copier OFF 2009/9/17 Gonen Shoham gone...@sapiens.com Hi I have the COPYRDR exec (from long time ago) which sends RDR file from one machine to another - keeping ALL the original RDR file properties. I found out that the USER which sent the original RDR file is not kept when the RDR is copied to another user. Can someone suggest a better way to replicate RDR file from one machine to another with keeping the original user ? many thanks -- Kris Buelens, IBM Belgium, VM customer support
Re: COPY RDR to another machine
If you have VSSI's VTAPE product, you can use VTAPE for the SPXTAPE, assuming you are using a fairly recent build. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Thursday, September 17, 2009 12:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: COPY RDR to another machine I doubt that COPYRDR keeps *all* the properties, e.g. creation time will be changed. For an exact copy: SPXTAPE to dump the RDR file to tape, then restore on the target system. If you only need to set the origin userid: use Diagnose D4 to set the alternate userid of the copying user to the sender's userid. As this is cheating, one needs a special CP class to be able to use Diag D4; and if an ESM is installed, extra permissions are required in the ESM (for RACF that is in class VMBATCH). My RxServer package contains a DIAGD4 MODULE, you would use this sequence: DIAGD4 copier sender EXEC COPYRDR DIAGD4 copier OFF 2009/9/17 Gonen Shoham gone...@sapiens.commailto:gone...@sapiens.com Hi I have the COPYRDR exec (from long time ago) which sends RDR file from one machine to another - keeping ALL the original RDR file properties. I found out that the USER which sent the original RDR file is not kept when the RDR is copied to another user. Can someone suggest a better way to replicate RDR file from one machine to another with keeping the original user ? many thanks -- Kris Buelens, IBM Belgium, VM customer support
Re: COPY RDR to another machine
I cannot use a tape for this. I need it to work like TRAN RDR except that I do not have the ability to get the privilege required... -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Thursday, September 17, 2009 10:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: COPY RDR to another machine I doubt that COPYRDR keeps *all* the properties, e.g. creation time will be changed. For an exact copy: SPXTAPE to dump the RDR file to tape, then restore on the target system. If you only need to set the origin userid: use Diagnose D4 to set the alternate userid of the copying user to the sender's userid. As this is cheating, one needs a special CP class to be able to use Diag D4; and if an ESM is installed, extra permissions are required in the ESM (for RACF that is in class VMBATCH). My RxServer package contains a DIAGD4 MODULE, you would use this sequence: DIAGD4 copier sender EXEC COPYRDR DIAGD4 copier OFF 2009/9/17 Gonen Shoham gone...@sapiens.com Hi I have the COPYRDR exec (from long time ago) which sends RDR file from one machine to another - keeping ALL the original RDR file properties. I found out that the USER which sent the original RDR file is not kept when the RDR is copied to another user. Can someone suggest a better way to replicate RDR file from one machine to another with keeping the original user ? many thanks -- Kris Buelens, IBM Belgium, VM customer support
Re: COPY RDR to another machine
On Thursday, 09/17/2009 at 05:20 EDT, Gonen Shoham gone...@sapiens.com wrote: I cannot use a tape for this. I need it to work like TRAN RDR except that I do not have the ability to get the privilege required... If you don't have the needed privileges, then you are not permitted to send files that appear to be from someone else. There are no tools that get around that. If *you* don't mind having the origin user ID changed, then you can spool the *copy* to yourself and TRANSFER the original to the other person. Alan Altmark z/VM Development IBM Endicott
