How Do You Design a COBOL Compiler? 3

[Dimandja]

Hi K5tm,

This question is mostly addressed to you - how many COBOL compiler designers do we know on this forum? Many of us COBOL programmers have been curious as to how a COBOL compiler is designed.

For example, which documents do you consult for syntax and functionality?

Why do we have so many flavors of COBOL?

What languages are used in coding the compiler?

And, the question you may not like: why do COBOL compilers cost so much more than those other language compilers?

I am sure there are many more such questions out there.

Dimandja

 

[k5tm]

Dimandja,

I'll try to answer some, and take a pass on others.

Which documents do you consult for syntax and functionality?
The root document is the ANSI/ISO standard, along with published interpretations. In the past there was also the CODASYL Journal of Development, which was rich in anticipated extensions. The now-disused CCVS tests also provided some consistency in semantics.

In real terms, there have been a couple of "elephants" in the market that have dictated a set of extensions that have been required for compatibility in the marketplace. RM/COBOL's predecessor compilers were found in the nonDEC minicomputer market -- NCR, TI and others.

Why do we have so many flavors of COBOL?
Because different vendors are responding to different market segments, with different requirements. It has been only very recently (in COBOL years, that is) that there has been such an overwhelming swing to the desktop.

What languages are used in coding the compiler?
In our case it is a mixture of languages, one proprietary, that allow us to be highly portable across a broad range of platforms.

why do COBOL compilers cost so much more than those other language compilers?
As you might expect, I won't engage in speculation. All I can really say is that our customers expect us to be around a long time with a great deal of product reliability and stability, and we have evolved a business model that meets those expectations. I hope that you find this response, such as it is, satisfactory.


Tom Morrison

http://www.liant.com

 

[Dimandja]

You have answered all the questions, Tom.

One more: what do you think of the implementation of Object Orientation in COBOL? Is this in much demand out there? Is it worth (for us old COBOL programmers) the effort to learn these skills for COBOL?

Thanks.

Dimandja

 

[k5tm]

OneThree more: what do you think of the implementation of Object Orientation in COBOL?

My particular exposure to the market would lead me to believe that it was something designed by a committee for some purpose which I cannot detect...

Is this in much demand out there?
Not in the market that my company serves. Just about zero demand, actually.

Is it worth (for us old COBOL programmers) the effort to learn these skills for COBOL?
That totally depends upon the market segment you are in. If you work for one of our customers I think that you would be better served learning what they might care about -- legacy integration, XML, Web services, etc.

Tom Morrison

http://www.liant.com

 

[WMK]

May I add a couple of additional comments (even though I no longer work for a COBOL vendor).

1) One source of many "extensions" to ANSI/ISO COBOL language is/was the X/Open COBOL "CAE". This was the first "portable" definition of COBOL (originally targetted at Unix-type environments) to:

- include "National" (DBCS) language support
- file-sharing/record locking
- (character based) screen definitions
- line sequential file support
- Comp-5 ("true binary&quot data types
- several other features

Although many of these features were "taken from" existing implementations (such as RM), the X/Open specification gave a "portable" definition of them

***

As far as OO support goes, there has been a "reverse" chicken-and-the-egg situation. The Standards commitees were VERY SLOW in coming to a final definition and SOME vendors saw enough demand to implement early versions. Those versions were INCOMPATIBLE with each other and incompitle with the final ANSI/ISO definition. This has lead to using OTHER programming languages where a PORTABLE solution to OO was required.

Time will tell, but *IF* Microsoft's current .NET "common language run-time" actually does become a "de facto standard" for workstations, then OO support in COBOL will gain increasing importance for workstations (or at least those using either .NET or the ISO-accepted "CLR" environment). Fujitsu already has full .NET support (in one part of their product line). Micro Focus has .NET "co-existance" support now, and has announced its intention to provide a fully .NET enabled compiler. Only time will tell how important that will be.

For IBM, Java-interoperability seems to be its "push" for supporting OO COBOL. This has NOT really taken off in the IBM mainframe world, but SEEMS to be strategic for them.

Bill Klein

 

[Crox]

Hi,

About writing a compiler there is a book from Niklaus Wirth which is very nice to read.

It is a lot of work to make a compiler. True compiler builders make the compiler in the language they are writing. They start with some elementary statements, compile twice, expand it, compile twice, etc. etc. Incremental development.

Using structures: BNF is ok, JSP is also ok.

I wrote some interpreters in COBOL using JSP. I like the work. It takes some time but in fact if you create good structures it is not so difficult.

Some elementary things can be difficult for example in COBOL. If you combine the REPLACE statement and you use in a program also the COPY ... REPLACING and your copymember contains also a REPLACE statement, to make this preprocessor working allright at all times is complex.

Also if you have funny source in a copymember with continuations at every line which contains only one character of an identifier at every line and the identifier is replaced ..... It can be of any use to break through a source-check But a true compiler has not any problem with this funny source.

Regards,

Crox