Patrick Mullen writes:

> There are run time fields in the root file that get modified during a
> DBOPEN (regardless of Mode)...They revert back to zero (in the cases I
> examined) upon DBCLOSE...So in effect, no lasting modification transpired
> although a run time modification took place (returned to its/their
> initial/default values upon DBCLOSE, in the fields I examined)...
>
> I must say that I, too, was surprised but now understand how it happened.
>
> The coresponding/underlying datasets do *not* get an updated 'mod date'
> during dbfind/dbget on a Mode 5 opened database, however...

A side effect to this behavior is that an incremental backup will consider
this root file modified today, thus backing it up. Moreover, using the
default TurboStore option ";FULLDB" will cause TurboStore to write the
entire database to tape, even though none of it has been modified. This can
be quite a surprise to find a large archive database on a partial backup.

Another issue is that TurboStore sets the DBSTORE flag and writes the last
logfile and datestamp to each root file it backs up. In doing so, TurboStore
is also updating the access and modify dates of the root file in the file
label. Consequently, databases appear to have been modified just because
they have been backed up.

I suspect that because of the speed and capacity of DDS2, DDS3, and DLT
drives that most users are just doing daily full backups and no longer
running incremental backups or this issue would have received a lot more
attention. And those that are concerned about the length of daily backups
are selectively backing up files rather than using the ";DATE=" parameter of
TurboStore.

Has anyone else noticed this behavior? Has it been a problem for you? Just
curious.

Doug.

Doug Werth                             Beechglen Development Inc.
[log in to unmask]                               Cincinnati, Ohio