Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!LBL.ARPA!nagy%43198.hepnet
From: nagy%43198.hepnet@LBL.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: RE: VAX C printf problem (not really)
Message-ID: <8704032323.AA04334@ucbvax.Berkeley.EDU>
Date: Fri, 3-Apr-87 07:37:15 EST
Article-I.D.: ucbvax.8704032323.AA04334
Posted: Fri Apr  3 07:37:15 1987
Date-Received: Sun, 5-Apr-87 07:21:43 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 24
Approved: info-vax@sri-kl.arpa

>I don't know if this has been submitted to the net before, but I've noticed
>a pecular occurance when using the SET HOST/LOG sequence to capture output
>from C programs using the printf statement.  For instance, the following
>segment of code will print one line and a carriage return to the screen:
... omitted to save the innocent ...     
>SYS$OUTPUT PROG.LOG to capture the output works as expected, writing one
>line to PROG.LOG.
     
The problem is not VAX C printf, but in how SET HOST writes it log file.
THe file written by using DEFINE of SYS$OUTPUT is created in Stream_LF
mode (normal for VAX C files).  The "delimiter" in this file is the
new line in the 3rd printf.

The file written by SET HOST/LOG is a normal VMS text file of variable
length records and carriage return attribute.  Each printf's output
ends up as a separate record in this file.  What seems to be going on
here is that each printf is turned into a separate $QIO operation and
is being picked up by RTPAD (the program you run when you do SET HOST)
as such.  RTPAD then writes this packet to the log file as a record.
Thus the 3 printf's result in 3 records.  WHen you TYPE the file, each
record becomes a separate line due to the carriage return attribute.

So, the problem is in RTPAD in that it seems to write its log files
with an inappropriate choice of record type and attributes.