Page 1 of 1

RMDS

PostPosted: Fri Jan 15, 2010 11:07 pm
by pillai
Hi all,

We use RMDS in mainframe as our report management system.
We do fullpack back-up of all RMDS packs every night. As the data is growing this back-up takes longer hours and hence we have a batch window issue.
I am wondering if we have an option or product to do incremental back-up of RMDS packs.

Thanks.

Re: RMDS

PostPosted: Sat Jan 16, 2010 12:02 am
by Robert Sample
Contact the vendor for support.

Re: RMDS

PostPosted: Sat Jan 16, 2010 1:06 am
by pillai
We did. Vendor doesn't have a solution.

Re: RMDS

PostPosted: Sat Jan 16, 2010 1:10 am
by dick scherrer
Hello,

What software is being used to create the backup?

What media is being written to for the backup?

Re: RMDS

PostPosted: Sat Jan 16, 2010 1:48 am
by Robert Sample
We used Tivoli a while back and it could do incremental backups -- but I don't know if it could do incremental backups of RMDS.

DF/DSS is an option -- we use parallel mode to back up two 3390 mod 3 disk packs at a time and it averages about 9 minutes per pair of packs to back them up (each pack is roughly 75% full).

Re: RMDS

PostPosted: Sat Jan 16, 2010 4:14 am
by pillai
We use DFDSS to do the pack backup.
we also average 8 to 9 min for a 3390 mod 3.
As we have too many packs the timing becomes a issue.

Re: RMDS

PostPosted: Sat Jan 16, 2010 4:34 am
by dick scherrer
Hello,

To Repeat:
What media is being written to for the backup?


The new "fat" tapes/ ecart devices are considerably faster than the 3480/3490 carts if they are not already being used. I don't remember the "numbers". . . :?

Re: RMDS

PostPosted: Sat Jan 16, 2010 5:16 am
by Robert Sample
It sounds like your site needs to do a major analysis effort. If the jobs are I/O bound, you may be able to reduce timing by spreading workload across the channels evenly . If the jobs are CPU bound, you could look at running when the CPU is less busy. If neither of these ideas work, you r site may need to spend some money to upgrade (tape drives to use newest models as Dick suggested, or DASD to allow disk-to-disk copies instead of disk-to-tape, or perhaps a CPU upgrade). Since your pack backup times seem reasonable, there may not be much we can suggest -- only someone very familiar with your site could make suggestions based on analyzing the SMF data.