jfjr@MITRE-BEDFORD.ARPA.UUCP (04/16/87)
Why do batch log files (files you get when you run a batch job with NOPRINT) mildly upset EDT. When EDT is called to edit these files it will complain with something like "input file not in standard format". It will edit the file, and if you EXIT rather than quit the resulting file is fine but I find it disconcerting that DEC which produces quality stuff has one system program - the batch logger- generating files that EDT another DEC program complains about. When I first saw this happen I thought that our system manager screwed up but I saw this on another system (I am talking about 4.whatever) I ate my words but I am still curious. Jerry Freedman, Jr jfjr@mitre-bedford.ARPA "Beware of programmers bearing screwdrivers"
nagy%43198.hepnet@LBL.ARPA (04/16/87)
For some reason, DCL insists on writing text files as VFC files (variable with fixed control) with the record attribute as "Print File Carriage Control". This is true for batch logs (I did a DIR/FULL on a .LOG file for this information), or files written with OPEN/WRITE. In this VFC file, the control bytes (2) contain the carriage control information (1 byte for spacing before printing the line and 1 byte for spacing after printing the line). EDT, TPU and many other VMS utilities and layered products which deal with text files expect text files to be written in VAR format (variable length records) with "Carriage Return Carriage Control" as the record attribute. If the file is not in the expected format, then EDT and TPU output an error message but are otherwise quite happy. If you want a real joke, try using a VAX C program to write a file and then read THAT file with EDT. VAX C writes its text files in Stream-LF format. The last time I looked, EDT did not like Stream format files at all!
LEICHTER-JERRY@YALE.ARPA.UUCP (04/17/87)
This whole area (the multitude of formats for "simple text files", and the incompatible handling of such files by various utilities) is probably the single worst feature of VMS. It is not, however, totally without rhyme or reason: For some reason, DCL insists on writing text files as VFC files (variable with fixed control) with the record attribute as "Print File Carriage Control". This is true for batch logs (I did a DIR/FULL on a .LOG file for this information), or files written with OPEN/WRITE. In this VFC file, the control bytes (2) contain the carriage control information (1 byte for spacing before printing the line and 1 byte for spacing after printing the line). There's a very simple reason why DCL creates process-permanent files with print file carriage control: Images can write to the PPF using any of the supported record formats, and the print file format is the only one that is a superset of all the rest - i.e., can model the rest correctly without a lot of elaborate, and potentially high-overhead, hacking. The VAX C library is pretty good at converting all the various arcane formats into simple ASCII streams, and is quite capable of writing those streams out as "vanilla" VMS text files (variable length, carriage return carriage con- trol) - though you have to ask it to do so, since its default is STREAM_LF format. An fopen call of the form: fopen(fspec,"w","rfm=var","rat=cr") will do the trick. The traditional tool for "normalizing" file formats, however, is TECO - it will read damn near anything correctly, and write a "vanilla" file. There's no need to actually do any editing: Just type: $ EDIT/TECO <file> *EX$$ where the "*" is TECO's prompt, and the "$"'s are ESCAPE's - CTRL/[ for those with ESCAPE-proof keyboards. (Those of you on VAXes without PDP-11 compatibi- lity mode, and also without the PDP-11 simulator that comes with the VAX RSX product, will have to wait for V5's native-mode TECO....) -- Jerry -------
JM9W@TE.CC.CMU.EDU.UUCP (04/17/87)
I have found that using the FDL file below with CONVERT is an easy solution to "fixing" files written as batch logs, via DCL Open/Write statements, etc. As an example of one of my standard uses for it, I have a daily batch job that writes a file via DCL Open/Write, and this file must then be used by a program that can't handle print carriage-control files. The FDL file, DCLCONV.FDL is used in the following CONVERT command: Convert /Fdl=Dclconv Datafile.Txt;0 Datafile.Txt;-1 Here is DCLCONV.FDL: TITLE "DCL file converter" IDENT "26-JUL-1985 18:17:23 VAX-11 FDL Editor" FILE BEST_TRY_CONTIGUOUS yes RECORD CARRIAGE_CONTROL carriage_return FORMAT variable SIZE 512 -Jim Murawski -Carnegie Mellon Computing Services -Pittsburgh, PA, U.S.A. Disclaimer: Any opinions in the above message do not necessarily reflect the opinions of my employer, Carnegie Mellon. -------