Re: Method to force keeping of source

Warren Simmons wrote:

> Oh, and what about the potential savings when the source is not
> available, but the data file is? WS.

This refers to the idea of encoding the record description of a file within
the file itself, perhaps as a resurrection of, or more properly expansion of
the functionality of, LABEL RECORDS ARE STANDARD.

I have several thoughts on this.

First and foremost, my position is that a user who doesn't back up,
safeguard and archive
his source files is being no less foolish than a user who doesn't back up,
safeguard and archive his critical corporate data files.

Because the layout of fields of ANSI-defined USAGEs in memory is defined by
the implementor, and the way fields of those various USAGEs are distributed
in records and the way those records are gathered into blocks and recorded
on the various media are also defined by the implementor, there is no
practical way for the record layouts to be recorded in a manner that would
be meaningful except in the narrow context of the machine on which the file
was written and machines directly compatible with it.  Any presumption that
the information so recorded would be useful outside that context would be
erroneous and would almost certainly lead the user into a false complacency.

Many implementations strive for device independence in I/O -- thus, a
program originally written to produce a tape file can be made to produce a
printer file or a card deck without recompiling the program.   There are
devices -- printer, punch, paper tape, remote terminal (yes, Unisys MCP
systems have "SELECT ... ASSIGN TO REMOTE"), in-memory QUEUE (ditto) -- to
which writing such information would present *significant* problems.

Many circumstances require the ability to access a file from programs
written in various languages.  The only language in which a COBOL record
description is fundamentally meaningful is COBOL, and the overhead
associated with archiving the record layouts in the data file and of
ignoring it (or having the operating environment bypass it) might be
regarded as onerous to users of ALGOL, RPG, Pascal or C that have previously
been able efficiently to access and update the files.

I believe the information being recorded, the manner in which that
information is recorded, the contexts in which the decision to record or not
to record the information can be made at compile time, and the contexts in
which it is suitable or not suitable to record this information at execution
time, are all implementor-defined.

For that reason, I don't see this as a feature that should be standardized.
If everything that the feature does is implementor-defined at the broadest
possible level, both at compile time and at execution time (including the
circumstances under which either the compiler or the operating environment
must ignore the mechanism altogether), what's left to standardize?

Since its suitability, functionality and its very presence in context are
all implementor-defined to start with, this is a great example of a feature
that *any* implementor can choose to implement as he sees fit, even today.

As for standardizing something like this, I'd be more inclined to suggest a
COBOL "data dictionary" feature, standardized data-base declaration and
access syntax (on the list for consideration for a post-2008 standard
already), or (Heaven forfend!) Object Orientation.  Oh, yeah.  I forgot.
That last one's already in the standard.

-Chuck Stevens