Expertise on Fortran 2026

32 → 64-bit migration

Mon, 01 Jan 0001 00:00:00 +0000

Moving a real Fortran ERP from 32-bit to 64-bit is rarely a recompile. Pointer sizes, integer kinds, file formats, third-party libraries, and decades of implicit assumptions all have to be found and fixed without breaking business logic that has been correct for thirty years.

We have done this on a production ERP — see Projects → Profitool — and we know what to look for.

Where we add value

Auditing the codebase for 32-bit assumptions: integer kinds, pointer arithmetic, record sizes, common blocks, EQUIVALENCE.
Driving the translation with Promula / gmFortran and hand-tuned changes where the tool can’t decide.
Locking the result with tests so the 64-bit build provably matches the 32-bit one before you cut over — see Expertise → Testing.
Operational cutover: data file formats, on-disk layouts, third-party library upgrades, and rollback plans.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au

Testing

Mon, 01 Jan 0001 00:00:00 +0000

A lot of long-running Fortran codebases have no automated tests at all. Every release is “compile, run the smoke script, hope”. We change that — without rewriting the code first.

Where we add value

Native unit tests in Fortran with TAP-style output and prove runners — see the worked example at Examples → Unit Tests.
Regression testing by capturing the output of the existing system on real inputs and locking it down before any change is allowed.
Integration tests across SQL, REST, and external libraries that we have added — see Examples → SQL and Examples → REST API.
CI pipelines that run the test suite on every change, in containers, before any deploy.
Test coverage specifically targeting the migration boundary so a 32 → 64-bit cutover is provably safe.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au

Version control

Mon, 01 Jan 0001 00:00:00 +0000

Plenty of Fortran codebases pre-date modern version control. We have repeatedly walked into engagements where “the source” is a folder on a fileserver, several zip backups, and tribal knowledge. That doesn’t work for testing, releases, or recovery — so we fix it.

Where we add value

Capturing the current truth: figuring out which copy is real and getting it cleanly into Git (or whichever VCS you use).
Branching and release strategies that match how your team actually works, not somebody else’s textbook.
Hooking version control into builds, tests, and deploys so what’s tagged is what runs.
Recovering history from old backups when you want to reconstruct a timeline — see Expertise → Legacy data.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au

Packaging

Mon, 01 Jan 0001 00:00:00 +0000

A Fortran build that only works on one engineer’s machine is a liability. We package Fortran systems so the same binary you tested is the binary that ships — and so the next person can build it five years from now without you in the room.

Where we add value

Containerised builds with pinned compilers and dependencies (HDF5, NetCDF, MPI, BLAS / LAPACK, vendor libraries).
Versioned, reproducible artefacts — same inputs, same output, every time.
Deploy packages that drop into your existing infrastructure rather than demanding a rewrite of it.
Build-system rationalisation when the existing Makefiles / scripts have grown organically over decades.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au

Backup and recovery

Mon, 01 Jan 0001 00:00:00 +0000

A Fortran ERP that loses a day’s data is not a software problem — it’s a business problem. We design backup and recovery for systems where the database, the data files, the binaries, and the build artefacts all matter, and all have to come back together.

Where we add value

Backup strategies that actually get tested, not just scheduled.
Restore drills — proving recovery works before you need it.
Point-in-time recovery across SQL databases plus the on-disk Fortran data files that live alongside them.
Disaster recovery plans that account for the build system and the source tree, not just the data.
Migration of old backups onto modern storage — tightly related to Legacy data.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au

Legacy data

Mon, 01 Jan 0001 00:00:00 +0000

A lot of Fortran systems sit on top of decades of data: binary records in undocumented formats, files copied from machines that no longer exist, tapes nobody has read in years. We are comfortable in that territory — and we know how to bring that data back into a system you can use today.

Where we add value

Reading old binary formats — record-based, fixed-width, vendor-proprietary, or whatever the previous decade left you with.
Reverse-engineering schemas from the Fortran code that wrote the files, when documentation is long gone.
Pulling data off old media and old machines onto modern storage with integrity checks.
Migrating recovered data into modern stores (SQL, files, APIs) without losing fidelity — see Examples → SQL.
Long-term archiving plans so this is the last time anyone has to do it.

Talk to us

simon@unisolve.com.au or scottp@dd.com.au