Re: Method to force keeping of source
From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 06/30/04
- Next message: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Previous message: Lueko Willms: "Re: Class Test for Valid Characters"
- In reply to: Warren Simmons: "Re: Method to force keeping of source"
- Next in thread: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Reply: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 30 Jun 2004 10:41:52 -0700
Top posting:
It appears to me that your wish is that the COBOL standard should prevent
*any* difference between implementations, either in the operating
environment for the compiler or in the execution environment. It also
appears to me that your wish is for any deficiency that might be perceived
in that operating environment, the appropriate solution is always an
enhancement to the COBOL standard and in COBOL implementations conformant
with that standard.
I do not believe the problems of source maintenance -- which is the topic
that started this thread -- are unique to COBOL; I believe *exactly* the
same problems exist with Pascal, Algol, RPG, BAL, Delphi, and C# inter
pluribus alii. The procedures that are appropriate for backup in an
*operating environment* are specific to that *operating environment*.
The standards committee has been careful over the years *not* to insist, for
example, that a packed-decimal field must always include space for a sign
whether or not it's declared with one, or that it must always occupy a fixed
number of bytes, any more than it has mandated that a Usage Binary item
shall always occupy four bytes and be represented as a binary value in
two's-complement notation.
I think the standard *should* allow standard COBOL compilers and programs to
run on everything from a PDP-8 to a 256-bit-word super-ueber-computer,
presuming an *implementor* is willing to provide a compiler for the
environment. If the standard places limits or requirements on the operating
environment, and those limits or requirements are outside the capabilities
of that environment, standard COBOL cannot be used effectively in that
environment. Should the standard specify a USAGE such that items can be
declared in a format identical to Standard Intermediate Data Items? If so,
how should those items be represented in memory? Should a (hypothetical)
machine that operates entirely in decimal be required to encode a SIDI in
binary? Should a machine that favors binary be required to encode the data
in decimal? I personally don't.
Not every problem that every shop using COBOL might encounter is
appropriately solved by the COBOL compiler, or by the standards committee
mandating the way in which the operating environment must solve it. I
think a user's failure to back up his source files is one of those problems
that neither the standards committee nor the designer of a COBOL compiler
for a particular implementation should be expected to solve, or required to
solve.
-Chuck Stevens
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:0RpEc.47473$OT6.19203109@news4.srv.hcvlny.cv.net...
> 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
> >
> >
- Next message: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Previous message: Lueko Willms: "Re: Class Test for Valid Characters"
- In reply to: Warren Simmons: "Re: Method to force keeping of source"
- Next in thread: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Reply: docdwarf_at_panix.com: "Re: Method to force keeping of source"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
