Search This Blog

Wednesday, December 14, 2011

Visual COBOL Now Supports Dialog System Applications

Once upon a time, Micro Focus introduced a slick little piece of technology known as Dialog System.  Its purpose in life was to allow the COBOL developer the ability to build nice looking user interfaces.  In its day, there was nothing better.  Thousands of applications were built using the tooling and everyone was happy.

Then along comes .NET and what was once "leading edge" soon became somewhat obsolete.  But those that build applications using Dialog System were left hanging. 

What do you do with these applications? 

If you are the application owner, reworking them as WinForms or Web Forms was a manual effort at best.  If you are the CIO, having your team completely rewrite these applications just because you wanted a slicker UI was often more work than could be justified.  And Micro Focus hasn't had much of an answer for converting these applications either. 

That is up until now...

With the latest release of Visual COBOL R4 Update 2, Micro Focus is providing tooling to allow you to continue to work with your Dialog System applications or begin the process of converting them to something else.

Yes, its true!  You can either keep them "as is" and continue to support them or you can begin to modernize your user interfaces as it makes sense.  With this new release, there is no longer a need for an "all or nothing" approach. You can either start taking advantage of .NET elements within the existing Dialog System application interface or you can begin moving completely out of Dialog System.

For instance, you want to introduce WPF into your Dialog System application?  Go for it.  You want to drop a .NET grid control into you interface?  Not a problem. 

So, if your shop has an application written using Micro Focus Dialog System screens, you now have options.

For more information, check out the online docs here

Enjoy!

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!

Sunday, June 12, 2011

The COBOL Challenge


(Buy this T-Shirt at Zazzle.com)
 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.

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...

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.

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?

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. 

  • 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!
(COBOL is the only language that does all of these things.  I bet you can't prove me wrong.)

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

Thursday, May 5, 2011

More Performance!

I was just informed that the upcoming webinar on May 11th being hosted by Micro Focus will be focused on COBOL and performance. And that Alex Turner will be doing the session.

Set your VCR's to record!!!! (ok, truthfully... how many of you still have VCR's? Show of hands. Uh huh. That's what I figured. And they still all blink 12:00 a.m. don't they? *grin*).

To sign up for the session, click here.

May 11th is also my mother's birthday. Happy B-day Ma!!!!

I got you a cake!

Friday, March 25, 2011

COBOL and Speed: A perfect combination

I've been asked a few times in the past if I had any suggestions for "best practices" or "how to write the fastest code possible" when coding COBOL. And I'm almost always stumped for an answer that is beyond one or two sentences.

Well, I'm now in luck.

One of the developers at Micro Focus has posted an article on the community website (http://community.microfocus.com) which covers this very topic.

You can find the article at http://community.microfocus.com/library/articles/84_Coding_for_speed_size_and_portability

In his article, you'll find some pretty good tidbits which will have your code screaming along in record fashion in no time.

Which brings a question to mind...

How often do you review your application source to see if you can make it better? Once in awhile? Never? Only when it breaks?

I once had a programmer who worked for me dig into a rather complex piece of long running code (sometimes upwards of 20 hours). He was able to rewrite the routine and reduce the clock time to less than three minutes on average. No I didn't write it originally *smile*. But it goes to show you that you shouldn't overlook doing a review of the source once in awhile to see if there is a better way to do things now that you are older and wiser.

Just a thought!

See ya.

Monday, March 14, 2011

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*

Tuesday, February 1, 2011

It's All About Community

Micro Focus has recently launched a new community site for those who use the many different tools the company produces.  For those that haven't visited as of yet, click on community.microfocus.com and take a look.  You'll find forums, blogs and articles dedicated to each product area, not just COBOL.

For instance, there are sections on DevPartner, Silk, and i.Sight (Modernization Workbench) and so on and so forth.  Of course the COBOL sections are the best, but then again maybe I'm biased in some way :).

While still in its infancy, I believe it has potential to turn into something rather useful.  I would like to encourage you to post on the site and share your ideas/questions, etc.  I'm a firm believer that you'll only get something out of it if you put something in to it.  Yeah, I said that. *smile*

I've already found a pretty interesting post on the site showing how to do a mail merge using Visual COBOL and Microsoft Word.  Pretty slick stuff and something I've often wanted to do myself.  I wonder what else someone will post?  I'll just have to keep checking back huh? *wink*

Oh well, lunch break is over.  Gotta get back to it.

See ya!