10 Things I Hate About You, COBOL

Actually, I don't hate COBOL. I just couldn't resist the blog title. But there are some things about it that I find annoying.

1. All Variables are Global

Global variables make it difficult to track down bugs; when a variable can be changed at any point in the code it's hard to tell what happened. In COBOL, every variable is a global variable.

2. No Parameter Passing

In most languages, you can pass parameters to subroutines. But you can't do that in COBOL. So how do you move data to a subroutine for processing in COBOL? You put it in … global variables.

3. No Returning Values

Just like you can’t pass values to a subroutine, you can’t return values from one either. You can, however, store the results in…global variables.

4. Verbosity

They say it was designed so non-technical people could read it. Problem is, non-technical people don't read it.
I've worked in three shops that used COBOL. None of them had non-programmers looking over COBOL code. So, to make things easier for these people, they made it harder for programmers. They optimized for the wrong user.

5. PERFORM is overloaded

The same keyword used to call a subroutine is also used to create a Loop.

6. Working Storage

All variables in a COBOL program are declared in the WORKING-STORAGE section. So, when you're working on a piece of code and need to see how a variable is declared you have to go to the working storage section, find it, and then go back to your code. This becomes a time-consuming process. Especially with large programs that have hundreds of variables.

7. Levels

Levels end up allowing multiple variables to point to the same piece of data. Changing one changes the others. While this can be helpful, it makes it difficult to track down bugs.

8. String Handling

Not having a variable length string type makes it hard to work with strings in COBOL.

9. Ending IF Statements with Periods

COBOL 85 added END-IF, but I still run into a lot of code that uses periods. This is especially annoying when there is a large block of code with multiple IF statements.

10. NEXT SENTENCE and CONTINUE

I find it hard to figure out where a NEXT SENTENCE or CONTINUE will send control - especially inside of IF statements that use periods.

Comments

Post a Comment

Popular posts from this blog

Restoring Color Icons in Gimp 2.10

Image
When Gimp 2.10 was released, the new icons for the toolbox items were all black and white. If, like me, you'd like to go back to the color versions, here's how:  Select Edit --> Preferences From the Preferences dialog, under the Interface section, select Icon Theme For the icon theme, select Legacy if you want icons like they were in 2.8.  If you'd like color versions of the new icons, select the icon theme named  Color . 
Read more

PowerBuilder and SQL Server: Tips On Working Together

I recently worked on a project that used PowerBuilder for the front end and SQL Server for the database. I've worked with both of these technologies in the past but this was the first time I used them together. Below are some notes about the things that I learned regarding PB and SQL Server working together. Single Quoted Strings If you do any work with SQL statements in SQL Server Management Studio (SSMS), you'll find that SQL Server only accepts strings if they are surrounded by single quotes. You can use double quotes in the PowerBuilder painters and they'll get translated properly on their way to SQL Server. But you may want to just go ahead and use single quotes everywhere, especially if you are trying to track down a problem by copying SQL from PowerBuilder and pasting it into SSMS. Identity Columns One of my tables had its primary key set in SQL Server to autoincrement. In my datawindow I would insert a row and then do an update. I was expecting the value SQL Server ...
Read more

A tip on multithreading in PowerBuilder

The way you do multithreading in PowerBuilder is to create an object that contains the code you want to run in another thread. You then create an instance of this object as a “shared object”. You also code another object – the “interface object” and pass the shared object a reference to it. You can then call functions on the shared object and have them run in the other thread. The shared object communicates back to the main thread via the interface object. The other day I set up a program using a shared object. I had a shared object that was running some code asynchronously. When it was done, it called a function on the interface object and the interface object called a function in my window to let me know it was complete (by setting a variable). At one point I needed to wait until the shared object was done with its processing before I continued what I was doing in the main thread. I had it coded something like this: Integer li_status Li_status = wf_get_status() Do while li_status = ...
Read more