We have problems but intermittend on temporary KSAM files ... sometimes they are
emptied before getting them permanent.
I do not know whether there is a generic problem in KSAM with 5.5 but we
remembered that in the beginning of 5.0 there were also problems with KSAM files
...
Best regards, Andreas Schmidt, CSC, Germany
[log in to unmask] on 08/13/98 05:08:16 PM
Please respond to [log in to unmask]
To: [log in to unmask]
cc: (bcc: Andreas Schmidt/HI/CSC)
Subject: CM KSAM/File System Bugs in 55 pp4? (long)
We're calling HPRC on this, but I'd like to know if anyone can confirm
or deny the problem:
Since upgrading from 5.0 to 5.5 pp4, we're not getting all our CM KSAM
data files backed up when using the DATE parameter of STORE. Our
developers are saying that, under 5.0, any time a KSAM file was opened
for read/write access, the modification date on the file was updated,
even if no changes were actually made.
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.)
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?
Thanks for your kind attention.
Patrick
(going back to -- what *was* I doing?)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Why is it that when I was young life was complex because
I lacked experience and now that I'm experienced life is
complex because I'm not young?" - James Trudeau
|
