Legacy

Robert,

Regarding legacy I have some additional comments to make. Legacy is as the word translates some thing inherited.

My opinion is the definition of legacy means in the IT world more the situation in total which has been left to the actual IT world from the early world of COBOL and even late 1401 / 1410.

In the early 1960‘s there was a huge dominance of IBM. Even COBOL was defined clearly in its ANSI limits IBM added a huge number of proprietary elements that made the complete source almost impossible to transform to another platform.

Other hardware makers like Siemens, RCA, Unisys, Bull, ICL etc. joined the marked sooner or later and came as well with proprietary add one’s. These proprietary products are now the Legacy we have to deal with.

Most of these “OLD” products are almost impossible to maintain so no documentation has been left, the people having created these products are long time in retirement or gone meanwhile.

For a fact is that a huge number of these products is pout there in the world wide market and still running. Especially in the actual market there is almost no one who can finance these developments and transformation.

To make this transformation easier we need:

Code analyzers to create some kind of documentation ( some are available on the market )
Transforming tools extracting from documentation into a basic version of Cobol
Optimizing the Basic version with a Source-Code generator to create a new platform neutral modernized solution.

Never Text in Source Code

Especially the Legacy Cobol programs showing text strings in the source. At that time there was hardly no other way to go.

When UNIX V was with MF Cobol the world changed for us.

Based on the frequent changes in the text , language , legal and other requirements , we never had a wording = text in the source.

we had :


01 Field1xxxxx ( element of the Data Dictionary ) .

02 Subfield Pic x(80).




At the moment the text was necessary what wording so ever it was called from a data base and moved into the Subfield by adjusted length.



What kind and size of text was necessary a key indicated. All text was stored in a text data base and each one had its own key. A browser helped finding the text and the key. This key was randomly inserted in the filekey of the source.



This technology avoided any dependency of source change regarding the text.



Heinz

Think you've got Class?

Ok, back to the class room boys and girls.

I told you about data types.  Now let's tie some of the Object Oriented terms back to what you might know as a COBOL programmer.

Let's talk class.

To begin I'll toss some big words out to make sure to sound important and all knowing:

Instantiation, polymorphism, inheritance, and ummm a few others I've forgotten over the years.

If you read the various OO books you'll find those words seem to be key to understanding what is a class and how to use it.

I beg to differ.  As you can probably guess, I'm more of a plain speaking kinda guy.

I think of a class as a master template containing prewritten routines you can use.

To use a class, you load a copy of this master template into memory and store that location into a uniquely named variable so you can reference it.

Now you have access to all of those prewritten routines which were in that template, just by referencing that variable you stored the location in.

Consider it a program you've already called and you have access to each paragraph or section in the program as a callable routine.
That's about all there is to it.

So, take another look at the routine Alex posted about 99 bottles of beer.

It is just a reuseable program with a bunch of subroutines.

We'll cover how to create an instance and call the methods in another post.

So, does this help clear it up a bit?

What are your thoughts on the subject?

What is Legacy?

Nice post Rick.

Thanks!

Hope everyone had a great Turkey day!

I ate too much *smile*

I have a question for you folks:

What is your definition of a legacy application?

Mine is rather simple... If it is being used by you or your company and can't be replaced with the click of a button or a simple keystroke, it is a legacy application.

The click of the button/ simple keystroke comment is the key I believe.  If it the application is so commoditized that you can switch from A to B to C with a mouse click or installing a different tool and it makes no difference, I wouldn't consider it a legacy application.  What is it then?  I would consider it merely a tool. 

Consider a 9/16" wrench.  Does it matter if it came from Sears or Lowe's or Home Depot?  Not really.  They all fit into your hand and allow you to loosen or tighten a 9/16" nut.  Now of course there are differences and everyone has their favorite (I personally use Craftsman).  But, in the end its just a wrench.

Now if you took a blow torch to that wrench and bent the handle in a U-shape so that it would allow you to adjust the front torsion bar on a 1965 Plymouth Fury, that is a legacy tool (I once had that car and the mechanic at the tire shop actually pulled his customized wrench out of his tool box and proudly told me why he customized it.  Seems you can't get to one of the bolts you need to reach to do a front end alignment on that particular car without a few choice cuss words or the properly modified wrench.  Anyway, you get my point I think.

Make sense?

So, if your application does something specific that can't be replaced, regardless of what it was written or where it came from, consider it a legacy application.

That's my opinion.

What's yours?

Amazing Grace!

No not the song... I'm of course referring to Adm. Grace Hopper. Quick: Do you know when the first and accurate COBOL compile took place? Bonus Points: On what machine? I'll answer this in a little bit but I first wanted to expand on Roberts' post about National Computer Science Education Week in America and Adm. Hopper.

If you haven't read a good book lately I have an excellent one to recommend. It's "Grace Hopper and the Invention of the Information Age" by Kurt W. Beyer. It was published in September 2009 and provides a fascinating review of Adm. Hoppers early years in technology, as well as the early years of technology. It's amazing to read about the early machines and the limitations they dealt with. Kurt Beyer has done an excellent job presenting the Admirals early years. While we always tend to remember the best things in our past, there are some things we tend to forget. Mr. Beyer reviews the Admirals years at the Hardvard Computational Labratory during the war years (that's World War 2) working under Dr. Howard Aiken (then Commander Aiken, as this was a Navy installation) and the wrok she did on the original Mark 1 computer. At the time the Mark 1 was a rather advanced piece of machinery. It was 3 feet wide, 51 feet long and wieghed 9,445 pounds! Definately not a laptop by any means. And it had electro-mechanical gates! Input was from paper tape and had no disk storage. Everything was read in from the tape. The Admiral was the person who in essecense perfected the operation of coding the machine and wrote the operations manual, which was in essence the first coding manual. She was instrumental in bringing not only the Mark1, but Mark 2 and Mark 3 to life.

Mr. Beyer's book further goes on to her life after leaving Harvard and some of the trials and tribulations she experienced. Her main goal in life was to expand the use of the computer to people who were not in the mathmatical field. You see at the time only people with a math degree were able to work on computers. Admiral Hopper had the unthinkable notion that computers could be used by people not in mathematics for say accounting, inventory, health care, anything that required gathering and processing large amounts of data. Imagine that, a computer for something other than math.

Mr. Beyer presents a wealth of information about the early years of the information age. He has also presented a significant amount of facts on why the Admiral deserves more recognition for her role, and the role of other women, who were the early pioneers in our field.

Winter is getting close and the snow isn't far away. Get ahold of this book, a nice warm cup of coffee or hot chocolate and enjoy! Oh, and the date of that first compile? It's in the book!

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!

Understanding COBOL for .Net Data Types

How many feel like maybe you must of drank those 99 bottles of beer?  Head spinning like a top?

COBOL?  That can't be COBOL code Alex posted.  Or is it?

My favorite email on Alex's post had a comment which I'm sure applies to many

"...if that is COBOL, I'm in deep !#$!"

Well, I have good news and bad news.  Good news is that it is COBOL. 

Or was that the bad news? *grin*

Never fear.  You too can read and write latin errr COBOL for .Net.  How you ask?

Well, let's start at what I consider the basics (some may argue), data types.

All of us are familiar with the syntax of defining COBOL variables using things like PIC X(11) and PIC S9(04) COMP, etc. For instance, defining a COBOL variable containing a string of text is as simple as:

01  WS-VAR1              PIC X(11) VALUE "HELLO WORLD".

More good news...  In the COBOL of today, this still works just fine.  However, to facilitate working in the .Net world, a few new data types have been added to the language.  I've listed them out below, along with their corresponding COBOL equivelant.

• binary-char  --->  PIC S9(2) COMP-5
• binary-char unsigned ---> PIC 9(2) COMP-5
• binary-short ---> PIC S9(4) COMP-5
• binary-short unsigned ---> PIC 9(4) COMP-5
• binary-long ---> PIC S9(9) COMP-5
• binary-long unsigned ---> PIC 9(9) COMP-5
• binary-double ---> PIC S9(18) COMP-5
• binary-double unsigned ---> PIC 9(18) COMP-5
• float-short ---> USAGE COMP-1
• float-long ---> USAGE COMP-2
• object ---> USAGE OBJECT REFERENCE  

So, when you see a line of code in a COBOL for .Net program which looks like this:

01  WS-VAR1 BINARY-SHORT.

You can translate it to what you are familiar with:

01  WS-VAR1  PIC S9(4) COMP-5.

Simple enough huh?  *smile*
 
I believe these new data types were created to help you and I make sure we move the data into the right field with the proper sizing already figured out.  I can recall quite a few times where I was trying to mix languages such as C and COBOL and having to manually write what I called a bridge routine to convert a C data type to fit into the appropriately defined COBOL variable.  With these new data types, the guesswork is taken out of it.  Working with a C# binary long field and need to call a COBOL program?  Not a problem.  Just use a COBOL variable defined like so:

01  WS-VAR1 BINARY-LONG.

and then call your COBOL program passing it the data from the C# routine to the COBOL program appropriately (Rick covers the how on some of his postings).

Ok, now for the twist...  There have also been a handful of new data types added which just didn't exist in the COBOL of yesteryear.  I've listed them below and their equivelent C# data type.
 

• character ---> char
• condition-value ---> bool
• decimal ---> decimal
• string ---> string

These "new" data types have some pretty interesting features which you will want to look at.  And believe it or not, I think you might find them handy.  First we will take a look at the COBOL data type of "character".  Character is for defining and storing a single character of data.  That's it.  Nothing more to it. 

But what if you need to define a string of characters?  Traditional COBOL would maybe have you put something like Character(11) or some such together.  That would require you to know how many characters you wished to store in the field.  So, toss that out.

In the COBOL for .Net world, you would use the data type "string" for storing text, that is, a number of characters. Just like in C#, a COBOL string is immutable (say that fast 5 times), which means that a string is never changed after it has been created. When using routines which change a string, the actual string is not changed - a new string is returned instead.

01  WS-VAR1  STRING

Several of you are probably thinking "But what about an internal table" and how does it work.  That is straight forward as well, probably even better than you would expect.  Take a look:

01 WS-ARRAY-OF-LONGS     BINARY-LONG OCCURS ANY.

This statement declares a table or array (a better description) of Binary-Longs, but notice the word ANY appearing at the end.  This allows the length/size of the array to be decided at runtime.


01 WS-ARRAY-OF-STRINGS   STRING OCCURS ANY.

Same thing with the statement above.  Cool stuff huh?

Next up, an item I think long over due,  the boolean variable type "condition-value".

01  WS-TRUE-FALSE-FLAG                 PIC X(01).

      88  WS-TRUE                                    VALUE "T".

      88  WS-FALSE                                  VALUE "F".

With the "condition-value" this same statement could be done a bit differently.

01  WS-TRUE-FALSE-FLAG   CONDITION-VALUE.

To reference WS-TRUE-FALSE-FLAG in your program you just check to see if it is True or False.

The "decimal" data type is interesting to me due to it's versatility.  How often have you needed to define a field in Working-Storage to hold a number, but did not know how large the value might be?  Some would probably claim "poor design" but what if the size could not be predicted?

By using a "decimal" data type, you are defining a 128 bit variable to represent values within the range 1E-28 to 7.9E+28.  I believe the decimal data type was specifically created to deal with decimal values when dealing with money.

There are of course several restrictions on the usage of these new data types that you'll need to read up on.  You can find out the real nitty gritty in this online documentation.

So, if you revisit the code sample that Alex provided, you'll see a couple of things which may make a bit more sense now.  At least in the variable declarations portions anyway.

We'll get more into the other items another day once this soaks in.  ;)

Any questions?

Doing The Waltz

What a great post on dancing COBOL. Here is some more COBOL dancing to build on the idea. Recursion, local scope, classes and beer all in the same program!

Thanks for the mention of the 99 bottle code Robert. I saw your post and thought I should raise the bar. I few comments on my post on 99 bottles (here) suggested that local variable scope, recursion and other cool stuff is missing from COBOL. Totally untrue! Here is a COBOL program which shows off the new 'quoteless' type syntax which we are working on and at the same time shows off a few of the OO features in the standard Micro Focus COBOL for .net product which is already out there:

      $set sourceformat(free)
     
   class-id. "Singer".

     method-id. "main" public static.
         procedure division.
         invoke type Singer::SayLine(by value 100)
     end method "main".
     
     method-id. "SayLine" public static.
     
        01 bottle-word     string.
        01 count-word      string.

        procedure division using by value bottles as binary-long.
            if bottles equals 0 then
                display "Go to the store and buy some more, 99 bottles of beer on the wall."
                goback
            end-if
            add -1 to bottles
               evaluate bottles
                   when 0
                       move "No"      to count-word
                       move "bottles" to bottle-word
                   when 1
                       move bottles   to count-word
                       move "bottle"  to bottle-word
                   when 2 thru 99
                       move bottles   to count-word
                       move "bottles" to bottle-word
               end-evaluate
              
               if bottles not equals 99 then
                   display "Take one down and pass it around, " count-word::"ToLower"()
                           " more " bottle-word " of beer on the wall."
               end-if
                          
               display count-word " " bottle-word
                   " of beer on the wall, " count-word::"ToLower"()
                   " " bottle-word " of beer."
                  
            invoke type Singer::SayLine(bottles)
        end method "SayLine".
        
      end class "Singer".

As you can see, this is a pure recursive implementation demonstrating the local scope of the method variables.

Making COBOL Dance!

Hey folks!

When was the last time you learned something new about COBOL?

Yesterday?  Last week?  A year?  Ten years ago?

A fair question that I believe every single developer should seriously consider.  I'm betting that the average COBOL developer hasn't spent much time learning "new" things about the language they have made their living supporting or writing.  However, you ask someone who is writing C#, Java or VB.Net applications and they will probably point to the three or four books on their desk which they refer to on a fairly regular basis.

Why is this?

Any professional in IT will tell you that the one thing that stays the same is the fact that technology continues to change.  And that to stay current or marketable in their role, they have to constantly expand their knowledgebase.

So, why is it that the typical COBOL developer seems to stick with the version of COBOL they learned in college?

I would like to issue a challenge to you.

I challenge you to learn COBOL, specifically object oriented COBOL and or COBOL.Net.

I can count on both hands the number of people I personally know who are proficient with this single most significant exstension to the language.   Ever since Grace found her first bug people have been making COBOL dance.  My question to you...

Learned any new steps lately?

You've seen the code sample Alex posted showing how to solve the 99 Bottles of Beer programming puzzle.  Pretty slick stuff huh?  Even remotely curious?  Could it be time to revisit COBOL and expand your knowledge?

Here is a very straight forward online tutorial on the subject to get you started.

Additionally, Rick Malek has been an avid poster of articles for years out on C# Corner which are intended for the C# developer to understand COBOL.Net.  Take a look at his examples for an introduction into some of the things you can do with COBOL and .Net above and beyond what you probably know today.

 "Ah, but Robert, there are only a handful of books on the subject...".  Yep.  I noticed that as well. 

Hmmm... I wonder how those other books got written?  Think they just copied what someone else wrote?  Nah, they dug into the subject material, made themselves experts, and then decided to put their knowledge down on paper.  Seems to me with the sheer number of COBOL developers out there, there could be a decent market for a new book or two.  Any aspiring authors out there?

Ok.  The challenge has been issued.  *grin*

Any questions?

99 Bottles Of Beer In COBOL for .net

Robert was kind enough to let me post to this great blog - here is my first effort!

By: Alex Turner

You may or may not know that there is a fabulous website dedicated to the song 99 bottles of beer. The idea being to show how to print out the lyrics to this song in as many languages as possible. Traditional COBOL is OK at this, but I have to admit - a bit clunky. So, our team at Micro Focus spent a few minutes showing just how clean an implementation in COBOL for .net (and for that matter other managed environments - but that is another store) can be.

Well, today my submission (though a team effort) got accepted, here is the link to the 99 bottles website:

http://www.99-bottles-of-beer.net/language-micro-focus-cobol-for-.net-2173.html

Also, here is a link to a post discussing the concepts and giving some tweaks:

http://nerds-central.blogspot.com/2009/09/cobol-for-net-better-than-c-at.html

COBOL and Twitter?

A buddy of mine, Mike Bleistein, has created a COBOL routine to post tweets out in Twitterville.  Check out the video he created of it out on YouTube.  Once he posts the code for it somewhere out on the web, I'll point you to it.

Cool stuff huh?

Where is COBOL being used today?

Through my job I get to see many different shops using various technologies in many different ways. It continues to amaze me how folks are using COBOL to run their business.

For instance, I've seen multiple shops using COBOL to process high volumes of payment transactions, medical claims, EDI transactions, loan approvals, shipping transactions, etc. But quite literally one of the "coolest" things I've seen was in a refrigerated warehouse.

The people in this sub zero degree environment have to wear cold weather gear, including gloves, and walk around pulling items from shelves for shipping. Their old process was to print out their pick list and begin going around the warehouse to fill up their bins. As they pulled the items, they would make notes on their paperwork as to quantities pulled, inventory counts, etc. Off and on came the gloves. It worked but it wasn't ideal.

Their IT department came up with a solution which allowed them to arm the warehouse workers with headsets and a handheld device. The handheld replaced their printouts and instead of writing, they spoke into the headset. Voice recognition software translated their responses and automatically updated the bill of lading, inventory quantities, etc by calling existing COBOL routines running on a backend server. The operators loved it and their efficiency went up exponentially. Slick stuff huh?

While the headsets and handheld devices were the new item in the mix, the fact they could tie into their existing COBOL applications saved them a ton of time and money to put this in place.

Another shop I visited did work with nuclear "things". I found in talking with them that the COBOL inventory management system was rather critical in determining what item sat on a shelf next to what item. If certain things were place incorrectly, it would result in a big flash of light and most of the eastern seaboard would go away. Talk about a high stress system to maintain! Imaging being the guy responsible for making a change to that COBOL application and then putting the changes into production. I'm thinking the old "I'll just test it in production approach" wasn't used much. *grin*

So, now your turn. What's the coolest thing you are doing or have you've seen someone do with COBOL?

COBOL: It's Everywhere

The plethora of anti-COBOL articles on the web has prompted me to write this article. I have heard for years that ‘COBOL is dying’ or ‘COBOL will be dead soon’ and yet here it is 20 years later and guess what, COBOL is still going strong! I’ve been coding COBOL since roughly 1991 and have met quite a few COBOL developers over the years. I am now working for Micro Focus, the leading Enterprise Application Management and Modernization Company with over 1500 employees worldwide. While our mission has expanded significantly since our birth in 1976, our roots are firmly in the COBOL environment.

I know that’s not what some of you may want to hear but it’s true. COBOL is still doing the heavy lifting of the business world and will continue to do so for many, many more years to come. (I’m betting well into my non-existent grandchildren’s careers!)I’d like to discuss in this article why COBOL has continually received a less than equal opportunity in the market-place: Lack of knowledge as to what COBOL is, has become and can do. I’d like to address these issues one at a time.

What COBOL is
COBOL was originally developed in 1959 by Admiral Grace Hopper for the Department of Defense. It was the first language developed that enabled a person to utilize a ‘normal’ language style to create applications to run on a computer. Prior to that assembly language was the prevalent language utilized. COBOL, as you may know is an acronym for COmmon Business Oriented Language, the emphasis being on business. It is utilized in every industry around the globe from telecommunications, banking, finance, manufacturing, government, aerospace, security, and many more too numerous to mention. Micro Focus asked one reporter to live for one day without using COBOL and it couldn’t be done. It is everywhere. So why then does it receive such a bad reputation if it’s so widely used? One would think the prevalence of COBOL would make it quite popular. One of the main reasons is the environment in which a COBOL developer has to operate in. The majority of COBOL is found on mainframe based systems (IBM, Fujitsu, Hitachi, and DEC) that have a simple character based user interface (UI). Costs to maintain these systems are usually quite high and priority is given to the applications running the company, not the developers creating or maintaining them. So to add to a less than robust UI we have low priority which translates into long times to edit, compile, and test programming changes. All this means developers get frustrated and start looking for something other than mainframe (COBOL) based development, but they take their frustrations with them when they leave thus spreading the word that COBOL is a dead-end or brain-dead world. Nothing however can be further from the truth.

What COBOL has become
COBOL has grown significantly. Do you know it is the only computer language that has evolved through multiple standards? Over the year the ANSI Committee has continued to expand and refine the language through several different standards and continues to improve the language to keep up with the growing technology.

Does C, C++ or Java have a standard that compiler vendors have to adhere to? I seem to recall a recent analyst's review of languages which listed COBOL as "stable and mature" while Java and a few others were actually considered to be in a declining state. That is a trend that continues to occur with many of the "popular" languages out there, but not COBOL. COBOL has grown to match the needs of the business and is one of the most portable languages around. A program compiled on a mainframe can be, if no machine specific instructions are included in the code, moved to a Windows, Unix or Linux platform, recompiled and utilized for what it was intended to.

COBOL has evolved into a multifaceted tool that could be utilized for a number of solutions from web to web-services to client-server applications. However COBOL was intended to process large amounts of data in an efficient manner (efficient in CPU, memory and storage usage). COBOL was not designed to manage a UI. While it has evolved into a graphically capable interface there are other languages such as C# or VB.NET that were designed specifically to create the users interface. Why not leave COBOL to do the heavy lifting of the transaction and provide the answers to the questions the application is meant to answer? After all, it is the original COBOL that was developed by a business analyst to answer a specific business problem. Let COBOL continue to perform the job it’s been doing along, helping companies be profitable.

What COBOL can do
Web Services, web sites, code-behind, XML data read and write, client-server applications, data transformation, .NET integration, Java integration, Visual Studio.NET, Eclipse, recursive calls, pointers, arrays, bit level data manipulation, write once run anywhere, WPF, WCF, ASP.NET, 32-bit and 64-bit, ActiveX, ADO.NET, Assemblies, Call the Windows API, CGI, COM, CORBA, DBCS, dynamic linking, file conversion, floating point, HTML, ISAPI, memory management, mouse manipulation, multi-threading, National Locale Support, Object Oriented, ODBC, OLE, parsing, spawn processes, SQL – DB2, Informix, ODBC, Oracle, SQL Server, Sybase, UDB, stored procedures, Unicode support, XML formatting and parsing to name a few.

Is there something not mentioned above? Let us know and we’ll probably be able to provide an example.

Dead?
A recent blog post I’ve seen claims COBOL is “…so very, very dead.” I think that is still 30 years away at least from being true. As long as smart decision makers look at the options and take the lowest risk, highest return approach by letting COBOL do the job for which is was intended (high volume processing of data to pay the bills and keep the world running), COBOL will be around a long time. Don’t bash it, don’t underestimate it. Embrace it and use it for what it was intended to do, getting high volume business processing done!

Happy Coding!

Guess I better introduce myself...

Now that I've posted a couple of items here I realized I haven't introduced myself. My apologies for the oversight. My name is Rick Malek and I'm a Solutions Engineer with Micro Focus and a COBOL bigot! I firmly believe COBOL has a very well deserved place in our world. It's been doing a lot of heavy lifting for years, long before Java, C# or VB were even dreamed of. Now don't get me wrong, COBOL isn't the answer for everything but it is the answer for a lot of things. I love to discuss or debate people who say a customer should throw out all their COBOL code and rewrite the application in a new "modern" language. My first question is always "Why?" What is the big technical advantage to rewriting an application to another language just to end up...wait for it... at the same spot you're in right now! Providing the same results but having now spent a lot of time and money you didn't really have to get to the same results only in a new language. It defies belief.

A little bit about me; I've spent the majority of my career migrating Mainframe Development Environments to the Windows Server platform. I specialized in the assessment of the mainframe development environments and designing and implementing unique client solutions to resolve specific issues related to client requirements. Starting from a core infrastructure and then adapting it to meet the specific client requirements has proven to provide a great deal of flexibility to the client while providing an industry standard development environment.

Along with designing and implementing the new environment I also spend a great deal of time designing, creating and delivering training sessions targeted at easing the transition for developers from the mainframe to the Windows Server system. The core essentials of development, source code management, database development and usage are demonstrated in the new environment. One of the key values developers obtain is the realization of the ability to not only maintain the core set of business values but the ability to quickly and easily expand these capabilities in a new, more efficient development environment.

I reside in Minot, North Dakota with my wife of 30+ years, Pennie and 3 children (Jason, Mathew and Ashley). All of my kids are in college and not one of them programs! I can't believe it. We have a nice ranch with 53 acres and horses that can be a bit of work, but also relaxing.

I encourage you to write about your experiences with COBOL. It's a great language with a solid future. I also encourage open and respectful debate. If you have an opinion or comment that disagrees with anything posted please feel free to post it. As long as it's respectful we'll be happy to discuss it!

Take care and Happy Coding!

Now that's what I'm talking about...

I post articles on another website dealing with COBOL and .NET interaction. One of the articles posted recently was how to call COBOL from C#, both procedural and object oriented. Someone asked me how would you call C# from COBOL? Well before I could respond to the question the person replied they figured it out! And they said it was quite simple and sent me the code to look at. The person did a great job, kept it simple and (here's one my pet-peeves) DOCUMENTED what was done!

So you see, there are others out there doing COBOL and making it work with Microsoft's languages. It's not difficult, just takes some figuring out the data translations. Bottom line, don't throw away your years of investment in COBOL just because it's COBOL! It can and does work fine (and most times better) in a distributed environment. Not convinced? Try it. I promise you won't be disappointed and will be pleasantly surprised.

Happy Coding!

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!