Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 08/27/2008 at 07:48 EDT, Thomas Kern [EMAIL PROTECTED] wrote: If the VM stack and the linux stack were both connected to a VSWITCH, would monitoring function in the physical switch see that clear text data is being transfered from VM to linux? No. Data is sent directly to the target guest. If you connected the two with a private VSWITCH that did not have any OSA, you would guarantee that even an ARP broadcast will not be seen. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Oh Drat. :( We have a mandate that ALL FTP must be secure FTP, and it's going to be enforced very (VERY) soon. We may have to continue doing the darned intermediate file method in order to use the CMS FTP client. :( -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 22, 2008 5:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Wednesday, 08/20/2008 at 03:20 EDT, Michael Coffin [EMAIL PROTECTED] wrote: I'm not in front of a VM terminal, so forgive me is this is documented - but is secure FTP supported? I don't recall seeing a parm for it (doesn't mean it's not there and I didn't see it). :) Not in the FTPPUT and FTPGET stages directly, no, as they don't use the CMS FTP client to do their work. The APIs that provide secure ftp are not available to REXX and C sockets. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 08/27/2008 at 06:20 EDT, Michael Coffin [EMAIL PROTECTED] wrote: Oh Drat. :( We have a mandate that ALL FTP must be secure FTP, and it's going to be enforced very (VERY) soon. We may have to continue doing the darned intermediate file method in order to use the CMS FTP client. :( I would use a Linux FTP proxy running next door to TCPIP that can connect with ftps. Think of the proxy as 1/2 of the FTP client. Taken together they constitute the originating host. The network interface on Linux and the network interface on VM TCP/IP could be thought of as two interfaces on the same IP stack. The phrase FTP proxy need not come up in any conversation. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
If the VM stack and the linux stack were both connected to a VSWITCH, would monitoring function in the physical switch see that clear text data is being transfered from VM to linux? /Tom Kern Alan Altmark wrote: On Wednesday, 08/27/2008 at 06:20 EDT, Michael Coffin [EMAIL PROTECTED] wrote: Oh Drat. :( We have a mandate that ALL FTP must be secure FTP, and it's going to be enforced very (VERY) soon. We may have to continue doing the darned intermediate file method in order to use the CMS FTP client. :( I would use a Linux FTP proxy running next door to TCPIP that can connect with ftps. Think of the proxy as 1/2 of the FTP client. Taken together they constitute the originating host. The network interface on Linux and the network interface on VM TCP/IP could be thought of as two interfaces on the same IP stack. The phrase FTP proxy need not come up in any conversation. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 08/20/2008 at 03:20 EDT, Michael Coffin [EMAIL PROTECTED] wrote: I'm not in front of a VM terminal, so forgive me is this is documented - but is secure FTP supported? I don't recall seeing a parm for it (doesn't mean it's not there and I didn't see it). :) Not in the FTPPUT and FTPGET stages directly, no, as they don't use the CMS FTP client to do their work. The APIs that provide secure ftp are not available to REXX and C sockets. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
¿SPXTAPE will support dump to disk in the future? Thanks 2008/8/20 Dave Jones [EMAIL PROTECTED] Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
This is huge! Thanks Jiri! If we were all on FBA, then copying disks would be as trivial as copying files because the disk would be must a big block-o-bytes. But since z/VM is still saddled with ye olde CKD tricks because of the indirect influence of z/OS, this new ability to *convert* a disk (image) to a block-o-bytes is ... well, it's HUGE. Awesome! -- R;
Re: DDR'ing 3390 DASD To Remote Location
CA's V/Seg does backup and restore DCSS/NSS/NLS/UCR files to disk and maintain the original Date/Time/OriginID information when/if the files are restored from the backup. Of course the restored file does inherit a new SpoolFileNumber ... and there is no automated remote capability. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, August 20, 2008 09:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I'm surprised that your posting about being able to backup/restore DCSS/NSS files to disk was not jumped on by a lot of people. I'd love to have that. Does it/can it restore the original creation DCSS/NSS date? The date problem and the fact that IBM's DCSSBKUP only works with DCSS's, not NSS's, is a big drawback. This is especially significant, given my new, remote, connection to Cornell. I'm semi-retired and working from my house in Plano, TX. I'd like to be able to minimize the calls to operations to mount a tape. If you want to contact me off-line, I'm [EMAIL PROTECTED] Jim Dave Jones wrote: Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
Re: DDR'ing 3390 DASD To Remote Location
Please let us know where we can find it when you are ready. Sounds pretty good to me.. Another step towards a tapeless society. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Dave Jones Sent: Wednesday, August 20, 2008 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
¿SPXTAPE will support dump to disk in the future? There's a requirement for supporting PIPE connections like the DDR mods that were just made available. Status is unknown at the moment other than IBM has seen it and seems to understand the desire for the function, but hasn't made any public statements of when or if they will do this. It would be nice, though, wouldn't it? (BTW, Jiri - the DDR work looks good for us. Beer is definitely on us next time.) -- db
Re: DDR'ing 3390 DASD To Remote Location
Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Gang, I've just sent it off to Fran to be included on his VM download web page. He'll post a note here when it's ready to go. There are two (somewhat cryptic) documentation files included. Huegel, Thomas wrote: Please let us know where we can find it when you are ready. Sounds pretty good to me.. Another step towards a tapeless society. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Dave Jones Sent: Wednesday, August 20, 2008 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
And it does have that very important prereq - you must have V/Seg. Another option is VSSI's VTAPE. It is possible to use a VTAPE as the device for SPXTAPE . However, before you try it, make sure you have a current build of VTAPE. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Imler, Steven J Sent: Thursday, August 21, 2008 4:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location CA's V/Seg does backup and restore DCSS/NSS/NLS/UCR files to disk and maintain the original Date/Time/OriginID information when/if the files are restored from the backup. Of course the restored file does inherit a new SpoolFileNumber ... and there is no automated remote capability. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, August 20, 2008 09:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I'm surprised that your posting about being able to backup/restore DCSS/NSS files to disk was not jumped on by a lot of people. I'd love to have that. Does it/can it restore the original creation DCSS/NSS date? The date problem and the fact that IBM's DCSSBKUP only works with DCSS's, not NSS's, is a big drawback. This is especially significant, given my new, remote, connection to Cornell. I'm semi-retired and working from my house in Plano, TX. I'd like to be able to minimize the calls to operations to mount a tape. If you want to contact me off-line, I'm [EMAIL PROTECTED] Jim Dave Jones wrote: Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
Re: DDR'ing 3390 DASD To Remote Location
Dave Jones' SFB VMARC is now on my download page at http://zvm.sru.edu/~download or http://zvm.sru.edu/~download/SFB.VMARC As Dave says in his DOC: The normal distribution is for z/VM 5.1 5.2 and 5.3 I haven't been able to get it to work in z/VM 3.1 . Note that the download may be slow because this is the beginning of the semester and students are fiercely dropping and adding courses. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- On Thu, 21 Aug 2008 10:22:32 -0500 Dave Jones said: Gang, I've just sent it off to Fran to be included on his VM download web page. He'll post a note here when it's ready to go. There are two (somewhat cryptic) documentation files included.
Re: DDR'ing 3390 DASD To Remote Location
I now have running on z/VM 3.1 PIPEDDR, FTPPUT and FTPGET. Thanks Bruce, /Fran --- On Thu, 21 Aug 2008 11:10:27 -0400 Bruce Hayden said: Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Hello, In its current implementation DRPC requires z/Architecture and therefore it will not run under z/VM 3.1. I'll try to look at the code again, see if I can change this, but it will probably require a bit of work. -George z/VM I/O Development IBM Endicott The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/21/2008 01:26:35 PM: I now have running on z/VM 3.1 PIPEDDR, FTPPUT and FTPGET. Thanks Bruce, /Fran --- On Thu, 21 Aug 2008 11:10:27 -0400 Bruce Hayden said: Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
Since the DRPC package has now made the ftpget/ftpput stages available and documented them, I added an ftp option to my PIPEDDR package so that disks can be dumped and restored to and from and ftp server. You can find it at http://www.vm.ibm.com/download/packages/descript.cgi?pipeddr via the vmarc archive link on that page. Note that PIPEDDR does not use the new DDR stage discussed in this thread, just the ftp stages made available with the DRPC package. And, in case it is not obvious, the output files written by the DDR pipe stage and PIPEDDR are not compatible - you must use the same utility to restore a disk that you used to dump it. I'll gladly accept any feedback on the ftp option. I have some ideas on further improvements, but I wanted to get a version out there with the new support and get any feedback about its use. -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
I'm not in front of a VM terminal, so forgive me is this is documented - but is secure FTP supported? I don't recall seeing a parm for it (doesn't mean it's not there and I didn't see it). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Stehlik Sent: Tuesday, August 19, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR'ing 3390 DASD To Remote Location A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: DDR'ing 3390 DASD To Remote Location
I'm surprised that your posting about being able to backup/restore DCSS/NSS files to disk was not jumped on by a lot of people. I'd love to have that. Does it/can it restore the original creation DCSS/NSS date? The date problem and the fact that IBM's DCSSBKUP only works with DCSS's, not NSS's, is a big drawback. This is especially significant, given my new, remote, connection to Cornell. I'm semi-retired and working from my house in Plano, TX. I'd like to be able to minimize the calls to operations to mount a tape. If you want to contact me off-line, I'm [EMAIL PROTECTED]. Jim Dave Jones wrote: Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: DDR'ing 3390 DASD To Remote Location
Waw, that sounds great. 2008/8/19 Jiri Stehlik [EMAIL PROTECTED]: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Kris Buelens, IBM Belgium, VM customer support
Re: DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC 'Bout darn time. First of all, THANK YOU. That's been needed for AGES. Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Cool. Notice that this project is still a work in progress, therefore feedback is welcomed! Q: does this version also include the CMSDDR mods? So, when do you start on SPXTAPE? 8-) -- db
Re: DDR'ing 3390 DASD To Remote Location
Fantastic! That was me asking about that, I ended up using PIPE TRACKREAD, creating an intermediate file, and VMFTP'ing that (but it's VERY time consuming). I'll take a look at your mods ASAP and give you feedback (do you want it here or privately, if the latter is your email in the package?). Thanks George, can't wait to try it out! :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Stehlik Sent: Tuesday, August 19, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR'ing 3390 DASD To Remote Location A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: DDR'ing 3390 DASD To Remote Location
Hi Dave, Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. Yep, George has been working on this project with that exact requirement in mind. Considering the recent discussions here on this very topic, we thought we'd try to get some feedback on it now instead of waiting to get it into the release stream. If the feedback is positive, it'll certainly join the actual product in a future deliverable. Q: does this version also include the CMSDDR mods? No, this is an otherwise unmodified DDR module. For the purposes of this download, we wanted to limit the changes within a single deliverable. Regards, Eric Eric Farman z/VM I/O Development IBM Endicott, NY (607)429-4958 (tie 620)
Re: DDR'ing 3390 DASD To Remote Location
Yep, George has been working on this project with that exact requirement in mind. Fantastic. That's exactly what I wanted to hear. Q: does this version also include the CMSDDR mods? No, this is an otherwise unmodified DDR module. Yeah, about 3 seconds after hitting send I realized that with PIPE support CMSDDR becomes as simple as DDR FOO BAR A | OUTFILE DDR B, so I didn't need CMSDDR any longer anyway. Cool. Thanks for making it happen. Beer's on us next time I'm in Endicott. -- db
Re: DDR'ing 3390 DASD To Remote Location
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED] wrote: Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Details details details.! Thanks Alan Altmark wrote: On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED] wrote: Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott -- 'in media stat virtus' Virtue's in the middle
Re: DDR'ing 3390 DASD To Remote Location
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? Run INSTPIPE MODULE from MAINT 2CC. Adam
Re: DDR'ing 3390 DASD To Remote Location
LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott Well, far be it from me that I suggest that VM Development begin to talk to themselves. You lot 're odd enough to begin with...8-) -- db
Re: DDR'ing 3390 DASD To Remote Location
Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So once you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/19/2008 02:39:55 PM: On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:48 PM, David Boyes wrote: Well, far be it from me that I suggest that VM Development begin to talk to themselves. You lot 're odd enough to begin with...8-) As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. Adam
Re: DDR'ing 3390 DASD To Remote Location
As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. You see, I was never worried about it when I talked to myself. I only started to wonder when I started ANSWERING myself. That's when even the wife and kids leave the room and stay out of my way! (as they probably should!!) Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said: Run INSTPIPE MODULE from MAINT 2CC. I'm stuck on z/VM 3.1 because I am on a FLEX-ES box. I found INST* files on MAINT 2C2 but not FTPGET or FTPPUT. I have the latest Princeton Runtime Distribution but there is no FTPGET or FTPPUT stages. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. I prefer to think of this as discussing the problem with the person who understands it the best. That's my story and I'm sticking with it. Nora Graves
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 2:29 PM, Fran Hensler wrote: On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said: Run INSTPIPE MODULE from MAINT 2CC. I'm stuck on z/VM 3.1 because I am on a FLEX-ES box. I found INST* files on MAINT 2C2 but not FTPGET or FTPPUT. I have the latest Princeton Runtime Distribution but there is no FTPGET or FTPPUT stages. Fortunately, then, they are in the DDR stage that George just added. The stages appeared in 5.1 to support the DVD install of z/VM. I would not expect earlier releases to have them on MAINT 2CC. Adam
Re: DDR'ing 3390 DASD To Remote Location
Now if we could get the TERSE/DETERSE stages added, we might get these du mps down to a better size for transferring cross-country. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro te: Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So o nce you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, August 19, 2008 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Now if we could get the TERSE/DETERSE stages added, we might get these du= mps down to a better size for transferring cross-country. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro= te: Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So o= nce you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then reading then, compressing them and writing them as cms files is too much I/O for the process. A pipe stage to properly compress the piped input is necessary for efficiency. The PACK stage can be used but it doesn't buy y ou as much as other well-known compression algorithms. Being able to use the LZCOMPACT option on the DDR OUTPUT control statement might make the outpu t small enough to then use PACK simply to maintain record boundaries nicely and possibly to keep the data in a buffer size that is good for an encryption stage. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 13:22:27 -0700, Schuh, Richard [EMAIL PROTECTED] wrot e: Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh
Re: DDR'ing 3390 DASD To Remote Location
No. it doesn't. Keep plugging for a way. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, August 19, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then reading then, compressing them and writing them as cms files is too much = I/O for the process. A pipe stage to properly compress the piped input is necessary for efficiency. The PACK stage can be used but it doesn't buy y= ou as much as other well-known compression algorithms. Being able to use the= LZCOMPACT option on the DDR OUTPUT control statement might make the outpu= t small enough to then use PACK simply to maintain record boundaries nicely= and possibly to keep the data in a buffer size that is good for an encryption stage. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 13:22:27 -0700, Schuh, Richard [EMAIL PROTECTED] wrot= e: Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh
Re: DDR'ing 3390 DASD To Remote Location
Thanks George. Works really well. Ran backup of VMSRES (mod3) in 8 minutes using LZ and pack (600MB) to my desktop and the restore of a mdisk from the backup worked just fine. Thanks very much. Hans -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Stehlik Sent: August 19, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR'ing 3390 DASD To Remote Location A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: DDR'ing 3390 DASD To Remote Location
On Wednesday, 06/18/2008 at 01:01 EDT, McKown, John [EMAIL PROTECTED] wrote: If this is like some things in z/OS, the response from IBM development will be along the lines of: It is not documented because we don't want anyone else to use it. We don't want others to use it because if they do, then we must support it. And if we support it, then we cannot make arbitrary changes to it to implement what we want, should __our__ needs change. That's pretty much it, yes. We wrote an internal utility that let's us do FTP installs of z/VM; a very specific function for a very specific kind of data. We test that it works for our purposes. We don't verify that it will work for *any* purpose. Ergo we don't document it and any use of it in any other context is unsupported. That is, we won't accept APARs on it unless you can't install z/VM using it and we won't feel the slightest bit of guilt if we change how it works, the inputs, the outputs, the format, or delete it altogether. Making something generally useful and supported is far more expensive that just documenting things. We had business justification to provide a way to do an FTP install. We didn't have a justification to introduce a general-purpose remote ddr function. If the difference between supported and unsupported was just an hour's worth of work, there's be a LOT more things in VM. They might not work very well, but at least there'd be a lot of 'em! I think country music artist Garth Brooks said it best: Thank God for unanswered prayers. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Wouldn't it be 'nice' if things like that were 'available' to the rest of the community. 'Unsupported' is fine just put out a disclaimer 'Use at Your Own Risk' and put them on a download page... -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Alan Altmark Sent: Friday, June 20, 2008 1:07 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Wednesday, 06/18/2008 at 01:01 EDT, McKown, John [EMAIL PROTECTED] wrote: If this is like some things in z/OS, the response from IBM development will be along the lines of: It is not documented because we don't want anyone else to use it. We don't want others to use it because if they do, then we must support it. And if we support it, then we cannot make arbitrary changes to it to implement what we want, should __our__ needs change. That's pretty much it, yes. We wrote an internal utility that let's us do FTP installs of z/VM; a very specific function for a very specific kind of data. We test that it works for our purposes. We don't verify that it will work for *any* purpose. Ergo we don't document it and any use of it in any other context is unsupported. That is, we won't accept APARs on it unless you can't install z/VM using it and we won't feel the slightest bit of guilt if we change how it works, the inputs, the outputs, the format, or delete it altogether. Making something generally useful and supported is far more expensive that just documenting things. We had business justification to provide a way to do an FTP install. We didn't have a justification to introduce a general-purpose remote ddr function. If the difference between supported and unsupported was just an hour's worth of work, there's be a LOT more things in VM. They might not work very well, but at least there'd be a lot of 'em! I think country music artist Garth Brooks said it best: Thank God for unanswered prayers. Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, June 20, 2008 9:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Wouldn't it be 'nice' if things like that were 'available' to the rest of the community. 'Unsupported' is fine just put out a disclaimer 'Use at Your Own Risk' and put them on a download page... From our point of view, yes. From IBM's, no. Why? Because, sure a taxes, somebody would ignore the use at own risk and put the thing into some production process. Later, IBM changes something and the production process fails. The original person is gone that implemented the process is gone. The person now stuck with it calls IBM and is told tough toenails. The management of the company is now angry at IBM for not supporting this business critical process. Not a good thing from IBM's standpoint. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: DDR'ing 3390 DASD To Remote Location
Maybe the question to ask is: Is there any way that we, the customers, could assist IBM in bringing these tools up to supported status, in a manner which in IBM's view is cost effective and meets their business objectives? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: June 20, 2008 10:31 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, June 20, 2008 9:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Wouldn't it be 'nice' if things like that were 'available' to the rest of the community. 'Unsupported' is fine just put out a disclaimer 'Use at Your Own Risk' and put them on a download page... From our point of view, yes. From IBM's, no. Why? Because, sure a taxes, somebody would ignore the use at own risk and put the thing into some production process. Later, IBM changes something and the production process fails. The original person is gone that implemented the process is gone. The person now stuck with it calls IBM and is told tough toenails. The management of the company is now angry at IBM for not supporting this business critical process. Not a good thing from IBM's standpoint. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: DDR'ing 3390 DASD To Remote Location
You could make that argument about everything on the z/VM Download page.. We all still get tools from there. OK some companies by policy do not allow downloads then they are out of the picture.. and Some companies are still running VM/ESA 2.3 on a 9121 .. What is support? Basically just an warrantee policy. We all have/had cars that are out of warrantee, but keep driving them. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of McKown, John Sent: Friday, June 20, 2008 9:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, June 20, 2008 9:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Wouldn't it be 'nice' if things like that were 'available' to the rest of the community. 'Unsupported' is fine just put out a disclaimer 'Use at Your Own Risk' and put them on a download page... From our point of view, yes. From IBM's, no. Why? Because, sure a taxes, somebody would ignore the use at own risk and put the thing into some production process. Later, IBM changes something and the production process fails. The original person is gone that implemented the process is gone. The person now stuck with it calls IBM and is told tough toenails. The management of the company is now angry at IBM for not supporting this business critical process. Not a good thing from IBM's standpoint. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: DDR'ing 3390 DASD To Remote Location
If source code were available for all of the entries on the IBM Downloads website, then groups of people wanting to use some function in production could take over the support of the code. Sort of like the Waterloo Mods and VMShare, we can fix/enhance the code together. /Tom Kern On Fri, 20 Jun 2008 09:38:06 -0500, Huegel, Thomas [EMAIL PROTECTED] wr ote: You could make that argument about everything on the z/VM Download page. . We all still get tools from there. OK some companies by policy do not all ow downloads then they are out of the picture.. and Some companies are still running VM/ESA 2.3 on a 9121 .. What is support? Basically just an warran tee policy. We all have/had cars that are out of warrantee, but keep driving them.
Re: DDR'ing 3390 DASD To Remote Location
Just like Open Source. :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Friday, June 20, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location If source code were available for all of the entries on the IBM Downloads website, then groups of people wanting to use some function in production could take over the support of the code. Sort of like the Waterloo Mods and VMShare, we can fix/enhance the code together. /Tom Kern On Fri, 20 Jun 2008 09:38:06 -0500, Huegel, Thomas [EMAIL PROTECTED] wrote: You could make that argument about everything on the z/VM Download page.. We all still get tools from there. OK some companies by policy do not allow downloads then they are out of the picture.. and Some companies are still running VM/ESA 2.3 on a 9121 .. What is support? Basically just an warrantee policy. We all have/had cars that are out of warrantee, but keep driving them.
Re: DDR'ing 3390 DASD To Remote Location
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Friday, June 20, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Just like Open Source. :) -Mike Yeah, but WHICH LICENSE? There are a LOT of them. And the rights granted and responsibilities required can vary greatly. For true community software, I am a GPL bigot. It forces anyone who modifies the code AND DISTRIBUTES IT to make the changes public so that everybody can benefit from them and extend it futher. It does not force a person who modifies the code, but does not distribute it to make his personal changes available. However, companies tend to like the ones which allow them to take the code, modify it, distribute the modified binary (usually for a fee) and not disclose their changes. I.e. it lets companies modify and monitize the original source, without giving much of anything back. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: DDR'ing 3390 DASD To Remote Location
The VM community shared a lot more code before people started worrying ab out licensing. I don't remember anyone making money off of the Waterloo Mods. /Tom Kern On Fri, 20 Jun 2008 13:27:35 -0500, McKown, John [EMAIL PROTECTED] wrote: Yeah, but WHICH LICENSE? There are a LOT of them. And the rights granted and responsibilities required can vary greatly. For true community software, I am a GPL bigot. It forces anyone who modifies the code AND DISTRIBUTES IT to make the changes public so that everybody can benefit from them and extend it futher. It does not force a person who modifies the code, but does not distribute it to make his personal changes available. However, companies tend to like the ones which allow them to take the code, modify it, distribute the modified binary (usually for a fee) and not disclose their changes. I.e. it lets companies modify and monitize the original source, without giving much of anything back. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology
Re: DDR'ing 3390 DASD To Remote Location
On Fri, Jun 20, 2008 at 3:41 PM, in message [EMAIL PROTECTED], Thomas Kern [EMAIL PROTECTED] wrote: The VM community shared a lot more code before people started worrying about licensing. I don't remember anyone making money off of the Waterloo Mods. And most of that was before the Berne Convention came into effect. Now, all published works are automatically copyrighted, requiring some sort of license for others to use it. The author can declare the work to be in the public domain, but most people don't want to give up all control, just let other people use it freely. Hence the various licenses that are now in use. Mark Post
Re: DDR'ing 3390 DASD To Remote Location
3 months was chosen back in the early '80s. This is local government. Revenue in: Sales tax: Comes in automatically. Audits may be done at a later time. Federal distribution of income tax to local gov'ts: Comes in based on latest population figures. Earnings tax: Comes in automatically. May be audits at a later date. Real Estate taxes: We do have to bill. But can be same as last year. Revenue out: Payroll: Pay same as last time. Accounting: Pay the biggies manually. We have 3 months before most businesses will take action. Hence, 3 months. But we also produce election notices. Can't miss those on a Federal election. But I don't know what would happen in mist of a disaster. But I'm pretty sure I have it down to a month, assuming I survive. G Most plans are for the big earth quake. It would take out City Hall and the region. No problems with recovery then. There will be few left alive. Tom Duerbusch THD Consulting Michael Coffin [EMAIL PROTECTED] 6/18/2008 9:04 AM Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Tuesday, June 17, 2008 3:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location It depends on your recovery window. In the shop where we don't have disaster recovery tests, the window is officially 3 months, but I have it down to 1 month. In the shop where we do disaster recovery tests, the window is 3 days. IMHO, the closer you get to a hot site (already spinning a copy of your files), the more you need the monkey boy. In the days recovery window, good instructions are needed. In the month recovery window, we can get a system programmer consultant (to replace me, a consultant), that can get the system up. But all that depends on your recovery time frame, what you have in place (contacts, contracts, locations, etc), and what the shop is willing to pay for. We are pretty much in sync in the other aspects. I'm planning on a VM recovery system, on a single 3590 tape, with the script to restore the system, on floppy. That includes a small VSE system (no VM tape management, but VSE does have Dynam, and all the rest of the 390 backups are done within VSE), to restore each of the other VSE systems from tape (currently 3590, soon to be TS1120). Then, we (may) need to do application level restores from the most current backup available. But that can be done via the scheduling software. Yep, DDR is nice in that it restores the cylinders that are on that tape without caring if the cylinders before or after are done. Just mount the tapes, have rexx scan the TLBL, attach the disk drive and restore that set of cylinders. Eventually, all cylinders that got backed up, will be restored. I had a similar concept back in the late 80's/early '90s. Thanks for the info Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Michael Coffin [EMAIL PROTECTED] 6/17/2008 12:28 PM Hi Tom, You really should plan towards monkey boy as being the only resource capable of performing the recovery. I classify disasters in three classes: 1. Minor: This would be like a prolonged regional power failure, but all facilities, systems and equipment are still present. 2. Major: This would be something involving the total loss of the computer facility and perhaps even some staff, but at least some people with expertise and knowledge of the business and systems are available to participate in the recovery. For example, a fire at the computer facility. 3. Total: All facilities and staff are impacted and unavailable, nobody has expertise and knowledge of the business and systems - this is the monkey boy scenario. An example might be a natural disaster (hurricane, tornado, earthquake, etc.) or act of terrorism. The recovery system is prestaged on tape, it's a small footprint z/VM system with EVERYTHING needed to perform the recovery (it senses available ARM libraries, networks, DASD, etc. etc.). Restoring the recovery system to disk and IPL'ing is the one part of the process that is not menu driven, but it's well documented and really only involves a few steps: 1. Mount recovery tape. 2. IPL DDR on the head of the recovery tape. 3. Restore the recovery system to disk. 4. IPL the recovery system from disk and startup the menu-based recovery system. The 4 steps above are the most technical part of the process, the monkey boy simply needs to execute commands and provide responses
Re: DDR'ing 3390 DASD To Remote Location
We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
I think the reference was to a VTS unit. Is emulated tapes are called VTAPEs, I believe. Either Rick did not trademark VTAPE or he gave IBM permission to use it. (Or he is going to file suit as a result of this note :-) ). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 8:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam
Re: DDR'ing 3390 DASD To Remote Location
VSE has VTAPE now. CA has CDTAPE that works with z/VM now. Copyright Computer Associates International, Inc. 2003 CDTAPE simulates the CMS TAPE and VMFPLC2 commands allowing you to run various software installation procedures like AIM or CIS using tape image files instead of real tape volumes. Tape image files can reside in CMS or on your TCP/IP connected workstation. You indicate which location CDTAPE is to use by means of the CDTAPE START command. I would think that IBM could to it right now too. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
That is excatally what it can do in VSE.. Point the output to an IP address where the client is running (there is LINUX, WINDOZE, UNIX, etc. versions) and run your VSE job to either read or write the tape input/output to the remote VTAPE server.. So simple and I can't believe IBM developed it. But why not in z/VM? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
Ed, Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, June 18, 2008 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location That is excatally what it can do in VSE.. Point the output to an IP address where the client is running (there is LINUX, WINDOZE, UNIX, etc. versions) and run your VSE job to either read or write the tape input/output to the remote VTAPE server.. So simple and I can't believe IBM developed it. But why not in z/VM? I have used the VSE VTAPE over TCPIP and with VSAM. In our case, VSAM performs MUCH better. It was explained to me that our FLEX box doesn't have the same throughput over the network that a shiny new Z box with OSA would have. It would be great to have VTAPE in VM natively. Of course, I am spoiled as we have had FAKETAPE with FLEX since 2001. We still do CMS backups to FAKETAPE using VMFPLC2. Then we run a VSE job to copy the non-labeled FAKETAPE to a cataloged tape that VSE DYNAM knows about. That way we can have our CMS backups in the same catalog as our VSE stuff. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DDR'ing 3390 DASD To Remote Location
3 months was chosen back in the early '80s. This is local government. As Mel Brooks would say: It's good to be the king!
Re: DDR'ing 3390 DASD To Remote Location
Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ Original Message: - From: Adam Thornton [EMAIL PROTECTED] Date: Wed, 18 Jun 2008 10:00:08 -0500 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting
Re: DDR'ing 3390 DASD To Remote Location
Hi Michael, we use as DR a VTL from BusTech, the MAS. So, we have FICON attached a MAS, and we write our tapes in normal open systems disks. Then, the reseller here in Germany, mainstorconcept, installed also a replication module over IP and now we have all the virtual tapes in a second DR location. In relative short time we have all our DDR's in the another location. And also encrypted. For us is also interesting, that the tapes are stored in linux in AWSTAPE format. We replace our old DR solution from CMSDDR FTP with this hardware. best regards, N. _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066
Re: DDR'ing 3390 DASD To Remote Location
Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: So, if I can decipher the parms for the FTP stages all I really need to do now is: PIPE TRACKREAD | TRACKSQUISH | FTPPUT (FTP_parms to be deciphered) There may be some other intermediate stages (BLOCK 1024, etc.) that need to go in as well, I'll take a look at how Bruce Hayden already addressed this in PIPEDDR and just change the output stage to FTPPUT (assuming I can either decipher the correct parms, or if some kind soul from IBM could forward a tiny little README on this officially or otherwise I'd be in your debt!). The nice thing is I can also integrate FTPGET into the recovery process which will speed things up nicely as well. Thanks Adam and David for steering me in the right direction. FWIW, there is an example of PIPE FTPGET in INSTLBMD EXEC - so that might provide a clue as to what parms are required and/or supported. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ Original Message: - From: Adam Thornton [EMAIL PROTECTED] Date: Wed, 18 Jun 2008 10:00:08 -0500 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting
Re: DDR'ing 3390 DASD To Remote Location
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 11:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: If this is like some things in z/OS, the response from IBM development will be along the lines of: It is not documented because we don't want anyone else to use it. We don't want others to use it because if they do, then we must support it. And if we support it, then we cannot make arbitrary changes to it to implement what we want, should __our__ needs change. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: DDR'ing 3390 DASD To Remote Location
Do I smell a WAVV requirement? There may also be a formalized request/requirement mechanism on the z/VM web site (there is on the z/VSE web site). Michael Coffin wrote: Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: So, if I can decipher the parms for the FTP stages all I really need to do now is: PIPE TRACKREAD | TRACKSQUISH | FTPPUT (FTP_parms to be deciphered) There may be some other intermediate stages (BLOCK 1024, etc.) that need to go in as well, I'll take a look at how Bruce Hayden already addressed this in PIPEDDR and just change the output stage to FTPPUT (assuming I can either decipher the correct parms, or if some kind soul from IBM could forward a tiny little README on this officially or otherwise I'd be in your debt!). The nice thing is I can also integrate FTPGET into the recovery process which will speed things up nicely as well. Thanks Adam and David for steering me in the right direction. FWIW, there is an example of PIPE FTPGET in INSTLBMD EXEC - so that might provide a clue as to what parms are required and/or supported. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: DDR'ing 3390 DASD To Remote Location
Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom, We also have Doctor D on VSE, and I vaguely recall reading about that feature. Sounds like a good project for a rainy day! Thanks for pointing that out. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DDR'ing 3390 DASD To Remote Location
At my last client we did all the VM backups using FCOPY in VSE since we did not have a tape management system in VM but we did in VSE. Very easy technically to do but hard for a VM bigot like me to do. You use what you have where you have it. The DR procedures would IPL VSE standalone programs and then use FCOPY to restore the VM system. No DDR just standalone FCOPY. Hans -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: June 18, 2008 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom, We also have Doctor D on VSE, and I vaguely recall reading about that feature. Sounds like a good project for a rainy day! Thanks for pointing that out. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
DDR'ing 3390 DASD To Remote Location
(Cross-posted on VMESA-L and LINUX-390) Hi Folks, I want to eliminate use of tapes in my weekly DR process. Currently we DDR numerous 3390 spindles to 3590 tape cartridges. I have set up a Linux server at our DR site with a ton of free disk space, but the question becomes what is the best method to get images of our DASD stored on it? I've modified our procedures to use DDR2CMS to create CMS files representing the 3390 DASD images, which are then FTP'd to the Linux server - but the process is VERY inefficient: 1. DDR2CMS produces RECFM=V files which are unsuitable for FTP (I've NEVER had any luck successfully FTP'ing RECFM=V files to a non-CMS environment and getting them back in the correct format later), so I have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. 2. The output from DDR2CMS for a 3390-3 spindle may actually be LARGER than a 3390-3 spindle (even using COMPACT), so we need to use 3390-9 spindles as work space, something I'm not fond of doing (as a general rule we don't use 3390-9's at this site, but I configured a string of them just for this purpose). There is a great tool on the VM download page called PIPEDDR which basically does what DDR2CMS does using PIPE TRACKREAD - and it can write the output to a TCPIP stage. This is exactly what I'm looking for, with ONE important difference - PIPEDDR only talks to a remote VM/CMS system running PIPEDDR to receive the output, I need to be able to PIPE the output to a remote Linux storage server. Can anyone recommend a nice client that can run on Linux and listen on a TCPIP port, accept some authorization credentials and host commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of data similar to what PIPEDDR might write to it's TCPIP stage? I could then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing indirectly to the Linux server. I'd rather not reinvent the wheel if there's already something out there. :) PS: It would be sweet if there were just a way to mount a remote EXT3 filesystem somehow on CMS, but it looks like the only way to do this is with NFS, which is a problem because it is considered an unsafe protocol. :( -Mike
Re: DDR'ing 3390 DASD To Remote Location
On Jun 17, 2008, at 10:42 AM, Michael Coffin wrote: Can anyone recommend a nice client that can run on Linux and listen on a TCPIP port, accept some authorization credentials and host commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of data similar to what PIPEDDR might write to it's TCPIP stage? I could then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing indirectly to the Linux server. I'd rather not reinvent the wheel if there's already something out there. :) Funny you should ask. I tried a few weeks ago to write a Perl client to do trackread/ trackwrite, but the synchronization never worked right for me, and then real work intervened. Adam
Re: DDR'ing 3390 DASD To Remote Location
When experimenting with encrypting backups, I used PIPEDDR to write PACKE D versions of the data to a CMS minidisk. These are RECFM F LRECL 1024 and can be ftped to Linux and back as binary files, forcing the RECFM/LRECL on return. PIPEDDR can then be used to read these files and restore your DAS D. I also tried the CKDSVRST program from the IBM Downloads page, but that required the extra COPYFILE (PACK step, again reading/writing the data mo re than necessary. Have you thought about using Linux tools (dd ?) to read/write your DASD? /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 11:42:13 -0400, Michael Coffin [EMAIL PROTECTED] om wrote: (Cross-posted on VMESA-L and LINUX-390) Hi Folks, I want to eliminate use of tapes in my weekly DR process. Currently we DDR numerous 3390 spindles to 3590 tape cartridges. I have set up a Linux server at our DR site with a ton of free disk space, but the question becomes what is the best method to get images of our DASD stored on it? I've modified our procedures to use DDR2CMS to create CMS files representing the 3390 DASD images, which are then FTP'd to the Linux server - but the process is VERY inefficient: 1. DDR2CMS produces RECFM=V files which are unsuitable for FTP (I've NEVER had any luck successfully FTP'ing RECFM=V files to a non-C MS environment and getting them back in the correct format later), so I have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. 2. The output from DDR2CMS for a 3390-3 spindle may actually be LARGER than a 3390-3 spindle (even using COMPACT), so we need to use 3390-9 spindles as work space, something I'm not fond of doing (as a general rule we don't use 3390-9's at this site, but I configured a string of them just for this purpose). There is a great tool on the VM download page called PIPEDDR which basically does what DDR2CMS does using PIPE TRACKREAD - and it can write the output to a TCPIP stage. This is exactly what I'm looking for, with ONE important difference - PIPEDDR only talks to a remote VM/CMS system running PIPEDDR to receive the output, I need to be able to PIPE the output to a remote Linux storage server. Can anyone recommend a nice client that can run on Linux and listen on a TCPIP port, accept some authorization credentials and host commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of data similar to what PIPEDDR might write to it's TCPIP stage? I could then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing indirectly to the Linux server. I'd rather not reinvent the wheel if there's already something out there. :) PS: It would be sweet if there were just a way to mount a remote EXT3 filesystem somehow on CMS, but it looks like the only way to do this is with NFS, which is a problem because it is considered an unsafe protocol. :( -Mike
Re: DDR'ing 3390 DASD To Remote Location
Mike Coffin wrote: so I have to COPYFILE (PACK the output from DDR2CMS Neatly avoiding the direct question, in case no one can provide the requested solution... have you tried using a PIPE to read in the DDR2CMS file, run it through the PACK stage, and replace it on disk? It *may* be faster than COPYFILE. I have not timed it, though. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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: DDR'ing 3390 DASD To Remote Location
Hi Mike, Actually, If I have to continue this mode of operation where I produce an intermediate file, I'll probably stop using DDR2CMS and just use PIPEDDR to create the LRECL=F file for FTP'ing. I'll have to mod PIPEDDR though, you see we read cylinder 0 from the real production pack, and then all the remaining cylinders from a SnapShotted copy of the production pack (but with a different label and different cylinder 0 of course). DDR allows you to do this nicely. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Tuesday, June 17, 2008 12:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Mike Coffin wrote: so I have to COPYFILE (PACK the output from DDR2CMS Neatly avoiding the direct question, in case no one can provide the requested solution... have you tried using a PIPE to read in the DDR2CMS file, run it through the PACK stage, and replace it on disk? It *may* be faster than COPYFILE. I have not timed it, though. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. 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: DDR'ing 3390 DASD To Remote Location
Hi Tom, Yep, I've already thought about dropping DDR2CMS (see post I just sent) - at least it would eliminate the need to copy the file into an RECFM=F file. Of course dd from local DASD to a Samba mounted file share would be perfect, just one little problem - it doesn't run under CMS(!). I've got literally thousands of lines of REXX code which automates our DR process entirely that I'm not prepared to re-write so that Linux can do the data delivery. The SnapShots would have to be done in VM/CMS anyhow since I'm not aware of a SnapShot command interface for Linux, and various VM-based servers would still have to be brought up/down, quiesced and such on VM/CMS so it would get a bit complicated (not undoable, just a lot of wheel-reinventing, and of course the end result is a process that runs in Linux, I'm a VM'er and like my important business processes written and running in VM/CMS). It was the very first thing I thought of when I realized CMS simply cannot mount remote EXT3 filesystems and easily read/write to them and NFS was out of the question anyhow. PS: Did you guys at DOE go the TS1120 route? -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, June 17, 2008 11:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location When experimenting with encrypting backups, I used PIPEDDR to write PACKED versions of the data to a CMS minidisk. These are RECFM F LRECL 1024 and can be ftped to Linux and back as binary files, forcing the RECFM/LRECL on return. PIPEDDR can then be used to read these files and restore your DASD. I also tried the CKDSVRST program from the IBM Downloads page, but that required the extra COPYFILE (PACK step, again reading/writing the data more than necessary. Have you thought about using Linux tools (dd ?) to read/write your DASD? /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 11:42:13 -0400, Michael Coffin [EMAIL PROTECTED] wrote: (Cross-posted on VMESA-L and LINUX-390) Hi Folks, I want to eliminate use of tapes in my weekly DR process. Currently we DDR numerous 3390 spindles to 3590 tape cartridges. I have set up a Linux server at our DR site with a ton of free disk space, but the question becomes what is the best method to get images of our DASD stored on it? I've modified our procedures to use DDR2CMS to create CMS files representing the 3390 DASD images, which are then FTP'd to the Linux server - but the process is VERY inefficient: 1. DDR2CMS produces RECFM=V files which are unsuitable for FTP (I've NEVER had any luck successfully FTP'ing RECFM=V files to a non-CMS environment and getting them back in the correct format later), so I have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. 2. The output from DDR2CMS for a 3390-3 spindle may actually be LARGER than a 3390-3 spindle (even using COMPACT), so we need to use 3390-9 spindles as work space, something I'm not fond of doing (as a general rule we don't use 3390-9's at this site, but I configured a string of them just for this purpose). There is a great tool on the VM download page called PIPEDDR which basically does what DDR2CMS does using PIPE TRACKREAD - and it can write the output to a TCPIP stage. This is exactly what I'm looking for, with ONE important difference - PIPEDDR only talks to a remote VM/CMS system running PIPEDDR to receive the output, I need to be able to PIPE the output to a remote Linux storage server. Can anyone recommend a nice client that can run on Linux and listen on a TCPIP port, accept some authorization credentials and host commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of data similar to what PIPEDDR might write to it's TCPIP stage? I could then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing indirectly to the Linux server. I'd rather not reinvent the wheel if there's already something out there. :) PS: It would be sweet if there were just a way to mount a remote EXT3 filesystem somehow on CMS, but it looks like the only way to do this is with NFS, which is a problem because it is considered an unsafe protocol. :( -Mike
Re: DDR'ing 3390 DASD To Remote Location
The back half of this also needs to be considered. In case of an actual disaster, the process you are using requires a running VM system before you can do the restore. Disaster recovery sites have VM running. If you have your own replacement hardware, you can bring up the VM starter system, but you may still need software, along with scripts etc, on that site, in order for you to connect to your backup site, and bring the volumes back. Just something to consider before getting to far into the backup half of the project. Tom Duerbusch THD Consulting Michael Coffin [EMAIL PROTECTED] 6/17/2008 10:42 AM (Cross-posted on VMESA-L and LINUX-390) Hi Folks, I want to eliminate use of tapes in my weekly DR process. Currently we DDR numerous 3390 spindles to 3590 tape cartridges. I have set up a Linux server at our DR site with a ton of free disk space, but the question becomes what is the best method to get images of our DASD stored on it? I've modified our procedures to use DDR2CMS to create CMS files representing the 3390 DASD images, which are then FTP'd to the Linux server - but the process is VERY inefficient: 1. DDR2CMS produces RECFM=V files which are unsuitable for FTP (I've NEVER had any luck successfully FTP'ing RECFM=V files to a non-CMS environment and getting them back in the correct format later), so I have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. 2. The output from DDR2CMS for a 3390-3 spindle may actually be LARGER than a 3390-3 spindle (even using COMPACT), so we need to use 3390-9 spindles as work space, something I'm not fond of doing (as a general rule we don't use 3390-9's at this site, but I configured a string of them just for this purpose). There is a great tool on the VM download page called PIPEDDR which basically does what DDR2CMS does using PIPE TRACKREAD - and it can write the output to a TCPIP stage. This is exactly what I'm looking for, with ONE important difference - PIPEDDR only talks to a remote VM/CMS system running PIPEDDR to receive the output, I need to be able to PIPE the output to a remote Linux storage server. Can anyone recommend a nice client that can run on Linux and listen on a TCPIP port, accept some authorization credentials and host commands (i.e. MKDIR, CD to dir, etc.) and receive/write to disk a stream of data similar to what PIPEDDR might write to it's TCPIP stage? I could then skip creating the DDR2CMS file and COPYFILE (PACKing it, writing indirectly to the Linux server. I'd rather not reinvent the wheel if there's already something out there. :) PS: It would be sweet if there were just a way to mount a remote EXT3 filesystem somehow on CMS, but it looks like the only way to do this is with NFS, which is a problem because it is considered an unsafe protocol. :( -Mike
Re: DDR'ing 3390 DASD To Remote Location
If you have your own hotsite, you can prestage a copy of the 530RES, 530W 01, etc volumes and have all of your special code on that system. Or a more compact 1 volume DR recovery system, a 3390-m9 is MORE than enough space. /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 11:30:40 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: The back half of this also needs to be considered. In case of an actual disaster, the process you are using requires a runn ing VM system before you can do the restore. Disaster recovery sites have VM running. If you have your own replacement hardware, you can bring up the VM starter system, but you may still need software, along with scripts etc, on that site, in order for you to connect to your backup site, and bring the volumes back. Just something to consider before getting to far into the backup half of the project. Tom Duerbusch THD Consulting
Re: DDR'ing 3390 DASD To Remote Location
This is where it would be nice if Linux had a special filesystem driver f or WRITING CMS minidisks. Yes, DOE purchased an ATL of the new encrypting tape drives that z/VM can not directly use because of the lack of an out-of-band EKM at our DR vendor. So z/OS performs ALL of our backups, at least as long as the zSeries remains at DOE. /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 12:29:30 -0400, Michael Coffin [EMAIL PROTECTED] om wrote: Hi Tom, Yep, I've already thought about dropping DDR2CMS (see post I just sent) - at least it would eliminate the need to copy the file into an RECFM= F file. Of course dd from local DASD to a Samba mounted file share would be perfect, just one little problem - it doesn't run under CMS(!). I've got literally thousands of lines of REXX code which automates our DR process entirely that I'm not prepared to re-write so that Linux can do the data delivery. The SnapShots would have to be done in VM/CMS anyhow since I'm not aware of a SnapShot command interface for Linux, and various VM-based servers would still have to be brought up/down, quiesced and such on VM/CMS so it would get a bit complicated (not undoable, just a lot of wheel-reinventing, and of course the end result is a process that runs in Linux, I'm a VM'er and like my important business processes written and running in VM/CMS). It was the very first thing I thought of when I realized CMS simply cannot mount remote EXT3 filesystems and easily read/write to them and NFS was out of the question anyhow. PS: Did you guys at DOE go the TS1120 route? -Mike
Re: DDR'ing 3390 DASD To Remote Location
Hi Tom, Yep, I have that all covered. This is actually a DR process that I developed about 8 years ago (and have been improving over the years) that is a complete soup to nuts system, automating both the backups AND the recovery. The system assumes a worst case scenario where computer center is gone, and all of the people having detailed knowledge of the system are likewise gone, it allows someone with virtually no knowledge about the specifics of the system being recovered and very minimal mainframe knowledge to fully recover the system. When we conduct DR drills we typically recruit a management type that has minimal computing skills and little specific knowledge about the system (someone we affectionately refer to as the monkey boy, with the understanding that a slightly trained monkey could actually complete this task) to actually conduct the recovery. The programming staff provides no input to the monkey boy, instead taking notes of anything in the documentation that they found unclear and/or any technical problems that may arise. The entire process is menu-driven and pretty slick (including a Recovery Monitor that reports what each DDR slave is doing, what's it's ETA to completion of the current task is, what the total ETA to full system recovery is, the ability to quiesce and restart slaves/streams/devices, etc.). In 2006 there was a massive flood in Washington DC that required implementation of this DR Plan. I'm pleased to say it worked without a hitch, and from the time we got the green light to start spinning tapes we were back up in running in something like 3 or 4 hours (I think we had about 20 DDR slaves running simultaneously). While this process works extremely well, I now want to remove tapes from the process - there are a number of reasons why this makes sense: 1. There is a Federal mandate to encrypt all removable media which this site is subject to, and we don't presently have TS1120 tape drives/cartridges. 2. Tapes can be lost and/or damaged (damage used to happen with ALARMING frequency!), one bad tape and your entire recovery could be jeapordized. Ultimately, I'd like to have our production DASD replicate (either in realtime or via a nightly batch job) to a remote DASD array using PPRC - but until such time as I get funding to do that (perhaps never!) I need to eliminate the darned tapes. :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Tuesday, June 17, 2008 12:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location The back half of this also needs to be considered. In case of an actual disaster, the process you are using requires a running VM system before you can do the restore. Disaster recovery sites have VM running. If you have your own replacement hardware, you can bring up the VM starter system, but you may still need software, along with scripts etc, on that site, in order for you to connect to your backup site, and bring the volumes back. Just something to consider before getting to far into the backup half of the project. Tom Duerbusch THD Consulting Michael Coffin [EMAIL PROTECTED] 6/17/2008 10:42 AM (Cross-posted on VMESA-L and LINUX-390) Hi Folks, I want to eliminate use of tapes in my weekly DR process. Currently we DDR numerous 3390 spindles to 3590 tape cartridges. I have set up a Linux server at our DR site with a ton of free disk space, but the question becomes what is the best method to get images of our DASD stored on it? I've modified our procedures to use DDR2CMS to create CMS files representing the 3390 DASD images, which are then FTP'd to the Linux server - but the process is VERY inefficient: 1. DDR2CMS produces RECFM=V files which are unsuitable for FTP (I've NEVER had any luck successfully FTP'ing RECFM=V files to a non-CMS environment and getting them back in the correct format later), so I have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. 2. The output from DDR2CMS for a 3390-3 spindle may actually be LARGER than a 3390-3 spindle (even using COMPACT), so we need to use 3390-9 spindles as work space, something I'm not fond of doing (as a general rule we don't use 3390-9's at this site, but I configured a string of them just for this purpose). There is a great tool on the VM download page called PIPEDDR which basically does what DDR2CMS does using PIPE TRACKREAD - and it can write the output to a TCPIP stage. This is exactly what I'm looking for, with ONE important difference - PIPEDDR only talks to a remote VM/CMS system running PIPEDDR to receive the output, I need to be able to PIPE the output to a remote Linux storage server. Can anyone recommend a nice client that can run on Linux
Re: DDR'ing 3390 DASD To Remote Location
On Tue, 17 Jun 2008 11:42:13 -0400 Michael Coffin said: have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. Michael, 47 minutes seems way too long to me to DDR a 3390-3 pack. I tried using PIPEDDR to dump a 3390-3 and it took 9 minutes. Aria.
Re: DDR'ing 3390 DASD To Remote Location
Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 11:42:13 -0400 Michael Coffin said: have to COPYFILE (PACK the output from DDR2CMS. DDR2CMS takes around 47 minutes/spindle, and the COPYFILE takes around 38 minutes - the FTP only takes around 17 minutes! So we are really wasting nearly 90 minutes/spindle just prepping the data to be transmitted. Michael, 47 minutes seems way too long to me to DDR a 3390-3 pack. I tried using PIPEDDR to dump a 3390-3 and it took 9 minutes. Aria.
Re: DDR'ing 3390 DASD To Remote Location
Hi Tom, You really should plan towards monkey boy as being the only resource capable of performing the recovery. I classify disasters in three classes: 1. Minor: This would be like a prolonged regional power failure, but all facilities, systems and equipment are still present. 2. Major: This would be something involving the total loss of the computer facility and perhaps even some staff, but at least some people with expertise and knowledge of the business and systems are available to participate in the recovery. For example, a fire at the computer facility. 3. Total: All facilities and staff are impacted and unavailable, nobody has expertise and knowledge of the business and systems - this is the monkey boy scenario. An example might be a natural disaster (hurricane, tornado, earthquake, etc.) or act of terrorism. The recovery system is prestaged on tape, it's a small footprint z/VM system with EVERYTHING needed to perform the recovery (it senses available ARM libraries, networks, DASD, etc. etc.). Restoring the recovery system to disk and IPL'ing is the one part of the process that is not menu driven, but it's well documented and really only involves a few steps: 1. Mount recovery tape. 2. IPL DDR on the head of the recovery tape. 3. Restore the recovery system to disk. 4. IPL the recovery system from disk and startup the menu-based recovery system. The 4 steps above are the most technical part of the process, the monkey boy simply needs to execute commands and provide responses provided on a Recovery Worksheet completed by the host site technical staff, so even though it is a technical process, it's really more a question of following instructions (whether you understand them or not). :) I think we probably use around 30 or 40 full 3590 tapes, but since the entire process is automated and you can run multiple concurrent restore streams it becomes a moot point (basically you just tell the process how many 3590 drives are available for your use in the available ARM's and it will dispatch a number of dynamic DDR recovery slaves, one per tape drive). Years ago I wrote an automated recovery system for BellCore (the research and development arm of the old phone company). Back then, it might take 3 or 4 3480 carts to hold a single DASD spindle. That process was pretty elegant too, the SL on the tapes (and yes, all of my DDR tapes use SL tapes - which of course is a challenge in and of itself!) specified what contents were on that cartridge. The operators would fire up the DR Recovery process and simply start opening buckets of tapes and stuffing them into 3480 autoloaders in any order. The recovery system would piece it all together, and of course had a nice status monitor showing the progress of each spindle recovery and the ability to quiesce/restart slaves and such. I remember one time when we were at Sunguard for a DR drill the z/OS guys (MVS back in those days) were busily responding to a million human-interactive steps, locating and mounting specific tapes, initiating jobs to read tapes/write to DASD, etc. etc. - the VM guys were just sitting there having a coffee and watching the automated recovery monitor, occasionally opening a fresh tub of tapes and stuffing them into 3480 autoloaders in no particular order. Since we also had multiple concurrent streams going our recovery was done painlessly and QUICKLY compared to the poor ol' MVS guys. :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Tuesday, June 17, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I do like the monkey boy concept. I keep trying to go towards that state. You have a menu driven system, which implies you are not restoring to bare iron. So what was prestaged? Do you have a mini VM system on tape (or DVD) to be restored? If this is a Flex or P/390 type system, never mind. They have some other, easier, more interesting options. For one site, which doesn't do disaster recovery tests, I'm thinking of a TS1120 backup and a script, which will be testing on one of our LPARs, for recovery of our systems. At another site, which does disaster recovery tests, and Sungard has VM, I'm looking at scripts for the standalone side, to eliminate the people errors when restoring their systems. BTW, they keep the most recent 2 generations offsite, just in case of a media failure. They are 3480 based, and the standalone restores take some 80 tapes. Uggg! Tom Duerbusch THD Consulting Michael Coffin [EMAIL PROTECTED] 6/17/2008 11:49 AM Hi Tom, Yep, I have that all covered. This is actually a DR process that I developed about 8 years ago (and have been improving over the years) that is a complete soup to nuts system, automating both the backups AND the recovery. The system assumes a worst case scenario where computer center is gone, and all of the people having detailed knowledge
Re: DDR'ing 3390 DASD To Remote Location
The added cycles for software encryption is a problem for me also. I use an drive enclosure made by Addonics that encrypts everything on the drive using various levels of encryption. It's all hardware based and to get to the data on the drive, you need to plug in the encryption key before you turn the drive on. Aria. On Tue, 17 Jun 2008 13:38:01 -0400 Michael Coffin said: Hi Tom, Yep, we were also looking at Dave's VM/Encrypt product and I REALLY loved what I saw, but we didn't have the cycles available on the IBM 2066-0B1 to use it in production. Then it was decided that the TS1120 would be the approved means of encrypting mainframe tapes so.. :( -Mike
Re: DDR'ing 3390 DASD To Remote Location
Tom, you,re closethe real name is VM/Encrypt-Tape; more information about it can be found here: http://www.vsoft-software.com/products.html Mike, the amount of CPU cycles VM/Encrypt-Tape consumes is a function of the zSeries processor it runs on. If the processor supports the (new) KM/KMC instrunctions for the encryption algorithm you want to use, VM/Encrypt-Tape will use that hardware to do the encryption (very fast). If the processor does not support the KM/KMC instrunctions for the choosen algorithm, then it falls back to a software implementation of the encryptioon algorithm. As an example, the z990 has hardware sypport for the AES algotithm with a key size of 128 bits, while the new z10 hardware supports AES with a key size up to 256 bits. If you request a AES 256 bit key length encryption operation on a z990, VM/Encrypt-Tape will do it in the software, on a z10, it will do it in the hardware. What this means is that tapes can be moved back and forth between production and DR sites without the requirement that both sites have the same types of hardware tape encryption devices and support software (IBM, third party, etc.) installed. It's very flexible Thanks for the kind words, too. DJ Original Message: - From: Michael Coffin [EMAIL PROTECTED] Date: Tue, 17 Jun 2008 13:38:01 -0400 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Tom, Yep, we were also looking at Dave's VM/Encrypt product and I REALLY loved what I saw, but we didn't have the cycles available on the IBM 2066-0B1 to use it in production. Then it was decided that the TS1120 would be the approved means of encrypting mainframe tapes so.. :( -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, June 17, 2008 1:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I have looked at your Backup/Recovery code, quite extensive. 1) With the use of a software encryption product (I think it is currently called VM/Encrypt, Dave, help), and a modified PIPEDDR, I was able to write encrypted backup tapes and restore them at our DR exercise last summer. Just about when DOE decided on a hardware only solution. 2) So true. I was actually thinking of a PIPEDDR type server to run at both sides of a DR connection, that acted like a backup server at production, with scheduled jobs that fired off workers to read each minidisk, full-volume, snapshot volume and send compressed data across the net to the recovery server at the hotsite which would fire off workers to receive each stream and write the data back to disk. I was thinking of a VM based server but it could be a linux server with some VM workers to handle snapshot requests and SVM shutdown/xautolog requests from a linux scheduler. But both would require more effort than I can give it. (Anyone got a product development team that needs some work?) /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 12:49:39 -0400, Michael Coffin [EMAIL PROTECTED] wrote: Hi Tom, Yep, I have that all covered. This is actually a DR process that I developed about 8 years ago (and have been improving over the years) that is a complete soup to nuts system, automating both the backups AND the recovery. The system assumes a worst case scenario where computer center is gone, and all of the people having detailed knowledge of the system are likewise gone, it allows someone with virtually no knowledge about the specifics of the system being recovered and very minimal mainframe knowledge to fully recover the system. When we conduct DR drills we typically recruit a management type that has minimal computing skills and little specific knowledge about the system (someone we affectionately refer to as the monkey boy, with the understanding that a slightly trained monkey could actually complete this task) to actually conduct the recovery. The programming staff provides no input to the monkey boy, instead taking notes of anything in the documentation that they found unclear and/or any technical problems that may arise. The entire process is menu-driven and pretty slick (including a Recovery Monitor that reports what each DDR slave is doing, what's it's ETA to completion of the current task is, what the total ETA to full system recovery is, the ability to quiesce and restart slaves/streams/devices, etc.). In 2006 there was a massive flood in Washington DC that required implementation of this DR Plan. I'm pleased to say it worked without a hitch, and from the time we got the green light to start spinning tapes we were back up in running in something like 3 or 4 hours (I think we had about 20 DDR slaves running simultaneously). While this process works extremely well, I now want to remove tapes from the process - there are a number of reasons why this makes sense: 1. There is a Federal mandate to encrypt all
