Author Archives: Doug

When I read blogs and articles discussing COBOL and then scroll through the negative comments underneath, my first thought is to write a post to continue to defend COBOL and disprove all of the negativity.   But that is not where I ended up today.

I am at point in my career where I hope to be able to bring programming value for another 10 – 15 years.  I have learned in recent years to develop applications in Visual Basic, .NET, C# as well as continued development and maintenance of COBOL applications.   It was 34 years ago that I was taught the COBOL programming language but my appreciation of what COBOL could offer in an organization did not happen immediately in my first job after college.

My first job after college took me through computer operations where I was a night computer operator on a Digital VAX mainframe for over a year.   It was in this position that I began to see the huge benefits of COBOL in a BATCH processing environment.   The speed of COBOL handling thousands and thousands of transactions and the detailed reports being produced was amazing to me!  I was then mentored by one of the COBOL programmers for about 4 months in COBOL programming techniques and was given some smaller projects that I could work on while doing my nightly operations.  I was able to get up to speed very quickly and began to maintain and develop some COBOL programs.

So, with that being said, I can truly understand why someone that has never seen or worked with COBOL may not appreciate the history and current day value that COBOL can and does bring to the table.

As you see from my history, it took me awhile to really gain that knowledge and appreciation of COBOL even though I had already spent a huge chunk of time at the University, in the computer room, learning and writing COBOL.

So why continue the arguments?  I’ve arrived at a place where I feel that there’s no need to.   Detlef a.k.a “The COBOL Kid” and I are going to go into some deep discussions over the next weeks to explore and hopefully shed some light and understanding on the need for COBOL in 2015.

Recently, I found this comment in the string following a blog post discussing IRS budget cuts and COBOL.

http://money.cnn.com/2015/02/03/pf/taxes/irs-budget-cuts/

Good one!

I recently was asked by a college student if I could teach him COBOL. It wasn’t that he wanted to be a true professional COBOL’er but it was the fact that he read these Blogs and magazine articles at a deeper level (without formulating an immediate opinion) and realized that there is going to be a need for COBOL programmers in the near future and maybe he could step into the picture somewhat with some basic training.  He understood the language and opinion that the experienced programmers were sharing.   And this brought me full circle.  It may not be as much about raising the dead (although this fits perfectly with COBOLZombies), but maybe we are being directed towards a need to begin sooner than later the necessary training and mentoring today’s and tomorrow’s pool of programmers.

Let’s get the conversation going.

No need to go into the statistics.   I am sure everybody is tired of hearing this!

__ % of business and transactions systems around the world run on……

__ % of global financial transactions are processed in ……

__ billion transactions per day are supported by …..

Billions of lines of ____ code is in use today.

You can fill in those lines.

Are COBOL programmers really in demand today.   You would think so…right?   How do you replace the long-time COBOL coders?

Why do we not see that need?   Of course, you can read articles about that specific need as you surf the net but really can you open up today’s newspaper and find one or more businesses looking to fill a COBOL programming position? Probably not.

Is it that businesses are afraid to advertise the fact that their main systems are built around COBOL? Hmm, that’s an interesting thought.

Maybe organizations are trying to lure their former COBOL developers out of retirement and when they are unable to, they are looking to get their COBOL developers to do some internal training.   Why not teach your Java, VB or C# developer to actually become a productive COBOL programmer. It really only takes 40 hours of training to begin programming in COBOL.   The actuality in IT today is to know many programming languages.

It is very common today to have a software developer that is maintaining COBOL code to also know SQL, VB.NET, Oracle, DB2, Unix scripting, C++, and/or Java.

COBOL can be called from other languages to help leverage the business rules necessary to maintain a fully functioning business system. This is called wrapping. COBOL programs can be wrapped within, integrated into, called from, or call most other commonly-used modern technologies, including C, C++, C#, .NET, Java, PHP, AJAX, and Oracle, to name a few.

As a COBOL programmer for 30 years and one with many of tools and skills listed above in my tool belt, I think it is time for the COBOL community to stand up on the “WAGON” and promote our skills to the business world. It is time to show the “World” how we can provide the necessary skills to train and to continue developing in a IT market that is constantly evolving with new technologies and programming languages.

Not only are existing COBOL developers knowledgeable in a variety of programming technologies, but we also bring to the table many years of business intelligence.   Yes that’s right, Business Intelligence.   Think about it, many of the COBOL applications developed were the first applications developed in an organization. We had to understand the needs of the business, what was driving the business, the type of data needed to drive the business, the type of reports necessary to give management the information they need for decisions to be made.   This was the true foundation of the business.   Today’s applications and so called “Modern” technologies would not exist if it weren’t for that foundation that was built years ago.

Enough said, lets open up the conversations, let’s get the COBOL WAGON moving down the road!

For those who have never seen a COBOL program and are interested, here is an example of the classic “Hello World” program in COBOL in which I have modified it slightly to HELLO WORLD wake up!.

IDENTIFICATION DIVISION.

PROGRAM-ID. HELLO.

*

ENVIRONMENT DIVISION.

CONFIGURATION SECTION.

SOURCE-COMPUTER. RM-COBOL.

OBJECT-COMPUTER. RM-COBOL.

DATA DIVISION.

FILE SECTION.

PROCEDURE DIVISION.

MAIN-LOGIC SECTION.

BEGIN.

DISPLAY “world wake up, COBOL is here to stay!”.

STOP RUN.

MAIN-LOGIC-EXIT.

I love this Craigslist Ad that I came across.

This really got me thinking.  Is this where the “Life Air” of COBOL is located?  …In a bottle?

We seem to bottle up so many things to preserve the contents.

Are we as an industry putting a lid on COBOL, hoping it will perform today as it did yesterday until we can replace it with another package or another programming language?

How about dusting of the old bottle of COBOL, breaking the seal, openining the lid and breathing the power of COBOL.

See what COBOL has done for us in the past and leveraging its power to see what new things it can do for us today!

You probably don’t know this about me.  Outside of COBOL migrations, COBOL programming and COBOL repository analysis work, I have another passion;  I’m a picker.  Now you may or may not know what that is and so I will come out and tell you.  A picker, goes to garage sales and finds treasures.  I love it and so sometimes, I take my vacation time and spend it with my son searching for treasure.

We have a great time.  It’s fun for both of us to spend time together, to bond over shared values, and to score by spotting a valuable treasure.

I consider myself the person to usher the “second stage” in the life of a treasure.  The first stage is when someone buys something  brand new.  Then, they may have it and keep it for 40 or 50 years.  I know what to look for.  I know how to find the treasure in the box.

Writing this, it got me thinking about the similarities with my finding treasure in the old COBOL applications that I work on for my day job.

Much of the work I do today , in the COBOL world, revolves around helping businesses to understand the value that they have in their COBOL repositories.   As the COBOL programs age (some programs 50 + years old now) many of the solid business rules “The Treasures”, residing deep in the millions of lines of COBOL code, are lost and yet they still function as though they were written yesterday bringing incredible value to business in which they are tied to.   I have enjoyed being part of the development of tools that aid in finding and documenting these treasures.

Many people have dismissed COBOL and are trying to replace it.  I love giving COBOL apps a second stage of life.  To me, COBOL is a treasure.

COBOL has been around 53 years and counting…can you believe it?  In 2010, The Smithsonian celebrated COBOL’s 50th anniversary with a new site.

You can read about COBOL at the National Museum of American History

In my work, I have encountered customers that are looking to re-engineer their COBOL applications but don’t understand really what they have with their COBOL programs.  Yes, they may understand the input’s and output’s to their programs but rarely do you find the expertise to reveal the “Business Rules” that are buried within the thousands of lines of code that run the businesses.   The in-house COBOL experts, sadly to say, are getting close to retiring, or actually have retired.   I have encountered situations where COBOL programmers are actually afraid of revealing their knowledge of the COBOL programs worried they may be asked to retire earlier than they want.  I have even encountered situations where retired COBOL programmers have been asked to rejoin the company as a consultant.

With so many things going on, the one thing that remains consistent is the need to understand the many, many, many COBOL environment repositories that exist in the corporate world today!  And, there are many!  The work is not only to document but to help maintain systems that were here 30, or 40+ years ago and will more than likely be here for a very long time from now.  This is one of the things I do and one of my passions.

There are many tools and applications (some small, some large) that have tried to encompass the idea of providing an analysis of a COBOL environment.  I hope to blog about the tools I’ve come across and in particular I want to share about the GDT Portfolio Analysis tool that was created by the COBOLZombies team.

I want to share my experience because I love this stuff.

Fun articles: The Atlantic: Smithsonian Celebrates COBOL 50th With a New Site

Wikipedia: COBOL

After making a debut almost a year ago now, the COBOL PortFolioAnalysis tool has provided an incredible analysis boost to a very large customer out east. The tool is analyzing over a thousand JCL and COBOL programs, mapping data and flow of the programs and JCL in a matter of minutes. The results can be ported to a relational database and programs can also be completely flowed out in a graphical flow representation (visio, word, pdf). This tool will be vital in upcoming mainframe migrations to determine the actual programs, JCL and datafiles that will need to be migrated. As we are continually enhancing the tool, we are now looking at implementing an “Impact Analysis” process into the tool. As the population of COBOL programmers declines, and knowledge of the COBOL programs (that remain the heart of processing for many businesses) diminishes, a tool such as the COBOL PortFolioAnalysis will become extremely important to help these companies understand the business rules and aid the developers in maintaining the COBOL environment.

Have you ever wanted your COBOL program to talk to you?

Have you had a need to have your COBOL programs “Tell” your computer operator’s that there was a problem during execution.

Have you had a need to have your COBOL programs talk to help the visual impaired?

See how easy it is to code a call to “Speech” software by clicking on the following video link.

Adding Voice to your COBOL Application

If you are interested in learning more about this please reply to this post.  More COBOL fun to come!

Managing COBOL legacy systems

Part 1 – migrations

Have you ever worked on a COBOL mainframe migrations to a server platform, or about to consider one?  While working as a technical manager providing COBOL solutions for my customer base, it was obvious that there was a need for me and the customer to gain a better understanding of their COBOL source repository.   For our migration, we needed a complete inventory – data files mapped and JCL hierarchies, and also extract business rules and produce flowcharts, but when I looked around for tools on the market that could provide some of these needs, they usually fell in one or all of the following categories:

• Too Expensive to license
• Difficult to work with
• Did not exactly provide what was needed

Frustrated I couldn’t meet my needs from an existing product, working with my team of experienced COBOL and VB programmers we came up with a generic platform independent COBOL portfolio analysis tool that works on a laptop. This tool functions seamlessly in the work place, and provides just about everything we needed:

• Data Maps
• File usage
• JCL hierarchies
• Business rules
• Flowcharts

We even got the tool to include business rules in the flowcharts, and with client input the tool is constantly evolving. Now, when I work on COBOL migrations at a customer site, I load up my laptop with the customer inventory and use the tool to map out a portfolio analysis to help guide the process.

If anyone else has needed to manage their COBOL legacy systems and has looked for a similar tool to assist, let me know your thoughts, I’d be happy to discuss issues and resolutions with you.