Duh Imagine that. Not being able to copy a full 3490E (1.2 GB) to a 3480E (200 MB) cart.
Do you have your cart types reversed? You should always be able to copy a 3480 to a 3490. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 2/7/2006 1:24 PM >>> Richard, I was never able to copy a full 3490E cart to a even brand new 3480E cart. Each time the output tape filled up before we got to the end, I presumed because of the inter-record gaps. I seem to remember reading various posts and articles over the years indicating that there is a physical gap on the tape whenever writing starts again after a pause. What you say may be true, but anecdotal evidence indicates otherwise. Why else did every single attempt to copy a full tape to a new or used cart of the same size fail? Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "VM/ESA and z/VM Discussions" <[email protected]> 02/07/2006 11:46 AM Please respond to "VM/ESA and z/VM Discussions" <[email protected]> To [email protected] cc Subject Re: Tape conversions Mike, What the stopping and restarting of the tape did was to slow down the process, not waste space by inserting gaps. In the good old days, the IRGs were there between the records regardless of the starting and stopping of the tape. A File Mark was recognized by the h/w because of an extremely long gap that was followed by a specific block of data. The space left by the stop/start was short enough that the h/w counted it as an IRG and did not prime itself to look for the file mark. Regards, Richard Schuh -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Tuesday, February 07, 2006 8:36 AM To: [email protected] Subject: Re: Tape conversions Marcy, Back in the "bad old days" I wrote a VMBRECR8 EXEC which can be used to "recreate" missing VM:Backup tapes with the proper internal tape chaining. However it ran into a problem when copying from tapes that were full, because to make the required changes to the volsers from the good tape onto the output "COPYn" tape, it has to read the input tape's SLs and User Header Labels, build the appropriate replacement User Header labels and write them to the new output tape. That means stopping the output tape repeatedly while preparing the new output labels - each time introducing inter-record gaps which take up physical space on the tape. Just enough space that a full input tape will usually not quite fit onto a new output tape. But... if you are copying VM:Backup tapes to a higher density media one-for-one, then VMBRECR8 EXEC might work for you. OTOH, it won't update the records in the VM:Backup with the new tape density since this is all done completely outside of VM:Backup. Editing the catalog *could* be done, but you'd probably want to work with CA on that issue. :-) The syntax for VMBRECR8 is: ---<snip>--- VMBRECR8 ? VMBACKUP is used to create tapes from the nightly VM DASD backups, and also perform the tape I/O and TWINing for VM:Archiver service machines. VMBRECR8 is used to create valid copies of tapes created by VMBACKUP in cases where one tape becomes damaged or lost. It requires that the volser of the lost or damaged tape, and the volser of the corresponding VM:Backup COPY. Lots of damaged VM:Archiver tapes can be re-created by running a Merge/Purge request. The good tape should be mounted on virtual 181, and the tape to be re-created on virtual 182 before executing this command. Note: Each tape written by VMBACKUP has internal pointers to the tape before and after it, as well as volsers of the first tape in each VM:Backup stream in the backup job. Simply COPYing a VMBACKUP-created tape and changing the VOL1 WILL NOT WORK! +-FROM-+ >>-VMBRECR8--+-Sibling(lost/damaged)Vol-+--+------+--------------------> >-----------+-Input(good)Vol-+----------------------------------------> >--+-----------------------------------------------------------------+>< +-(-+---------------------------------+--+------------------------+ +-SiblingPrevVol--SiblingNextvol--+ +-)--NOWARN--DEBUG--RPT--+ Where: SiblingVol is the BAD or missing VM:Backup tape (also known as the COPY tape). InputVol is the GOOD Onsite or Offsite VM:Backup tape. Options: If the tape is chained in the TMC, the SiblingPrevVol and SiblingNextVol are not needed, as that information will be obtained from VM:Tape. SiblingPrevVol is the previous volume in the chain (if any) of the Sibling. SiblingNextVol is the next volume in the chain (if any) of the Sibling. PostOptions: NOWARN prevents display of a warning message when the VMBRECR8 command completes. DEBUG do not erase "VMBRECR8 CMSUTx" work files when exiting. There contain the re-built Standard Labels as written to the output (SiblingVol) tape, where "x" is the physical file number (i.e. SL 1 HDR=1, SL1 TLR=3, SL2 HDR=4). RPT check VMBACKUP catalog for tape copy number and stream info. Does not require tapes to be mounted, but chaining is required in the TMC. Example: E.g. where 200000 is damaged and 712345 was the Sibling as known to VM:Backup or VM:Archiver as the COPY tape. VMBRECR8 200000 712345 ---<snip>--- Maybe this could be used as an inspiration for something you write to meet your particular needs? Just ask for a copy. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Marcy Cortes" <[EMAIL PROTECTED]> Sent by: "VM/ESA and z/VM Discussions" <[email protected]> 02/06/2006 08:52 PM Please respond to "VM/ESA and z/VM Discussions" <[email protected]> To [email protected] cc Subject Re: Tape conversions DITTO is not going to understand all the volume chaining in the VM:Backup tapes. Only something that understood that is going to do the trick. Marcy Cortes (415) 243-6343 "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, February 06, 2006 2:34 PM To: [email protected] Subject: Re: [VMESA-L] Tape conversions I use DITTO to copy tapes. [EMAIL PROTECTED] wrote: > What do folks do about moving old VM:Backup and old HIDRO tapes to new > media types? We have a bunch that are supposed to move from IBM 3590 > to STK 9480C and the media types are different and CA doesn't support > moving them. I suggest we just leave 1 drive, but HW manager doesn't > like that at all... > > > > Marcy Cortes > (415) 243-6343 > > "This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based > on this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation." > > -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us 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. 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.
