Inside COBOL #41
by
Shawn Gordon
President
The Kompany
Ah the COBOL world suddenly is heating up dramatically. Seems that when our forefathers designed those big mainframe systems back in the 60’s no one figured they would still be around 30 or 40 years later. Not many languages have flourished from this time, but COBOL is the by far the biggest and most entrenched. We’ve talked before about the sheer amount of COBOL code out there, and while new development has probably dropped to about 50% of all new development, COBOL is probably 80% of legacy systems.
So why do we care? Well there’s gold in them thar COBOL skills. Companies and schools don’t teach or train in COBOL anymore it seems. It’s an old, un-sexy language, and everyone has moved on to fascinating new technology. Trouble is that the year 2000 is just around the corner, and someone has to modify those billions of lines of code out there. Currently COBOL coders can get $45 – $65 per hour depending on the region, and the closer we get to 2k d-day, the higher those rates will go. Some estimates I am seeing are for over $150 per hour. That’s almost enough to get me to take on the tedious challenge of fixing date code.
This also brings up an interesting point. Those of you who spend time working on these projects, are also going to be very familiar with the systems after the year 2k problem goes away. This means you will be well positioned to continue on at a company as they decide to develop new systems and convert the old ones. I also think that after everyone spends so much money getting year 2,000 ready, they are not going to be very inclined to throw it away on a new system anytime soon. This means that COBOL will continue to proliferate for another decade at least.
During this time, the COBOL compilier companies will finally have an opportunity to catch up with the rest of the universe and offer exciting environments like Java, Visual Basic, and Delphi, for COBOL. COBOL could easily turn into a Java replacement on the web, with it’s easier learning curve, and huge installed base of programmers. This is the time to really push and take over, but I fear that the big 3 COBOL companies will continue to sit and look and say “gosh, we should do something to be a part of this”.
I think one of the real tragedies is that the COBOL 97 standard probably won’t be done till the year 2000. This is kind of ridiculous since I originally heard it was going to be COBOL 93. There are going to be great things in the 97 standard that could help the year 2k crunch, but it will be much to late to be of any help to anyone.
As long as we are on the topic, I thought I would run some internet COBOL sources by you to stay on top of things;
Organizations
COBOL Foundation www.cobol.org
National Association of programmers www.naponnet.org
Newsletters and Publications
The COBOL report www.cobol.org/tcr1.htm
The IBM COBOL newsletter www.software.ibm.com/ad/cobol.cobnews.htm
Micro Focus COBOL Developer’s Journal www.cobb.com/mfc/freevu2h.htm
Articles and White Papers
Bibliography of articles on COBOL www.software.ibm.com/ad/cobol/cobbib.htm
Micro Focus White Papers www.mfltd.co.uk/cgi-bin/WhitePapers
Review of the great COBOL debate www.cobol.org/welcom2.htm
Resources
COBOL programming & information www.missouri.edu/~c592073/cobol/
Technical information center lsc.liant.com/rm/techinfo/tips/
COBOL information center www.daimi.aau.dk/~mayer/cobol/html
The Flexus COBOL information page www.flexus.com/index.html
COBOL Standardization Status www.microfocus.com/Standards/
IBM COBOL Family Resource Catalog www.software.hosting.ibm.com/ad/cobol/igyrcmst.htm
COBOL FAQ www.lib.ox.ac.uk/internet/news/faq/archive/cobol-faq.html
Newsgroups
comp.lang.cobol
alt.cobol
And of course the compiler companies
Acucobol www.acucobol.com
MicroFocus www.microfocus.com
RM Cobol www.liant.com
Fujitsu well I don’t know their site, try www.fujitsu.com
And to keep from only being a soap box issue, I will leave you with one lovely little tidbit I just picked up recently. I am sure you are all familiar with the SELECT..ASSIGN clause in COBOL where you can assign a program variable name to a real file. If the file doesn’t exist, it will be built as a temp file with the record size specified in your FD clause. However, it will only be built with 1023 records by default. Much to my suprise, I have spent all these years calling the COMMAND intrinsic to set a file equation to get a larger file limit, or to build the file before hand. Turns out that in the ASSIGN portion, you can specify the number of records as well, so
SELECT TEMPFILE ASSIGN TO “MYFILE,,,50000”
will build MYFILE as a temporary file with 50,000 records. It’s funny how it’s that little stuff that you learn once, and never look at again, that can provide some of the handiest little tricks. The only problem with this is that MYFILE will still be a temp file. I don’t know any way to make it perm unless you set a file equation, or build it first. However this is great for generating temp scratch files.
So until next month, tally ho.