At  12:26 PM 3/23/00, Russ Smith wrote:
>I am having a problem with a C program writing data to a KSAM file.  The
>entire buffer is not being written to the file when the two keys have the
>same value.  Some background -
>
>:build
>KSAM1;dev=disc;disc=75000;rec=-16,,f,ascii;nocctl;ksamxl;key=(B,1,8;B,9,8)

[snipped open modes; I don't think they matter here]

>So, when I issue the following commands:
>
>     sprintf(Buffer,"%8.8s%8.8s",LocatorKey1, LocatorKey2);
>     FWRITE(KSAM1FileNo,Buffer,-strlen(Buffer),0);

Someone else already suggested you should add DUP or RDUP on the key
definitions, but that would allow duplicates values *in the same key
field*.  As I understand your problem, you're trying to write the same
value into two *different* keys in the same record.  (In other words, DUP
or RDUP is needed to add duplicate values in the same key field of
different records.  That's very different from what you're trying to do, I
think.  ;)

>I get the output record correctly in KSAM1 only IF the values of
>LocatorKey1 and LocatorKey2 are different.  If the values are the same,
>the first 8 bytes are written correctly and bytes 9-16 are blank.  I've
>done a display functions on the output and the EOLN marker appears after
>byte 8, so the remaining data is not appearing as blank, rather it is
>never making it into the output file.  An FPRINTF to STDERR shows the data
>correctly in the Buffer variable BEFORE the FWRITE, but the data just
>isn't making it to the file.  I'm stumped.  Any thoughts?

What does "done a display functions on the output and the EOLN marker
appears after byte 8" mean?  I think that probably means you used :PRINT or
some similar command (perhaps in an editor) to copy the file to the
$STDLIST and looked at it with display functions enabled in your
termulator.  If so, perhaps you got bit by the last  bytes of the record
being treated as a line number and suppressed.  (Been there.  Done
that.  So have lots of other folks. ;)

Try using FCOPY's ";HEX;CHAR" options to look at the data in the
file.  That's *much* more reliable than using display functions when you
want to see what's really in the file.  (For one thing, I think it's been
quite a while since some things (like NULL and DEL) got displayed in a
modern HP terminal.)

If that's not the problem, then there has to be *something* in the last 8
bytes of every record in the KSAM file since you built it with fixed length
records.  FCOPY with HEX and CHAR options will show you what's there even
if it's NULL bytes.

HTH.
--
Jeff Woods
[log in to unmask] (preferred)
[log in to unmask] (alternate)
[log in to unmask] (deprecated)
[log in to unmask] (work)