12 · Case study
An IBM i (AS/400) core that other systems callService programs · binder source · JT400 · XMLSERVICE · .NET or Java
The system
The problem
The business wants the logic on the box available to a web front end, a mobile application or a partner, and it does not want the logic rewritten to get there. Today that access happens through bridges: Java reaching in over JT400, Node and Python over XMLSERVICE, each one calling programs, commands, files and data queues directly. Where a bridge chooses its target at run time, nobody has the full list of what it touches.
Inside, an interactive RPG program handles the screen and the business rule in the same object. Exposing it as it stands means exposing the screen handling with it. The question of which programs to expose cannot be answered from a spreadsheet, because the spreadsheet does not know which service program exports which procedure, or what each procedure reaches once it is called.
What ran
Binder source gives the procedures each service program exports and the binding directories that group them. That export list is a declared public surface and the natural seam for anything that crosses the boundary. It is read from the source, so it is the surface the system actually has rather than the one a document describes.
Every JT400, XMLSERVICE and itoolkit call from off-platform code into programs, commands, files and data queues on the box. Where the target is chosen at run time, the resource kind is recorded instead of a name, so a call that cannot be pinned to one program is still counted rather than lost.
For each exported procedure and each bridged call: the programs it reaches, the files it reads and writes, the data areas and data queues it touches, and the commitment control scope it runs in. This is what decides whether an entry point is safe to expose as it is, or drags a transaction boundary with it.
An interactive RPG program becomes an API controller plus a web page on .NET, a REST controller plus a page on Java. The subfile control and detail pair that makes a scrolling list becomes a server-paged list endpoint; the function keys become named actions. Batch RPG and ILE subprocedures are already callable units with a signature, and they are the cleanest mapping in the set.
The plan lists every export and every bridged call with a decision: expose it as an endpoint, keep it behind the existing screen, or leave it. Commands become CLI commands or admin endpoints with the parameter types and defaults their command source declares. The message file becomes a resource file or bundle, because the text users see lives only there. Nothing is written until the plan is approved.
Each endpoint is a small change, a real build and a commit. Once a called program has moved behind an endpoint, the bridge that reached for it is removed rather than reimplemented.
What it produced
An API surface derived from the exports
Endpoints that correspond to procedures the system already declared public, with the call graph behind each one recorded, so a reviewer can see what a request reaches before it is opened to a partner.
A list of bridge callers to retire
Every off-platform call, by language and by what it touched, against the endpoint that replaces it. The list is what makes the bridges removable instead of something everyone is afraid to switch off.
The green screen untouched
The 5250 interface keeps working throughout. The endpoint and the screen share the same logic, so the decision about the screens can be taken later, on its own terms.
Where it ended
Which entry points are exposed. The plan puts each one in front of you with what it reaches, and a procedure that reaches a commit scope across several files is a different decision from one that reads a single table. The boundary of a transaction has to match the original exactly, including which files are under commit, and that is checked rather than assumed.
What happens next
The reason to start from binder source is that the export list is a fact the system states about itself. An interview produces the list people remember; the binder source produces the list the linker enforces, and the two are rarely the same.
CogniDev