Craig Fairchild replies:

>>> Craig Fairchild <[log in to unmask]> 08/13/98 10:14am
>>>
Hi Patrick,

On Aug 13, 10:08am, Patrick Santucci wrote:
...
> Now, under 5.5 pp4, the data file seems to get its modification date
> changed only if the file is actually modified.
>
> In both cases, the KSAM *key* file mod date is updated; apparently, it
> gets updated even if you open the file read-only. (Note: I believe
> they're using the CKOPEN intrinsic.)
>
> This has caused our developers many problems because their store
comes
> in the middle of their production cycle and they use the backup for
> application failure recovery. Since the only thing backed up in some
> cases is the key file, it causes problems when they need to restore.
>
> Can anyone verify that, in 5.0, a CM KSAM *data* file opened for
> read/write access gets its mod date updated even if there's no
> modification? (I figure the first step is determining that a change has
> actually occurred.)
>

Yes, this is true. In 5.5 the changes went in to change a file's
modification
timestamp only if it was truely modified. Most customers view this as a
plus
since it means that partial backups complete faster and use less media
because
unmodified files are no longer mistakenly being backed up. It sounds like,
in
your case, you really don't want to use the DATE parameter to STORE,
but
instead want these CM KSAM files to be unconditionally stored.
-------------------------------------------------------------------------------
However, the 5.5 communicator writes on page 3-9 that the modification
date of mapped files and compatilbility mode files are not affected by this
change.  The modification date in the file label is always updated when
these files are opened for write access.  Since CM KSAM file are
compatibility mode files by definition, they should work as before.  Maybe
the documentation and action don't jive.

Mike Berkowitz
Guess? Inc.