COBOL: Still Learning and Growing

Continuity

I was recently asked about the direction of COBOL and whether or not I believed the language would continue for very much longer. To say I was taken aback by the question would be a serious understatement! I pointed the person to an article I did last year about COBOL not only being everywhere but what it could do. The article was titled “COBOL: It’s everywhere” and can be found at http://www.c-sharpcorner.com/UploadFile/RSM50/EVRYWHR09032009152715PM/EVRYWHR.aspx . Now maybe I’m being rather naïve, but really why wouldn’t COBOL not only continue but grow and adapt? All one has to do is to take a serious historical perspective of the COBOL language and one can see not only continuous enhancements to the language, but continual expansion of the language. Let’s take a quick historical review of COBOL, shall we?

Yes COBOL is old. It’s over 50 years old already. In most cases it’s been around longer than most of the developers working in a given shop. Just because something is old though doesn’t mean it’s still not useful and serving a purpose. We’ve heard the examples before, “Have a credit card?”, “Use a cell phone?”, “Have a house mortgage?”, “Pay income taxes?”… all and many more examples are being ran by COBOL systems in some point in time. Micro Focus asked a reporter once to live a single day without interacting in some manner, shape or form with COBOL and it couldn’t be done. So it may be old, but it’s also very wide-spread and serving us day in and day out without any recognition. Now let’s look at how COBOL has grown through the years.

Evolution

Even though COBOL is old, it has not stopped learning. COBOL has gone through a number of revisions. To set the baseline let’s take a brief look at each of the versions of COBOL and identify the key contributions made to the language starting with ANS COBOL 68 (yes that’s 1968).

• ANSI COBOL 1968 In December 1960 a COBOL program was successfully compiled and executed on two different platforms without requiring any code changes. This demonstrated the concept of compatibility to the early pioneers and the need to ensure the language remained consistent across multiple vendors. During the course of the next several years however compatibility suffered. The American National Standard Institute (ANSI) set about the task of re-establishing compatibility. COBOL 68 was the first ‘official’ release of the language.



• ANSI COBOL 1974 This version was considered by many to re-emphasize the need for compatibility. It contained a number of features that were not in the original version.



• ANSI COBOL 1985 Another revision of the original version with new features. One of the most important was the introduction of structured constructs. This included the inclusion of scope-terminators such as ‘END-READ’ and ‘END-IF’ to name two. This release was geared towards standardized coding techniques.



• ANSI COBOL 2002 A significant enhancement of the language was accomplished with the 2002 release of the language. Several of the key concepts introduced included National Language support including support for the Unicode character set, user-defined functions, calling conventions to and from non-COBOL languages, framework support (.NET and Java), floating-point, and XML generation and parsing. One would characterize this release as geared towards interoperability.
  

Let’s look at the above information in a different perspective. The different versions of the language are presented with the key object each version achieved:

ANSI 1968: Language Standardization
ANSI 1974: Language expansion
ANSI 1985: Technique standardization
ANSI 2002: Interoperability

From this we see a progression of maturity in the language beginning with defining a standard manner in which to communicate, to growing in capabilities and finally to enabling communications with others. A logical progression and growth enabling COBOL to become capable of achieving many more tasks than ever imagined by its creators. But yet the perception exists that COBOL can’t do anything more than add numbers together. But what about the question posed earlier, “Will COBOL be around for very much longer?” Well the NEXT standard has been in development for a while and is due to be released for public comment in August 2010.

Continued Expansion

The next standards goals are to continue to expand the capabilities of the language while making it able to interact with the other languages of the day. To that end the following are being proposed for inclusion in the standard
— Dynamic-capacity tables
— Function pointers
— Any-length elementary items
— Increased size limit on nonnumeric literals
— Enhanced locale support in functions
— Support for industry standard floating-point formats and arithmetic, including multiple rounding options
— Structured constants
— Enhanced date and time handling
— Parametric polymorphism, also known as method overloading

If you’d like to follow the process of the standard you can visit http://www.cobolstandard.info/j4/ . We as COBOL developers should be aware of the changes being proposed to the language we work with on a daily basis so that we may be able to adapt our techniques to take advantage of the new constructs in our toolbox.

Awakening

What has to happen though is for the development community world-wide to realize what a valuable asset it has in all this COBOL code floating around the world and what a versatile language COBOL really is. Companies have invested billions of dollars in these systems. They’ve spent years tweaking, tuning, refining the logic to do just what they need. Then someone says “COBOL ain’t cool” and they look at getting rid of it. Why? We can interact with COBOL in ways unheard of before with .NET being a primary example. Let’s wake up and realize the enormous economic investment that has been made of COBOL and instead of trying to replace it, let’s help make it do even more. Look at new platforms for performance gains, look at new frameworks such as .NET for interaction but let COBOL keep doing the job it’s been designed for…making money! Will COBOL be around for another 50 years? Time will tell but with its demonstrated ability to grow, adapt and expand I would bet on it.

Let’s hear what you have to say. Do you code COBOL? Does your company have applications written in COBOL? How are you using it? Are you looking to expand it? Have you or your company considered expanding what COBOL can do to achieve business success?

The COBOL Version: Going The Way of Jello?

Once upon a time, every customer RFI had a question about the version of COBOL the compiler supported.  That was years ago.  I can't tell you the last time I got that question.  Not only that, I can't recall when the last time anyone cared really.

Why is this?  Have COBOL versions gone the way of gelatin?  Have they blended so much or become so generic that eveyone calls it by the same name, regardless of what version it is?  Name another brand of gelatin.  (Bet ya can't)

Well, one reason I personally never get the RFI question is probably due to the fact that the Micro Focus dialect has become the defacto standard if you are working off the mainframe.  And that just happens to be the toolset I work with.  Yes, it is nice to be with the market leader *grin*.  It does make life easier sometimes.  The only version related question recently was "Do you support Enterprise COBOL?".   Again, this was probably due to this being the version on the mainframe they used.

With these two exceptions in mind, I still don't see why companies have lost interest in the latest version of the COBOL standard.  Ask a shop working with Java and you'll find out quickly if they are on 1.3 or a 1.6, etc.  Same thing with the .Net framework.  I guarantee you'll find out quickly if a company targets  the 2.0 or 3.0 version of the .Net framework.

But the COBOL version?  Maybe my imagination, but it doesn't seem to be that important anymore.

Could it be that everyone lumps every version into the same bucket?  Its all just COBOL right?

As many may or may not know, the last published COBOL standard was released in 2002.  There were a number of items in the 2002 edition related to Object Orientation which truely brought the language into the modern era.  From the notes on the COBOL Standards website, there are references to a supposed release targeted for 2008 which were supposed to move it even further forward.  I wonder what ever happened to that version.  Anyone know?  Why did it die on the vine?  I know for a fact the group still meets and is working on advancing the language.  But why has it remained unpublished?  Isn't it about time a new version was announced?

Oh well, I digress.

What I'm most curious about is your company's conformance to a particular COBOL version or published standard.  What version do you use?  Are there any elements of the 2002 standard that your company uses or conforms to?  Or are they tied to a vendor specific version of COBOL like Micro Focus or Acucorp?


A more basic question...Do you know what is in the 2002 edition of the COBOL standard?  You can find it at the ISO website just in case you were curious...

And one other question before I finish up on the topic.

If a new version of the standard were to be released on the world, what would it mean to you?  To your company?  From what I can see, it would be a safe bet that very little discussion would occur around the subject until somone needed to upgrade their compiler. 

Kinda like the "if a tree fell in the woods, would it make a sound" question. *smile*

With my limited knowledge of what is being discussed by the group, this may ultimately be a bit of short-sightedness if your company uses COBOL but isn't up on the subject.  There may be elements within the standard which would allow your company to save money or do more with the language.

All things considered, how would you propose the guys over at the COBOL Standards Group go about getting your attention?

What needs to happen to bring this to the forefront in your shop?

Just curious.

Declarative Sorting Of Dynamically Allocated In-Memory Tables With COBOL

One of the things COBOL is really good at is data processing.

Its declarative data model makes it second only to SQL for this purpose. Both in Managed COBOL and native COBOL, Micro Focus COBOL can sort an in-memory table just by saying 'sort'. Not only that, a little trick with pointers and the linkage section means that we can sort any sized table and allocate the memory for that table on the fly. Here I am using Visual COBOL (Visual Studio COBOL) to work through these ideas. To do this, I am using an imaginary example of a retail data control system where we have product variants and stock keeping units (skus). Our little program shows how we can sort variant name/sku pairs by the sku number.

What does declarative mean?

Here we simply declare the structure of our table and how it is indexed and can be sorted:

linkage section.
       01 variants occurs 1 to 1000 depending on variant-count
                   ascending key is sku
                   indexed   by jump-start-index.
           03 sku  binary-long.
           03 decr pic x(20).

Because we have put this in the linkage section, we have declared all this but we have not allocated any storage to it yet - that comes later. Now we sort:

sort variants

Now that is the bit I love! Having declared the data and key structure of the table, COBOL knows everything it needs to know about how to sort it. We do not have to call some sort function passing in some functional thing like a lambda or a call back. All that complexity is taken away. We want the table sorted - so we tell COBOL to sort it! If only my kids were so easy to instruct...

How About Pointers And Allocation?

As mentioned, the declaration of the table is in the linkage section. I have also created a working storage item 'mem-ptr' which is usage pointer. This approach means we can use CBL_ALLOC_MEM to assign a block of memory to use for storing our table. The size of the block to allocate is worked out from the size of each record via the "length of" keyword pair and multiplying the result by variant-count. The location of that memory is pointed to by mem-ptr and we can tell COBOL to use it for our table by the statement "set address of variants(1) to mem-ptr". However, COBOL does need to know how big the table is. This is done by using variant-count in the "depending on" clause of the table declaration.

Putting It Together In Visual COBOL

First open Visual Studio:

Then start a new project:

Then pick a native COBOL template:

Take the created source and replace it with the source below:

$set sourceformat(variable)
       program-id. "sorter".

       working-storage section.
       01 mem-ln        binary-long.
       01 mem-flags     pic x(4) comp-5 value 0.
       01 int-bl        binary-long.
       01 mem-ptr       usage pointer.
       01 status-code   pic x(2) comp-5.
       01 variant-count binary-long.
       
       linkage section.
       01 variants occurs 1 to 1000 depending on variant-count
                   ascending key is sku
                   indexed   by jump-start-index.
           03 sku  binary-long.
           03 decr pic x(20).
           
       procedure division.
       
           move 10 to variant-count
       
           set mem-ln to length of variants
           multiply mem-ln by variant-count giving mem-ln
           
           call "CBL_ALLOC_MEM" 
                using     mem-ptr
                by value  mem-ln mem-flags
                returning status-code
           if not status-code = 0
               display    "Failed to get memory"
               stop run
           end-if
           
           set address of variants(1) to mem-ptr
           
           move 1234       to  sku(1)
           move "beans"    to decr(1)
           move 12         to  sku(2)
           move "fish"     to decr(2)
           move 4532       to  sku(3)
           move "cat food" to decr(3)
           move 2342       to  sku(4)
           move "dog food" to decr(4)
           move 1231       to  sku(5)
           move "sauce"    to decr(5)
           move 1254       to  sku(6)
           move "bread"    to decr(6)
           move  999       to  sku(7)
           move "chicken"  to decr(7)
           move    1       to  sku(8)
           move "beer"     to decr(8)
           move    2       to  sku(9)
           move "wine"     to decr(9)
           move  9999      to  sku(10)
           move "tnt"      to decr(10)
           
           sort variants
           
           perform varying int-bl from 1 by 1 until int-bl greater variant-count
               display sku(int-bl) " =- " decr(int-bl)
           end-perform
           goback
           .
       end program "sorter".

Giving this:

Now click in the left margin to put a break point on the "goback":

Now step into the program using the debugger and it will stop on the break point:

We can now see the sorted output!

For more stuff like this - check out the Visual COBOL Knol and The Managed COBOL Knol community sites

Why APM Is Important To COBOL?

Some of you may be asking "why is APM relevant?".  What has application portfolio management got to do with COBOL?  And how does it relate to everything else I've read on this blog?

Let me connect the dots.  (forgive me if I wander a bit *smile*)

To many folks, COBOL is "old code" that has got to go.  The reasons many provide usually have something to do with the user interface or the data, but not the core functionality these applications provide.  Those using the applications on a daily basis hate the old character interfaces.  This is thanks to the fact that everything else they use has a slick web interface and they can generate their own adhoc reports without waiting for weeks or months for IT to get around to it.

To quote a CIO I spoke with recently "Users hate using the character screens but we couldn't do business without the functionality the systems provide".  He also had issues with the data.  Since everything was "locked" into the applications, they had to create a data warehouse which replicated the various information and made it more accessible to the business users.

He really really really would like to do something with the applications, but he didn't buy into the "let's rewrite it in (your language here)" pitch.  This is due to the fact that he realizes those applications are very complex and rewriting them introduces unacceptable risk.  If he understood how these applications worked, he might be able to do something with them.

I saw another example of this today while visiting one of the largest insurance companies in America.  One team within the company was tasked with trimming $100 Million out of the company's operation budget.  To do so, they started asking questions about their mainframe-based COBOL applications.  What they found was that no one understood everything these applications did.  Nor did they know how interwoven the various applications were with the rest of their infrastructure.  Sure they knew pieces and parts, but no one had the big picture.

Just to make sure you didn't miss my point, no one in this multi-billion dollar company understands how their systems work or what they consist of.

And we are talking a company with literally hundreds of architects, project managers, application developers, etc.  Even those who have been with the company 30 years only knew what parts of the various application elements did or were comprised of.  And these folks are making multi-million dollar decisions based on what they know about their systems every day!

Yikes!

I've digressed a bit, but hang in there, I can draw it all together. I think... *wink*

How would both of my examples solve their problems?  APM.

With an APM-type solution, that old code becomes a reusable building block for the new applications your company needs.  By using an APM solution to gain an understanding of the application and its composition, you could then take that "old COBOL code" and re-purpose it with a new user interface or by opening up the data layer. 

With an APM solution, companies can see how to reduce their IT expenses by identifying dead application elements, unnecessary application complexity, duplicate functionality and data.  APM-based solutions can provide management a real-time picture of these systems.  Who knows, they might even realize how risky a complete rewrite to (your language here) really is.

Recall the earlier posts on Visual COBOL? (see how I wove that in there?  slick huh?)

Once you have identified those pieces which are key to the business, you could use a tool like Micro Focus Visual COBOL to create a COBOL-based web service.  Then those who are building the new user interfaces could use whatever language they want to build that slick new user interface.  And by doing so, COBOL continues to have a place in the environment.

Or what about the post on migration?  (yes that was another post I made) With an APM solution, you can identify what pieces of an application can be moved off the mainframe to a Windows or UNIX or Linux server.

So, back to my point.  I believe that APM-based technologies are critical to the future of COBOL. 

They can give new life to those COBOL systems...

That's my thinking anyways.  What's yours?

Application Portfolio Management - Best Practices

It's tough to control your application portfolio. Your systems have been developed over the course of years or even decades. The people that developed the apps may have moved on to other roles and documentation is out of date. So, the portfolio gets more and more complex. And that complexity means they are slower to adapt and more expensive to maintain.

Application portfolio management is an approach to help return control to application managers. In this series of posts, I'll take a look at best practices for managing the application portfolio.

• Goal: Constant fire-fighting is no way to run a development organization. Especially in today's era of tight budgets and fast change. In this post I'll summarize the goal of APM and set the stage for a discussion of best practices. Read the post.
  
  
• Questions and Metrics: APM data should answer questions that address a specific goal. Say, ‘why is this business process inflexible?’, ‘where can I cut costs?’, or ‘where is my software architecture flawed?’. To answer these different questions requires different combinations and weightings of data (user surveys, application code, or external sources). Sometimes more of one source, sometimes another. Read the post.
  

• Decision-Makers: APM data needs vary based on where you are in the organization. Higher level managers require higher level abstractions, particularly of technical metrics. Also, different types of users will have different data needs. An architect may want technical complexity data, but it may only be meaningful to him if it is filtered by architectural models. Read the post.
  

• Maturity: There are different levels of maturity for decision-making. This maturity directly affects which metrics are accessible in the first place and also indirectly because it determines the kind of business goals that an organization is prepared to address. Read the post.
  

• What’s next: As a particular initiative moves from “decision” to “action”, different data may be needed. More “bottom-up” data may be necessary to implement the decisions at this stage. Further, different metrics can be monitored to ensure the success of a given development or modernization project as it is executed. Read the post.

Precision: What is it Precisely?

Alex has an interesting post over on Nerds Central which I believe you may find of value.

He details a couple of useful items specific to decimal precision in Cobol and Java.  It is interesting  because it illustrates the use of a Cobol data type I've not played with, float-long. 

Float-Long came about a few years ago, along with Float-Short and Float-Extended and was made part of the 2002 Standard I believe.  To make a long story short, Float-Long isn't quite as accurate as you would hope, but does have its uses.  Alex provides a complete example showing how to acheive both an exact arithmatic answer using a Comp data type and how to use the Float-Long data type.

The other reason I find the post of interest is that in his article, it appears the Java code can only duplicate what the Cobol Float-Long data type provides (which is inaccurate), not the more precise answer he achieved using the more standard Cobol data type of Comp-1. 

Am I mistaken in my interpretation of the Java sample he provided?

This looks like a red flag to me if your Java code is doing any math which requires a high level of accuracy on the right side of the decimal.

Can someone verify this and post a Java-based example confirming/denying the problem?

I'm curious but only know enough Java to be able to nod in the right places when talking with a Java developer. *smile*

P.S.:  The Visual Studio 2010 Launch in Las Vegas was quite the event.  Thanks to various issues with my plane ride (rerouted due to medical emergency and then detained in Albuquerque, NM due to mechanical issues, etc), it only took me 20 hours or so to make the 3 and 1/2 hour trip home.  At least I wasn't flying to London!

Visual Cobol. You gotta see it

Hey folks!

I'm in lovely Las Vegas on the conference floor talking with customers about the new Visual Cobol release which is being announced at the Visual Studio 2010 Launch.

So far the feedback has been that this is really slick stuff indeed.  This is the first time I've gotten a chance to look at the new syntax support.  Micro Focus development has done a tremendous job simplifying the syntax.  If you haven't looked at the articles out on C# Corner, go take a quick look.

Oh well, gotta go.  Mike wants his laptop back!