C# Expert Makes COBOL.Net Scream

This week I'm spending time working with a C# expert on a COBOL modernization project.  What's interesting is that this individual is using his knowledge of C# to re-architect an existing COBOL application, and the results will still be COBOL. 

While I'm admittedly a novice on the ins and outs of .Net, he's extremely strong in both the framework and object oriented design.  Combine his know-how and a basic education on COBOL.Net and in less than two weeks, we've converted the application front end to Winforms and tied it to the existing COBOL business logic.

Why is this interesting?

This proves that your company can give your COBOL developers and your .Net developers a tool like Micro Focus Visual COBOL, a week of basic education on COBOL.Net and ...

TA-DA!

You can get the best of both worlds.  You get a group who knows both Microsoft .Net and COBOL who now have the basic ingredients to begin modifying your COBOL applications to fit your current corporate IT direction.  Comingle the groups and the technologies and you'll get several things:

• A brand new application based on tried and true application source leveraging an industry standard framework.
• A energized team of people educated in both your mission critical applications and the framework you've adopted as your corporate direction.

And the team will really enjoy doing it.

Huh?

Yep.  I've seen it this week.  People who want to be involved are stopping by every single day asking for details and wanting to know how they can help.  This includes folks from both sides of the development shop!  Those already on the team are having fun doing something they never thought could be done.

It's true.  Put developers to work breathing life into these systems and they will enjoy the work.  Developers like a challenge and cool tools.  Both sides of the team will become immersed in learning their parts of this "new world" and the religious battle about languages will become secondary to the mission.  Each group will use the tools and language that meet their particular needs and you will get an application which is based on the tried and true applications which have been running your business.

Don't believe me?  Give it a test drive.  Put your own team together, mixing folks from both sides of the fence and give them the basic goal of bringing an existing COBOL application forward to the .Net world.  Add in some education / guidance and see what happens.  Let me know the results!

ASP.Net, ADO.Net and COBOL - The Right Tools for the Job

Hey folks,

In working on learning how to write a web application using COBOL, I thought it would be interesting to understand how to retrieve a BLOB (binary large object) using ADO.Net and display it back to the user.

So, armed with a downloaded copy of the AdventureWorks database from Microsoft's website, I set about to create an ASP.Net page and its corresponding "code behind" page (out of COBOL of course) to do just that. 

First off, you'll see from the ASP.Net page in the image above that I'm populating a drop down list box with data from one of the tables in the database.  Once the user selects a row from the list, the code behind page launches the "Fetch_ProductImage" method defined within my COBOL program (to see the complete images you may have to click on them to make them full screen).

The image above shows the various objects I had to define using some of the "new" data types I mentioned in an earlier post to this site.  Addittionally, you'll see that I define objects based on the ADO.Net class.  How I use them is shown below in the  method "Fetch_ProductImage".  This is used to grab the image stored within the BLOB field for the selected item:

Once selected the image is displayed to the user via the web browser.  Pretty slick huh?

It's much like using cursors with traditional SQL, with many of the same steps.  In traditional SQL, you define the cursor, open the cursor, read the row(s), then close the cursor.  Similar thing with the data reader.  You define the statement you wish to execute against the table, open the data reader, load the data reader with the rows you wanted, read the row(s) from the data reader, close the connection.  Very similar processes.

One interesting difference I've found is that with a data reader, the rows are stored as "read only".  With traditional SQL you can choose to update the rows contained within the cursor.  But within a data reader, the data can't be modified.  And as I believe is true with a cursor, you can only read forward with the data reader.  Once you have read the row, the previous row is no longer available to you.

There are several other interesting things you can do with ADO.Net.  Just to give you an idea... Everything above was based on examples in the first 50 pages from a 585 book I bought on ADO.Net.  Yes it was written for a VB.Net developer, but I was able to translate it from gibberish into COBOL easily enough *grin*.

Overall it wasn't too difficult. Yes, I know I didn't go into details on how to do all the steps involved with the web form portion of this.  That was because I figure that was the easier part and you too can pick that up from a good book on building ASP.Net web pages.  As I mentioned in a previous post, I've been working from Imar's book "Beginning ASP.Net 4 in C# and VB".  As to the rest, it is all shown above in the COBOL example.  There's surprisingly not that much to it huh?

I hope this was of value for you.   Drop me a note if you have any questions or comments.  I'd love to hear from you!