Don’t get consumed in the Media Hype

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/

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.

 

Hello World..Wake up!

Hello World

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.

 

Preserving COBOL

I love this Craigslist Ad that I came across.

CraiglistAd

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!

 

 

COBOL and the Dinosaur Story

COBOL is not a Dinosaur!

Everybody who ever heard something about COBOL, especially that is is an OLD Langugage, needs to view this Video.
Then, imagine, really imagine the impression to a point where you see the picture of COBOL beeing one of the most modern languages you can think of.

There is only one limit in this world, your Brain.

The Trun’k’ation Effect

trunk-a-tionIn one of my recent “Picks”, I came across an old camel back trunk.  Wow what a piece of history.  As I analyzed the features of the trunk, I found a patent date of 1888 and inside was a picture pasted to the lid which was easily dated to the late 19th century.  An awesome $30.00 find!  I am sure that one of the uses of this trunk was to pack your belongings as you traveled to the United States from another country. Many times people had to reduce their belongings to the size of the trunk and leave some very special family heirlooms back in the country where their lives began.

Well, with that being said, it got me to thinking about some COBOL analysis projects that I have been involved with. Recently a customer came to us wanting to know why data in particular field was being truncated and what the impact of increasing the size of that field would be throughout their COBOL repository.  Losing important data can have a huge effect on daily business just as leaving family heirlooms behind had a huge effect on families moving to the United States years ago! With the tools that we have developed and also existing tools, we can now quickly drill down to the specific lines of code and data fields that impacted this particular field and gain an understanding of what the impact to other fields, programs and data files would be if that field was increased in size. This can be done in a matter of minutes!

The “Hidden” Treasure

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.

 

Poor Quality Code

Here’s an older but Interesting Article on CIO.com.  Bill Curtis from Cast said

“there are many people going into Java now that really don’t have strong computer science backgrounds. We may just be seeing the fact that there is an awful lot of people writing code who aren’t gurus in software engineering.”

What does that really mean?

I was always told that students do not learn COBOL at school because it is not modern. Now I read that they learned the modern language Java but only up to the point to write “Hello World”?
I have to repeat my most important message again! How can we make students understand that COBOL is not dead? How can we make Teachers understand that they have to teach even so called dead languages?

Let’s start the Discussion! You, yes you, who just read it, play the Ball.

I think it will not be the last time to repeat this.

Here’s the full article.

CIO article snip

If someone in Germany, Area Cologne, wants to learn COBOL and more, please contact me via

Detlef.Lexut @ lexut.de (no spaces)

COBOL Skills Gap opening wide

Today I read an interesting article from Ed Airey about the “COBOL Skills Gap“. When Ed says “If we don’t drive interest in IT the impact on business could be brutal.”, and I just can completely agree to this. I see COBOL Programmers leaving companies where they worked more then 30+ years. These Programmers built applications from scratch and maintained these for decades to adjust them to market needs. When these people retire they are sometimes replaced by 2 or more programmers to fill the gap. And I am talking about really experienced individuals, and yes, you guess right, they will also retire soon. Ed also writes: “The student perception of languages such as COBOL is that it is considered ‘un-cool, outdated or even ‘dead’. The current business use and reliance on the COBOL language demonstrates this to be an incorrect position.”  Agreed, I also find Java Programmers who talk about COBOL will be gone by 2015 because IBM will no longer develop CHIPs that can run COBOL Programs. I don’t know where they get this idea from but I know that we have to do something to share our knowledge with the future students. let's-talkI am wondering how one can help here. Myself I am writing in this ‘un-cool’ and ‘dead’ language since 25+ years. Using the Micro Focus Workbench I started writing Mainframe emulators. A complete Toolset to migrate files, run Batch processes and Emulating a whole Transactional System, all written in this ‘un-cool’ Language. How can we make students understand that COBOL is not dead? How can we make Teachers understanding that they have to teach even so called ‘dead’ languages? Let’s start the Discussion! You, yes you, who just read it, play the Ball.  Let’s talk. Wants to read the full Article? Here you go.

CZO_20130426_001

Leave a comment below and let’s continue the conversation.

Dates For The 2013 GDT User Conference Announced

GDT User Conference 2013 is a 3-day educational and knowledge transfer gathering for the GDT and Micro Focus COBOL Community and will run from June 2nd to the 5th in San Diego, California.

GDT User Conference Overview and Details

Register today

AGENDA

Day1 | June 3, 2013 Sessions Include:

  • What’s New in GDT V5.1
  • Exposing your COBOL Applications Part I (Your COBOL Repository)
  • Exposing your COBOL Applications Part II (Your COBOL Programs in action)
  • Optimizing your Repository (Part I) “COBOL program and JCL optimization”

view details…       register…

Day2 | June 4, 2013 Sessions Include:

  • Optimizing your Repository (Part II) “Operations Optimization”
  • GDT AutoPilot (AuPi) – Demonstration
  • Small Programs Doing Big Things! (The power of COBOL programs)
  • GDT Roadmap / Micro Focus Roadmap

view details…      register…

Day 3 | June 5, 2013 Sessions Include:

  • Customer Roundtable – GDT Product and Support Influence Session
  • ARI Case Study: GDT V5 Upgrade
  • The LINDAB Migration Case Study
  • Sonepar Case Study

view details…      register…

 

2013-GDT-User-Conference

Register for the 2013 GDT User Conference – June 2-5

Register today 

 

A snapshot of the state of COBOL

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