a companion discussion area for blog.codinghorror.com

COBOL: Everywhere and Nowhere


#141

Jeff,

Unfortunately you have fallen into the common trap of comparing bad COBOL with good C#. If you had written good COBOL using Micro Focus products it would look like this:

method-id. “button1_Click” private.
procedure division using by value sender as object e as
type “System.EventArgs”.
set button1::“PropTest” to "Call COBOL"
end method “button1_Click”.

Which has almost exactly the same number of syntactic elements as the C# version.

You have also chosen an example of something C# is very good at. How about something extremely useful and at which C# is not very good? How about writing large precision calculation software? This is the sort of thing that stock exchanges, banks and many other ‘heavy lifting’ applications have to do all the time. If COBOL is so clunky, show me how C# would do this (I think you will find you need a third party class library and a page of code to do what COBOL does in a few lines):

   program-id. Program1.

   01 a pic 9(30)v99.
   01 b pic 9(30)v99.
   01 d pic 9(30).99.
   01 i binary-long.
   procedure division.
    perform varying i from 0 by 1 until i equals 35
        compute a = a * 9 + i  / 91
        compute b = b * 9 + i  / 101                  
    end-perform
    move a to d
    display "First number   " d
    move b to d
    display "Second number  " d
    add a to b giving d
    display "Sum of the two " d
    
   end program Program1.

Not only is this a simple and clean implmentation, it will compile and run native on almost any major platform as well as .net.

The point being that one reason COBOL has been around for so long because it does what it does very well. Not only that, but modern versions of COBOL do everything else well in addition.

The next generation of COBOL from Micro Focus will be able to do even more with even fewer syntactic elements required and even more features C# and other similar languages lack.

Best wishes - AJ


#142

it’s probably not your opinion, but it’s more like comparing the iphone/every other phone with a straight forward oldschool calculator

what would you use to do some simple calcs?

cobol programs are often used in banks or companies like that

if you just have to put in a couple of numbers - and calculate them/or transfer them to other banks - which is actually pretty much what banks are doing - then cobol is far better than using a 4gl language


#143

This goes back to the root cause of all legacy software problems in my opinion “All software should have a shelf life”, “All software should come with an expiry date.”.


#144

80% of all code is COBOL? And to think it’s inventor didn’t even have a mustache - or did she?


#145

80% of all code is COBOL? And to think it’s inventor didn’t even have a mustache - or did she?


#146

“I have never, in my entire so-called “professional” programming career, met anyone who was actively writing COBOL code.”

There are many young ( you don’t believe though) people who are developing / supporting COBOL code, for the bank / corporations around the globe (not only North America but all over the world) – can be found in INDIA.

There are 174 job post for COBOL developer every day on local job website.
http://jobsearch.naukri.com


#147

Program1… I would be interested to know how well it compiles and runs in actual practice. My concern is that 936 should have at least 34 digits to the left of the decimal, and you only appear to have given space for 30. (The actual number will be higher than 936, of course, because of the variance introduced by ‘i’).

(I would also be curious about the bank that needs to measure decillions of anything, but hey, to each their obscurely large numbers, yes?)


#148

That last was directed at Alex Turner. Sorry.


#149

(I would also be curious about the bank that needs to measure decillions of anything, but hey, to each their obscurely large numbers, yes?)

I’m not Alex Turner, but I’ll reply anyways.

You must be joking. If you ever one day do development for a bank, you’ll quickly learn that precision at almost any scale is da holly grail.


#150

@Narayanaswami Vengaprasad Murthy

The people who are developing / supporting COBOL code in India or anywhere else are a product of necessity and not out of self-interest or enthusiasm.

Given a choice they will gladly accept a newer technology.


#151

The sample code you used to show COBOL code in .net is not typical for COBOL applciation , (NO GUI) .COBOL is used for modeling business and transaction. I worked in very large project using COBOL for 3 years, and I have been working with.NET as well recently.And I can guarantee you that working in businness transaction with .net is not compared to COBOL. COBOL seems to be more concise and more ATOMIC. I’ve experienced a situation where Green and black terminal are more usable and bug free than fancy gui with bunch of button.
(think command line vs GUI) I think more developper find command line more productive than GUI ,same apply to end users.


#152

Herb J: porting COBOL to C, way to go! From 1959 straight to the mid 70s!

Once your colleagues are done, I suggest Turbo Pascal.


#153

There. It is done.

I wrapped the entire cobol thing in a single web service. You just reference the sucker and off you go. cobol forever.


#154

Forget COBOL.NET, we now have “COBOL on Cogs” keeping the language alive and up with the latest programming trends.

http://www.coboloncogs.org


#155

Thomas,

The program compiles and runs just fine. The overflow characteristics of the calculation are defined. However, increasing the size of the fields to 9(32)v99 gives this result:

First number 04302298532283486384640958153141.48
Second number 00043457560850577111133950902536.17
Sum of the two 04345756093134063495774909055677.65

Now, as to who requires large numbers like this? The following COBOL uses large numbers to compute the geometric mean of 5 tax returns to five decimal places. I realise it is a bit artificial, but it proves the point that high accuracy numbers can be required quite easily.

   program-id. Program1.

   01 a pic 9(28)v99999 occurs 10.
   01 b pic 9(28)v99999.
   01 d pic 9(28).99999.
   01 i binary-long.
   procedure division.
    move  125621.23 to b
    *> generate some numbers - these would be from a data source
    *> in a real application
    perform varying i from 1 by 1 until i equals 5
        compute b = b * 1.11176
        move b to a(i)
    end-perform
       
    *> compute the geometric mean
    perform varying i from 1 by 1 until i equals 5
        multiply b by a(i) giving b
    end-perform

    move b to d
    display "Working variable " d
    compute b = b ** 0.2

    move b to d
    display "Geometric Mean   " d
    
   end program Program1.

Which gives:

Working variable 0137870017292352733686651403.77949
Geometric Mean 0000000000000000000000169002.82570

As with any example, this one can be attacked, however, I believe it to be illustrative.

All the best - AJ


#156

As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
“Beware of bugs in the above code; I have only proved it correct, not tried it”


#157

As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
“Beware of bugs in the above code; I have only proved it correct, not tried it”


#158

As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
“Beware of bugs in the above code; I have only proved it correct, not tried it”


#159

sorry :frowning:
Bad firefox.


#160

OK, no way am I reading 200+ comments, but I submit this:

Most of the COBOL workforce is retired, dead, or dying. There exists little to no interest in young Developers to go the COBOL route. Companies better start migrating, lest they find themselves in a pinch to find any COBOL people.

That said, the average salary for COBOL Developers (Sorry, “Programmers”) is poised for a steep hike in the next decade or so.