RE: APYJRNCHG

["Reeve Fritchman" <reeve@xxxxxxxxxx>]

No...to make sure you don't get caught in this trap, you'd have to restore
all objects from each SAVCHGOBJ.  Journaling is the only option that handles
records...but your industrial-strength backup is by far the best.

The only step you could take to make your backup better would be to journal
master and transactions files and roll the receivers off to tape several
times a day.

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of Bale, Dan
Sent: Wednesday, August 22, 2001 11:01 AM
To: midrange-l@midrange.com
Subject: RE: APYJRNCHG

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Thanks, Bruce, I feel better now!

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.

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.

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"?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From: R. Bruce Hoffman, Jr. [SMTP:rbruceh@attglobal.net]
> Sent: Wednesday, August 22, 2001 10:29 AM
> To:   midrange-l@midrange.com
> Subject:      Re: APYJRNCHG
>
> Hey, Al.
>
> My only problem with this response is that it's a blanket statement
> implying
> that journalling is of no use, and I know you don't truely believe
> that, do
> you?
>
> so... as I see it, what you really said was:
>
> One of the reasons for doing Journals and SAVCHGOBJ is to recover to a
> point
> in time.
>
> If that point in time that you wish to recover to happens to be the
> point in
> time where you took the save changed objects, then fine. Journals will
> complicate that recovery.
>
> Your point of ignoring journals is well founded. Most people don't
> take the
> time to figure out a comprehensive save strategy that includes the
> journal
> receivers being taken off the system and physically away from the site
> on a
> regular, recurring basis other than at the same time they take the
> save
> changed objects.
>
> So, if the point in time is to a specific hour of the day, you need to
> consider using journals and journal receivers, but, and this is a big
> but...
> you must also consider more frequent isolation of the receivers.
>
> This, like very fast tape drives, costs money. A complicated restore
> process
> must be offset by the financial need to recover to more specific
> points in
> time.
>
> Again, if that point in time is not a factor in a site loss situation,
> then
> not saving the journals will shave your restore time, but the journals
> can
> allow you to recover more quickly and more precisely from say a
> program
> induced error. (A more likely, and more frequent problem). Offsite
> journal
> receivers can be a hinderance here.
>
> There are always a lot of things to consider in save restore.
>
> ===========================================================
> 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
>
> -----Original Message-----
> From: barsa@barsaconsulting.com <barsa@barsaconsulting.com>
> To: midrange-l@midrange.com <midrange-l@midrange.com>
> Date: Tuesday, August 21, 2001 10:07 PM
> Subject: Re: APYJRNCHG
>
>
> >
> >Forget using your journal entries as a part of the restore.  On
> SAVCHGOBJ,
> >change the OBJJRN parameter from *NO (the default) to *YES.
> SAVCHGOBJ was
> >created when journaling was a key part of OS/400's (then CPF's) save
> >restore strategy.
> >
> >Al
_______________________________________________
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