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!

 

Datagrids, ADO.Net and Cobol

The last few months have had me focused on an internal project which involves multiple pieces, some of which are Micro Focus products, while others are from partners such as HP, LRS, Syncsort, Microsoft and CA.

And as such, I haven't had much time to dig into using my new favorite tool, Visual COBOL.  That's left me sad *smile*.  To fix this, I spent part of my weekend writing code.  It sure beat raking leaves!  (Ummm... I'll get to it next weekend I promise dear).

One of the things I figured out was how to create an ADO.Net datatable, add fields to it, populate it with data, and tie it to a DataGrid.  It's pretty easy actually.

First thing you do is define a variable in working storage that can hold the definition of the table.

Then in my program I create a new instance of the table and store it in this variable.

And then I added a column to the ADO.Net datatable by first defining a variable in Working Storage that could hold the definition of a column:




And then doing the add like so:

After that, it was just a matter of setting the various properties of the column:

And adding it to my datatable.

Once I had the table defined, I linked the datagrid control I had placed on my Winform to it.

Now that the data table has been defined, it is just a matter of adding some data to it.  To do this, I had to first create a new row in the datatable. 




And then once that was done, I inserted data into that row matching its definition:

The only tough part was figuring out the syntax of adding a row to the table. In VB.Net, the statement would have been:


Trow = Tbl.NewRow()

But as you can see, in Visual COBOL, I had to first set the data type of the field and then add it to the table.  What's an extra statement among friends right? *smile*

The last set statement above uses the Now method of System.DateTime and stores it in the column I created.  The "ToShortDateString" at the end of it allow me to choose the format of the date string being stored into the column.  I could have just as easily accepted the current-date from the system clock and placed it in there.  But I thought I would try the .Net method instead.

Fairly simple.  Once I figured all this out, it didn't take long to expand on things and create something I could toy around with...

 Yes, I know it isn't that impressive, but I now know how to create an ADO.Net data table, populate it and link it to a datagrid.  And so do you by the way *wink*.

And I'm betting neither one of us knew how to do it before you read this.

See, I can learn new tricks *smile*

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?