Fortran (FORmula TRANslating System) is a general-purpose, imperative programming language that is especially suited to numeric computation and scientific computing. History of FORTRAN can be tracked late 1953 when John W. Backus submitted a proposal to his superiors at IBM. The First FORTRAN compiler appeared in April 1957.

Some notable historical steps where:

  • FORTRAN II in 1958
  • FORTRAN III in 1958,
  • FORTRAN IV in 1962.
  • FORTRAN 66 or X3.9-1966 become the first industry-standard
  • FORTRAN 77 or X3.9-1978. This is the version of the Fortran I learned 1996.
  • Fortran 90 was released as ISO/IEC standard 1539:1991 and ANSI Standard in 1992
  • Fortran 95 was released as ISO/IEC standard 1539-1:1997
  • Fortan 2003 was released as ISO/IEC 1539-1:2004
  • Fortran 2008 was released as ISO/IEC 1539-1:2010 is most recent standard
  • Fortran 2015 is planned in late 2016.

More comprehensive history and introduction can be found e.g. from

Thus Fortran programming language is not dead ! I did use Fortran in same day as I started writing this blog (05/07/2015). There is some historical reason why I decided to learn Fortran. In department of computer science, university of Helsinki there is course named Software Project where students design, implement and test larger application. I participated on this course 1996 and my application was Ringing Software for Ringing Centre, Natural History Museum, University of Helsinki. Their original software used magnetic tapes and Fortran66/77 programs. Our assignment was to transform this to use Oracle database and UNIX. At that time we decided to use Fortran77 (with some Fortran90 extensions, mainly structures) and ProFortran precompiler from Oracle.


There is version of GNU Fortran named GFortran. The GFortran compiler is fully compliant with the Fortran 95 Standard and includes legacy F77 support. In addition, a significant number of Fortran 2003 and Fortran 2008 features are implemented.

To my experience GFortran is very good compiler and really includes most of the legacy support you need (and lot of new stuff I really do not need). However, I found one example that is useful but not supported, variable length format. Consider following:

Here format (2x, I4) is repeated times and depends runtime values. This can be transformed to:

This is because format can be a string variable and above produces format (A,44(2X,I4),A) (assuming years 1971 and 2014). But, in my opinion the first one is more clearer and simpler. Additionally, I learned to use pre-Fortran90 STRUCTURE and RECORD extensions, like

This can naturally expressed using TYPE:

I mostly use Fortran90 and free-form (longer line lengths than  allowed by standard Fortran77) but only limited amount of new features. Thus code might look like Fortran77 mostly:

Naturally, there is number of commercial Fortran compilers like Intel Fortran and NAG .

Clearly one of the bad features of Fortran are implicit types. If a variable is undeclared, Fortran 77 uses a set of implicit rules to establish the type. This means all variables starting with the letters i-n are integers and all others are real. Many old Fortran 77 programs uses these implicit rules, but you should not! The probability of errors in your program grows dramatically if you do not consistently declare your variables. Therefore, always put following in start of your Fortran program:

SQL and Fortran

Fortran does not natively understand SQL-clauses, but you can use e.g. embedded SQL. Embedded SQL is SQL-clauses inside a host language like Fortran. Lets take a example:

Naturally, normal Fortran compiler will not understand clauses starting with EXEC SQL. Thus, you need to first use precompiler. Precompiler changes embedded SQL-clauses (above include clauses are copied to resulting file) and other SQL-clauses are transformed to CALL-clauses to provided database server API-calls. Naturally, this means that you software will work only for precompiled (and then compiled) database provider.

Currently, there are precompilers at least for Oracle and DB2 databases (see However, OS support is diminishing. E.g. Oracle Fortran Precompiler does not anymore work on Linux 64bit when using Oracle >10g. This in my opinion is bad because porting your Fortran software from Oracle to e.g. DB2 is not trivial especially if you have application with 100000 lines of Fortran code.

This fact has lead on my experience to situation where some of the system is re-implemented using Java and some of the code modified to pure Fortran so that it read input from files (generated using pure SQL) and by removing all embedded SQL-clauses.

Fortran and MariaDB

There is no connectors for Fortran to MariaDB /MySQL. However, you could use ODBC, however the free ODBC modules FLIBS and fodbc fail to compile in my 64-bit Linux and after some hacking with fodbc, it did not really work. Naturally, you could write your own fodbc for MariaDB/MySQL but currently I do not have a real need or enough free time to do so. Alternative way of doing this is create C-language interface between Fortran code and ODBC driver.

Lets take very simple example where Fortran program connects to MariaDB database, selects a version and disconnects.

As you note string variables need special handling as Fortran has constant strings. Therefore, we need to add C string end character before calling C-routines and then remove trailer before using string in Fortran again. And then simple C-interface (no real error handling):

And, if you compile these and run the resulting program you might see something like following:

Future of Fortran ?

There is clearly need languages like Fortran. It has some very nice features like formatted I/O and mathematical functions. However, learning Fortran might be up to you because it is not taught as first (or second) programming language on most universities or similar schools. Thus number of people who can use Fortran on programming or teach it is decreasing rapidly. However, my experience is that learning Fortran is simple if you can master at least one programming language (ok, I had learn already C/C++, COBOL, PL/I, Basic on my earlier studies). So you want to learn Fortran ? If Internet resources are not enough there is number of books. Book I have used is obsolete (Fortran 77 and Finish-language version Fortran 90/95) but e.g. is a good one.

Last  week, a SSL connection security vulnerability was reported for MySQL and MariaDB. The vulnerability states that since MariaDB and MySQL do not enforce SSL when SSL support is enabled, it’s possible to launch Man In The Middle attacks (MITM). MITM attacks can capture the secure connection and turn it into an insecure one, revealing data going back and forth to the server.

Issue resolution in MariaDB is visible through the corresponding ticket in MariaDB’s tracking system (JIRA):

The vulnerability affects the client library of the database server in both MariaDB and MySQL. But, the vulnerability does not affect all the libraries, drivers or connectors for establishing SSL connections with the server.

The vulnerability exists when the connection to the server is done through the client library libmysqlclient. This client library is provided with the database server and is a fork of the corresponding client library in MySQL. The client library is used by probably the most used tool, the MySQL Command-Line tool of which a forked version is shipped with MariaDB.

In addition to libmysqlclient, the MariaDB project provides the following connectors:

These connectors also support SSL connections to the database server and make use of the similar parameters etc. to establish secure connections. Here is an update on whether the connectors are affected or not:

  • Affected – MariaDB Connector/C is vulnerable in the same way as libmysqlclient
  • Not affected – MariaDB Connector/J does the right thing and aborts any unsecure connections if SSL is in use
  • Not affected – MariaDB Connector/ODBC does not currently support SSL

For MySQL’s Connector/J it is worth mentioning that it has two properties, “useSSL” and “requireSSL”. If “requireSSL” is selected, then unsecure connections are aborted.

Many of the tools that are used to connect to MariaDB or MySQL make use of libmysqlclient. Thus, when using these tools over an untrusted network, it’s highly recommended that you restrict network access as much as possible with normal means, even if you’re using SSL to connect to MariaDB or MySQL. Some best practices that are easy to put in place for decreasing the risk of MITM attacks include:

Finally, since we’re in the middle of fixing the vulnerability in MariaDB, we appreciate your input regarding which versions of MariaDB that should get the fix backported. For background, the SSL support in MySQL (up until 5.7) and MariaDB is not enforceable. This is the intended MySQL behavior, implemented back in 2000, and clearly documented in the MySQL reference manual as:

“For the server, this option specifies that the server permits but does not require SSL connections.

For a client program, this option permits but does not require the client to connect to the server using SSL. Therefore, this option is not sufficient in itself to cause an SSL connection to be used. For example, if you specify this option for a client program but the server has not been configured to permit SSL connections, an unencrypted connection is used.”

MariaDB 5.5 and 10.0 are stable versions and behave as documented – they permit SSL, but do not require it. To enforce SSL, when the appropriate options are given, will change the behavior and might break existing applications where a mix of SSL and non-SSL connections are used. In MariaDB 10.1 this is not a problem since MariaDB 10.1 is still in beta, although it is very close to release candidate status. There we will introduce the fix. As for MariaDB 5.5 and 10.0, we are collecting input to determine whether we should change the behavior of 5.5 and 10.0. Please visit our website for more details, and share your feedback at:

The initial reports on the vulnerability can be found through these sources:

About two and a half years ago I wrote about how the MariaDB project moved bug reporting from Launchpad to JIRA. Every now and then I get contacted about how it was done and whether I would be willing to share the tools used for doing it and of course I’ve done that. Especially in one occasion the scripts were even further developed by one company that was in the process of doing exactly the same, i.e. moving bugs from Launchpad to JIRA. Thanks for the enhancements Philip Colmer from Linaro!

In Launchpad there isn’t a readymade tool for exporting bugs and I didn’t find any 3rd party tools for doing it. Launchpad however has an API through which most (if not all) information in Launchpad can be retrieved. Launchpad has made a library available in Python making use of this API.

By using the Launchpad Python API, I wrote a Python script that pulls out bug information from Launchpad and creates an XML document for each bug. If the bug includes attachments these are also downloaded and named in a way that they can be connected to the XML.

It would, of course, be nice if the bunch of XML files and attachments that you end up with after running the Python script could be uploaded directly into a JIRA instance. Unfortunately this is not possible, unless it has been added recently, and instead a separate format is needed. According to my investigations, JIRA supports importing information best if it’s in CSV (comma separated values) format. That leads to converting a bunch of XML files to a CSV file. The CSV file can include links to the attachments.

I’ve done quite a lot of C# programming in the past and still had the way of dealing with XML in C# in my head, so I chose to do the XML to CSV conversion in C# in a Windows command line application. You’ll find the application named JiraCSV in the Github repository mentioned below.

The scripts described above have been useful for those that have reached out explicitly asking for a copy of them, but maybe the interest is broader. To initially get to the point where migration was successful it took a lot of trials to correct the data, add missing data, change the XML or CSV structure, and so on to get everything accepted by JIRA. I hope that by now sharing these scripts people will save a significant amount of time. That’s why I’ve decided to put them up on Github so that anyone interested in them can pick them up and make use of them or even improve them further. You can find them at