How do you keep mainframe knowledge when the experts retire?
The short answer
Capture it in a form that is tied to the code and survives change: a model of the system built from the source, where every fact cites the lines it came from, with your experts' confirmations, corrections and notes stored beside those facts. Knowledge written into documents drifts away from the code; knowledge attached to the code's own structure can be checked and kept current.
By Nisius · Updated
What knowledge is actually at risk?
Less of it is in people's heads than it seems, and the part that is matters most. The structure of a system, its programs, jobs, datasets and tables and how they connect, can be recovered from the code. What cannot be recovered from the code is why a rule exists, which calls are decided at run time and to what, which steps are done by hand, who owns what, and when things run.
Why are documents and interviews not enough?
Both produce text that is separate from the code. The day the code changes, the text is out of date, and nothing tells anyone which part. Interviews are also expensive for the experts, who are usually the busiest people on the team, and they tend to repeat what is already in the code rather than what only the expert knows.
What works better?
- Build the map from the code first, so your experts' time goes to what only they know.
- Give experts short review sessions with a queue: confirm, reject or correct each fact and rule, and record what the code cannot show.
- Store their contributions beside the facts they describe, with who said it and when, so a later re-reading of the code does not erase them.
- Make the result askable: newer staff ask questions in plain language and get answers that cite the lines and the expert notes behind them.
- Start with the flow you can least afford to lose, and measure whether questions get answered correctly and faster than before.
How Telikos does it
In a Telikos pilot your experts work through a review queue in two or three short sessions: they confirm, correct or reject the facts and rules for a flow's key programs and record what the code cannot show, such as dynamic calls, manual steps, owners and schedules. Telikos ingests the code again and checks that every correction survives.
Corrections override what was extracted, and every annotation is written to the audit log.
Related questions
How much expert time does capturing mainframe knowledge take?
Less when the structure is extracted from the code first. In a Telikos pilot, experts spend two or three short review sessions on one flow, plus grading answers in the final week.
What should experts record that the code cannot show?
The targets of calls decided at run time, manual steps, owners, schedules, and the business reason behind rules that look arbitrary in the code.