What LegacyPhoenix is made of.
Parsers, one model, an interface for the people who know the system, and a choice of targets.
Platforms
OpenVMS
Working todayVAX, Alpha, Integrity and x86. The working prototype reads COBOL, C, MACRO, ACMS, DECforms, Rdb and DCL here. BASIC, FORTRAN, FMS and TDMS are in development.
IBM mainframe (zSeries)
PlannedCOBOL, PL/I and Assembler, with JCL, CICS, IMS, Db2, VSAM and MQ.
IBM i (AS/400, iSeries)
PlannedRPG, CL and COBOL, with DDS, physical and logical files, data queues and data areas.
Legacy UNIX
PlannedC, C++ and COBOL applications on older UNIX systems, with their shell scripts, embedded SQL, Tuxedo services and shared memory. Sector7 knows this ground: the practice it ran for IBM ported thousands of applications from Sun and HP to IBM Linux and IBM AIX.
The model
One self-contained file holds the whole system: things, the links between them, what was not modelled, what an AI inferred, and what your experts decided. Parser facts, AI inferences and human decisions are kept apart, so you always know which is which.
Every fact carries the file and line it was read from.
Every construct a parser reads becomes a fact or a counted "not modelled" row.
Totals are reconciled against an independent count of the source text.
The operating system is part of the system
Shared memory, mailboxes, locks, logical names, processes and queues decide how programs cooperate. LegacyPhoenix collects them from system service calls in programs, from command procedures and from build files, and shows them in the same network as the code.
The interface
- Navigator Working today
- move through the network, search, and read the source behind a fact.
- Validation Working today
- review queue, decisions, sign-off, reviewer sign-in.
- Target chooser In development
- options side by side with their consequences.
- Proof dashboard In development
- scenarios, matches, differences and coverage over time.
Target stacks
You are shown options, not one answer. Each choice sits behind a boundary in the generated system, so another option can replace it later without starting again.
- Java Working today
- generated data classes, transaction classes, schema and wiring on a runtime library.
- Java with an Apache stack Working today
- an embedded web server for the transaction interface, and a browser front end generated from the original screen definitions.
- Further targets In development
A modern interface for the new system
The converted application is not a terminal screen redrawn in a browser. It has two faces over the same tasks.
The faithful face is generated from the original screen definitions: the same fields, positions, function keys and flow. It is the proof at screen level, and a fallback for users who should not be retrained yet. Working today
The modern face is a new interface for daily use: searchable lists, fields that know their type, the business words your users already know, usable by keyboard, touch and screen reader. In development
Both call the same tasks with the same data. The modern face changes how a person works, never what a task does.
Beyond the original
Once the original behaviour is preserved, the application can be extended. The first kind of extension is more options in fields:
Choices instead of codes.
The interface offers the valid values where the original expected a code typed from memory.
Value sets that can grow.
Allowed values become data, so a new one is added without changing code.
Richer inputs.
Dates, amounts, searches and multi-part values are entered naturally and stored in the original form.
Every extension is named, tested and switched on by configuration. With every extension off, the new system is the proven equivalent of the original. In development
Keyed files: keep them, or move them to tables
In developmentWhere the legacy application uses keyed indexed files, you choose file by file. Keep a file as it is, or move it into a table that mirrors its records and keys. The program is not changed by the choice, and it must behave identically either way: the same record content, key order, status values and locking.
Your choice of database
In developmentYou pick the database for the converted system. A database is offered only after LegacyPhoenix's own tests and a full proof have passed on it.