Our operator is going to start documenting each step in the process to see where the delay is more exactly. On tapes, we put one in Friday and do the normal save with a *LEAVE. That tape sits in the drive until Sat night when we do a savsecdta, savcfg and a few other small libraries with a *LEAVE, Sunday backup is the same so we are just adding the few objects to the end of the Friday tape. We have two tape drives and then so Sunday night we also kick off a duptap from one drive to the second. We send the original to our on campus tape storage vault and the copy goes off site.

... but the forest is so pretty... well not this time of year, lots of grey-brown trees with not leaves. Kinda depressing looking
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Wednesday, April 09, 2008 3:45 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Longer backup after an IPL

Hi Mike

Agreed re the compress I wasn't really thinking about the details, just
things that could cause an issue.

You mention that you are not there to change tapes on weekends. How do you
manage the tapes for the weekend save, in particular the positioning. Do you
do two saves to one tape on weekends ? Could the longer save after the IPL
be the tape repositioning ?

I still think as per my earlier email that you should compare the steps in
the job on a one to ne basis to see which bit of it is taking longer. At the
moment you are trying to see why the whole process takes longer - break it
down into its constituent parts as that will give you more insight into what
the issue might be.

Look at the trees not the forest :)

Regards
Evan Harris

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Thursday, 10 April 2008 12:31 a.m.
To: 'Midrange Systems Technical Discussion'
Subject: RE: Longer backup after an IPL

The script does the same backup process every night Mon-Fri. Weekends are
different since we are not open for business and not here to change tapes.
The script does a save of security data, configuration, all non-system
libraries except our test libraries, all of the IFS. We IPL every Sunday AM
and savsys once a month. The only time we do a GO SAVE 21 is just before an
upgrade or OS or hardware.

Wouldn't it be odd if a save of an object caused it to be decompressed? What
would be the purpose of doing compression if on every save
(which every object on the system should be saved at least once a month) the
object was decompressed.


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.