COBOL "real estate" 2

[WMK]

I thought I would start a new thread - as a follow-up to some discussions in another thread (and some confusion in that thread).

The 2002 ISO Standard introduces "free form reference format". So let's talk about "fixed format reference format" first - which is the ONLY *standard* definitiion before 2002.

In that format there were 4 "things" of interest:

1) Columns 1 - 6
- up until the '85 Standard this was for sequence numbers and needed to be numeric (in ascending order). In the '85 Standard this was expanded to allow any alphanumeric character.

2) Column 7
- this was the "indicator" area and allowed
- space (doing nothing special)
- * (for a comment)
- D (for a debugging line)
- / (for a listing page break)
- - (for a continuation line)

3) Columns 8-11
- This was for the A-Area. In a STANDARD CONFORMING compiler certain "structures" must start in this column (e.g. paragraph names, 01 levels, etc) - while other items must NOT start in this area (e.g. procedure division statements, 02-49 levels, etc)

4) Column 12 - ANYWHERE THE IMPLEMENT SAID
NOTE WELL: the end of this area was NOT specified to be column 72 - and at least some compilers supported column 80 - and there was no restriciton on where it was.
- This is the B-AREA. The "position specifing the ending" was called the "R-Margin". Any "syntax" (unless required to be in the A-area) could be in this area.

NOTE WELL:
There was some confusion whether "conforming" implementations could or could not allow "comments" between the R-margin and the "end-of-line". IBM's mainframe compiler (for example) allowed "comments" in columns 73-80.

NOTE WELL 2:
For implementations with "line sequential" type source code, allowing the "end-of-line" indicator in the middle of alphanumeric literals was a "real problem". Most (all?) conforming compilers had SOME "option" to allow this, but it was rarely the default. The '85 (and earlier) Standards *assumed* a "record sequential" type source code - which caused some problems for non-COBOL oriented (source code) text editors.

***

Various "'85 Standard compilers" (and earlier) allowed:
- data in columns 1-7
- A-/B-area "confusion"

but this was always an EXTENSION and when "standard conformance flagging" was turned on, a message needed to be issued. There was NO consistancy in implementations with these extensions - especially when it came to comments and continuations.

***

In the 2002 Standard, the "free form reference format" introduces

A) the ability to have up to 255 CHARACTERS (not columns) per line.

B) New "indicators" and "directives" to handle what used to be dealt with in column 7, i.e.
>>PAGE
*> comment lines
>>D debugging lines
new types of literal continuations

NOTE WELL:
These new indicators/directives are ALSO allowed in fixed form reference format.

C) removal of all A-/B-area restrictions. (For implementations - such as IBM's mainframe compiler - that used to allow the period at the end of paragraphs to be optional, this will now need to be removed.)

D) A directive to "switch" between fixed and free form reference format in the middle of a source program.

Bill Klein

 

[Dimandja]

When I studied COBOL in school, this "real estate" affair is my worst most memorable experience with the language. If COBOL had been my first language at that time (already had IBM assembler under my belt), I would have dropped programming courses.

This is hands down the most annoying feature of COBOL.

I am glad my NonStop Server COBOL85, never offered ANSI as a default compiler setting. In fact in 24 years of using this compiler, I have yet to meet anyone who specified ANSI for their compilation.

Luckily, newer COBOL compilers do not even mention any "real estates" in their manuals.

Dimandja

 

[webrabbit]

I have a text editor that allows me to edit in 132-column display mode (it is PE3), and my compiler is Micro Focus. So I specify SOURCEFORMT"FREE" and use 132 columns. It is amazing how much difference this makes in the clarity of the program. I almost never have to split statements. I can indent four columns without getting too far to the right, which makes it much easier to see the logic structure. And screens and reports are solid, which makes them much easier to code and view.

Not all display adaptors support 132-column mode. My adaptor is a Voodoo 3D. It has 132x60, which is great. I limit all paragraphs to 60 lines, which means I can view the entire paragraph at once.

 

[tlogan]

So What? I don't get it. What's the big deal? Maybe I'm getting old, but I just don't get the problem here.

You learn the language the way it you need to learn it. When you're in an IBM shop, using IBM software, you learn to do it the IBM way. When you're in an HP shop using HP software you learn to do it the way HP does it.

At it's core COBOL is COBOL, the rest is just going along to get along. I've seen this not only from shop to shop, and department to department within a shop, but even from system to system within a department. Everyone has their own way of doing things. In order to be a susccessful programmer (in ANY language), you have to recognize how things are done, and do it that way. Otherwise (or ELSE in COBOL-ese) most of what you do is useless. COBOL systems tend to be the long-lived, mission critical systems and will be there long after you're gone. So write your code with that in mind. SOMEONE will have to come in in 5 or 10 years and cleanup after you. Which I guess is OK, since I've made a pretty good carreer out of it so far. (Remember that little guy at the end of the prarade in the 'Fractured Fairy Tales?' That's me. Please be kind.)

I've been monitoring a lot of the threads here, and it seems to me that a lot of the COBOL programming going on out there shouldn't be. Look at the thread about math using 18-digit numbers. Come on! That's not really what COBOL is designed for. Write a Fortran or SAS or even Asemebler exit if you need to. After support for Report Writer was dropped, I started seeing a LOT of Eastytreive.

I think the problem is in the College-level education system. Kids are comming out of college with that "throw away" the code in six or 8 or months or a year because a new standard J2EEE something-or-other just came out and we have to re-write everything. COBOL wasn't designed to be re-writen every year. By far, he worst problems I've encountered are the ones where someone tried to go in and "fix" a COBOL program and tried to get "cute."

So, the way I see it, unless you're writing a brand-spanking-new COBOL system from the ground up and have complete (like in you're the only one on the team) control over the entire project, I don't see how any of this really matters.

BTW - All that numbering in COL 1-7 goes back to the days of card decks and if you've ever dropped the deck of a 2 or 3K line program, you were REALLY glad they were numbered.

TLogan
The Man Without an Interesting Moniker

 

[WMK]

Much of what you state I understand - and some of it I even agree with <G>. However, your statement

I've been monitoring a lot of the threads here, and it seems to me that a lot of the COBOL programming going on out there shouldn't be. Look at the thread about math using 18-digit numbers. Come on! That's not really what COBOL is designed for. Write a Fortran or SAS or even Asemebler exit if you need to. After support for Report Writer was dropped, I started seeing a LOT of Eastytreive.

Shows:

A) you probably work in IBM mainframe shops (only) and haven't ever tried to port a SAS or Easytrieve application to HP, Tandem, etc. Historically, one of COBOL's main "selling points" was the portability of its code across operating systems and vendors.

B) that you aren't aware of many of the enhancements to COBOL that have made it "designed for" arithmetic applications.

This later includes (examples only)

- 1989 Intrinsic Functions such as
- Standard-Deviation
- Sin, COS, etc
- Mean, Midrange, etc

- 2002 Enhancements such as
- 31 digit numeric support
- "true" binary and floating-point (standard definitions)
- bit manipulation

COBOL is *not* your grand-father's "business-oriented" language any more (or at least it isn't LIMITED to that).

***

The point is why should a "programmer" be required to use (know) multiple programming languages if the same language can handle a VARIETY of types of applications - and do it well?

Bill Klein

 

[Dimandja]

BTW - All that numbering in COL 1-7 goes back to the days of card decks and if you've ever dropped the deck of a 2 or 3K line program, you were REALLY glad they were numbered.

I did learn to program using punched cards. I get your point about the advantages of numbering, because I did also drop my cards many times. However, COBOL was not the only language I learned while juggling decks of cards. My gripe has to do with the enforcement of a feature that has nothing to do with the language.

 

[k5tm]

I get your point about the advantages of numbering, because I did also drop my cards many times.

What? Where I 'grew up', using the card sorter was a very technical thing to do, requiring submission of your deck to the operators, thereby obtaining much ridicule. That's why it was so important to have a very nice diagonal stripe (perhaps even two, of differing colors) across the top of your deck.

Tom Morrison

http://www.liant.com

 

[Dimandja]

That's why it was so important to have a very nice diagonal stripe (perhaps even two, of differing colors) across the top of your deck.

Neat trick! I forgot about that one.

 

[webrabbit]

Strange. In the ten years of handling card decks (FORTRAN, COBOL, Assembler, and data) I never dropped a deck. And I am a kluz. But the cards got out of sequence from time to time anyway. One culprit was the IBM 2501 card reader. It had a ballistic stacker, and the cards would, very rarely, stack out of sequence.

 

[Crox]

There are other things you can do with the COBOL numbers when you use for example ISPF or SPF/SE or a look-alike.

Sometimes if you need a huge amount of grouped source-lines with much look-alike's, groups of moves from one row of variables to an other or other manipulations of a lot of look-alike source, I repeat the group of sample lines as many times as there are columns. I put the lines between labels, sort them on source, paste the variables directly on the lines which need them because now after sorting, they are near each other, sort again on the line-number and finish in a few seconds what can take hours.

There is a well known football-prof here in the Netherland - Johan Cruijff - who has his own proverb: "Ieder nadeel heeft zijn voordeel" which means "Every disadvantage has it's advantage". The sort trick used with the cobol line numbers is one of them.

Regards,

Crox

 

[webrabbit]

Yeah, I used to do tricks like that with ISPF. PC based text editors are in most cases better at doing such things, but I have never found another editor which dupicates ISPF's "overlay" line command, which overlays only into blank columns.

 

[tlogan]

WMK -

A) you probably work in IBM mainframe shops (only) and haven't ever tried to port a SAS or Easytrieve application to HP, Tandem, etc. Historically, one of COBOL's main "selling points" was the portability of its code across operating systems and vendors.

B) that you aren't aware of many of the enhancements to COBOL that have made it "designed for" arithmetic applications.

point A - is true enough. However, I'd be interested to hear from ANYONE who has been able to write code of any language and port it across systems like this without ANY changes WHATSOEVER. That's what "they" said about SQL, too. Except for the most basic of retrievals, I've yet to write some DB2 SQL and port it directly to ORACLE or SQL SERVER without some modifications. EVERY vendor has their own extensions making portability an issue.

point B, however, IS my point. I AM aware of these "enhancements" and that IS my point. If COBOL were DESGINED for this, they would have been there in the first place. Enhancements never seem to work as well as if they had been there all along.

The point is why should a "programmer" be required to use (know) multiple programming languages if the same language can handle a VARIETY of types of applications - and do it well?

When the only tool you have is a hammer, EVERYTHING looks like a nail. My point here is that you should always use the right tool for the job. My question is how well COBOL handles these enhancements. It may work, but there are better tools out there.


webrabbit -

Strange. In the ten years of handling card decks (FORTRAN, COBOL, Assembler, and data) I never dropped a deck. And I am a kluz. But the cards got out of sequence from time to time anyway. One culprit was the IBM 2501 card reader. It had a ballistic stacker, and the cards would, very rarely, stack out of sequence.

On the rare occaissions when I dropped a deck, it was usually while transferring from a reader or punch machine to a box, for transport. Those boxes were always a rare find and treated like gold. We also had a punch machine that would type different letters than it punched. It would type correctly but punch wrong. Maybe THAT wasn't fun!

TLogan
The Man Without an Interesting Moniker

 

[Crox]

Webrabbit, beside the mainframe SPF or PDF or ISPF, I am a SPF/SE and SPFPC user for many years now from Command Technology Corporation and those are great products. CTC combines both mainframe and windows possibilities so with several things, it is even (whas that possible) more powerful. In the windows version of SPF you have statements which makes it possible to cut, copy or paste complete columns on their place so you can paste an immense block of variables into a repeated line. Try the COLSPASTE statement in a free evaluation copy from

http://www.commandtechnology.com.

You will like it a lot. You can make your own macro's. It works fast. You have syntax-colorization for every language. Cobol looks very well. You know the HIGHLITE statement on the mainframe, do you?

You can change all sources in a directory or in a filelist that you can create by for example searching in several directories. So if you do it smart, you can do some typical conversion or maintenance work with this CHANGE statement technique and you will be faster than any offshore site.


The possibilities are great and I never have seen any editor with similar possibilities, never. I even challenge anybody to show some editing problem that can be done significant faster with their editor than with SPF.

What about these commands:

C P'.' ' ' ALL

Changing all non-ebcdid or non-ascii characters into space

C P'=' ' ' ALL 73 80

Changing all characters on columns 73 thru 80 into spaces

f 'WORK' 8;:.W;F 'PROC' 8;:.P

Creating a label .w on 'work' on column 8 and label .p on 'proc' on column 8

&C PIC ' PIC' ALL 15 45 .W .P <lots of enters until nothing is moving anymore>

Shifting 'PIC' to the right between labels .w and .p until they are on the same column.

x all;f 'PROBLEMVAR' all

Showing only the lines containing 'PROBLEMVAR'

etc. etc. etc. So many possibilities that I allways take my editor with me to any customers site.

Which editor can do something like that without programming macro's?

Regards,

Crox

 

[k5tm]

and you will be faster than any offshore site

No, Crox, please do not start that thread again!

Tom Morrison

http://www.liant.com

 

[Dimandja]

Which editor can do something like that without programming macro's?

And where is COBOL in this?

 

[Crox]

Dimandja,

The editor is an import tool to make and maintain COBOL.

Using a good editor and you organize for your project or your organization bite-sized chunks of COBOL which can easily be imported into your cobol-source, changed, modified, etc. etc. it is a very, very big difference.

It is possible for example to make your source with notepad. But if you do, you lose a lot of time compared to using an ISPF look-alike editor, for sure. It is comparing walking with using a F16 jet fighter.

 

[Crox]

No, Crox, please do not start that thread again!

I guess you don't depend on any job, do you? Perhaps you even outsource a lot yourself, Tom? I don't like it when a lot of people are loosing their job. Most of them are mainframe cobol programmers like many people here but you don't care, do you?

 

[k5tm]

Crox,

I forgot to add

(was supposed to be humorous...)

Tom Morrison

http://www.liant.com

 

[Crox]

I don't consider this funny at all. Anybody working with Indians, is closing the eyes for things like this:

http://news.nationalgeographic.com/news/2003/06/0602_030602_untouchables.html

so I know it is off topic - sorry - but we should not close our eyes for this horror.

 

[webrabbit]

I use PE3 to edit my COBOL source code (and .BAT files and control data, etc.). When I first started programming COBOL on pc's (1985), the only editor available was WordStar! After using that for about a year, IBM released Personal Editor. It was great, had macros and many features. By the time SPF/PC came out, I had gotten used to the instant response of PE. I used SPF/PC for a while, but liked PE better.

Then I bought BRIEF. It was great; had undo and macros plus lots of other goodies. Unfortunately, it would crash if you didn't save often enough. When it crashed and deleted the original file and the backup, I abondoned it.

I found a little shareware editor called SLED. It has lots of features, but no macros. It is also limited to 25x80, but it has a companion SLHED that runs in graphics mode on a Hercules compatable TTY card and gives you 35x90. (BTW, if anyone knows where the author is, I would like to reward him.)

While at a clients site, one of the supervisors was running an editor at 132x60. I asked him what it was. He said PE3 and showed me some of its features. It turned out to be a rewrite of IBM's Personal Editor, with many new features. So I bought a copy. I still use it. The only thing it does not have is regular characters, which BRIEF had. It has SPF look-alikes beat hands down. It is one of the few text editors that treats a text file as a sequence of records instead of a sequence of bytes (which is one of the strong points of SPF clones). It can do block overlays, column shifts, even column and line shifts within a block. Every key is programmable (on the fly even). When I was writing a whole bunch (hundreds) of e-mail addresses, I changed the "`" key to generate "@" so I wouldn't have to use the shift key so much.

There is a product called PE32 which works with Windows and is supposed to have all the features of PE3 plus more. I have a trial copy, but haven't had time to check it out thouroughly.