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.

> It gets worse: Yesterday our system crashed, and the job which creates
> KSAM key file recovery job streams didn't work correctly. We have a
> program which checks the crash flag on the KSAM files and builds a list
> of those which need to have a KEYINFO;RECOVER performed on them in
> KSAMUTIL. Apparently it didn't work, and one of our developers was in
> late last night, manually running all the recoveries. So now it also
> looks like the crash flag isn't getting set. (I say "apparently" because
> I'm actually supposed to be on vacation, so I haven't been able to
> verify this -- my colleague at work is looking into it.)
>
> Has anyone else run into this, or can you offer any explanation as to
> why the change in CM KSAM data file behavior?
>

Hmm, this one I don't know about. As a workaround, you could try using FCOPY to
copy all your CM KSAM files into NM KSAM files. NM KSAM files use MPE/iX's
Transaction Management facility and automatically recover to a consistent state
after a system crash. The CK... intrinsics work interchangably with either CM
or NM KSAM files, so in theory your applications wouldn't even notice the
change. Of course, if your applications are creating CM KSAM files I guess
you'd have to try and use file equations to override that to have them create
NM KSAM files.

>-- End of excerpt from Patrick Santucci

I hope this helps!

Craig

--
Craig Fairchild

Email: [log in to unmask]               Phone: (408) 447-5990
USPS:  Hewlett-Packard Company           Fax:   (408) 447-4278
       M/S 47UA
       19447 Pruneridge Avenue
       Cupertino, CA 95014