Re: The problem with SAVCHGOBJ . . .

In the described scenario using SAVCHGOBJ daily since a GO SAVE Option-21, any libraries that were /created/ new during the month, objects within those libraries would not be saved by a request to SAVCHGOBJ REFDATE(*SAVLIB) because the new library has no value for its saved-date. If a library is saved just after created, then there will be a saved-date available as reference date when the SAVCHGOBJ runs.

If the date\time of the /monthly/ activity were retrieved and specified on the REFDATE parameter, then [one might infer from the quoted & another reply, that] even the objects from the libraries that were never saved, would also be saved.? I was not aware [or should I say, I do not expect] that would transpire, because that would /break/ the restore strategy for RSTOBJ from the save-changed, because the library object would not have been restored as part of any prior RSTLIB. The CL /savchgOBJ/ is a request to save /objects/ within a library, not the *LIB object itself, which requires a SAVLIB request.

Regards, Chuck

Jerry Adams wrote:

Well, I guess I'm missing the point here. I don't use SAVCHGOBJ
here, but we did at another company for which I worked. There we
did a Save 21 monthly and the SAVCHGOBJ daily. The Save 21 got
everything (previously saved or not). If there were no changes
to a library, nothing was backed up until the monthly full system
save. While physically one could just do a SAVCHGOBJ and *never*
do a SAVLIB, it sounds impractical to me. But, as I said,
perhaps I missed the point.

Is that the best game you ever pitched? -Reporter to Don Larsen
after pitching the only perfect game in World Series history.

Simon Coulter on Friday, May 07, 2010 8:47 PM wrote:

On 08/05/2010, at 7:21 AM, James H. H. Lampert wrote:

. . . is that if you do a SAVCHGOBJ, and it finds a library
that's never been saved, it doesn't save it, or anything in
it.

SAVCHGOBJ saves objects changed since the specified reference
date. The default reference date is the last SAVLIB date for
the library containing the changed objects. Because no SAVLIB
has been performed on a newly created library the reference
date is (effectively) null and you'll get CPF3745 and the save
will fail. Resolve it by specifying a reference date instead of
the default.

You could also issue a SAVLIB of the library to a temporary
save file immediately after creating it (i.e., while still
empty). That would set the default reference date and then any
new objects would be picked up.