Re: Question aboout DDR Backup Question
I have a user mod for DDR to interface with VM:Tape to request a new volume at end-of-tape. Works with non-labeled tapes only. Peter -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: March 9, 2010 10:37 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Question aboout DDR Backup Question Sergio Lima wrote on 03/09/2010 09:00:11 AM: > I'm doing a REXX here that will do a backup from some DISKS of Maint > machine to tape. > So, We want backup more than one disk to tape, using the LEAVE > option from all DUMP statements. > When the DDR find the END of the TAPE, can I give control in my REXXprogram ? > Another words, Can I get a retun code, and say "operator pelase > mount the next volume ?" Sorry, no. This is one of those cases where you have to use a programmed operator (e.g. IBM Operations Manager) to monitor the console of the user running DDR. Whenever DDR issues the "mount next volume" message, the programmed operator would see it and send the message to the system operator. Regards, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development 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: Question aboout DDR Backup Question
> > That is the DRPC package (see > > http://www.vm.ibm.com/download/packages/descript.cgi?DRPC > > That's it. Thanks, Bruce. So, Attach a tape drive to your id at virtual address 181 (and one at 182 if you want it to alternate drives) Attach the disk you want to dump at virtual address 1FFF (remember, the virtual machine owning the disk should be logged off while you're doing this) FILEDEF OUTTAPE TAP1 SL ( RECFM FB BLKSIZE 8000 LRECL 80 ALT TAP2 LABELDEF OUTTAPE FID ? VOLID ? FSEQ CRDTE n EXDTE n Respond to the FID prompt with a OS dataset name, eg VOLUME.xx.DDR.DUMP.julian-date-for-today Respond to the VOLID prompt with a couple of tape volume names (these are SL tapes, so your TMS should get involved if you have one, otherwise you have to keep track of which tapes you used in some way. Note that if you use CRDTE and EXDTE on the LABELDEF, you can tell which tapes are available by mounting the tape and using TAPE DVOL1 (TAP1 to look at the label information outside of the backups). Then: PIPE DDR DUMPALL DDRIN A | QSAM OUTTAPE Where the file DUMPALL DDRIN A contains: SYSPRINT CONS INPUT 1FFF 3390 SCRTCH DUMP ALL Y (blank line) And watch the fun. For the next disk, update the LABELDEF for the next FSEQ number with the CHANGE operand, and rerun the PIPE DDR step. Repeat for all volumes. Presto. Tape label checking in DDR that works with bare CP or with a TMS, and it won't let you mount the tapes in the wrong load or in the wrong sequence. The same approach works with TCP sockets and netcat on a Linux box, and it's nicely restorable if you run the DDR stream through FBLOCK as well. I wish IBM would ship the DRPC DDR as the standard one. Then all we would need to do is produce a PIPE-friendly SPXTAPE, and presto! Tape free z/VM. -- db
Re: Question aboout DDR Backup Question
> For those wondering: "Great! But where do I find The PIPE-capable > DDR > ?"... > http://www.vm.ibm.com/download/packages/ Except that's not the one I'm referring to. IBM made available a version of DDR that directly supported PIPE input and output. It was a summer project by an intern, and they released it from one of the VM developer pages. It used the standard DDR format instead of the PIPEDDR format. I'll see if I can find the information about it. It was posted to this mailing list. -- db
Re: Question aboout DDR Backup Question
Tom wrote: >It would indeed be nice if IBM or some other vendor would provide a DDR >program with full tape label support, but my head got too bloody from >beating on that wall 25 years ago. They DID! Safe Software, Inc has (had??) a product to do just that: SafeDR Their home page: http://www.safesoftware.com/ The SafeDR product page: http://www.safesoftware.com/SafeDR.htm Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Thomas Kern Sent by: "The IBM z/VM Operating System" 03/09/2010 11:27 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Question aboout DDR Backup Question You can force DDR to write/read files 2-n preserving a pseudo-standard label. Yeah, I know it isn't the true MVS standard label, but it can still have the volser in it. And I try to rewrite the label to include the name of the SVM that is using the tape (MAINT, SFSADMIN, DRS1-DRS00020, VMBAR, etc). It would indeed be nice if IBM or some other vendor would provide a DDR program with full tape label support, but my head got too bloody from beating on that wall 25 years ago. /Tom Kern On Tue, 9 Mar 2010 16:21:04 +0100, Kris Buelens wrote: >These solutions won't help with DDR. DDR wil anyhow overwrite the label -if >any- on all but the first tapes (keeping the label of the first tape means >you must position beyond it before starting DDR). >You'd need a DDR with tape label support, IIRC, there was a post here some >time ago with the DDR modifs required to do so. > 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: Question aboout DDR Backup Question
> That is the DRPC package (see > http://www.vm.ibm.com/download/packages/descript.cgi?DRPC That's it. Thanks, Bruce.
Re: Question aboout DDR Backup Question
Well... PIPEDDR is not the package that has the DDR module that can hook to CMS Pipelines. That is the DRPC package (see http://www.vm.ibm.com/download/packages/descript.cgi?DRPC). PIPEDDR provides a "DDR-like" function that uses the Pipelines trackread and trackwrite stages (and, by the way, it supports tapes and filedefs.) It is unfortunate that the name PIPEDDR implies "real" DDR, but the DRPC package and function came after PIPEDDR existed. On Tue, Mar 9, 2010 at 2:03 PM, Mike Walter wrote: > For those wondering: "Great! But where do I find The PIPE-capable DDR > ?"... > http://www.vm.ibm.com/download/packages/ > > If you have not visited the IBM VM Download page, and as long as your site > does not restrict downloads of mainframe utilities, then go visit it... > NOW! > IMHO - you are losing valuable time re-inventing the wheel -- repeatedly. > > Mike Walter > Hewitt Associates > The opinions expressed herein are mine alone, not my employer's. > > > Further, the "help" on that page reports: > > > > > > IBM Systems > > System z > > z/VM > > > > > Description of PIPEDDR > Download count: 14 this month, 2473 altogether. > Downloads for PIPEDDR: > VMARC archive: v-24K > PIPEDDR EXEC > This exec is somewhat mis-named, because it does not dump and restore in > DDR format but uses PIPE's TRACKREAD and TRACKWRITE stages. This exec will > dump a disk into a regular CMS file to allow sending the data over the > network. The CMS file can also be compressed, saving disk space. The exec > will also restore the file back to the same or a different disk. The > compression method supported is pack. Pack creates a file that is > compatible with the PACK option of the CMS COPYFILE command. > A file created by this exec has the disk information in the first record > (size and device type) and the contents of the disk in the rest. > The disk can also be dumped over a TCP/IP connection directly to a > receiving PIPEDDR exec running on a remote system or to a file on an FTP > server. A file can be restored from an FTP server or an HTTP (web) server. > Also, dump to and restore from a tape is supported by using the TAPE > option and the same operations using a CMS filedef using the FILEDEF > option. > PIPEDDR requires the Princeton Runtime Distribution level of Pipelines at > version 110B0004 (15 May 2002 level) or later. It uses the PICKPIPE EXEC > to load this level if it is needed. PICKPIPE is also available via the VM > download library. See the PICKPIPE description or get the VMARC file. > The FTP option requires either the INSTPIPE MODULE from a modern version > of CMS (found on MAINT 2CC or MAINT 193) or the DRPC MODULE from the DRPC > package on the VM download library. See the DRPC description or get the > VMARC file. > The FTP option can also use a NETRC DATA file stored anywhere in the > search order. This file can supply a password or a userid and password for > the connection, so that the password would not be hardcoded into an exec > or displayed on the console. > The exec also has a TERSE option, but it can only be used if the TERSE > Pipelines stage is available. This allows the exec to create output files > that are smaller or send less data over the network. The TERSE Pipelines > stage is not available outside of IBM, but a standalone terse function is > available as part of the FCOPY package on the VM download library. See > the FCOPY description or get the VMARC file and extract the FCOPYTRS > MODULE. This module will allow you to terse the output file created by > PIPEDDR. > A help file is included in the package. Enter HELP PIPEDDR for usage > information. > Feedback: Bruce Hayden Linux on System z Advanced Technical Support > Some examples of how to use PIPEDDR. > To dump a minidisk to a file with the default name: > PIPEDDR DUMP MAINT 19E > This creates a file named MAINT DISK019E A > To dump the same disk to a different filemode: > PIPEDDR DUMP MAINT 19E = = E (PACK > To restore the file to the same disk: > PIPEDDR RESTORE MAINT 19E > To restore the file to a different disk and skip the prompt: > PIPEDDR RESTORE CMSUSER 191 MAINT DISK019E A (NOPROMPT > To send an entire minidisk over the network On the receiving node, enter: > PIPEDDR RESTORE MAINT 19E (LISTEN > This will display the port number it is using. To force the port to 12345: > PIPEDDR RESTORE MAINT 19E 12345 (LISTEN > On the sending system use (where is the listening port): > PIPEDDR DUMP MAINT 19E nodeid.example.com > The connection should be made and the disk sent over. Note that PACK is > the default for remote connections. > To send a minidisk to a file named maint.disk019e on an ftp server: > PIPEDDR DUMP MAINT 19E (ftp(-h server.example.com -u hayden -p password) > > To restore a minidisk from file disk.dump on an ftp server, and skip the > prompt, either of these commands can be used: > PIPEDDR RESTORE MAINT 19E (noprompt ftp -h server.example.com -u hayden -p > password -d /disks -f disk.dump > PIPEDDR RESTORE MAINT 19E
Re: Question aboout DDR Backup Question
label Fix end of data marker for TCP/IP transfers V1.4.6 Add Filedef input/output support V1.4.5 Add single volume Tape input/output support V1.4.4 Add CIPHER option, usable only of the pipe stage is available V1.4.3 Add HTTP option and the ability to specify a URL for it and FTP V1.4.2 Allow use of a NETRC DATA file for FTP parameters V1.4.1 For FTP option, use DRPC MODULE first if found, then look for INSTPIPE MODULE pipe filter on MAINT 193 V1.4.0 Overall clean up V1.3.11Add FTP option using DRPC MODULE V1.3.10Use CPFMTXA to put label on disk before restore V1.3.9 Fix math error in report of megabytes transferred V1.3.8 Fix disk label reading code V1.3.7 Fix false "success" message "David Boyes" Sent by: "The IBM z/VM Operating System" 03/09/2010 12:38 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Question aboout DDR Backup Question > It would indeed be nice if IBM or some other vendor would provide a DDR > program with full tape label support, but my head got too bloody from > beating on that wall 25 years ago. They did. The PIPE-capable DDR lets the TAP stage handle it. Then you don't care about tape length, or label management or any of that stuff. 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: Question aboout DDR Backup Question
> It would indeed be nice if IBM or some other vendor would provide a DDR > program with full tape label support, but my head got too bloody from > beating on that wall 25 years ago. They did. The PIPE-capable DDR lets the TAP stage handle it. Then you don't care about tape length, or label management or any of that stuff.
Re: Question aboout DDR Backup Question
Use the pipe-capable DDR, and dump to standard label tapes via the TAP SL stage. If you do that, normal multi-volume tape processing is done, and you specify the volumes in the LABELDEF for the output tape DD. Works well.
Re: Question aboout DDR Backup Question
You can force DDR to write/read files 2-n preserving a pseudo-standard la bel. Yeah, I know it isn't the true MVS standard label, but it can still have the volser in it. And I try to rewrite the label to include the name of the S VM that is using the tape (MAINT, SFSADMIN, DRS1-DRS00020, VMBAR, etc). It would indeed be nice if IBM or some other vendor would provide a DDR program with full tape label support, but my head got too bloody from beating on that wall 25 years ago. /Tom Kern On Tue, 9 Mar 2010 16:21:04 +0100, Kris Buelens wrote: >These solutions won't help with DDR. DDR wil anyhow overwrite the label -if >any- on all but the first tapes (keeping the label of the first tape mea ns >you must position beyond it before starting DDR). >You'd need a DDR with tape label support, IIRC, there was a post here so me >time ago with the DDR modifs required to do so. >
Re: Question aboout DDR Backup Question
I wrote my own tape management system and DDR backup manager to work with standard DDR and unlabeled tapes to handle this. The server, called TAPEMGR, runs PROP and becomes an OBSERVER of DDR worker machines that it autologs. The DDR workers send a command to TAPEMGR to mount their first tape, and TAPEMGR mounts subsequent tapes when the HCPERP2233I is observe d on the DDR worker. For each tape mount, TAPEMGR selects a scratch tape from its tape catalog and sends a message to the tape operator telling them what tape to mount. The biggest risk with unlabeled tapes is that the tape operator might mount the wrong tape. In our case, the tapes are used exclusively for DD R and are sent offsite, and they can't mount a tape that's not onsite. For the one or two times the wrong tape has been mounted over the last handfu l of years a simple catalog update is required to record what tape was actually used and sent offsite. Brian Nielsen On Tue, 9 Mar 2010 16:21:04 +0100, Kris Buelens wrote: >These solutions won't help with DDR. DDR wil anyhow overwrite the label - if >any- on all but the first tapes (keeping the label of the first tape mea ns >you must position beyond it before starting DDR). >You'd need a DDR with tape label support, IIRC, there was a post here so me >time ago with the DDR modifs required to do so. > >2010/3/9 Thomas Kern > >> Do you have real operators mounting the tapes or are they in stackers or an >> automated tape library, or do you have a tape management program like >> VMTape? Four different situations requiring four different programming >> efforts. >> >> If you have operators, you can send a msg to them to mount the next scratch >> tape and reply to you with the volser. Then use WAKEUP to intercept their >> message, parse it for volser and then compare against the real tape volser >> when you read it from the tape. >> >> If you have stackers full of scratch tapes, just use TAPE RUN to drop the >> full tape, and read the volser of the next tape when it comes ready. Y ou >> can >> loop on 'CP REWIND 181' until it responds or you can misuse another IB M >> program WAITDEV from the TCPIP product and just wait for 181 to come ready. >> Then read the volser of the next scratch tape and assume it is correct . >> >> If you have an IBM ATL, the DFSMSRM command can be used to request a >> scratch >> mount, and then you can read the tape volser when the command complete s. >> >> If you have a tape management program like VMTape, use its command to >> request a scratch tape and I think it has an option to give you the volser, >> if not, then read the volser from the tape when the mount command >> completes. >> >> /Tom Kern >> >> >> On Tue, 9 Mar 2010 17:00:11 +0300, Sergio Lima >> wrote: >> > >> >Hello List. >> > >> >I'm doing a REXX here that will do a backup from some DISKS of Maint >> machine to tape. >> >So, We want backup more than one disk to tape, using the LEAVE option from >> all DUMP statements. >> >When the DDR find the END of the TAPE, can I give control in my REXX >> program ? >> >Another words, Can I get a retun code, and say "operator pelase mount the >> next volume ?" >> >We also need have a history from the Tapes used from backup to restor e >> later. >> >Someone have experienced this situation ? >> > >> >Thanks very much >> > >> >Sergio Lima Costa >> >System Support >> >GRV Solutions >> >Sao Paulo - Brazil >> > > > >-- >Kris Buelens, >IBM Belgium, VM customer support >
Re: Question aboout DDR Backup Question
Sergio Lima wrote on 03/09/2010 09:00:11 AM: > I'm doing a REXX here that will do a backup from some DISKS of Maint > machine to tape. > So, We want backup more than one disk to tape, using the LEAVE > option from all DUMP statements. > When the DDR find the END of the TAPE, can I give control in my REXXprogram ? > Another words, Can I get a retun code, and say "operator pelase > mount the next volume ?" Sorry, no. This is one of those cases where you have to use a programmed operator (e.g. IBM Operations Manager) to monitor the console of the user running DDR. Whenever DDR issues the "mount next volume" message, the programmed operator would see it and send the message to the system operator. Regards, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Question aboout DDR Backup Question
Do you have real operators mounting the tapes or are they in stackers or an automated tape library, or do you have a tape management program like VMTape? Four different situations requiring four different programming ef forts. If you have operators, you can send a msg to them to mount the next scrat ch tape and reply to you with the volser. Then use WAKEUP to intercept their message, parse it for volser and then compare against the real tape volse r when you read it from the tape. If you have stackers full of scratch tapes, just use TAPE RUN to drop the full tape, and read the volser of the next tape when it comes ready. You can loop on 'CP REWIND 181' until it responds or you can misuse another IBM program WAITDEV from the TCPIP product and just wait for 181 to come read y. Then read the volser of the next scratch tape and assume it is correct. If you have an IBM ATL, the DFSMSRM command can be used to request a scra tch mount, and then you can read the tape volser when the command completes. If you have a tape management program like VMTape, use its command to request a scratch tape and I think it has an option to give you the volse r, if not, then read the volser from the tape when the mount command complet es. /Tom Kern On Tue, 9 Mar 2010 17:00:11 +0300, Sergio Lima wrote: > >Hello List. > >I'm doing a REXX here that will do a backup from some DISKS of Maint machine to tape. >So, We want backup more than one disk to tape, using the LEAVE option fr om all DUMP statements. >When the DDR find the END of the TAPE, can I give control in my REXX pro gram ? >Another words, Can I get a retun code, and say "operator pelase mount th e next volume ?" >We also need have a history from the Tapes used from backup to restore l ater. >Someone have experienced this situation ? > >Thanks very much > >Sergio Lima Costa >System Support >GRV Solutions >Sao Paulo - Brazil
Re: Question aboout DDR Backup Question
These solutions won't help with DDR. DDR wil anyhow overwrite the label -if any- on all but the first tapes (keeping the label of the first tape means you must position beyond it before starting DDR). You'd need a DDR with tape label support, IIRC, there was a post here some time ago with the DDR modifs required to do so. 2010/3/9 Thomas Kern > Do you have real operators mounting the tapes or are they in stackers or an > automated tape library, or do you have a tape management program like > VMTape? Four different situations requiring four different programming > efforts. > > If you have operators, you can send a msg to them to mount the next scratch > tape and reply to you with the volser. Then use WAKEUP to intercept their > message, parse it for volser and then compare against the real tape volser > when you read it from the tape. > > If you have stackers full of scratch tapes, just use TAPE RUN to drop the > full tape, and read the volser of the next tape when it comes ready. You > can > loop on 'CP REWIND 181' until it responds or you can misuse another IBM > program WAITDEV from the TCPIP product and just wait for 181 to come ready. > Then read the volser of the next scratch tape and assume it is correct. > > If you have an IBM ATL, the DFSMSRM command can be used to request a > scratch > mount, and then you can read the tape volser when the command completes. > > If you have a tape management program like VMTape, use its command to > request a scratch tape and I think it has an option to give you the volser, > if not, then read the volser from the tape when the mount command > completes. > > /Tom Kern > > > On Tue, 9 Mar 2010 17:00:11 +0300, Sergio Lima > wrote: > > > >Hello List. > > > >I'm doing a REXX here that will do a backup from some DISKS of Maint > machine to tape. > >So, We want backup more than one disk to tape, using the LEAVE option from > all DUMP statements. > >When the DDR find the END of the TAPE, can I give control in my REXX > program ? > >Another words, Can I get a retun code, and say "operator pelase mount the > next volume ?" > >We also need have a history from the Tapes used from backup to restore > later. > >Someone have experienced this situation ? > > > >Thanks very much > > > >Sergio Lima Costa > >System Support > >GRV Solutions > >Sao Paulo - Brazil > -- Kris Buelens, IBM Belgium, VM customer support
Question aboout DDR Backup Question
Hello List. I'm doing a REXX here that will do a backup from some DISKS of Maint machine to tape. So, We want backup more than one disk to tape, using the LEAVE option from all DUMP statements. When the DDR find the END of the TAPE, can I give control in my REXX program ? Another words, Can I get a retun code, and say "operator pelase mount the next volume ?" We also need have a history from the Tapes used from backup to restore later. Someone have experienced this situation ? Thanks very much Sergio Lima Costa System Support GRV Solutions Sao Paulo - Brazil _ Navegue sem medo: O Internet Explorer 8 te deixa mais protegido. Baixe gratuitamente. http://go.microsoft.com/?linkid=9707132