Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!panda!genrad!decvax!decwrl!ucbvax!rti-sel.UUCP!amr From: amr@rti-sel.UUCP.UUCP Newsgroups: mod.computers.vax Subject: Re: Stream files... Message-ID: <8608251406.AA28155@rti-sel> Date: Mon, 25-Aug-86 10:06:30 EDT Article-I.D.: rti-sel.8608251406.AA28155 Posted: Mon Aug 25 10:06:30 1986 Date-Received: Wed, 10-Sep-86 22:02:01 EDT References: <8608190243.AA24449@ucbjade.Berkeley.Edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Alan Roberts Organization: Research Triangle Institute, RTP, NC Lines: 31 Approved: info-vax@sri-kl.arpa 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)