Re: Method to force keeping of source

Xref: kermit comp.lang.cobol:90690

See comments inserted below.

Warren

Chuck Stevens wrote:

> Warren Simmons wrote:
>
> 
>
>
> This refers to the idea of encoding the record description of a file withi
n
> 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 b
y
> the implementor, and the way fields of those various USAGEs are distribute
d
> 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 fil
e
> was written and machines directly compatible with it.  Any presumption tha
t
> the information so recorded would be useful outside that context would be
> erroneous and would almost certainly lead the user into a false complacency.[/colo
r]


>
> 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 previous
ly
> 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 n
ot
> 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 executi
on
> 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 featur
e
> 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
>
>

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:
> 
within 
expansion of 
up, 
> 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.
>
>
>
>
> 
by 
distributed 
recorded 
would 
file 
that 
be 
complacency.
>
> 
a 
to 
previously 
not 
in 
execution 
standardized. 
broadest 
the 
environment 
>
> 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
> 
are 
feature 
today. 
suggest a 

In article <cbuu10$31e7$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:

[snip]

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

It was found, I believe on a baked-clay, cuneiform-engraved tablet from
the Eresh library in Sumer - or some equally ancient source - something
along the lines of:

A jackel-headed woman with her eyes akimbo
And a king sitting sideways on his throne,
Adrip with gold,chipped nose uplifted - *thusly* -
All engraved upon a pyramid of massive size
With the body of a lion, paws that refreshes,
A tale told by an idiot and the head of a fox!

... no, wait, that was a stream of ancient Egyptian holograms...
diaphragms... hieroglyphs... all right, enough of this particular set of
obscure references... something along the lines of:

The question is not 'What will you do if the disk goes down?' but 'What
will you do *when* the disk goes down?'

DD

<docdwarf@panix.com> wrote in message news:cbuvch$6td$1@panix5.panix.com...
> In article <cbuu10$31e7$1@si05.rsvl.unisys.com>,
> Chuck Stevens <charles.stevens@unisys.com> wrote:

> The question is not 'What will you do if the disk goes down?' but 'What
> will you do *when* the disk goes down?'

" 'The question is,' said Humpty Dumpty, 'which is to be master -- that's
all.' "   ;-)

The COBOL standard doesn't refer to "disk", it refers to "mass storage
device", which for  all COBOL cares could be a robot making wedge-shaped
impressions in clay tablets, so long as there's a robot in the operating
environment with a stylus that can read the wedge-shaped impressions in the
clay tablets and report the information back through the operating
environment to the program.

What the mass storage device looks like, how it records and retrieves the
information, and where it puts it, are none of COBOL's business.  I've seen
several systems based on magnetic tape that could easily serve as "mass
storage devices".  A ROM burner is a mass storage device, so is a CD burner,
so are the ubiquitous chip-based USB-interface disk lookalikes like the one
I have on my keychain.  Why is it *COBOL's* job to care whether, why, how,
and what happens if, a disk goes down?

Around thirty years ago there was a w-long "introduction to computers"
class given to the managers of companies that were in the final stages of
ordering systems from the vendor that put on the class.  At the very end of
the class, the participants were given a final opportunity to ask for
clarification on any issues.  One CEO raised his hand and asked "Is COBOL
faster than disk?"

The COBOL standards committee places a high priority on making COBOL
available on, and applicable in, as many *diverse* operating environments as
possible.  "Operating environment" includes the machine-instruction
architecture that underlies the generated object code, the portions of the
operating system software that directly support execution,
non-language-specific utility software, and any COBOL-specific software that
might be required either at execution time or otherwise.   The standard
deliberately allows the implementor as much flexibility in the specification
of the "operating environment" as possible.

There have indeed been cases -- for example, the '74 standard's MEMORY SIZE
in SPECIAL-NAMES as well as  LABEL RECORDS and VALUE OF in File
Descriptions -- in which the meaning of the clause is specific to the
operating environment and cannot effectively be standardized.  They were
marked as obsolete in the '85 standard for that very reason, and are no
longer present in the 2002 standard (though implementations may retain them
as implementor-defined extensions so long as they are identified as such by
the compiler and in the documentation).

-Chuck Stevens

On 30-Jun-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> One CEO raised his hand and asked "Is COBOL
> faster than disk?"

So what do I need to do to be as smart as a CEO?

What Chuck mentions below is actually something that we talked about when
developing the 2002 Standard.  The question had to do with "locks" and "wait
"
times.  I may or may not have been the person who said it, but someone on th
e
committee mentioned that once could (theoretically) create a Standard confor
ming
compiler that used a "monk with a stylus" to write records out.  In a more
realistic vein, there are SIGNIFICANT differences in I/O times depending upo
n
operating system, type of file, etc.  Therefore "sync" read/writes in 1000th
s of
a second on one O/S might be totally unrealistic in another.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cbv327$3a0$1@si05.rsvl.unisys.com...
>
> <docdwarf@panix.com> wrote in message news:cbuvch$6td$1@panix5.panix.com..
. 
> 
>
> " 'The question is,' said Humpty Dumpty, 'which is to be master -- that's
> all.' "   ;-)
>
> The COBOL standard doesn't refer to "disk", it refers to "mass storage
> device", which for  all COBOL cares could be a robot making wedge-shaped
> impressions in clay tablets, so long as there's a robot in the operating
> environment with a stylus that can read the wedge-shaped impressions in th
e
> clay tablets and report the information back through the operating
> environment to the program.
>
> What the mass storage device looks like, how it records and retrieves the
> information, and where it puts it, are none of COBOL's business.  I've see
n
> several systems based on magnetic tape that could easily serve as "mass
> storage devices".  A ROM burner is a mass storage device, so is a CD burne
r,
> so are the ubiquitous chip-based USB-interface disk lookalikes like the on
e
> I have on my keychain.  Why is it *COBOL's* job to care whether, why, how,
> and what happens if, a disk goes down?
>
> Around thirty years ago there was a w-long "introduction to computers"
> class given to the managers of companies that were in the final stages of
> ordering systems from the vendor that put on the class.  At the very end o
f
> the class, the participants were given a final opportunity to ask for
> clarification on any issues.  One CEO raised his hand and asked "Is COBOL
> faster than disk?"
>
> The COBOL standards committee places a high priority on making COBOL
> available on, and applicable in, as many *diverse* operating environments 
as
> possible.  "Operating environment" includes the machine-instruction
> architecture that underlies the generated object code, the portions of the
> operating system software that directly support execution,
> non-language-specific utility software, and any COBOL-specific software th
at
> might be required either at execution time or otherwise.   The standard
> deliberately allows the implementor as much flexibility in the specificati
on
> of the "operating environment" as possible.
>
> There have indeed been cases -- for example, the '74 standard's MEMORY SIZ
E
> in SPECIAL-NAMES as well as  LABEL RECORDS and VALUE OF in File
> Descriptions -- in which the meaning of the clause is specific to the
> operating environment and cannot effectively be standardized.  They were
> marked as obsolete in the '85 standard for that very reason, and are no
> longer present in the 2002 standard (though implementations may retain the
m
> as implementor-defined extensions so long as they are identified as such b
y
> the compiler and in the documentation).
>
>     -Chuck Stevens
>
>

Also top posting
by Warren

Again, Chuck,,,, I believe I understand your position and perhaps my
points are not clear enough to obtain interest. My view has been outside
of compiler production and maintenance.

It is probably clear that I believe that the development of COBOL has
been cut short compared to the development of the offerings of vendors.
My suggestion that the record description be part of the file is based
upon years of reading C.L.C. and personal experience with how shops are
run, not how they should be.  I believe COBOL is a good thing and
deserves to grow beyond the limits of a vendor biased group. O.K. you
all don't feel like you are biased. Do you feel like you have kept
pace with the needs of a common business programming language? My point
is that the effort is only current with the hardware and software
vendors that support them. All kinds of new things happen that these
vendors will never think to do something about unless a new idea
or two comes along.

I don't think for a moment that vendors would like to provide equal
data representation. There is to much money to be make by not overcoming
the differences. This is a large step away from the current status.

Yet, the tower of babbling goes on with more new tools to do the
same thing. I know something about the development of the Burroughs
lines and well as the Univac and the IBM lines. Outstanding work has
been done by each, and I've seen the systems they have developed uses in
mixed
situations. When they come together along with the other high end
systems, it's likely to satisfy a DOD or other agency requirement.
I do not see that going on with the organization driving COBOL
development because I believe there are functions in a general sense
that should be associated with COBOL AND MADE STANDARD.

As I've said, these are my opinions. I guess I side with those who feel
there is too much delay in flushing out the capabilities normally
expected with a compiler these days. That feeling drives me to wonder
why, and my only conclusion is the objective is to revert to status quo.
The concept and success of COBOL will fad like other tools. I guess we
just need to have something going on for the colleges to teach that has
a better ring to it. We need IT departments who make the same mistakes
all over again in support of something new. Label me disappointed. Given
the magic wand, there would be changes. As we used to complain, the only
thing wrong with *what ever* is that " they won't let me*us run it."

You should see this new gadget I just got for my computer. Holds the
equivalent of 88 floppy disks, and looks like a pack of gum.

Warren Simmons

Chuck Stevens wrote:
> 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, f
or
> 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 fix
ed
> 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 operati
ng
> 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 dat
a
> 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 problem
s
> that neither the standards committee nor the designer of a COBOL compiler
> for a particular implementation should be expected to solve, or required t
o
> solve.
>
>
Subsequent original material clipped in the interest of space, and time.

I don't know that this has anything to do with this subject, but
here is an actual case....

Corporate has multiple sites with IT services. For this story
you only need to know that one was running a corporate wage payroll
on an IBM 7010.

To plan for backup, and load sharing, a decision was made to
recompile the programs on the IBM 7xxx at the to be backup
location.

Since the IBM 7xxx had a bundle of registers, and other features,
the compiler supplied by IBM took advantage of the hardware features.
I'm half way sure that LE must have come form several situations like
this as, what happened next was:

Effort to install the backup site, and off load some from the fist site,
was delayed by many months.

Cause= the compilers were built by different teams, and to the hardware.

When this COBOL CODASYL person was asked to explain to the VP
responsible for all IT installations what was wrong with COBOL, as
a good soldier, he said it's not our fault, it's IBM's.
To which he responded somewhat: You better care if IBM is
at fault, your pension fund had a lot of their stock.

All of a sudden, the reason for leasing the incompatible
other computer became clear, and it is possible there
was egg on a lot of faces.

Think about the PC and how it has changed the market.

Warren

Howard Brazee wrote:

> On 30-Jun-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> 
>
>
> So what do I need to do to be as smart as a CEO?

Warren,
In all my years of working at IBM mainframe sites, for software vendors, and
with SHARE/GUIDE - I heard of one (exactly ONE) person/site that actually us
ed
the (required by FIPS) "flagging" mechanism to find out which extensions the
y
were using in their source code.

That is one MORE site than I ever heard of using the Micro Focus or Fujitsu
facility for doing "extension flagging".  Given that sites don't (apparently
)
care about writing "portable" source code - or that they don't think that th
e
ANSI/ISO/FIPS language definitions are the "real-world" standard language,  
I
question how much benefit there would ever be in "improving" the standardiza
tion
of the language.  The lack of using this flagging pre-dates the '85 Standard
,
much less the (still not fully implemented) 2002 Standard.

FYI,
It is also interesting how many of the current COBOL compiler vendors aren't
even "on" the committee(s) any more, e.g. AcuCorp, Liant, LegacyJ, HP
(representing Dec, Tandem, and the original HP). CA,  "OpenCOBOL", etc).  Wh
en
considered with the fact that of the three vendors currently on J4 (IBM, Mic
ro
Focus, Unisys) only Micro Focus has publicly committed to EVER producing a 2
002
conforming compiler - and I am not certain that they still state this.

Maybe I am agreeing with you (I am not positive exactly what you are
"advocating") - but the Standardization process simply doesn't seem "relevan
t"
anymore  - or at least not very.

NOTE:
The "death" of FIPS/NIST certification and US government "requirements" for
conforming compilers seems highly relevant to this - and this PRE-dated the
"delays" in the delivery of the 2002 Standard.

--
Bill Klein
wmklein <at> ix.netcom.com
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:40E3815F.5070303@optonline.net...
> I don't know that this has anything to do with this subject, but
> here is an actual case....
>
> Corporate has multiple sites with IT services. For this story
> you only need to know that one was running a corporate wage payroll
> on an IBM 7010.
>
> To plan for backup, and load sharing, a decision was made to
> recompile the programs on the IBM 7xxx at the to be backup
> location.
>
> Since the IBM 7xxx had a bundle of registers, and other features,
> the compiler supplied by IBM took advantage of the hardware features.
> I'm half way sure that LE must have come form several situations like
> this as, what happened next was:
>
> Effort to install the backup site, and off load some from the fist site,
> was delayed by many months.
>
> Cause= the compilers were built by different teams, and to the hardware.
>
> When this COBOL CODASYL person was asked to explain to the VP
> responsible for all IT installations what was wrong with COBOL, as
> a good soldier, he said it's not our fault, it's IBM's.
> To which he responded somewhat: You better care if IBM is
> at fault, your pension fund had a lot of their stock.
>
> All of a sudden, the reason for leasing the incompatible
> other computer became clear, and it is possible there
> was egg on a lot of faces.
>
> Think about the PC and how it has changed the market.
>
> Warren
>
> Howard Brazee wrote:
> 

On Thu, 01 Jul 2004 03:35:11 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:


HP is indeed still represented on the standards committee, unless you
know something my management hasn't told me.

As far as enabling standards diagnostics, I doubt that many users turn
them on on their regular builds.  I suspect they make one compilation
before beginning a porting project to a new platform.

Jeff Lanam     HP NonStop COBOL Project  INCITS/J4
NonStop Enterprise Division
Hewlett-Packard