RE: SAVCHGOBJ

["Graap, Ken" <keg@xxxxxxxxxxxxx>]

Fiona -

I agree with Al. Always save access paths...

You should investigate using the Save While Active feature of SAV/RST to
reduce your application offline time while doing backups too.

I B/U over 300GB a night using BRMS/400, our 3590 tape drives and the Save
While Active feature. Our production applications are only unavailable to
users for about 25 minutes a day and that is at 3AM... The end user hardly
even notices the downtime and I backup everything I need for a quick and
easy recovery.

Al has a great presentation on Save While Active that I bet he would send
you, if you asked nicely...

Kenneth
--
********************************
Kenneth  E.  Graap
IBM Certified Specialist
AS/400 Professional
System Administrator
NW Natural - Information Services
System Services
Phone 503 226 4211 X5537
FAX   603 849 0591
keg@nwnatural.com
********************************


-----Original Message-----
From: fiona.fitzgerald@notes.royalsun.com
[mailto:fiona.fitzgerald@notes.royalsun.com]
Sent: Friday, November 02, 2001 3:02 PM
To: midrange-l@midrange.com
Subject: SAVCHGOBJ




We backup changes , without the access paths during the week, & do a full
SAVLIB *ALLUSR at weekends with access paths.
Should the nightly save changes job save access paths just like the weekly
full saves ?

We've been using this strategy to minimise tape & offline batch-window
usage for 5 years, but I'm wondering if this is wrong for effective
disaster-recovery, when it slows down to rebuild them. Our application
files rarely change, only the pgms get upgraded weekly. Does anyone have an
opinion on the pros & cons of this ?

Fiona


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.