PFXplus and POWERflex: reading a 1993 4GL and getting the data out

If you are running PFXplus, you are almost certainly the only person you know who is. There is very little written about it, the vendor community has effectively dispersed, and most firms you approach will never have heard the name. None of that means your data is stuck.

What PFXplus is

PFXplus is a fourth-generation language and database development system from POWERflex Corporation, an Australian company. It was built to be compatible with DataFlex, which was a widely used business application platform of the same era, and that compatibility is the single most useful fact in this guide.

The release we have worked on in production is 2.50, dated 31 October 1993. Its collating sequence file is headed "Collating sequence for AUSTALIA", vendor typo included, which tells you something about both its origins and how long it has been since anyone edited it.

Systems built on it are typically stock control, order entry, invoicing or job costing for manufacturers and distributors. They were usually written by one person who understood the business completely, and they have run for thirty years with very little intervention.

What the file extensions mean

A PFXplus directory is intimidating mostly because the extensions are unfamiliar. They divide cleanly into program files and data files, and only the second group matters for recovery.

Where the data actually lives

Because PFXplus was built DataFlex-compatible, the data uses the DataFlex file layout. Each logical table is a set of files that belong together:

• CUSTOMER.DAT holds the records themselves, fixed length
• CUSTOMER.TAG holds the field names for those records
• CUSTOMER.K1, .K2 and so on hold the indexes
• A matching .FD file describes the record structure

That separation is why an ordinary tool cannot open a .DAT file and show you a table. The bytes are in one file and the meaning is in another. Once you read them together, the picture is complete.

Why this is recoverable even without source

This is the difference between PFXplus and genuinely hopeless situations, and it is worth being precise about.

The .FD file definitions describe every record and every field. The .TAG files supply the field names. Between them you have a complete map of the data structure that does not depend on the program source at all. Somebody can have lost every .PTC and every include file, and the data extraction is still provable.

What losing the source costs you is the business logic: the validation rules, the calculations, the sequence in which things happen. That matters if you are rebuilding the application. It does not matter if you want the records.

How the extraction works

1. Inventory the file sets. Group every .DAT with its .TAG, its indexes and its .FD. Files without a matching definition get flagged rather than guessed at.
2. Read the record definitions. The .FD gives you field positions, lengths and types. The .TAG gives you names. Together they produce a schema.
3. Extract into a staging database. SQL Server or PostgreSQL, one table per file set, with types mapped conservatively so nothing is rounded or truncated on the way in.
4. Reconcile. Row counts per file, and control totals against reports the business already runs. This is the step that turns an extraction into something you can act on.
5. Rebuild the relationships. The index files tell you what the application treated as a key, which is how you recover the relational structure that the flat files do not state.

What goes wrong

• Numeric formats. DataFlex-family numerics are not plain integers. Read them as raw bytes and you get plausible, wrong figures.
• Dates. Stored as day counts rather than readable dates. Getting the epoch wrong shifts every date in the system by a consistent amount, which is easy to miss and easy to check for.
• Trailing spaces. Fixed-length text fields are space padded. Import without trimming and every comparison downstream fails in a way nobody can explain.
• Overlay and redefined fields. Some records reuse the same bytes for different purposes depending on a record type flag. Extract without noticing and one column becomes nonsense for a subset of rows.
• Deleted records. Deletion is often a flag rather than a physical removal. Extract everything and you resurrect records the business deleted years ago.

What to do first

1. Copy the whole data directory. Every extension, not just the ones that look important. The .FD and .TAG files are small and they are the ones that make the job possible.
2. Find out whether the source still exists. Ask before the person who knows retires. It changes what a rebuild costs, though not whether the data comes out.
3. Write down who still uses it and for what. Many of these systems are consulted for history far more than they are used for daily work, and that changes the answer from a rebuild to an archive.
4. Extract one file set and reconcile it. If one table can be proven correct against a known total, the rest is repetition rather than risk.

The reason to start now rather than later is not that the software will fail. It has run since 1993 and it will probably run a while yet. It is that the person who understands it is the actual dependency, and that dependency has a retirement date.