[comp.os.vms] batch log files and EDT

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.
-------