[mod.computers.vax] Eliminating CR/LF from output to a terminal

KINGLEON@HUMBER.BITNET.UUCP (04/04/87)

I have a problem similar to the recent one by Dan Stewart (extra \n
added when sending output to a log file.)

  I'm trying to dump a binary graphic image down to a RasterTek Model
10 using  VAX C.  Every 80 bytes VMS adds a newline, which is interpretted
as a display pixel and scuzzes up the image.

   By using SET TERM/width I can increase this interval to 511 bytes,
but I'd like to eliminate it altogether.  Can anybody tell me how
its done?


Thanks Bunches (in advance)

TLI%Sargas@USC-OBERON.ARPA.UUCP (04/05/87)

You can try doing a SET TERM/NOWRAP....

Cheers,
Tony ;-)
-------

"MCCORE::BOLTHOUSE@ti-eg.CSNET".UUCP (04/06/87)

VAXC tends to use awful default RMS characteristics for stdout if your
interest is writing binary data.  I use the following open() sequences for
writing:

#ifdef VMS
#define text_open(fd,str,flags,mod) fd = open(str,flags,mod,\
                  "rfm=var","rat=cr","mbf=2","mbc=51")
#define binary_open(fd,str,flags,mod) fd = open(str,flags,mod,\
                 "rfm=var","mbf=2","mbc=51")
#endif

I also define appropriate macros for non-VMS environments.  Note the absence
of the "rat=cr" in the binary_open macro; the default is "rat=null", I think.
Anyway, this works nicely for binary data for me.  Note the same approach
can be used with fopen(), freopen(), creat(), and so forth.  I tend to prefer
using variable-length records on VMS for text; this could be debated :-).

Oh, the "mbf=2" means RMS should use 2 buffers (generally makes processing go
faster on machines with sufficient memory, slower on constricted machines). This
makes my code go *much* faster.  The "mbc=51" means RMS should grab 51 blocks
at a time, which is the number of blocks/track on an RA81.  I'm not as
convinced about the speed increase for the "mbc=" parameter as with the "mbf="
parameter, although empirical data (PCA) definitely indicates fewer IOs are 
taking place with "mbc=51".  Again, if you're working with memory-poor 
machines, this may not be a good idea.  Also, if you have badly fragmented
disks, neither of these 'tweaks' is likely to help your performance much.

david l. bolthouse
texas instruments defense electronics information systems VAX system support

ma bell:  214.952.2059
csnet:    bolthouse%mccore@ti-eg
arpa:     bolthouse%mccore@ti-eg.csnet

Disclaimer:  you know by now my employer doesn't necessarily agree with
what I think...