-
Thursday, August 11, 2011
Object Oriented COBOL Fundamentals
Hey folks!
Trying to figure out how to transition from procedural COBOL to object oriented COBOL.
It's nowhere near as hard as folks make it out to be.
For those new to the site, check out some of the older posts for examples, etc.
Additionally, there are some really good recordings out on the Micro Focus Community site (http://community.microfocus.com/) that cover the basics of writing object oriented COBOL.
Check out http://tinyurl.com/3czefpm for the first video in the series.
You'll need to register for the site to see the video (don't sweat it...membership is free *smile*)
If you need a copy of Visual COBOL to try some of this out, you can download an eval copy at http://visualcobol.microfocus.com/
Enjoy!
Wednesday, July 20, 2011
COBOL Gets Noticed!
![]() |
| ©A.M.P.A.S.® |
Now that is a headline. *smile*
Sunday, June 12, 2011
The COBOL Challenge
What if I could show you how to take advantage of the COBOL you have today?
Regardless of whether you still have COBOL developers or not. I'm talking about me showing you how to take advantage of your COBOL even if you have long since decided to move away from COBOL and have moved on to .Net or Java.
If I give you free software, free training, and free international publicity, would you be interested in finding out if the COBOL still has value for your company?
"Tell us more Robert!", you say with open curiousity. (at least that is how the voices sound in my head)
I'm willing to offer up arranging for you to get temporary licenses of Micro Focus Visual COBOL, some training on the product, and maybe even some help doing the work, if you'll let me tell the world about it. You and your company can remain anonymous if need be, but I want the story...
COBOL is still the right tool for the job and I want to prove it to you.
I'm especially interested in working with someone in Georgia or Florida (where I spend my time nowadays), but will make this open to one and all.
Let's get creative!
Want to find out if you can mix C# with existing COBOL?
Want to transform traditional procedural COBOL into a bunch of objects?
Want to see if you can deploy COBOL to your JVM? Or try to tie your customer portal to your backend COBOL application? I'm game.
If you are interested, send me a note to robert.collins-at-microfocus.com
COBOL is more relevant today than it has ever been. And I can prove it.
![]() |
| (Buy this T-Shirt at Zazzle.com) |
Regardless of whether you still have COBOL developers or not. I'm talking about me showing you how to take advantage of your COBOL even if you have long since decided to move away from COBOL and have moved on to .Net or Java.
If I give you free software, free training, and free international publicity, would you be interested in finding out if the COBOL still has value for your company?
"Tell us more Robert!", you say with open curiousity. (at least that is how the voices sound in my head)
I'm willing to offer up arranging for you to get temporary licenses of Micro Focus Visual COBOL, some training on the product, and maybe even some help doing the work, if you'll let me tell the world about it. You and your company can remain anonymous if need be, but I want the story...
COBOL is still the right tool for the job and I want to prove it to you.
I'm especially interested in working with someone in Georgia or Florida (where I spend my time nowadays), but will make this open to one and all.
Let's get creative!
Want to find out if you can mix C# with existing COBOL?
Want to transform traditional procedural COBOL into a bunch of objects?
Want to see if you can deploy COBOL to your JVM? Or try to tie your customer portal to your backend COBOL application? I'm game.
If you are interested, send me a note to robert.collins-at-microfocus.com
COBOL is more relevant today than it has ever been. And I can prove it.
Wednesday, June 8, 2011
Are You Getting the Most Out of Your Tools?
I've posted a similar questions in the past. Once I asked my readers "who has learned something new about COBOL recently?". Very few people were able to raise their hand.
The reality is that most people learn how to do something one way and continue to do it that way from then on. And in many areas of life, this makes sense. No need to reinvent the wheel.
Hence my question in the title: Are you getting the most out of your tools?
The tools have advanced, the COBOL language has advanced, but have your developers?
I met with a company today who uses Micro Focus Net Express, the pre-cursor to Visual COBOL. After just a few minutes of conversation, I was able to point out some features in the tools they already own that may save their development team significant time and aggrevation.
I offered to have Jim, my code slinging partner in crime, come by and take a look at what they do and how they are doing it. I did this with the idea that maybe we can show them a thing or two about using Net Express which could make life easier.
It might be worth revisiting what you can do with the COBOL of today. Thanks to tools like Visual COBOL I think you may find some extra money in the bottom of the box the tools came in. I'm just sayin...
The reality is that most people learn how to do something one way and continue to do it that way from then on. And in many areas of life, this makes sense. No need to reinvent the wheel.
Hence my question in the title: Are you getting the most out of your tools?
The tools have advanced, the COBOL language has advanced, but have your developers?
I met with a company today who uses Micro Focus Net Express, the pre-cursor to Visual COBOL. After just a few minutes of conversation, I was able to point out some features in the tools they already own that may save their development team significant time and aggrevation.
I offered to have Jim, my code slinging partner in crime, come by and take a look at what they do and how they are doing it. I did this with the idea that maybe we can show them a thing or two about using Net Express which could make life easier.
It might be worth revisiting what you can do with the COBOL of today. Thanks to tools like Visual COBOL I think you may find some extra money in the bottom of the box the tools came in. I'm just sayin...
Tuesday, June 7, 2011
Why Build a Reference Environment?
If you are selling cars, it is as simple as "why don't we take her out for a spin?" to show off the car. When talking about changing the way things will work, it's not that simple. Folks don't just want to see a simple demo. Oh, they do expect you to make it look simple, but what you focus on can't be the easy stuff.
For instance, its simple to demonstrate executing a COBOL program via a CICS transaction. That's core to what our company does. But when a customer wants to see things like "interfacing with a scheduler" and "managing our printers" and "how will operators will manage the platform", you have to have something a bit more robust. Otherwise you end up doing endless proof of concept (POC) projects to move things along.
A reference environment lets you demonstrate how the end result will look without having to say "I'll get back to you" or "there are a number of ways that might work". It allows your customer to focus on the "how do I take advantage of this?" versus "will it work?". Think of it as a pre-fab POC you can use over and over.
Its why I've been building one for the last few months...(read more here). Keep this in mind when you try to sell the boss on the idea of turning that COBOL application into the next killer app based on web services and the .NET framework. He'll be more inclined to consider it if you have an example.
For instance, its simple to demonstrate executing a COBOL program via a CICS transaction. That's core to what our company does. But when a customer wants to see things like "interfacing with a scheduler" and "managing our printers" and "how will operators will manage the platform", you have to have something a bit more robust. Otherwise you end up doing endless proof of concept (POC) projects to move things along.
A reference environment lets you demonstrate how the end result will look without having to say "I'll get back to you" or "there are a number of ways that might work". It allows your customer to focus on the "how do I take advantage of this?" versus "will it work?". Think of it as a pre-fab POC you can use over and over.
Its why I've been building one for the last few months...(read more here). Keep this in mind when you try to sell the boss on the idea of turning that COBOL application into the next killer app based on web services and the .NET framework. He'll be more inclined to consider it if you have an example.
Monday, May 30, 2011
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?
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?
Tuesday, May 24, 2011
COBOL Didn't Blink...The Development Environment Did
Why does COBOL wear the black eye that it has been proudly wearing since the 70's?
It is because the most common development environment people associate with COBOL is the green screen ISPF mainframe editor. Yuck! It is still what many COBOL developers use today.
Micro Focus did make in-roads into many companies during the past 30 years, but the majority of COBOL developers are still stuck on character-based interfaces developing application code.
No one really wants to use those tools. Go figure. Who'd want to pet an ugly dog? Not me. *smile*
I personally believe this is the reason that COBOL fell out of favor with the "up and coming" development world that has evolved during the last couple of decades.
The good news is there are options which allow companies to bring all of that application source forward into the same world C# and Java developers live in.
Today you have options. Developers can use a single IDE such as Visual Studio or Eclipse and do what needs to be done. Today's developers are no longer tied to a specific language. They can use what makes sense for the task at hand, mixing a bit of the old and new with no issues.
It isn't the language that caused the blip in usage, it was the development environment.
Good news is that this has changed with Visual COBOL. I believe COBOL will be the language of the decade for companies looking for flexibility. Hide and watch.
It is because the most common development environment people associate with COBOL is the green screen ISPF mainframe editor. Yuck! It is still what many COBOL developers use today.
Micro Focus did make in-roads into many companies during the past 30 years, but the majority of COBOL developers are still stuck on character-based interfaces developing application code.
No one really wants to use those tools. Go figure. Who'd want to pet an ugly dog? Not me. *smile*
I personally believe this is the reason that COBOL fell out of favor with the "up and coming" development world that has evolved during the last couple of decades.
The good news is there are options which allow companies to bring all of that application source forward into the same world C# and Java developers live in.
- COBOL that runs on the mainframe? Duh.
- COBOL and C# in the same application? Sure thing.
- COBOL and Java living together in perfect harmony? Yep.
- COBOL and VB.NET side by side? Why not?
- COBOL as managed source (.NET or JVM)? But of course.
- COBOL in the Cloud (Azure, Amazon, etc) Yes it runs in the Cloud!
Today you have options. Developers can use a single IDE such as Visual Studio or Eclipse and do what needs to be done. Today's developers are no longer tied to a specific language. They can use what makes sense for the task at hand, mixing a bit of the old and new with no issues.
It isn't the language that caused the blip in usage, it was the development environment.
Good news is that this has changed with Visual COBOL. I believe COBOL will be the language of the decade for companies looking for flexibility. Hide and watch.
![]() |
| This is why I don't take them to Walmart |
Subscribe to:
Posts (Atom)






