Re: Method to force keeping of source

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 06/29/04

  • Next message: Bill Law: "Cobol Opportunity Available" 
    Date: Tue, 29 Jun 2004 10:57:50 -0700

    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

  • Next message: Bill Law: "Cobol Opportunity Available"

    Relevant Pages

    • Re: Cobol Linear search Vs Perfrom Until
      ... ordering of the data, the presence of duplicates, or the form of SEARCH to ... is that they do in earlier compielrs, but the context of "defined results" ... If the implementor chooses to define the behavior outside of that restricted ... context in which the *standard* provides predictable results, ...
      (comp.lang.cobol)
    • Re: SEARCH ALL
      ... is limited in its subjects to keys referenced in the KEY ... It MAY well be possible for the implementor to ... That both the documentation and the standard at the time ... I duly reported back to the salesman that it was impossible to ...
      (comp.lang.cobol)
    • Re: A very *PERSONAL* view of ISO 2002 COBOL for the IBM (mainframe) environment
      ... I very much enjoyed reading Bill Klein's take on the '02 standard. ... Bill noted that in current IBM mainframe COBOL ... and it's *only* in free-form reference format, ... "Margin R" has been whatever the implementor ...
      (comp.lang.cobol)
    • Re: sprintf
      ... There would be no standard if if demons flew from my nose. ... Undefined behavior gives the implementor license to not catch ...
      (comp.lang.c)
    • Re: COMPUTE vs MOVE
      ... arithmetic expression in the '85 Standard. ... implementor may do ANYTHING they want. ... > WMK> everywhere else) is implementor defined. ...
      (comp.lang.cobol)