What's Your Language?

Introduction

Human nature has a strange way of not letting a person recognize valuable information or ideas, even when they are right in front them. Advertisers and sales people are always trying to draw your attention away from your current interest to the ‘newest’, ‘latest’ or ‘most innovative’ bauble. You and your company have a very valuable corporate asset that’s been in place for a number of years, silently working in the background to make you and your company profitable: your COBOL based applications.

Now bear with me, I know what you’re thinking… “COBOL??? You have GOT to be kidding!”. Yes, COBOL. Whether you “speak” Java, C#, RubyOnRails or any of the other newer languages consider what it is your COBOL applications have been doing all these years, what you’re looking for in a new or replacement application (or language) and the estimated costs of replacing those COBOL applications in terms of both effort and risk. There is significant value in the applications that have been running your business.

Silent Partner
 

COBOL has been a silent partner in your company’s success. It has been providing information to you day in and day out for too many years to remember. Yes, it’s old but honestly… so what? It is still doing the job for which it has been designed for, to process data and provide a competitive advantage to you. Yes technology has changed and you keep hearing “COBOL can’t do that”. The truth is it probably can but more on that later.  So COBOL has been processing the data it’s been receiving all these years, analyzing it, generating reports and keeping the lights on for your organization. The people who designed and maintained the application(s) may have moved on to other companies, are retired or in worst case have passed on. Yet the COBOL application they created is still doing its job and you want to replace it with ‘the shiny new bauble’. Why?

What does that bauble have that COBOL doesn’t? Is it a new user interface? Is it the ability to support web services, including JSON and REST based services? Is it the ability to process XML data or access .NET or JVM classes and extend your applications reach to these new platforms? Are you trying to get to a mobile platform? If you answered ‘yes’ to any or all of these questions then you need to take another look at COBOL. All of the technologies or techniques mentioned are supported or obtainable from your current COBOL application. The key is knowledge and being able to research the capabilities of the language, which is where IBM and Micro Focus come into the picture.

Skills Shortage

All the CxOs of your organization, and perhaps you as well, have heard is “COBOL can’t do that” or “COBOL is dead” or “no one is teaching COBOL anymore”. Some companies have had advertisements out for COBOL developers for months and haven’t had a single qualified applicant. They interpret this as validating the information they’ve been hearing all along, that COBOL is indeed a dead language. This however is far from reality.

Two of the largest COBOL vendors in the world, IBM and Micro Focus each provide a wealth of training scenarios.  From basic language courses to more advanced topics in integration with the new technologies. The IBM approach is more mainframe centric and can help you get new developers up to speed and productive in a short period of time. Micro Focus can also provide training for the mainframe centric developer but it can also provide training for those developers working in a distributed environment and looking to access new technologies such as .NET or JVM frameworks. Additionally Micro Focus has created an academic alliance with secondary education facilities around the world to help those institutions teach COBOL.

Rather than trying to hire a ‘COBOL programmer’ why not look for a developer already familiar with Visual Studio or Eclipse? New developers coming out of technical school, college, or existing developers looking to make a change in their career know one or in most cases, both of these development environments. The biggest obstacle, objection, learning curve to learning COBOL has been the environment in which it was maintained in. This should no longer be an issue as both Micro Focus and IBM have adapted the Eclipse environment and Micro Focus has even extended the development experience to Visual Studio. Developers already know these IDEs, they know how to manipulate the environment and are generally already productive in it. So a significant part of the learning curve has just been eliminated. So what’s left? The language…

Parlez-vous français?

While I do not speak French I can understand the basic constructs of the language, common phrases and can decipher enough to ask for help in translating it to English, which is my primary language. I can do the same for German and Russian. In actuality, anyone of us can do the same. We learn a primary language and through necessity, want or influence learn additional languages as we grow in our lives and expand our circle of friends and co-workers. The same can be said for computer languages.

I am a COBOL developer at this point in my career. I didn’t start out that way, but I learned it. The very first language I learned was Pascal. I then went on to Visual Basic, COBOL, JCL, SQL, SAS, CICS, REXX, Windows Scripts, VB.NET and finally C#. I am more fluent in computer languages than I am in spoken languages. What is the difference in all of these languages? Syntax. As a developer I know and understand how to formulate a series of expressions into a comprehensive set of instructions that instruct the computer to perform a series of tasks to complete a unit of work. Regardless of the language, the underlying logic flow is very similar in all circumstances. HOW I choose to implement the requirements is based on the environment in which I am running in. I may be coding a series of expressions in C# in the morning and a different set of expressions in the afternoon in COBOL. The language used is determined by the environment being employed and the requirements of the request. One constant though in all of the languages noted above is Visual Studio. I use Visual Studio for all my coding.

Any developer in the workforce today knows at a minimum three programming languages. These are dependent on the environment they are working in, but at a minimum, three languages. They can switch between these languages with ease (ok, you may have to stop a second to think about the syntax) and complete tasks quickly and efficiently. Why can you not add COBOL to that mix? You already know your development environment. You already are multilingual. You can adapt to the requirements of the request. You can learn COBOL and you can become a more strategic resource to your organization while expanding your career into areas never dreamed of. COBOL truly does run the world of business and you can help integrate it with the new technologies available.

COBOL: No longer a silent partner

COBOL has come a long way with new syntax, new interfaces, new techniques that could enable your application to take a drastic step forward. Instead of trying to replace COBOL, why not work alongside it to achieve rapid, stable results for you and your company?

You didn’t know the languages you are working with today, you learned them through spending time and writing code. Spend some time and write some COBOL code in Visual Studio or Eclipse. You’ll see you can do it and you may even say it wasn’t that bad.

 

Happy COBOL Coding!

 

COBOL and the CIO

Last week I had the opportunity to attend a CIO Forum here in Atlanta.  Two topics seemed to be at the top of everyone's list: cutting costs and mobile devices. 

On the cutting costs topic, almost every CIO there had a story to tell about how they were surviving in this economy.  They were doing it by reducing their costs so that they could survive on the same or smaller budgets than they had last year and the year before.  And they were expected to provide more value to the business than ever before.  Do more with less seems to be the mantra of the day.

On the mobility issue, again most of the attendees talked about how they were being pushed to provide accessibility to their corporate systems by their users/business groups for smartphones and notepad-type devices.  More and more people are plugging their own hardware into their corporate networks and expecting them to not only work, but be supported and leveraged.  As you can imagine, this is causing quite a bit of work for some and creating unique opportunities for others.

I have some good news for them.

Sounds like a job for COBOL! (this is a blog about COBOL after all *smile*).

To help with cutting costs...  why not reuse the business logic that has been captured in the COBOL code and repurpose it?  Turn those old routines into components/services  and redeploy them.  Put together a new UI, combining new features with existing processes.  It is relatively easy to do using tools like those from Micro Focus (I'm sure the other COBOL tool vendors have comparable solutions too).  Either way, reuse the existing code!  No need for those costly "green field" development projects.

One of the large insurance customers that is on your side recently did just this.  They took an old application that was written in COBOL, cut out the screen section logic, restructured the business logic as methods and classes and intermixed these routines with C# and a new Winform interface.  Within a 90 day period, they were able to do more work with a team of 5 or 6 than an entire dev team of 20+ was able to accomplish in 2 years.  Reusing existing application source saved them millions.

To help with the challenge presented by all of these new mobile devices, again, use your COBOL assets and provide your users new ways to access the information they need.  Let me give you an example of what I'm talking about.

While at the forum, I had the pleasure to speak with a fellow from a university down in Columbus Georgia.  He walked me through how they were providing their students smartphone apps which interfaced with their back-end applications (yes they were COBOL).  They could access their account details on their phones, their Ipads, on the college computers, etc.  For the IT team, it was nothing short of brilliant.  For the students, their reaction?  *Shrug*  They thought this was how it was supposed to work in the first place.  Go figure *grin*.

So, my message is this.  Companies are starting to figure it out.  COBOL is relevant in today's environment.  How are you making it relevant in your business?

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?

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

National Computer Science Education Week in America!!!!

One of my collegues, Peter Anderton (in the UK believe it or not), posted a link on his Twitter account.  Not that I was visiting Twitterville mind you.  I just noticed his link to Twitter on LinkedIn. *smile*

According to his post, the U.S. House of Representatives passed a resolution declaring the week of December 7th National Computer Science Education Week.  The date was picked in honor of Grace Hopper's birthday.  Here is the link for the resolution

Hmmm...

Follow my thinking process for a sec if you don't mind.

Grace helped invent COBOL. 

Because of this, Grace became synonymous with COBOL.

So, Grace = COBOL correct?

So is it safe to say that National Computer Science Education Week is also a tribute to COBOL?

The plan for everyone to realize that COBOL rules the world is coming together nicely.  *smile*

Now if we can get Al Gore to endorse COBOL (since he invented the internet) we can move my plan to stage II (add maniacal laughter here).

So, make sure everyone celebrates National Computer Science Education COBOL Week starting December 7th!

The Future of COBOL

You know I've seen lots of posts over the years talking about the death of COBOL and the future of this language or that language.

I've been thinking, maybe it would make sense to have an open discussion about the future of COBOL and how it has and will evolve in the near future. With that, I've invited a couple of folks who are directly involved in determing this future state to be authors on this blog. One is on the COBOL Standards committee, while the other is one of the key developers within Micro Focus helping to create these future versions.

If you have any specific questions around this area, feel free to post a comment or two. I think a lively discussion would have benefit on both sides of the fence.

Thanks!

P.S.: Can anyone identify where the bit of sculpture I've posted is located? Yes, I know it has nothing to do with COBOL, but I thought it added a nice touch, don't you think? :)

Welcome!

Blogging about COBOL!?!?! Now how cool is that? Welcome to "It's a COBOL World" Blog. We invite you to post your thoughts, comments, articles, pictures, whatever you have about COBOL here. We hope you'll find this blog interesting, informative and most importantly...useful! Don't be shy...sign-up and start sending in your thoughts. For other informative articles take a look at C#Corner (http://www.c-sharpcorner.com). Check out the COBOL.NET link in the left hand navigation pane. We'll post other links soon for other sites with COBOL information.

Again...Welcome!