Re: SAVCHGOBJ (was APYJRNCHG)

Jim,

I've never found one.  Someone had set up the backup of our MAPICS
transaction files library this way, and we had this issue come up a time or
two before I fixed the backup.  The only _safe_ way I found to avoid this
was to get a list of the files on the SAVCHGOBJ backup and actually go
delete them after restoring the full save and before restoring the
SAVCHGOBJ.

BTW, SAVCHGOBJ is only an incremental backup if you set the change date and
time yourself to make it that way.  By default it's a differential backup,
you only need to restore the full save and the LAST SAVCHGOBJ done.

Dave Shaw
Simpsonville, SC
---
If you would like to participate in the MAPICS-L mailing list go to
http://lists.midrange.com/cgi-bin/listinfo/mapics-l and follow the
instructions.

----- Original Message -----
From: "Jim Damato" <jdamato@dollargeneral.com>


> We had an issue with SAVCHGOBJ concerning multi-member files a few years
> back.  We worked with a package that relied heavily on file members as
data
> entry batches and as work members within job streams.
>
> The save command saves members as they are created or changed, but it did
> not account for the deletion of members.  When I performed a test restore
of
> a weekend save and incremental restores of daily SAVCHGOBJ changes I found
> that it accumulated all file members created during the week, even though
> many of the members should have been gone.  Within the context of this
> software package the presence of these members would allow data to be
> reposted.
>
> I was never able to figure out if I was doing something wrong, or, even if
I
> was doing it right, if there was any reasonable way to produce an accurate
> recovery process.