A Major Lesson from Fortran IV

Fortran? Why talk about Fortran on a Cobol blog!

Well, just to pass on a little experience before it’s too late.

In the late 1970s I began selling Dec PDP11-03s through my small software business. These minicomputers, the size of a three drawer filing cabinet, had floppy drives taking 8” diskettes holding a “massive” 256kb of data, a visual display screen and a keyboard. A 30 character per second “line printer” was an optional extra. They were the first proper computers to be practical and affordable by small businesses and the only programming language available was Fortran IV.

My peers laughed at my crazy idea of programming business and commercial applications in Fortran. “You can’t do that, it’s a scientific language” were among the printable comments. But I was impressed by the speed of the compiled code, many times faster than the Basic used by the Wang computers I had worked on previously. So I got down to work.

I found Fortran allowed me to use subroutines. So I could write and compile utility routines with parameter driven input and output. Once written and tested, these routines could be “called” by any other routine. So I slowly developed a sizeable library of routines to handle everything from outputting a single character to a fixed point on a screen to a complete report generator.

After a while, I could develop new applications at lightning speed by using my library of generic subroutines while coding errors and testing time greatly decreased, improving the viability of my business.

So what has all this to do with Cobol?

Now, almost thirty years after my Fortran days, many Cobol programs are still being written from scratch with the only concession to efficiency being a little copying and pasting in an editor. The reasons are almost too many to mention but include the dreaded “screen section” coding which often varies from machine to machine and compiler to compiler and Cobol’s own self-documenting ability which encourages the use of unique data names in every program and suite.

But there is a better way. Much better!

When I first started using sp2 and FormPrint from Flexus (read all about this at www.cobol.tv) I realised that this great software enabled Cobol to be completely divorced from both input and output functions. I could therefore “think Fortran” and write generic code. Routines to handle file management, listing and other repetitive tasks could be written once and used again and again in any application. Using the ability of the Flexus software to quickly create and generate screen layouts, validations and reports, software suites can be quickly assembled using a very high percentage of tried and tested generic cobol.

So thank you to Fortran in the past and Flexus now and in the future for making Cobol my rapid development tool.