× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



-----Original Message-----
From: Bale, Dan <D.Bale@handleman.com>
To: midrange-l@midrange.com <midrange-l@midrange.com>
Date: Wednesday, August 22, 2001 11:07 AM
Subject: RE: APYJRNCHG


>We do not use SAVCHGOBJ.  I have never been comfortable with the
>concept.  As such, I have made it a point to always to do as much of a
>backup on a daily basis as possible in a given environment.  Each night,
>SAVCFG, SAVSECDTA, SAVLIB *ALLUSR, SAVLIB *IBM, SAVDLO *ALL, and SAV
>(with recommended omits).  I know I have been fortunate to have worked
>in environments that give me the luxury to not have to resort to using
>SAVCHGOBJ.  I have a SAVSYS backup that gets redone everytime we do
>PTFs, or after an upgrade, or, as is mostly the case in our current
>environment, at least once every 3 months.

Ahh, the paranoid backup... ;-)

Most of the shops that I work in now have auto config on and an ethernet or
token ring line. Very little else in the way of configs and the configs very
rarely change. If you have the window, fine. If you can't deal with a
restore that requires you to use multiple tape sets, fine. But most don't
really need the SAVCFG every night.

The SAVSECDTA depends on your environment, but some smaller shops don't need
this every night either.

SAVLI B *ALLUSR is ok, but again, unless you are changing software or
putting up PTFs constantly, SAVLIB *IBM is probably overkill.

>
>In our current environment, we are not journaling our production files.
>We do not have the horsepower nor the DASD to support it.  Ideally, I
>would like to add a new ASP to each of our production boxes that would
>be dedicated to the journaling function.  If the primary ASP fails in
>such a way that we have to restore everything from scratch, I'd restore
>from tape, then apply journaled changes to get back to the point of
>failure.
>
>Does that sound like a reasonable approach?  I know I'm short on
>details, and I'll definitely have to read up on the subject if/when that
>opportunity arises, but it seems to me that this is viable.


Sure, just so long as you understand that if you don't isolate the journals
off site, a site loss leaves you with just the tapes sitting in the trunk of
your car or whereever your offsite storage takes place.

>
>Oh, the reason I am uncomfortable with SAVCHGOBJ.  (I'm sure someone was
>going to ask <g>)  Can anyone tell me what happens when you do a
>complete library save (SAVLIB) on Sunday night, delete a file from that
>library on Monday, do a SAVCHGOBJ on that library on Monday night, have
>the system crash on Tuesday, necessitating a restore of the SAVLIB from
>Sunday night, and a restore of the SAVCHGOBJ  from Monday night?  Will
>the file deleted on Monday be in the library after the SAVCHGOBJ is
>restored?  In other words, does the SAVCHGOBJ function handle deleted
>objects as a "change"?


No. The object is there from the full backup. SAVCHGOBJ saves any object, in
its entirety, if it has changed at all, since the reference data on the
SAVCHGOBJ command, which defaults to the last full save.

I can not currently think of a reason that someone should be uncomfortable
with the SAVCHGOBJ command. As in my previous example, it might not be a
significant savings based on your environment and the volume of data vs the
"touched" objects. In other words, I have seen situations where a SAVCHGOBJ
still takes the same number of tape volumes and almost the same amount of
time as doing a SAVLIB *ALLUSR.


===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified Specialist - AS/400 Administrator
 -- IBM Certified Specialist - RPG IV Developer

"America is the land that fought for freedom and then
  began passing laws to get rid of it."

     - Alfred E. Neuman





As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.