I do understand that you want to use TMM. However, in this specific case, why 
not just COPYDUMP from the old ATL to the new ATL without using TMM? I would 
guess that you will need to do any dataset stacking from the old volumes onto 
the new volumes "by hand". I'd likely do this in a single step with UNIT=AFF 
and VOL=REF= in the JCL so that there will only be a single mount of the new 
tape volume. I don't know how many volumes you have which would be a definate 
impact on how hard it would be to actually do. Your tape catalog may help 
because it should have the block count on the existing COPYDUMP tapes so that 
you can get a decent estimate of how to stack them onto the higher capacity 
3592 tapes. 

I know it's not what you want to do, but it may be better than doing a bunch of 
RESTORE and reDUMPs.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
[email protected] * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -----Original Message-----
> From: IBM Mainframe Discussion List 
> [mailto:[email protected]] On Behalf Of Fred Schmidt
> Sent: Sunday, February 20, 2011 5:33 PM
> To: [email protected]
> Subject: Re: How to move DFDSS DUMPS on tape with large block 
> sizes to TMM DASD?
> 
> On Fri, 18 Feb 2011 09:12:21 +0100, R.S. 
> <[email protected]> wrote:
> 
> >The most practical approach: use proper tools. HSM (of 
> FDR/ABR) backups
> >could be easily RECYCLEd, not to mention ease of backup process.
> >Of course HMS should be implemented in advance, so this is 
> not an advice
> >for this case.
> >
> >For this case I would suggest two approaches:
> >
> >1. WAIT. Start using new tapes for new backups and wait - old backups
> >will expire. he longer you wait the more backups expire.
> >
> >2. Remaining dumps (or everything if you don't want to wait) can be
> >COPYDUMPed without affecting BLKSIZE or restored on dasd with RENAME.
> >The last option involve manual process of changing names, at least at
> >HLQ level, but "manual" (non-HSM) backups do require such knowledge.
> >
> >BTW: Are you sure the blocksize on 3590 is 229360?
> >The largest blocksize available on Jaguar is 256kB.
> >BLKSIZE LIMIT (forgot the keyword) can be up to 2GB, but it is
> >theoretical (system software) limit. SCSI reference of 
> Jaguar specifies
> >that blocksize can be up to 2MB.
> >
> >So, if your blocsize is really 229360, then you don't need to reblock
> >the dumps!
> 
> Sigh. Maybe I didn't make the situation clear. 
> 
> We already have HSM. We already use TMM. We want to use TMM 
> with our new ATL
> (3592 tape) to hold DFDSS DUMP datasets currently on our old ATL (3590
> tape). The problem is that these datasets have a blocksize of 
> 229360 (and
> yes, I am sure of that). This blocksize is way too big for 
> DASD, which is
> where we have to put it for it to be put on tape by TMM. 
> COPYDUMP does not
> allow the blocksize to be changed. COPYDUMP is the only 
> supported way to
> copy DUMP datasets. So we appear to be stuck without a way of 
> moving this
> data to TMM, other than restoring the data and re-dumping it to TMM.
> 
> Any better ideas than restoring and re-dumping would be 
> gratefully appreciated.
> 
> Waiting for the old backups to expire is not an option, as 
> some of these
> have to be kept for 7 years and we need to move the old ATL out now.
> 
> Fred
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to