Re: Making money from Java

"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote in message
news:QLVof.203$RZ6.53@xxxxxxxxxxxxxxxxxxxxxxxxx

> The issue is too vital to simply take someone elses word about what the
> Bible says. :-)

Saying "The Bible clearly and definitely states ..." is a FAR CRY from "What
I read in the Bible leads me to believe ... ". It is precisely the
absoluteness of the first that speaks of arrogance about one's opinion,
because it elevates it to the level beyond confidence to *incontrovertible*
certainty.

Behavior reflecting humility I find more convincing of a Christian life than
behavior reflecting hubris.

> All that any of us say here simply reflects (hopefully) the best that we
> know. None of us have perfect knowledge, and none of us are without flaw.

I agree. If you believe that, then what you write ought to reflect it
consistently. It hasn't, at least to me.

> From direct and personal experience, I can assure you, this is quite true
> with respect to myself. :-)

Show me, don't tell me!

> However, that being said, when someone has devoted a lot of effort and
> time into studying an issue, they have a right to speak with confidence
> about the accuracy of what they say. Don't all of use do that on a fairly
> regular basis? I know Chuck does. :-)

I speak with confidence on issues with respect to the COBOL standard, at
least in part because I have played an active role in its development over
the last five years, and have been actively involved in ensuring that three
different COBOL implementations were in conformance with their respective
standards for over twenty years. I also have access to the standards
themselves and am reasonably facile in ferretting out answers to questions
of what the standard states and what it does not. But when I speak clearly
on behalf of the standard it is because the standard, having been written in
English in the first place, is incontrovertibly explicit on the particular
subject. E.g., it's not a leap to describe the behavior of MOVE statements
in which the operands overlap as undefined in ANSI-85 implementations given
ANSI X3.23-1985 page VI-69, 6.4.5, Overlapping Operands: "When a sending
and a receiving item in any statement share a part or all of their storage
areas, yet are not defined by the same data description entry, the result of
the execution of such a statement is undefined." I don't think there's
much wiggle room on that one. If an implementor defines the behavior, well,
that's up to the implementor, but there's no guarantee that any other
implementation will be the same. In a few cases in '02 COBOL and more in
the upcoming draft, I've actually written some of the features specified in
the standard.

I speak with authority on the Unisys MCP COBOL implementations because I'm
looking at the Original Text and can tell (in most instances) *exactly* what
they do. I also have full access to the change history over the last twenty
years for these products and am therefore able to track exactly what each
*used* to do. And in the particular case of the COBOL74 compiler in that
environment, I've personally revised around a third of the compiler either
to improve its maintainability and eliminate ambiguities at the source
level, or (in the most obvious example of MOVE statements involving group
items and the PICTURE processor) rewritten all of the logic associated with
the feature. I have confidence in my understanding of the rules for PICTURE
because I've written *three different* parsers for the PICTURE
character-string in my time, each time with careful study of the standard,
and each time painfully aware of the pitfalls therein.

Put a different way, I speak from authority on the subject of Unisys MCP
COBOL precisely because I am an architect for the products, and it's my job
to define as well as state what they do.

I speak from a position of authority on the subject of *standard* COBOL
based on two decades' experience and involvement in defending and/or
correcting the behavior of the Unisys MCP compilers relative to their
respective standards for over two decades, which means that I have
considerable experience finding my way around the documents.

I also speak from a position of authority as that I have been serving as the
Unisys representative on INCITS/J4, the committee that writes, modifies and
amends the COBOL standard for the last five years, and as part of those
duties, served as a part of the US delegation to ISO/IEC JTC1/SC22/WG4, the
international committee chartered with the overall direction and technical
content of the COBOL standard. I've also been appointed convener (chair)
of the latter committee for a three-year term, which gives my opinions
*some* credibility as to what conforms to the standard and what does not!

Despite all that, if you notice, my opinions usually begin with the likes of
"My reading of <relevant standard>, in particular <page-chapter-and-verse
citation>, leads me to believe ... that " and similar.

-Chuck Stevens


.

Relevant Pages

  • Re: Making money from Java
    ... >> time into studying an issue, they have a right to speak with confidence ... > I speak with confidence on issues with respect to the COBOL standard, ... > questions of what the standard states and what it does not. ... > I speak with authority on the Unisys MCP COBOL implementations because I'm ...
    (comp.lang.cobol)
  • Re: Cobol Copybook Parsing
    ... LINE SEQUENTIAL is a vendor extension, not standard COBOL. ... Not all implementations round up to the nearest byte, ...
    (comp.lang.cobol)
  • Re: Standard and COBOL file formats
    ... it merely describes a de facto standard that had ... LINE SEQUENTIAL is not defined by the COBOL ... >>streams and binary streams. ... >>different C implementations on a single platform may be ...
    (comp.lang.cobol)
  • Re: Requesting advice how to clean up C code for validating string represents integer
    ... Linkname: c standard - clc-wiki ... with a signed zero (including all IEC 60559 implementations) ... that follow the specification of annex G, the sign of zero ... between brake pedal and brake pads being through a complicated ...
    (comp.lang.c)
  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)