STEWART_SYS@uta.EDU.UUCP (04/02/87)
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:
printf("The quick brown ");
printf("fox jumped over ");
printf("the lazy dog.\n");
This results in:
The quick brown fox jumped over the lazy dog.
However, when running the program after doing a SET HOST/LOG, the output
in the log file contains:
The quick brown
fox jumped over
the lazy dog.
...even though the output seen on the screen is correct. Using DEFINE
SYS$OUTPUT PROG.LOG to capture the output works as expected, writing one
line to PROG.LOG.
Anyone got any clues?nagy%43198.hepnet@LBL.ARPA.UUCP (04/03/87)
>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.
NED@YMIR.BITNET.UUCP (04/03/87)
The "problem" is that SET HOST/LOG captures text essentially on a per-QIO
basis. Each of the printf calls you did seems to have resulted in a separate
QIO and hence a separate record in the log file. Note that log files are
written with no carriage control attributes and with explicit carriage
returns, line feeds and so forth in the records themselves, so the appearance
of the text is correct when you TYPE it out. This type of file (explicit
imbedded carriage control) is produced by several notorious VMS utilities,
notable RUNOFF.
I have used SET HOST/LOG to record sessions with DIALOG and other dialup
database services, and it can be a pain to munge the files produced into
something reasonable. The conversion program I use most of the time is TECO,
which for the most part does the right thing, reading a file with imbedded
carriage control and writing a "regular" file with carriage return carriage
control records. Long live TECO!
Ned Freed (ned@ymir.bitnet)KFL@AI.AI.MIT.EDU.UUCP (04/04/87)
This is because VMS is record oriented rather than character oriented. There is frequent confusion between a newline appearing because of the end of a record, and a newline appearing because the is a <CR><LF> in the file at that point. Different software deals with this differently. A file can have NONE for CARRIAGECONTROL. This means that only <CR><LF> will cause a newline on a terminal or a printer. You can covert your logfile to that form, but that wouldn't fix the problem, because there are no <CR><LF>s in the logfile. LIST for CARRIAGECONTROL is the default. That means a newline is sent to the terminal or the printer whenever there is a new record in the file. This is probably the form of your logfile. Do DIRECTORY/FULL to check. There are also STREAM files, which are character oriented like all text files in Unix and MS/DOS. This is how all text files should have been on VMS, had the developers thought about it a little. Unfortunately, most software on VMS does not generate or accept STREAM files. ...Keith