The problem

Why old applications become hard to look after

Many banks, insurers, manufacturers and public bodies still run their core business on programs written decades ago. The programs still work, but the knowledge about them has not been kept as well as the code.

The documentation is missing or out of date: The documents written when the system was built describe how it worked then. The code has changed many times since, so the only reliable description of the system today is the code itself.
The people who know the code are leaving: Much of what is known about the system is held by a few programmers. When they retire, the people who take over must learn it by reading programs one at a time.
Changes are slow and risky: A field or a program is used in many other places. Without a complete list of what a change affects, a programmer either searches for a long time or finds out in production.
A rewrite cannot show that it behaves the same: The old programs contain business rules that were never written down, so there is no list to check new code against. After a rewrite, nobody can say which of the old rules the new system keeps.

The solution

What Afunana does about each of these

Afunana reads the application from the machine it runs on and builds one model of every program, file and field and how they connect. Three parts of the product work from that model, in order. You can use all three, or put the weight on the one you need now.

Documentation and chat
For missing documentation and departing staff, Afunana documents every program, file, field and screen, and the business rules inside the code. Anyone can ask about the system in a chat, and every answer names the programs and lines it is based on.
Everyone
Maintenance: Afunana Developer
For slow and risky changes, Afunana shows the programs, files and screens a change affects before it is made. Programmers then edit, compile, test and debug on the IBM i or the mainframe, with every program they open already documented.
Programmers
Modernization
For a move to a new platform, Afunana proposes how each layer of the application should move, and people decide. It then writes the new code and runs the same cases on old and new, until both give the same result in every field.
Architects

How it works

One reading of your system, then three parts in order

Everything starts from the same reading of your system. Documentation comes first, because the other two parts depend on it. Maintenance keeps the application running and changing on its platform, and modernization moves it when you decide to. Afunana keeps reading the machine, so all three stay current.

The shared base

Your systemYour programs, files and data on IBM i, IBM Z, Oracle or another supported platform.
ExtractAfunana reads the source, the file and field definitions, and the system's own usage counts from the machine itself.
ModelA parser turns each program into a model of its calls, files, fields and rules, without AI.

1. Documentation

DocumentsThe AI describes each program, file, field and rule from the model.
ChatAnyone can ask about the system, and each answer cites its source lines.
People approveSpecialists correct and approve what was written, and their corrections are kept.

2. Maintenance

Afunana DeveloperA programmer opens the program in the browser or in VS Code, with its documentation beside the code.
Impact and change planAfunana lists what a change affects, then which programs to change and which cases to test.
Edit, compile and testThe change is made on the IBM i or the mainframe, in the programmer's own library.
Go liveThe approved version is promoted on your own system.

3. Modernization

Migration planAfunana proposes how each layer should move, and people decide.
Rules and new codeReviewed rules and codes feed the new code, screens, services and data.
ProofThe same cases run on old and new, and the results are compared field by field.
Go live on the new platformEach group goes live after its proof, while the old programs keep running.

Watch what changedOn a schedule you set, Afunana reads the machine again, so the model and every part stay current.

Documentation and chat

A description of the system that people can check

Afunana reads the system, works out how it fits together, and then the AI describes it, with every statement pointing to the code.

Your machineSource, file and field definitions, schedules and use. Never the business data.
FactsWho calls whom, which files each program uses, how each field moves.
One modelWith the relations between files deduced from their keys.
DescribedBy the AI, and checked against the code before it is shown.
Checked by peopleThey correct it, and anyone can ask the chat.

It reads, it does not copy data
Afunana connects with a user you choose and reads the source, the file and field definitions, the scheduled jobs and how often each program runs. It does not read the rows of business data.
Facts without AI
A parser works out which program calls which, which programs use each file, and how each field reaches a screen or a report. The same input always gives the same facts.
Parameters and menus
Afunana checks that what each caller passes matches what the called program expects, in COBOL, RPG and CL. It reads the users' menus, so a program shows which option reaches it.
The whole machine
On the IBM i it records what every source member in the libraries you name calls and uses. A map shows the machine's libraries, and you write down what to leave out.
Relations between files
Most of these systems declare none, so Afunana deduces them from how the programs use keys. One diagram shows them, each with its source lines.
Described by the AI
Programs, business rules, files, fields and processes are described in plain language. Every statement points to its source lines and is checked against the code first.
A chat that cites
Anyone can ask in plain language. The answer names the programs and lines it relies on, and says what it could not establish.
Kept current and corrected
When a program changes, only it and what depends on it are documented again. Specialists' corrections are kept with their names, and a program that failed is tried again at the end of the build.

Documentation and chat

Employee maintenance: its steps, the screens and the files they use. — **Business processes**Employee maintenance, with its steps, screens and files, each linked to its programs.

The ENKEMPSCR program page: its business purpose, who calls it and what it produces. — **Program documentation**The ENKEMPSCR program: its purpose, who calls it and what it produces.

The Employees tables, each explained: the employee master, the error list, the retirement list, the code table and the change log. — **Tables explained**Every table of the application, with what it holds and which programs depend on it.

The Employees tables in a diagram: ENPEMPS at the centre, its code table, its error list, its history and its retirement list. — **Relations between tables**The tables of the application and the relations Afunana deduced between them, each with its source lines.

ENKEMPSCR's business rules, numbered, each with its decision table. — **A documented rule**The business rules of ENKEMPSCR, numbered, each with its decision table.

ENKEMPSCR rule 2, the employee ID check digit, beside source lines 246 to 250 that call ENKCHKID. — **The cited source**Rule 2 of ENKEMPSCR beside source lines 246 to 250, where the program calls the ID check.

The chat explains what happens when a wrong employee ID is entered, each step citing its source line. — **A cited answer**What happens when a wrong employee ID is entered, each step with the source line behind it.

Maintenance

Changing the application in Afunana Developer

Afunana Developer is a development environment for the IBM i and the mainframe, in the browser or in VS Code, where every program is already documented.

PickA field or a program.
See the impactEverything it affects, each with the line that shows why.
PlanWhat to change, in what order, and what to test.
EditIn your own library, with mistakes marked as you type.
Compile and testOn the host, with the messages on their lines.
ApprovedFor the exact version that was reviewed.

The tools programmers know
PDM options, SEU line commands, ISPF, and the 5250 and 3270 terminals are all there. The difference is that every program opened is already documented.
The impact before the change
Pick a field or a program and see everything a change affects, with the line that shows why. Afunana turns that list into a change plan.
Edit, compile, debug
The change is made in the programmer's own library. The compiler's messages land on their lines, and on the IBM i the programmer can debug in their own job.
The screen as you type
Editing a display file draws the screen beside the code, and a click on a field leads to its line. One window lists the keys, the PDM options and the IBM i commands.
AI that compiles its own work
When asked, the AI makes the change, and Afunana compiles and corrects it until it builds. The programmer accepts or rejects each change, and nothing is written to production.
A chat beside the code
It answers about the open program and reads job logs and spooled files with the programmer's own authority. A failed job leads to the line that sent the error and the recent changes to that program.
Approval of the exact version
Nobody can approve their own change. A change made after approval must be approved again.

Afunana Developer

What a change to ENKEMPIO reaches, with the evidence for each line. — **Impact of a change**Everything a change to ENKEMPIO affects, with the evidence for each line.

DEPTCD, the department code: the six files that hold it and the programs that use it. — **Field lineage**The department code in every file that holds it, and the programs that use it.

ENPEMPS and everything that uses it: programs, a query, an SQL member. — **File map**The ENPEMPS file and everything that uses it: programs, a query and an SQL member.

Modernization

A plan for the whole application, then new code with proof

A migration is not a one-to-one translation of programs, so Afunana starts from the whole application, and people decide each step.

LayersFront end, services, database, batch and integrations.
ProposalsWhat to do with each, with reasons and evidence from the code.
People decideAccept, change or reject each proposal.
AssembledThe new system, piece by piece: in place, missing or proven.
ProvenThe same cases on old and new, compared field by field.
LiveData reconciled, and the application run on the Afunana Runtime.

Proposals with evidence
Afunana can propose merging programs that share their files and callers, or retiring programs that are never used. Where the code cannot decide, it asks.
The new system in one view
Each piece sits in its layer and shows whether it is reused, new work, in place, missing or proven. Any piece leads down to its decision, the old line, the new code and the proof.
New code from the same model
Programs in Java, C# or Python, or in COBOL and RPG in a current style, and screens in React or Angular. Each table gets web screens and REST services, and the database PostgreSQL, SQL Server, Oracle or Db2.
Proof, field by field
The same cases run on the old program and the new code, after packed, zoned and EBCDIC values are decoded. A program is finished only when every case matches, and the new code is compiled beside the proof.
Every rule accounted for
Each business rule is listed with its lines in the old code and in the new, so a rule left out is visible. A check found in several places becomes one rule that people confirm.
Codes and checks in one place
Status codes kept in many forms become one table of code values, picked from a list on the new screens. The input checks of the old programs become one validator per field, used by both screens and services.
The model workbench
People correct the model before code is generated: relations, names, merged screens, programs left behind. Afunana then generates again and reruns the proof, keeping hand-written code.
Data moved and reconciled
The data is copied to the new database and compared by counts, totals and a fingerprint of every row. A row that differs is shown with its key and the reason.
A few programs at a time
New code can call the old programs and the old programs can call the new, so the old system keeps running. Each group goes live after its proof.
The Afunana Runtime
It runs the new Java, .NET or Python applications from one package each, keeps every version and can roll back.
Linked and exportable
Every new line is linked to the old line it came from. The model and the cases can be exported to check code written by your own staff or by another tool.

The proof of one program

Test caseThe input to one run of the program.
The same case, run twice
- Old programThe result of the legacy program.
- New codeThe result of the generated code.
Compared field by fieldPacked, zoned and EBCDIC values are decoded first.
ProvenEvery case gives the same result in every field, and every rule is accounted for.

Modernization, on demonstration applications

The migration plan of the Employees demonstration application: a table of layers and a tile for each piece of the new system. — **The migration plan**Every piece of the new system in its layer, with how far each piece has come and how many decisions are open.

A proposal to merge ENKCHKDT, ENKCHKID and ENKCHKMAIL into one service: three options, Accept and Reject, and the evidence. — **A proposal**Merging three checking programs into one service, with the options, the reasons and the evidence from the code.

The Employees demo in the modernization screen: readiness 57 percent, proof 16 percent, 75 rules with none unaccounted. — **The application**Readiness, proof, rules and data for the whole Employees demonstration application.

ENKCHKDT side by side: COBOL line 50 highlighted, and the Python line generated from it highlighted beside it. — **Old and new, line by line**COBOL line 50 of ENKCHKDT and the Python it became, linked both ways.

ENKCHKDT proof: ten date cases such as leap years and month 13, all matched. — **The proof**Date cases run on the new code, each compared with the answer the rule expects.

The rule ledger: each business rule with its old lines, its new lines and its status. — **Every rule accounted for**Each business rule with its lines in the old code and in the new.

A generated table application: customer 1, its policies, and a link from each policy to its children. — **A table becomes an application**The policies of customer 1, each with links to its own claims and details.

Old and new data compared: rows and sums agree, two records differ because of impossible dates. — **Data reconciled**Counts and totals agree, and the row fingerprints find two records with impossible dates.

The generated REST services of the Employees demo, with inputs, outputs and a Try button. — **Services**The Employees application as REST services with an OpenAPI description, with the proof cases run through them.

Why Afunana

How Afunana is built

The points below describe how Afunana works.

It reads the system from the machine: Afunana connects to the IBM i, the mainframe or the Oracle database and reads the source together with what the system records about itself. The documentation therefore describes what is installed and running today, not an export someone made years ago.
The facts are computed from the code without AI: Calls between programs, the use of each file, the path of each field and the impact of a change are worked out by a parser. They cover every program that was read and come out the same every time.
The AI writes what people read, and cites its source: The AI writes the descriptions of what programs do, the business rules and the answers in the chat. Each of them names the program lines it is based on, so anyone can check it against the code.
It can run on your own server: Afunana can be installed in containers on a Linux server inside your network. The source and the documentation then stay there, and with an AI model hosted inside your network, nothing leaves it.
Changes are checked against their impact: Before a change is made, the programmer sees everything it affects, and the change plan lists what must be tested.
Modernized code is proven to give the same result: Each new program runs the same cases as the old one, the results are compared field by field, and every business rule of the old program is matched to the new lines that carry it out, before the program goes live.

Platforms

The platforms Afunana reads

The same screens, the same chat and the same audit records are used for every platform below.

IBM Z

COBOL
PL/I
JCL
CICS
Db2
VSAM

Batch jobs and CICS transactions are traced in the code from where they start to the programs and files they use. Afunana reads the mainframe through z/OSMF and installs nothing on it.

IBM i

COBOL
RPG
CL
DDS
Db2 for i
5250

Programs, files and fields are read from the machine itself. Programmers edit, compile and debug in their own job.

Oracle

PL/SQL
SQL
Forms

Packages, procedures and tables are read from the data dictionary, and nothing is installed on the database. Oracle Forms are added by uploading their export.

Natural and Adabas

Natural
Adabas

The source is imported from an export, so no connection to the host is needed.

SAP ABAP and BW

ABAP
BW

The source is imported from an abapGit export, so no connection to SAP is needed.

Delphi

Object Pascal
Forms

The project is uploaded as one zip, so no connection is needed. Its forms are documented as screens.

.NET

C#

The application is uploaded as one zip, then documented and modernized like any other. Its data annotations are read as business rules.

PowerBuilder

PowerScript
DataWindow

The exported source is uploaded as one zip. Its DataWindows are read for business rules.

Details of one screen field, on each platform

The Customer number field of an IBM Z BMS map: its type, what you can type and its path through the program. — **IBM Z BMS map**The Customer number field: its type, what can be typed in it and its path through the program.

The Status field of an IBM i display file: its values, the checks on it and its path from file to screen. — **IBM i display file**The Status field: its values, the checks on it and its path from the file to the screen.

The Reserve only field of a Natural map: its type, what you can type and how the program checks it. — **Natural map**The Reserve only field: its type, what can be typed in it and how the program checks it.

The Status item of an Oracle Forms canvas: its type, its business rules and the form's checks. — **Oracle Forms canvas**The Status item: its type, its business rules and the checks the form makes.

Enterprise

Installation, access and records

Afunana runs on your own servers, and every person, model and decision in it leaves a record.

InstalledOn your servers, with one script.
Signed inLocal accounts with a code, SAML or OpenID Connect.
Your applications onlyEach person sees what they are entitled to.
Models you choseTested on your own code by your administrators.
RecordedEvery request, approval and change, with who and when.
ForwardedTo your security monitoring (SIEM).

Installation
One script installs Afunana and updates it to the exact version you choose, on RHEL, AlmaLinux, Rocky Linux, Ubuntu or Debian. It can use a database and a reverse proxy you manage.
When the AI is unavailable
The documentation already written stays available.
Access
People sign in with a local account and an authenticator code, or through SAML or OpenID Connect. Each person sees only their applications, also through MCP, the interface your own tools use to ask Afunana.
The AI you chose
Administrators choose the models after testing them on your own code, and programmers cannot change them. A guide in the AI management screens takes an administrator through the governance steps.
Every request recorded
Each request to a model is recorded with who asked, about what, with which model and at what cost.
A nightly review of the chats
Fixed rules, without a model, list the questions that were asked again, left unanswered, slow or failed. When a question fails, your own model explains why.
Every version and approval kept
Each saved version of a program keeps who changed each line. Approvals and reported problems are recorded and can be forwarded to your SIEM.
Reference frameworks
The governance uses the NIST AI RMF, ISO/IEC 42001 and ISO/IEC 23894 as reference frameworks.

About Afunana

The people behind Afunana

Dov Keshet

Co-founder, Legacy Systems Architecture

Dov has four decades of hands-on experience with COBOL and enterprise applications. He has designed core systems and led development groups. At Afunana he leads the product and its architecture, from reading the source on the IBM i and the mainframe to planning, checking and writing changes back.

Batel Mirel

Co-founder, AI and Solutions

Batel spent fifteen years as a COBOL programmer on insurers' core systems. She designed and built the part of Afunana that turns code into documentation and answers. In her design, everything that can be known for certain is computed from the code without AI, and the AI writes from those facts.

Jonathan (Yoni) Clayman

Chief Business Officer

Jonathan has worked in sales and partnerships for enterprise software and AI companies for more than 20 years, selling both directly and through systems integrators. At Afunana he leads work with enterprise customers and partners.

Partners

For systems integrators and their clients

Systems integrators use Afunana in their client projects. During discovery, it follows the business processes into the code. During modernization, it shows which behavior must be kept and proves that it was. At handover, the client keeps the documentation and the answers, and Afunana updates them when the code changes.

Partnerships: Jonathan Clayman, Chief Business Officer, for integrators, resellers and global partners: jonathan@afunana.io.

Contact us about partnership

FAQ

Questions we get

Does our source leave our site?

Afunana can run on your own servers, with Docker or Podman. The source, the documentation and the search index then stay in that installation. The AI reads the relevant source through the AI service you configure, so with a model hosted inside your network, nothing leaves it.

Does the model see our comments?

When source is sent to the model, every comment is blanked out, and each line keeps its number so the citations stay correct. When writing the documentation, Afunana reads a comment only where the code leaves a name unclear, and it follows the code where the two disagree.

Where does Afunana write?

Changes are made in the programmer's own library on the IBM i, or under their own qualifier on the mainframe, and reach the system only when the programmer saves them. Afunana never writes to production.

Can it run on a Windows server?

Afunana runs on Linux. On a Windows server, it runs in a Linux virtual machine on Hyper-V or VMware.

Which AI models does it use?

Any model your organization approves from Anthropic, OpenAI or Amazon Bedrock, or a model hosted inside your network. Administrators choose a model for each task after testing it on your own code.

What do we need to start?

A server for Afunana, and either a connection to the host with a user you choose or an export of the source. The first application starts from a program you name, and Afunana finds the rest of it by following the code.

How are documents like Confluence pages used?

They are added to an application as supporting evidence, and only the parts that name a program or a file go to the AI. Where a document and the code disagree, the code is taken as correct, and a report lists every such place.

Request a demo

Tell us what you need

Tell us which application you would like to look at. A first project usually covers one bounded part of it, with questions your own specialists can judge, so that both sides agree beforehand how the results will be checked.

support@afunana.io

Afunana169 Madison Ave. #2172New York, NY 10016United StatesPhone: +1 888 890 2534

The AI legacy system manager: understand it, change it, modernize it

Application overview

Why old applications become hard to look after

What Afunana does about each of these

Documentation and chat

Maintenance: Afunana Developer

Modernization

One reading of your system, then three parts in order

A description of the system that people can check

It reads, it does not copy data

Facts without AI

Parameters and menus

The whole machine

Relations between files

Described by the AI

A chat that cites

Kept current and corrected

Changing the application in Afunana Developer

The tools programmers know

The impact before the change

Edit, compile, debug

The screen as you type

AI that compiles its own work

A chat beside the code

Approval of the exact version

A plan for the whole application, then new code with proof

Proposals with evidence

The new system in one view

New code from the same model

Proof, field by field

Every rule accounted for

Codes and checks in one place

The model workbench

Data moved and reconciled

A few programs at a time

The Afunana Runtime

Linked and exportable

The proof of one program

How Afunana is built

The platforms Afunana reads

IBM Z

IBM i

Oracle

Natural and Adabas

SAP ABAP and BW

Delphi

.NET

PowerBuilder

Installation, access and records

Installation

When the AI is unavailable

Access

The AI you chose

Every request recorded

A nightly review of the chats

Every version and approval kept

Reference frameworks

The people behind Afunana

Dov Keshet

Batel Mirel

Jonathan (Yoni) Clayman

For systems integrators and their clients

Questions we get

Tell us what you need