COBOL Standards 
Author Message
 COBOL Standards

As this is a major topic I have started a new thread.

In response to the topic "I need a decent COBOL compiler" Bill Klein
wrote :-

Quote:
> As the major proponent of "killing off" (or more accurately radically
> modifying) the draft's "processor dependent" definition, I certainly
> agree with your concern.  Unfortunately, J4 (and WG4) just are NOT
> hearing from many "users" who are concerned about this.
> It seems to me (always has - probably always will) that COBOL's  
> biggest "selling point" was/is its portability.  The current draft
> doesn't destroy this - but it does "wound" it quite a bit.
>I should (just so you understand why I SOMETIMES disagree with what I >am saying here), say that I think that the next Standard *must* >interact as well as possible with C, C++, and all those operating >system APIs that have become so popular.  To do this, I think that >COBOL *must* add some non-portable stuff - just to interact  
>successfully with other languages and functions that aren't portable.

Bill,

I've just recently got more 'web-involved' and started looking at
comp.lang.cobol. I'm delighted you mentioned Standards "You don't hear
from us - the developers". From a cursory search I did some months ago I
saw a "Standards" site which said contact your representative - who do I
contact here in Canada, Nanook of the North !

COBOL evolved initially because IBM, Unisys et al were trying to sell
the Pentagon on their specific machine "architectures" with their own
machine code and assemblers. Somebody had the guts to say "Enough
already!" - we'll formalize COBOL - let your machine interpret.

As an end-user pointed out to me, "COBOL is free". He was referring to
the standard intro you see in books "COBOL is an industry language and
is not the property etc.....". It's the toolkits we pay for.

As you know the COBOL OO Standards have already 'tipped their hat' to
the work done on Smalltalk, and in terms of COBOL standards, I believe
the following are relevant quotes :-

"He,  (Peter Deutsch - one of the many SmallTalk designers), strongly
opposed  integration with native user interface toolkits on the grounds
that it would untowardly increase the maintenance burden from the
platform fan out (that is, the need for different implementations for
different operating system/user interface combinations). He advocated
emulating the platform in Smalltalk using a framework approach, and then
later endorsed using a framework whose concrete subclasses would link to
the platform's toolkit. Allowing programs to invoke platform toolkit
capabilities directly, he correctly predicted, would result in
destruction of real portability. (Adele Goldberg - OO Languages 1998).".

"The tools industry is abuzz with the virtues of Java, but most of the
features present in Java have been part of Smalltalk for more than 25
years. .......... Because the tools manufacturers make money only on the
sale of development tools, training and upgrades, the stagnation of the
C++ market to date has launched the Java market into the forefront....."
(Victoria & Jonathan Pletzke - OO Languages 1998) - So much for the hype
about Java !

Within so-called Standard COBOL we have variations from compiler to
compiler. To insist that the standard should be "concrete" would inhibit
new ideas - but it would help considerably if there was an agreed
standard on representation of data in standard cobol files, obviating
the necessity of toolkit converters when moving data from MicroFocus to
Fujitsu or from Ryan-McFarland to Micro Focus etc.

Perhaps my biggest concern with the "Standards" is that although the
committees will come up with recommendations, will Base and GUI classes
for Object Orientation differ dramatically from one compiler to the
next ? I rather suspect that they will. If I create a collection or
dictionary in Fujitsu or Liant(RM) will it need a rewrite for
Merant(MicroFocus) NetExpress ?

Such an eventuality would mean that each compiler would contain compiler
specific toolkits for OO classes - and the word COBOL starts to become
meaningless.

In the same context that a standard was laid down for the original COBOL
68, have the current Standards Committees considered the possibility of
a COBOL-specific virtual machine with the flexibility to recognize
different operating systems. (Here I'm thinking on the "openness" of
Linux and the ability of any computer geek to write new code). Open
toolkits - not a very attractive idea to compiler developers !

Jimmy, Calgary AB



Thu, 29 Nov 2001 03:00:00 GMT  
 COBOL Standards
For anyone outside the US, if you are interested in contacting your national
body, a web page that you can start at is the WG4 (COBOL working group for
COBOL) - which is at:

 http://anubis.dkuug.dk/jtc1/sc22/wg4/

(check out the links to "your" and  "national body")

The person who has in the past represented Canada at WG4 doesn't have an
email address listed.  However, on the J4 mailing list, he is listed as:

   Ian Mooney (F) (D)
  Computer Horizons Canada Corp.
  66 Scarsdale Rd
  Toronto, M3B 2R7
  Canada
  Tel:  (416) 391-3600  ext 6010
  Fax:  (416) 385-7144

I do NOT know if he is still involved with Canada's representation in COBOL
Standards development, but it would be my guess that he could set you on the
correct path.

--
Bill Klein
    wmklein <at> ix dot netcom dot com


  <much snippage>

Quote:

> Bill,

> I've just recently got more 'web-involved' and started looking at
> comp.lang.cobol. I'm delighted you mentioned Standards "You don't hear
> from us - the developers". From a cursory search I did some months ago I
> saw a "Standards" site which said contact your representative - who do I
> contact here in Canada, Nanook of the North !

  <more snippage>

> Jimmy, Calgary AB



Thu, 29 Nov 2001 03:00:00 GMT  
 COBOL Standards
Great thinking, James..... it would seem that the need to have processor
dependent language material in the standard
could be replaced by the need to interface the standard instead.  Not only
that, but the effort might be more in the spirit of the COBOL objectives.
As far as the impact on compiler writers is concerned, that is the name of
the game. Provide the tool as needed or find another market.

Warren Simmons



Quote:
> As this is a major topic I have started a new thread.

> In response to the topic "I need a decent COBOL compiler" Bill Klein
> wrote :-

> > As the major proponent of "killing off" (or more accurately radically
> > modifying) the draft's "processor dependent" definition, I certainly
> > agree with your concern.  Unfortunately, J4 (and WG4) just are NOT
> > hearing from many "users" who are concerned about this.
> > It seems to me (always has - probably always will) that COBOL's
> > biggest "selling point" was/is its portability.  The current draft
> > doesn't destroy this - but it does "wound" it quite a bit.

> >I should (just so you understand why I SOMETIMES disagree with what I >am

saying here), say that I think that the next Standard *must* >interact as
well as possible with C, C++, and all those operating >system APIs that have
become so popular.  To do this, I think that >COBOL *must* add some
non-portable stuff - just to interact
Quote:
> >successfully with other languages and functions that aren't portable.

> Bill,

> I've just recently got more 'web-involved' and started looking at
> comp.lang.cobol. I'm delighted you mentioned Standards "You don't hear
> from us - the developers". From a cursory search I did some months ago I
> saw a "Standards" site which said contact your representative - who do I
> contact here in Canada, Nanook of the North !

> COBOL evolved initially because IBM, Unisys et al were trying to sell
> the Pentagon on their specific machine "architectures" with their own
> machine code and assemblers. Somebody had the guts to say "Enough
> already!" - we'll formalize COBOL - let your machine interpret.

> As an end-user pointed out to me, "COBOL is free". He was referring to
> the standard intro you see in books "COBOL is an industry language and
> is not the property etc.....". It's the toolkits we pay for.

> As you know the COBOL OO Standards have already 'tipped their hat' to
> the work done on Smalltalk, and in terms of COBOL standards, I believe
> the following are relevant quotes :-

> "He,  (Peter Deutsch - one of the many SmallTalk designers), strongly
> opposed  integration with native user interface toolkits on the grounds
> that it would untowardly increase the maintenance burden from the
> platform fan out (that is, the need for different implementations for
> different operating system/user interface combinations). He advocated
> emulating the platform in Smalltalk using a framework approach, and then
> later endorsed using a framework whose concrete subclasses would link to
> the platform's toolkit. Allowing programs to invoke platform toolkit
> capabilities directly, he correctly predicted, would result in
> destruction of real portability. (Adele Goldberg - OO Languages 1998).".

> "The tools industry is abuzz with the virtues of Java, but most of the
> features present in Java have been part of Smalltalk for more than 25
> years. .......... Because the tools manufacturers make money only on the
> sale of development tools, training and upgrades, the stagnation of the
> C++ market to date has launched the Java market into the forefront....."
> (Victoria & Jonathan Pletzke - OO Languages 1998) - So much for the hype
> about Java !

> Within so-called Standard COBOL we have variations from compiler to
> compiler. To insist that the standard should be "concrete" would inhibit
> new ideas - but it would help considerably if there was an agreed
> standard on representation of data in standard cobol files, obviating
> the necessity of toolkit converters when moving data from MicroFocus to
> Fujitsu or from Ryan-McFarland to Micro Focus etc.

> Perhaps my biggest concern with the "Standards" is that although the
> committees will come up with recommendations, will Base and GUI classes
> for Object Orientation differ dramatically from one compiler to the
> next ? I rather suspect that they will. If I create a collection or
> dictionary in Fujitsu or Liant(RM) will it need a rewrite for
> Merant(MicroFocus) NetExpress ?

> Such an eventuality would mean that each compiler would contain compiler
> specific toolkits for OO classes - and the word COBOL starts to become
> meaningless.

> In the same context that a standard was laid down for the original COBOL
> 68, have the current Standards Committees considered the possibility of
> a COBOL-specific virtual machine with the flexibility to recognize
> different operating systems. (Here I'm thinking on the "openness" of
> Linux and the ability of any computer geek to write new code). Open
> toolkits - not a very attractive idea to compiler developers !

> Jimmy, Calgary AB



Thu, 29 Nov 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. What's new *and* interesting for IBM mainframe COBOL programmers - in the next COBOL Standard

2. Next (post 2002) ISO COBOL Standard

3. Enhancements for future COBOL Standard

4. XML proposal initial input for future COBOL Standard

5. Reporting defects in the ANSI/ISO COBOL Standards

6. COBOL Standards "process"

7. ISO COBOL Standard - It's FINAL

8. Final comment on draft (probably soon to be official) COBOL Standard

9. LINE SEQUENTIAL files and the COBOL standard

10. Next COBOL Standard

11. COBOL Standards

12. *** "Duplication and distribution of current and future COBOL Standards in Jeopary

 

 
Powered by phpBB® Forum Software