Why discovery comes first: building the inventory
Mainframe applications are often decades old and poorly documented. Discovery means building an evidence-based inventory of every program, copybook, job, dataset, table and transaction, from both source code and runtime data, before anyone plans changes.
Why not just start changing things?
A typical core banking or insurance application has thousands of COBOL programs, thousands of copybooks, several thousand JCL jobs and many years of small changes by people who have since moved on. Documentation, where it exists, describes what the system was meant to do years ago. Application discovery is the work of finding out what the system actually contains and how its parts depend on each other, using evidence rather than memory.
Every modernization approach needs this: exposing a function as an API, moving batch to another platform, replacing a module with a package, or simply making a large regulatory change. Without it, estimates are guesses and surprises appear in production.
What goes in the inventory
| Asset | Where you usually find it | What to record |
|---|---|---|
| Programs | Source libraries, SCM tools, load libraries | Name, language, owner, last change, whether a load module exists |
| Copybooks | Copy libraries | Which programs include them, which records they describe |
| JCL and procedures | JCL libraries, PROCLIBs, scheduler definitions | Jobs, steps, programs run, datasets referenced |
| Datasets | JCL, catalog, program file definitions | Name pattern, type (sequential, VSAM, GDG), producer and consumers |
| Db2 objects | Db2 catalog, embedded SQL | Tables, views, packages and which programs use which tables |
| Online transactions | CICS resource definitions, IMS definitions | Transaction ID, initial program, related programs |
| Interfaces | MQ definitions, file transfers, API definitions | What enters and leaves the application, and to where |
Two kinds of evidence
Static analysis reads the artefacts and finds every possible relationship. Runtime evidence shows what actually ran and how often. Both are needed: static analysis cannot see a program name built in a variable at run time, and runtime data covers only the period you collected, which may miss quarter-end or year-end processing.
Useful runtime sources include SMF type 30 records (job and step activity, including program names), types 14 and 15 (non-VSAM datasets opened for input and for output; VSAM opens and closes appear in types 62 and 64), CICS monitoring records (type 110) and Db2 accounting records (type 101). Which records are collected and how long they are kept is a site decision, so ask the performance or capacity team early.
The source-versus-load problem
One of the first findings in most discovery exercises is that source and executables do not match perfectly. Some load modules have no matching source, some source has never been compiled into production, and some programs exist in several versions in different libraries. The production load libraries (STEPLIB or JOBLIB for batch, the link list, and the CICS DFHRPL or IMS program libraries for online work) are the truth about what runs; the source repository is the truth about what you can change. Reconcile them before trusting any analysis.
Which SMF record type records job and step activity, including the program each step ran?
Show a hint
It is the main job accounting record type.
Show the solution
SMF type 30 records job and step activity, which makes it a key source of runtime evidence.
Common mistakes
Documentation is a starting point, not evidence. Confirm every relationship from source, definitions or runtime data.
Month-end, quarter-end and year-end jobs will look unused. Collect at least a full business cycle, often thirteen months, or combine runtime data with scheduler calendars.
Source and production executables drift apart. Reconcile them first, or your analysis will describe a system that does not run.
What you will see at work
- Modernization programmes usually start with a discovery phase lasting weeks to months before any design work.
- Developers are asked to confirm and correct tool findings, because they know which oddities are real.
- Discovery repositories are kept up to date afterwards and become the reference for impact analysis on everyday changes.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.