AW: APYJRNCHG

Hi,

re savchgobj: I'll have a full backup on sunday and daily savchg. If I loose
the system on saturday I'll need 6 different
tapes to do the reload, right? What happens if one of the daily tapes is
damaged? As Murphy says, it sure will be the
monday tape...

Oliver

> -----Ursprüngliche Nachricht-----
> Von:  R. Bruce Hoffman, Jr. [SMTP:rbruceh@attglobal.net]
> Gesendet am:  Mittwoch, 22. August 2001 17:28
> An:   midrange-l@midrange.com
> Betreff:      Re: APYJRNCHG
>
> -----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
>
>
>
> _______________________________________________
> 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