Programs - Fortran

Survival of the Fittest?

Fortran and Cobol – no accident that they were the brain-children of 'single parents', creative individuals (John Backus and Grace Hopper respectively) rather than committees or project design teams. Please see the following links

https://en.wikipedia.org/wiki/Fortran
https://en.wikipedia.org/wiki/COBOL

(In the same vein, we can reflect that the epochal IBM 360 and Cray operating systems were conceived by lone geniuses, Gene Amdahl and the eponymous Seymour the Tunnel Digger respectively.)

The lower-case of Fortran in the first link indicates that Fortran has made the cut, and is still with us. The upper-case of COBOL indicates that it hasn't and isn't.

Why was this?

Look at ADA, Algol, Pascal, PL1 – highly-sophisticated languages that were once expected to carry all before them: one is tempted to say they've come, they've gone, but some of them are admittedly still around – nevertheless they are hardly household names any longer.

And report generators were supposed to make commercial programming languages obsolete, but they were Procrustean beds into which every system specification had to be tortured by lopping or stretching, hammers looking for a nail. Their principal attraction was to DP managers hoping to make their programming staff redundant.

This is not to claim that COBOL (or Fortran, for that matter) were by any means perfect. It was all too easy to write the most appalling programs, incomprehensible even to their authors after a few months had elapsed (reminding us of the poet Browning who when asked the meaning of a particular passage of verse said that when he had written it, both he and God knew its meaning, but by now only God knew).

The demise of COBOL was IMHO a tragedy. Its data-structured architecture was unsurpassed by any other language that I encountered. My one-time employers spent a fortune in the late 1970's and early 80's developing a version that would sit comfortably on desk-top computers of any kind, but were overtaken by the IBM PC and very nearly went to the wall. What an enormous shame that no mainstream software providers took up the challenge of producing a true PC Cobol, a Visual Cobol to which mainframe COBOL applications could have been migrated cleanly.

Visual Basic, the apparent successor to COBOL on the PC, was only fit for the most trivial and relatively menial applications. It was entirely inadequate for anything remotely mission-critical. It was no good for scientific, engineering or commercial applications, and was only really suited for interfacing other applications. Even then its bizarre flakiness could lead programmers such as myself to despair. Undocumented side-effects between various features led frequently to undiagnosable run-time errors, fury and waste of time. But it was widely used (and maybe still is in its new guise of VB.NET).

So there's no apparent rhyme or reason as to why some languages succumb whilst others flourish. Despite confident predictions over the past few decades of its imminent demise, Fortran is still with us, and my money is on Fortran to last for another quarter-century at the very least.

So Why Fortran?

For me and millions of other Fortran users world-wide since the mid-1960's, the great appeals are simplicity and transparency – you don't have to get your head round sophisticated programming concepts before you get started, you don't need to know a great many tricks of the trade, and what you see is what you get – there aren't a whole lot of special tricks going on behind the curtain.

And if you want to implement mathematical algorithms that's just fine – it does what it says on the box: 'Formula Translation'. Obviously there have been some major improvements down the years and I'd choose 'IF-THEN-ELSE' statements and state-of-the art character-string handling as the two greatest game-changers.

For about the last 15 years before retirement I was working exclusively on the migration of mainframe legacy programs onto PC, using a mix of Fortran, Visual Basic and Excel or Access VBA. Mostly very enjoyable and a constant learning curve. In turn, I encountered Microsoft Fortran, Lahey Fortran, Digital Visual Fortran and its badge-engineered successor Compaq Visual Fortran. Without doubt, for me, the Digital/Compaq Visual Fortran was clearly out in front, though I didn't have any time for the Microsoft Visual Studio with which it was encumbered, and evolved a very effective methodology of command-line usage instead.

After retirement, when I decided to revisit the Fortran-based computational projects of 1967/76, I googled around for Compaq Visual Fortran, but it had vanished from the face of the earth. You couldn't even get it off eBay. I did try a free download of the Silverfrost (Salford University) FTN95, but just couldn't get it to work at all, not a spark of life. Obviously more my fault than theirs.

Polyhedron Software Ltd evidently marketed the widest range of Fortran compilers, and so I decided to take their advice that Intel Visual Fortran had evolved from the Compaq product and was the one to go for. Plus they provided a month's free trial! And so that's what I'm now using permanently, and I'm very happy with it.

Downloading Intel Fortran

The Customer Services staff at Polyhedron were very tolerant and helpful throughout the period of time it took me to decide upon Intel Fortran, and then to evaluate it, and finally to purchase it. I asked a lot of questions and they were answered promptly and knowledgeably, but I think that a scripting of the whole process in advance would have maybe short-circuited many of the questions. So this is my 10-point agenda of what to do and to expect:

1)Download trial copy of MS Visual Studio 10.0 from www.microsoft.com/download/en/details.aspx?displaylang=en&id=2890
2)Download trial copy of Intel Visual Fortran Composer XE 2011 from www.polyhedron.com/
3)One-month Visual Fortran evaluation period.
4)Place order and make payment on www.polyhedron.com/
5)Receive email from Polyhedron with invoice attachment, plus Licence Key details, and specifying link to Registration and Downloads website registrationcenter.intel.com/RegCenter/
6)Register Licence Key on registrationcenter.intel.com/RegCenter/
7)Set up Intel Software Network account id and password on registrationcenter.intel.com/RegCenter/
8)Receive email from Intel confirming details of account access on software.intel.com/sites/support/ if need be.
9)Receive email from Intel confirming registration of Licence No. and attaching Licence File.
10a)Either download the licence file to C:\Program Files (x86)\Common Files\Intel\Licenses\, which my PC wouldn't let me do ...
10b)... or download to a folder in your development area, and then set the environment variable INTEL_LICENSE_FILE to point to that folder, as per software.intel.com/en-us/articles/how-to-set-intel_license_file-environment-variable/

Intel Visual Fortran documentation

I've identified and personally downloaded the following (free) Intel Visual Fortran advisory documents on the internet, and some may be of use to you. So far I've only had cause to consult the first four items in the table, and found them very helpful. These documents aren't easy to track down, and you may prefer to access the local copies as tabulated below.

TitleCodeLocal Copy
Intel Fortran Programmers Reference pdfFWL-710-02click
Intel Fortran Library Manual pdfFWL-LIB-710-02click
Intel Fortran Compiler Options txtCmd Line Helpclick
Intel Visual Fortran Forumn/an/a
Intel Fortran Compiler User's Guide.pdfFL-700-05click
Introduction to Intel Fortran Compiler Documentation.pdf307778-003USclick
Intel Fortran User And Compiler Guide.pdf304970-005USclick

Intel Fortran Batchfile Usage

Since the mid-1990's I have been compiling and linking Fortran applications using Windows batch files, and for me that's the easiest, cleanest and quickest way of doing it. The batch files are run from Windows, needing only to be double-clicked to activate.

1a) Content of ANGLIA_C_all.BAT, located within the ANGLIA object-code folder, to compile all routines within the ANGLIA source-code folder:

CALL "C:\Program Files (x86)\Intel\Composer XE 2011 SP1\bin\ifortvars.bat" intel64
IFORT /c "C:\Users\******\ANGLIA\W7FOR\*.FOR" /list >LIST.OUT

1b) Content of ANGLIA_C.BAT, located within the ANGLIA object-code folder, to recompile a particular routine ABCDEF within the ANGLIA source-code folder:

CALL "C:\Program Files (x86)\Intel\Composer XE 2011 SP1\bin\ifortvars.bat" intel64
IFORT /c "C:\Users\******\ANGLIA\W7FOR\ABCDEF.FOR" /list >LIST.OUT

2) Content of ANGLIA_CL.BAT, located within the ANGLIA executable folder, to create the executable ANGLIA.EXE by compiling and linking all the routines located within the ANGLIA source-code folder:

CALL "C:\Program Files (x86)\Intel\Composer XE 2011 SP1\bin\ifortvars.bat" intel64
IFORT /exe:ANGLIA "C:\Users\******\ANGLIA\W7FOR\*.FOR" /list >LIST.OUT

3) Content of ANGLIA_L.BAT, located within the ANGLIA executable folder, to create the executable ANGLIA.EXE from the object-files specified in ANGLIA_L.LIN, also located within the ANGLIA executable folder:

CALL "C:\Program Files (x86)\Intel\Composer XE 2011 SP1\bin\ifortvars.bat" intel64
IFORT @ANGLIA_L.LIN /exe:ANGLIA /list >LIST.OUT

given the content of ANGLIA_L.LIN:

"C:\Users\******\ANGLIA\W7OBJ\*.OBJ"
"C:\Users\******\SUBLIB\W7OBJ\SUB1.OBJ"
"C:\Users\******\SUBLIB\W7OBJ\SUB2.OBJ"

etc etc

Note that specified subroutines from numerous alternative subroutine libraries can easily be cherry-picked in the linkage procedure (3) – a capability I was never able to reproduce in Visual Studio, probably through lack of expertise: but why should such a vital facility be shrouded in mystery anyway?

File Management

The filetypes that I typically define in a Fortran project development project in the PC environment are as follows

ExtensionPurpose
Filename.BATDOS command batchfile
  
Filename.FORFortran source-code
Filename.OBJFortran object-code
Filename.LIB(N)Fortran library file
Filename.EXEFortran executable
Filename.OUTFortran compilation or linkage diagnostics
Directory listing from DIR batchfile
Search-string hits from FINDSTR batchfile
  
Filename.DATFortran data input
Filename.REFFortran reference data input
Filename.PRTFortran print output
Filename.PLTFortran plot output
  
CONIN$Keyboard input
CONOUT$Console screen display

These extensions simply enable the user to distinguish the various entities from each other, but all of them are au fond text files, created and generated by that most heroic little utility Notepad, the Sam Gamgee of the PC working environment: unobtrusive, hardworking and immensely useful.

A file newly-created in Windows as New Text Document by Notepad will have the default extension .txt, and to assign it the required extension of (say) .FOR you must take the SAVE AS option with File Name set as Newname.FOR and Save As Type set as All Files (.*)

DOS commands exist for a variety of useful purposes entirely unsupported by Windows, one example being to generate a directory listing of a Windows folder into a printable file:

DIR "C:\Users\******\ANGLIA\W7FOR\" >filename.OUT

Another enormously useful DOS capability is to generate a comprehensive list of all occurrences of a specified character string in all the text files in a Windows folder:

FINDSTR /N "string" "C:\Users\******\ANGLIA\W7FOR\*.FOR" >filename.OUT

Both these commands are easily operated Windows batchfiles, but the latter command can be parameterised

FINDSTR /N "%1" "C:\Users\******\ANGLIA\W7FOR\*.FOR" >"%2".OUT

and executed via the DOS command window, a shortcut to which should be on the Desktop, as

FINDSTR string filename

Incidentally, to generate an output file listing all the available MS DOS commands, simply issue the command HELP >filename (or click here). And to generate an output file listing all the features of a particular command, issue the command HELP command >filename (click here for an example of the FINDSTR command).

Print-File Carriage Controls

If you're hopelessly ASD, or you have a proper life to get on with, you may prefer to skip the next 7 paragraphs.

One of the longest-running irritants in the migration of Fortran applications from mainframe to PC, and from office laser-printers to personal ink-jet printers, is the print-file carriage control character.

On a mainframe this was taken to be the first character of each output line. For the default requirement of line-feed plus carriage-return, this had to be a space. For a page-feed (and implied carriage-return) it had to be the digit 1. The other controls were rarely used by programmers (including me), but the page-feed was hugely important for structuring a mainframe program print-out.

My antiquated copy of the Digital Fortran Language Reference Manual, for PC of course, does feature a CARRIAGECONTROL='FORTRAN' option in the OPEN statement and implies that this will honour the traditional controls. The Intel Fortran Programmers Reference still mentions it, but not as a widely-supported feature. I've never been able to get it to work in any situation.

The paradigm these days is that carriage controls are dead, and that each line of output starts a new line in the output document regardless of what its initial character may be.

Well and good, except for a page-feed. Ah yes, you now need to put an ASCII form-feed (FF =  hex C), as the first character of a line destined to begin a new page. Or maybe an ASCII Escape sequence (ESC E = hex 1B + "E") as the first two characters of such a line.

Actually hex C (which is also represented as the Venus female symbol) did work fine with the big floor-standing office printers at work. But on my little desk-top HP 3-in-1 personal printer (a fine piece of kit in every other respect) hex C is totally ignored. No page-feeds.

Why does technological progress seem to have such blind spots? No I don't know either.

But the answer to the page-feed problem, and very advantageous in other respects too, is a freeware utility called PrintFile. It has been written by Peter Lerup and can be downloaded from his website www.lerup.com/printfile. It remembers your current working directory and with two clicks you can tell it what to print. Clever doesn't have to be complicated.