× 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.



In answer to your question (see paste below), I have'nt proven this, but 
deleting the object, changes the library, so the library is picked up as a 
changed object.
Again, this has NOT been proved, but that is how it was explained to me. (I had 
exactly the same question).

>>> "Bale, Dan" <D.Bale@handleman.com> 08/22/01 11:01AM >>>
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Thanks, Bruce, I feel better now!
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



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.