Sunday, January 31, 2010
Saving the Baby
I know why companies are abandoning COBOL.
"Why is this Robert?", you inquire. Well, have a seat there and let me e'splain.
As many already know, the most expensive item in the data center is usually the mainframe and everything that goes into keeping it alive and well, processing the millions of rows of data and transactions each week. If asked what sound most exemplifies their data center, the CIO probably wouldn't pick the sound of a Ferrari. Or the sound of an ever reliable diesel engine. Nope. Not even close.
It would most likely be the sound of a vacuum cleaner going full tilt trying to inhale that sock someone left under the edge of the couch. As far as the CFO is concerned, these environments suck the money right out of the company coffers. Keeping the big iron up and running requires some serious funds.
These “enterprise platforms” allow those same companies to realize the profits the shareholders care so much about. Without these enterprise class systems created around the mainframe platform, there would be no company. A catch-22 it would seem.
The problem is that many people confuse the platform with the systems which run on them. And the largest portion of these applications are written in COBOL. So, mainframe = bad and COBOL = mainframe. Then many confuse the two and come to the conclusion that COBOL = bad.
A common theme I've heard over the years is to replace the platform AND the applications. This is how folks like SAP acquired such a toe-hold in many corporations. They sold CIO's on the idea that to reduce costs in the long term you had to do both. Bang, that COBOL shop goes the way of the dodo.
But I have yet to hear about a single company who implemented SAP or any other package on time and under budget. How these packages keep getting sold as replacements to the tried and true COBOL applications is beyond me.
Others have been pitching that they can rewrite these massive processing engines in another language on a lower cost platform quickly. And the initial prototypes seem to indicate this can indeed be done quickly and at a low cost. An uninformed decision is made and another COBOL shop bites the dust.
On a rewrite, what usually ends up happening is that the first prototype works well, but when they start trying to build a complete system, reality sets in. Many find it is very hard to recreate something in the projected couple of months which took 20 years to write. Going with a package or rewriting everything costs more than most folks realize. But these aren't the only options and COBOL doesn't have to necessarily die to help cut costs.
Companies can swap out the platform without swapping out the applications. The COBOL, PL/1, CICS, DB2, IMS, JCL applications can run just fine on platforms such as Windows Server 2008 R2. No need to throw out the baby with the bath water! 20 years ago, you had little choice. Nowadays, companies have options.
You've seen some of the posts by Alex, Rick, and myself about the “new” capabilities of the environment. In my next few posts, I'll discuss some of the features which allow you to move your existing mainframe COBOL applications off without rewriting them. Let me know if there is something particular you want me to focus on. Stay tuned!
"Why is this Robert?", you inquire. Well, have a seat there and let me e'splain.
As many already know, the most expensive item in the data center is usually the mainframe and everything that goes into keeping it alive and well, processing the millions of rows of data and transactions each week. If asked what sound most exemplifies their data center, the CIO probably wouldn't pick the sound of a Ferrari. Or the sound of an ever reliable diesel engine. Nope. Not even close.
It would most likely be the sound of a vacuum cleaner going full tilt trying to inhale that sock someone left under the edge of the couch. As far as the CFO is concerned, these environments suck the money right out of the company coffers. Keeping the big iron up and running requires some serious funds.
These “enterprise platforms” allow those same companies to realize the profits the shareholders care so much about. Without these enterprise class systems created around the mainframe platform, there would be no company. A catch-22 it would seem.
The problem is that many people confuse the platform with the systems which run on them. And the largest portion of these applications are written in COBOL. So, mainframe = bad and COBOL = mainframe. Then many confuse the two and come to the conclusion that COBOL = bad.
A common theme I've heard over the years is to replace the platform AND the applications. This is how folks like SAP acquired such a toe-hold in many corporations. They sold CIO's on the idea that to reduce costs in the long term you had to do both. Bang, that COBOL shop goes the way of the dodo.
But I have yet to hear about a single company who implemented SAP or any other package on time and under budget. How these packages keep getting sold as replacements to the tried and true COBOL applications is beyond me.
Others have been pitching that they can rewrite these massive processing engines in another language on a lower cost platform quickly. And the initial prototypes seem to indicate this can indeed be done quickly and at a low cost. An uninformed decision is made and another COBOL shop bites the dust.
On a rewrite, what usually ends up happening is that the first prototype works well, but when they start trying to build a complete system, reality sets in. Many find it is very hard to recreate something in the projected couple of months which took 20 years to write. Going with a package or rewriting everything costs more than most folks realize. But these aren't the only options and COBOL doesn't have to necessarily die to help cut costs.
Companies can swap out the platform without swapping out the applications. The COBOL, PL/1, CICS, DB2, IMS, JCL applications can run just fine on platforms such as Windows Server 2008 R2. No need to throw out the baby with the bath water! 20 years ago, you had little choice. Nowadays, companies have options.
You've seen some of the posts by Alex, Rick, and myself about the “new” capabilities of the environment. In my next few posts, I'll discuss some of the features which allow you to move your existing mainframe COBOL applications off without rewriting them. Let me know if there is something particular you want me to focus on. Stay tuned!
Monday, January 18, 2010
Love COBOL - Then Shout About It
People don't search the web about COBOL much - why? Because few people publish anything about COBOL - let's fix this!
I have been busy posting to 'The Code Project' a few articles on COBOL over the last two months:
- Using Tuples to Synthesize Polyadic Returns in C# and COBOL
- A Comparison Of .net COBOL, Visual Basic and C#
- A SVN Browser Using Scraping and WinForms in COBOL for .NET
- Calling F# from COBOL and Back Again
- Anonymous Delegates In COBOL for .NET
The Code Project is a Windows centric community code site. The interesting thing is that (remember that these have only been up for a few weeks) these posts have attracted over 7000 (yes - seven thousand) views!
If you love COBOL, write posts. People are interested. Post them on blogs, post them on code sharing sites. Even send them to me and I will post them (for details - just comment on this post).
Friday, December 18, 2009
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.
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.
Thursday, December 17, 2009
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.
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
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
Sunday, December 6, 2009
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:
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?
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?
Tuesday, December 1, 2009
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?
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?
Thursday, November 19, 2009
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!
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!
Subscribe to:
Posts (Atom)




