Whether you’ve been programming since the summer of ’69 or just started last year, you’ve probably heard of COBOL. As one of the most reliable programming languages, COBOL is at the heart of the world’s business applications. Which is why it is no surprise that 75% of the world’s business data, and 90% of financial transactions, are processed in COBOL.
COBOL is a language that has repeatedly proven its reliability, ease-of-use and value. This explains how it continues to stand the test of time with around 5 billion new lines of COBOL code added to live systems every year. Programmers around the world continue to gain experience with the language while building and growing their business. Globally, there are nearly 2 million developers working with around 200 billion lines of COBOL code in live operation! To help COBOL evolve and meet the future needs of business, Micro Focus Visual COBOL delivers the next generation of COBOL tools for the 21st century. With Visual COBOL, users are able to develop and modernize mission-critical applications using platforms that best fit particular business needs – ensuring that their organization remains on a path of growth and innovation.
There is a wealth of multi-faceted stories and personal experiences that accompany the COBOL language and its developer. We captured just a few of them at our Developer Conference back in April. Watch passionate programmers reflect on their experiences with COBOL in the video below.
What’s your fondest COBOL memory? Let us know by commenting here or tweet at us @MicroFocus using #COBOLrocks.
4 Comments
Really came to love COBOL after introduction of “SET ADDRESS OF TO ” and VALUE X'”. Coming from an Assembler background, these two simple changes opened up a world of possibilities for COBOL.
This is bittersweet instead of “fondest”. Back in 1970 I worked for a DEC
PDP-10 based timesharing company that got a project from the Office of Naval
Research to study the relative merits of batch vs. interactive COBOL
debugging. We didn’t have an interactive COBOL compiler, so we scrounged
around and found one out of Australia. The problem was that it was Level 1
COBOL, whereas we needed Level 2 for the project. So it got dumped in my lap
and I was told to bring it up to Level 2 ASAP. This included, for instance,
accommodating more than 1 array dimension!
I slaved away, working long hours, and just as I was getting the compiler to
approach Level 2 (including its run-time library), DEC came out with an
all-singing, all-dancing, 8-pass COBOL compiler. My efforts all went into the
bin. 🙁
The “fondest” part, though, was that ONR’s liaison officer to us for the
project was none other than (then) Commander Grace Hopper! I met with her
several times, and she gave one of her famous “nanoseconds”.
(A side note — here it is 42 years later, and I recently saw a LinkedIn
discussion about the merits of using DISPLAY statements for debugging…)
Fast forward to 1992; I enjoyed adding COBOL to our computer language expert
system’s repertoire of languages.
It is very great that you have triggered my memory of using display statements for debugging MF Cobol programs on Unix OS, to find where the control was going. I have removed all display statements once I finished debugging the program. It so happened that I missed removing one display statement before live run. During live run the display statement helped me to identify a massive data error.
My fondest memory – was to design and lead the development (I also coded too) the porting of an entire batch system to run on two DELL machines.
We had a daytime system that processed incoming files for the nightly batch run, and then the nightly batch run.
Not one line of code was changed in any of the 100+ COBOL programs, and the 200+ COPYBOOKS.
In this project, I turned the mainframe in to a large data server, and the only thing that ran on the mainframe was a new program (written in COBOL, Dialog Manager and REXX) that scheduled the downloading of new files that the clients still sent to the mainframe.
I had some great programmers helping me out with all the conversions (for example, JCL was converted to a SEQ dataset, and we ran 8 jobstreams that ran the datasets that held the converted JCL to run all the recompiled programs.