A very *PERSONAL* view of ISO 2002 COBOL for the IBM (mainframe) envi

[WMK]

I am updating a paper that I originally presented to SHARE (IBM user group) last
summer.

This paper presents my *personal* opinion and analysis of ISO 2002 COBOL
features and what will (might be) viewed as

"Good, Bad, and Ugly"

for those working with COBOL in an IBM mainframe (mostly z/OS) environment.

the latest (long) *DRAFT* of the document can be viewed in HTML format at:

http://home.comcast.net/~wmklein/SHARE/S8204.htm

I am definitely STILL working on adding additional items (the "New Ways of doing
Old tasks" section is still "blank" and I am about to start filling it in.

I would be more than happy to get suggestions (especially from those CURRENTLY
working with COBOL in a z/OS environment) on things to add, clarify, or
whatever. I would also be interested in those from other environments who might
have suggestions of "particular goodies" that they want (or have) from the '02
Standard.

You can post here - or email off-list with comments and/or suggestions.

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



Bill Klein

 

[razalas]

Bill,

very interesting document. Thanks for sharing with us.

perhaps I am misinformed. I am under the impression that the "free-form" format under the new standard is a configurable option, so that a shop would not necessarily be forced to migrate to the new format immediately.

Nonetheless I agree that there will be many places where migrating from fixed to free format source code will cause considerable trepidation due to the loss of data in columns 1-6 and 73-80.

Although personally from my own experience the loss of the info in cols 73-80 was not critical. It was typically "nice to have" but not absolutely necessary. Besides it seems like it would be fairly *easy* to convert such info to inline comments.

However, the data in cols 1-6 I am more concerned about. In my previous shop (MVS/zOS ISV), the line numbers in cols 1-6 were absolutely critical to maintenance of the programs since all changes were applied as *change* decks relying strictly on the sequence #'s in that area using a suite of homegrown source maintenance tools. And while I recognize that there are other options/tools available, changing an internal process so in-grained while be difficult, or painful at least.

Personally, I really like the new in-line comments. I think they are great. And at my current shop (Unix RM/Cobol), we use cols 1-6 for same sort of stuff that you often see in cols 73-80 elsewhere. But frankly, I won't lose any sleep over deleting this info.

The thing I am most looking forward to in the next version is the inclusion (I hope) of INTRINSIC and user-defined functions.

&quot;Code what you mean,
and mean what you code!
But by all means post your code!&quot;

Razalas

 

[Dimandja]

I have not read the entire document yet. But, having programmed for the Tandem NonStop machine for 25 years, I never had any problem with:

BAD: A-/B-margin removal: nobody ever used them. Our compiler had the ANSI directive which could enable these areas.

BAD: 250 character (not byte) lines: Our compiler allowed 255 characters per lines (editor limit). Never had any problem.

__________________________________________
Try forum1391 for lively discussions

 

[WMK]

The "bad" impression was for IBM mainframe shops. Don't ask me why, but they LIKE A-/B-margin restrictions. (The compiler can make some assumptions about missing periods with this - but it is more a "style" think than anything else.

A-/B-margin removal is true for FIXED form reference format (as well as free format).

...

Yes, it is ture that a "conforming" compiler must upport BOTH free and fixed format reference format - and that this is "selectable" at compile time. (You can even mix free form COPY members with fixed form main psource). The default is for FIXED format.

***

P.S. There may be some more updates to the document later this week - especially fixing some typos !!!

Bill Klein