[mod.computers.vax] Stream files...

ABSTINE@CLVMS.BITNET (Art Stine) (08/19/86)

Has anyone ever had to convert a 512byte fixed length file to true UNIX
style stream format? Using CONVERT, we get a file that still has a
max record length of 512, no matter what we specify as the size in the
FDL to convert it. The problem is that convert is putting a LF at the
end of each 512 byte record and ends up messing up the data...

What this is for is TeX. We have a routine which converts from TeX DVI
to Postscript and the routine is written in C. The routine is expecting
just a stream of bytes, no record blocking.


One of our programmers is currently using a Pascal program to convert the
binary DVI to an ASCII dump and then using a C program to read the dump and
convert it back to stream binary. The output from the C program makes
ANALYZE/RMS lose its lunch, since it doesn't seem to conform to RMS. But
the DVI2PS C program will read it, no sweat.

Any ideas?

Art Stine
Systems Programmer
Clarkson University
Educational Resources Center
Potsdam, NY 13676

Phone: (315)268-2292
BITNET: ABSTINE@CLVMS

amr@rti-sel.UUCP.UUCP (08/25/86)

In article <8608190243.AA24449@ucbjade.Berkeley.Edu> ABSTINE@CLVMS.BITNET.UUCP writes:
>Has anyone ever had to convert a 512byte fixed length file to true UNIX
>style stream format? . . .
>
>Any ideas?
>
>Art Stine

Faced with a closely-related problem (TeX DVI files and a PASCAL
DVI-to-Impress program), I avoided the issue. I wrote modules that
replaced the PASCAL I/O calls.  These were FORTRAN (yes FORTRAN)
subroutines which mapped the DVI file as a section, and then 
handled it as a simple vector of bytes along with a pointer to
the current location.

I realize it may sound complicated, but the system services needed
to map the file aren't really very tough.  Your source (512 byte,
fixed length, unformatted data) is an easy target to map to since
# of records <--> number of pages, and there should be nothing in
the file that isn't part of the byte stream.  I think you'll find
it significantly faster than ASCIIfying the DVI and then back-
converting to binary.

-- 


					Cheers,

					Alan Roberts
					Research Triangle Institute
					(decvax!mcnc!rti-sel!amr)