Hi, have a strange problem:

Using a C program reading raw TCP writing/inputs from a decserver 90M
and appending an text file (standard fopen and so on), works exclent.

Reading it up into memory and then adding one line (a new alarm) to
reverse the alarm list at a CR that the program is designed for makes
it almost unreadeble.
Characters dissepear, <LF> reppear despite the fact I kill them at
sight and so on.

tried some "wodo" like "rat=cr" and writing binary/or not but the
problem just changes, testprograms work just fine but not this one...

Think its the fileformat that is bugging me, I want to read with EDT
so it woult probably work perfect if i wrote this in DCL but now I
want to use my almost complete C program... and I'm lost :(

Anyone got any snippets on reading up a bit of text an writing it down
again - about 10k textfile or 1k just aslog as it passes 512 bytes as
I think there might the problem lurk. or just the correct fopen for a
EDT formtted (if there is one) file.

Not at work just now, so an example is hard to include - but I hope
you got the feel of the problem.

It appends characters (CR)  that shouldn be there, and omits some (at
512 bytes interval prbably)

Program works like this:

1.0 Init empty string (memory)
1.1 Read/wait from TCP device write to file. (works)
2.1 take same data from TCP device write to memory
2.2 Wait until char 13 (CR) in memory
2.3 read old "new" file
2.4 write new alarm from 2.1 to "new" file
2.5 write write old data from 2.3 but only some of it (1k or 10k
doesn' t matter)
3.0 repeat from 1.0

How do I do to get it to do a normal binary file in/out? C cant be the
problem, It must be me!

CY wrote:

> [...] appending an text file [...]

   Who created it?  How?  "DIRE /FULL"?

> tried some "wodo" like [...]

   Try any like "ctx = stm"?

      HELP CRTL creat Arguments

> Program works like this:
> [...]

   Actual code might be easier to diagnose.  If the problem is
with reading and writing files, then you should be able to
create a test case without any TCP/IP code, only reading and
writing files.

> [...] C cant be the problem, It must be me!

   Probably mostly you, but the C RTL was intended for use
with UNIX stream files, not VMS/RMS record files, so there are
some complications when using C I/O on VMS.

On Jul 6, 5:48=A0pm, CY <christ...@gmail.com> wrote:
> Hi, have a strange problem:
:
> How do I do to get it to do a normal binary file in/out? C cant be the
> problem, It must be me!

CRTL has problems in this area.
IMHO It is broken, because it tries to hard to help IMHO.

For a simple reproducer see my second reply in:
 http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=3D13=
85811

The response for OpenVMS Engineering was very discouraging.
"Please raise a Feature request for OpenVMS CRTL. "
sure...

Hein

On Jul 6, 10:48=A0pm, CY <christ...@gmail.com> wrote:
> Hi, have a strange problem:
>
> Using a C program reading raw TCP writing/inputs from a decserver 90M
> and appending an text file (standard fopen and so on), works exclent.
>
> Reading it up into memory and then adding one line (a new alarm) to
> reverse the alarm list at a CR that the program is designed for makes
> it almost unreadeble.
> Characters dissepear, <LF> reppear despite the fact I kill them at
> sight and so on.
>
> tried some "wodo" like "rat=3Dcr" and writing binary/or not but the
> problem just changes, testprograms work just fine but not this one...
>
> Think its the fileformat that is bugging me, I want to read with EDT
> so it woult probably work perfect if i wrote this in DCL but now I
> want to use my almost complete C program... and I'm lost :(
>
> Anyone got any snippets on reading up a bit of text an writing it down
> again - about 10k textfile or 1k just aslog as it passes 512 bytes as
> I think there might the problem lurk. or just the correct fopen for a
> EDT formtted (if there is one) file.
>
> Not at work just now, so an example is hard to include - but I hope
> you got the feel of the problem.
>
> It appends characters (CR) =A0that shouldn be there, and omits some (at
> 512 bytes interval prbably)
>
> Program works like this:
>
> 1.0 Init empty string (memory)
> 1.1 Read/wait from TCP device write to file. (works)
> 2.1 take same data from TCP device write to memory
> 2.2 Wait until char 13 (CR) in memory
> 2.3 read old "new" file
> 2.4 write new alarm from 2.1 to "new" file
> 2.5 write write old data from 2.3 but only some of it (1k or 10k
> doesn' t matter)
> 3.0 repeat from 1.0
>
> How do I do to get it to do a normal binary file in/out? C cant be the
> problem, It must be me!

I don't want to sound pedantic here, but your topic title says
"textfiles" and your last sentence above says "binary files".

Which one is it? There are major differencees; e.g. there are inherent
difficulties in using C-style IO for reading generic binary files in
any non-Unix-style environment (this is not just a VMS issue).

A small code sample (ideally just the IO stuff) would help folk see
what you're really doing.

If you're trying to do Vaxcluster-Console-System style functionality,
ie listen to a stream of serial input, parse it, and act on/store it
as required, then this should be eminently doable.

In article <1bd10c62-d5e6-4eb4-af83-1b2b65e102e3@c10g2000yqi.googlegroups.com>, CY <christery@gmail.com> writes:
> Hi, have a strange problem:
> 
> Using a C program reading raw TCP writing/inputs from a decserver 90M
> and appending an text file (standard fopen and so on), works exclent.
> 
> Reading it up into memory and then adding one line (a new alarm) to
> reverse the alarm list at a CR that the program is designed for makes
> it almost unreadeble.
> Characters dissepear, <LF> reppear despite the fact I kill them at
> sight and so on.

   What is the file format?  (directory/full will tell us)

   What is the I/O statement that writes the line?  (code snippet)

   What is the actuall content of the bytes in the buffer being
   written? (exam/hex from DEBUG)

Thanks to all, got some insight and will (at work where I cn reach the
VMS) try to make some "prints" with for exmple file format.
that changes (file format) as I change the fopen statement but I dont
know exactly how that impacts. (probably a lot)

This is probably a text file, but treating as binary did get me some
(not many) lost characters. so its an alarm printer = text and <CR> as
far as I can figure.

The only difference in C as I remember is that a 10 is coonverted into
10,13 or something in normal cases. But then I didnt dig into that.

The code is a bit desperata at the time, but Ill try to give you an
example, the problem is my testprograms doesnt do the same... but they
should. :(

just using fprintf as usual, same prgra write it one char at the time
(or several if its in the buffer) and it works - so I thought it was
the fileformat.

@Hein, thanks that might help.

//CY

On Jul 7, 5:30=A0pm, CY <christ...@gmail.com> wrote:
> Thanks to all, got some insight and will (at work where I cn reach the
> VMS) try to make some "prints" with for exmple file format.
> that changes (file format) as I change the fopen statement but I dont
> know exactly how that impacts. (probably a lot)
>
> This is probably a text file, but treating as binary did get me some
> (not many) lost characters. so its an alarm printer =3D text and <CR> as
> far as I can figure.
>
> The only difference in C as I remember is that a 10 is coonverted into
> 10,13 or something in normal cases. But then I didnt dig into that.
>
> The code is a bit desperata at the time, but Ill try to give you an
> example, the problem is my testprograms doesnt do the same... but they
> should. :(
>
> just using fprintf as usual, same prgra write it one char at the time
> (or several if its in the buffer) and it works - so I thought it was
> the fileformat.
>
> @Hein, thanks that might help.
>
> //CY

"in C as I remember is that a 10 is coonverted into 10,13 or something
in normal cases. But then I didnt dig into that."

You can't really avoid "digging into that" unless you are lucky enough
for everything to play nicely as text. Which obviously you haven't
been, so far, and indeed if your input is from a device which is
(e.g.) intended to connect to a serial printer, I would expect to have
to know what incoming characters separate one line from the next, and
which (if any) can be discarded. For example a CR/LF pair (\r\n or 015
012) can often be turned into a simple \n. But not always.

Best of luck anyway.