I think not.
I believe it has to do with the combination of syntax and methodology. Let's face it, Object Oriented Cobol syntax from the 2002 standard is confusing. Too many quote characters cluttering things up is my opinion. Additionally, to use it, there was this object oriented approach to program design we were supposed to learn. And because we had to learn a new language and we were coming from a procedural-based frame of reference, it stumped us. I think we were trying to learn too many new things at once.
*cue creepy music*
I have a secret...For the last couple of weeks, I've been working secretly in my lab deep beneath the dungeon cooking something up.
I have been working to come to grips with...
Dare I say it...Cobol.Net and ASP.Net. *gasp*
(Ok, I was in my home office in the basement. Anyway, back to the story)
I bought a book by Imar Spannjaars titled "Beginning ASP.NET 4 in C# and VB", and I had this thought... I wondered if I could translate what Imar was trying to teach the VB and C# crowd into Cobol.Net syntax. Guess what? You can. *smile*
First off, I've discovered that the new syntax the Micro Focus development guys have put together has made it easier for me to translate from VB.Net to the Cobol.Net.
And you want to know what else I found? The Object oriented approach started to make more sense. Not just basic sense but the kind of common sense you hope your teenage son finally gets before he graduates college (I keep my fingers crossed).
I found that for the most part I only had to grasp a handful of concepts and I could write slick web-based ASP.Net applications using Cobol.Net.
Basically it comes down to the new data types I've mentioned in earlier posts and two "new" statements, Set and Invoke. For instance, here is how you use the Set statement.
Translation:
If the HasFile field of the FileUpload1 control on the current web page is true (think of it as an 88 level switch), set ws-filename to the value stored in the FileName field of the FileUpload1 control on the current web page. If it doesn't, set the text of the UloadSuccessMessage object to "No File Selected. Unable to Upload" and make it visibile to the user.
And guess what? Invoke isn't much different.
call the Redirect routine of the Response "program" that is tied to the current web application and pass it the URL of "Default.aspx?Redirect".
Based on this rather amazing revelation (amazing to me anyways), I've come to the conclusion that yes Cobol programmers can make the leap.
It isn't really that much of a leap actually, but more like a series of small steps.
Additionally, I believe that C# and VB folks can understand the basics of this new version of the Cobol.Net syntax.
In the near future, I hope to post the complete source for the web application I've been building and you can see for yourself what I'm talking about. This stuff ain't rocket science.
Just in case you didn't notice, you too can give this a try. Download a copy of Visual Cobol for your home machine for 30 days (www.microfocus.com/visualcobol) and give it a shot. Can't figure out how to do something? Maybe we can figure it out together. Consider it a learning experience *grin*
Posts
Robert,
ReplyDeleteAs always - an excellent post. I would suggest that maybe, just maybe calling 'set' a new statement is being a little economical with the truth.
set my-pointer to address of my-group
set my-pointer up by length of my-group
etc...
Regarding "Additionally, I believe that C# and VB folks can understand the basics of this new version of the Cobol.Net syntax."
Yes - I have found graduates and interns with zero COBOL knowledge pick OO syntax up in 1 to 2 days. Using the COBOL community search engine http://www.nerds-central.com/Search/MicroFocusCOBOL.html helps fill in the gaps from there.
Best wishes - AJ
Thanks Alex. I did put new in quotes you know. *grin*
ReplyDeleteYou are right though. Set isn't really new. Maybe a better statement would have been "new use for the set statement". What do you think?
Well, duh! This just confirms my belief that if you can code, you can code. Doesn't matter what language, or the logic flow. Thank you!
ReplyDeleteI agree with the above, but there is a distinction. If you CAN code, the above is right, if you just can code, the above does not apply. Many years ago I tried to register to one of MF OO COBOL courses. None of them ran due to lack of participants.
ReplyDeleteMany COBOL programmers are simply coding clerks who wish do do their 9-5 tasks and nothing more. Only a few are computer freaks, who like to learn and solve new issues, and almost none of them have COBOL as their mother tongue.
well and now the million dollar question ... what is it good for?
ReplyDeleteFinding a good cobol programmer under the age of 45 is difficult enough. So why let these dino's do the job that thousands of angry young man love to do in modern programming languages. And if you need the old proven Cobol business logic in your web applications, modernize your Cobol apps to Services accessible for all these modern OO languages. Cobol is great for business logic and Data, presentation has never been a strong feature of Cobol so dont try to improve on that weakness, use its unsurpassed stability.
Reg, Cobol programmers under 45 are more common than you'd think. *smile* I'm below that mark easily.
ReplyDeleteTo your other point, the way what I've been working with works, you do the front end in ASP.Net and the server side code is in Cobol.Net. Using the right tool for the job is the key. And the server side code in Cobol makes tons of sense. You are more likely to replace how you present the information to the users than you are the business logic you use to run your shop.
With .NET and other UI technologies, the language doesn't matter or is becoming less and less important. Presentation has less and less to do with a language. OO COBOL when it first came out was seriously missing a strong class library or framework of classes. .NET provides that. C#, VB, and Visual COBOL all are just using the designer tools and .NET framework classes for the UI. Micro Focus has done a fabulous job of making COBOL a .NET language over the last 7 years. Oh, by the way you can still use the COBOL CALL statement to call existing critical business logic that can be recompiled as managed code.
ReplyDelete