Re: Method to force keeping of source

• Previous message: JJ: "Re: interacting with an ACUCOBOL application"
• In reply to: Chuck Stevens: "Re: Method to force keeping of source"
• Next in thread: Chuck Stevens: "Re: Method to force keeping of source"
• Reply: Chuck Stevens: "Re: Method to force keeping of source"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 30 Jun 2004 02:47:24 GMT

See comments inserted below.

Warren

Chuck Stevens wrote:

> 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.
>
You are quite right, Chuck. It reminds me of the user/vendor
relationships of the past. And I doubt that have changed that much.
In the case of COBOL, while some vendors take credit for producing it,
credit the users because they listened to Grace and demanded it because
there were no common methods that allowed users to freely choose
resources for their system needs without building a wall around the rest
of the vendors attempts to do business.

Every possible vendor wanted the right to bid on potential jobs. The
barriers that existed then made that very difficult, and probably caused
systems support costs that were unreasonable.

Your paragraph below spells that out very well. The concept of
implementor defined is one of the problems as I look at the situation as
much as or more so than the fact that Users should no better as you
suggest. It could be that this unacceptable way of treating the language
of problem statement and data recording is a practice we see in many
or most commercial endeavors. That does not make this practice a good
thing for the users. Much of human effort is spent overcoming the lack
of cooperation. In the case of COBOL, there has in my opinion, been lots
of cooperation, but not exactly to the same solution I believe more
acceptable to users of all levels of usage. The IEEE, as an example,
seems to keep all communications talking to each other by defining
interfaces. Yet, in the case of COBOL, it stops with the problem
statement. There is no attempt at creating one easy way to do the
problem definition.

While were equally implemented COBOL compilers recognize and some
how treat the same source code, it is not in a uniform manner, and
the user compiler options are implementor defined. Teach someone
COBOL, then turn them loose to code using a different compiler on
each job. Will they know how to run the compiler, and the utilities
that are provided with the compiler, or will they have to start asking
around.

I see many things of that nature that tell me that the job of creating
COBOL is unfinished in more than functional ways. I frequently believe
the lack of completion of the language is responsible for the
introduction of other tools that recreate the conditions prior to COBOL.

Of course, that's just me.

Most of your arguments make me think the way I do about the status
of the COBOL objectives. Having lived through the efforts by vendors
to circumvent the idea of one business language, I feel that the
vendors representatives have in large part found ways to cause
the need to CREATE new tools, and continue the status quo of the
pre-COBOL COBOL marketplace. However, from time to time there seems to be
a little light peaking through. I believe, for example, that the
availability of a free COBOL compiler, and tools built to work with
it will bring about more changes that will turn the emphases to what
the user wants. The speed of the desktop, and the drop in the cost of
storage, with the expansion of the net are powerful forces as I see
them. At least I hope so.

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

I love the question at the end of the previous section. My problem with
that is represented by the html, java, php, vbasic, etc most of which
have no major extension to coding but seem to me to fill voids in the
lack of continuing of standardization. Meanwhile, your inclination
expressed below, and it's development here in the C.L.C, NOT IN THE X3
AREA, would make a good sign that people are looking at what is needed,
and what is going on in the world ON A DAILY BASIS.

Warren Simmons

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

• Previous message: JJ: "Re: interacting with an ACUCOBOL application"
• In reply to: Chuck Stevens: "Re: Method to force keeping of source"
• Next in thread: Chuck Stevens: "Re: Method to force keeping of source"
• Reply: Chuck Stevens: "Re: Method to force keeping of source"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]