rpg-demo: IBM i capture and recovery tools

This repository develops a reusable method to bring a native IBM i application into Git. It captures source, SQL definitions, metadata, and executable instructions as checked text. Developers can continue to use native editors. The old parts-inventory application has been removed. Its history remains in Git.

The reference application is rpg-lemonade. The first recovered fixture is in native/ and database/. It has mixed RPG/400, fixed and free ILE RPG, SQLRPGLE, CL, binder source, and a native display file.

After a full runtime restore test passed, the seeded experiment removed LM_WEATH and LM_BUYUI source. Both replacements now compile and run under the original development names. The other 15 members came from the live source capture. The replacements are reconstructed source; they are not recovered copies of the original text. See reconstruction results.

The reusable-tool retry now captures real program instructions through Ghidra and PowerAS. A fresh recovery agent used captured evidence to write a pricing replacement. Its first frozen candidate passed all 13,166 native staging cases. See the retry results and limits.

Current tools

• Native development workflow and application scopes.
• Executable extraction and independent recovery retry.
• Reusable deterministic text bundles for source, metadata, SQL, and Ghidra instruction evidence, with integrity checks and comparisons.
• Strict source capture and local manifest verification.
• A pub400 command-authority check with explicit permission skips.
• Live SQL function, procedure, and trigger probes with cleanup.

Read capture instructions, the full plan, and work status. The live evidence records allowed features and denied trigger tests.

Test

python3 -m unittest discover -s recovery/tests -v

Pull requests run these offline tests. The current Binjovi recipe releases the tool's Git revisions. Earlier application releases proved native staging, packaging, deployment, and rollback with fixture-specific adapters. They remain examples for each application's deployment integration. See the native workflow.

Native source editing remains part of the design. Git imports must protect newer greenscreen edits. Use only the declared experiment objects in SOMEARA1, SOMEARA2, and SOMEARAB; these libraries also contain unrelated applications.

Open feature pull requests to trunk. Binjovi releases advance trunk and main. Do not merge a pull request directly in Forgejo.

recovery/metadata.py captures scoped catalog evidence. Its report lists the remaining gaps and does not claim a complete library snapshot. recovery/ddl_capture.py requires Zelnet v0.10.8 or later. It writes generated SQL to a new source file in the declared scratch library, exports it with strict verification, and removes that scratch file. For routines, supply the catalog specific name. Generated DDL is reconstructed source, not proof of the original source text.

Native pipeline timing

The current native recipe checks the source-recovery tools. Its configured pipeline ends at Git Release. Older IBM i Deploy records are historical evidence, not a target for new releases.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Cached BuildKit steps still appear as cached work; a missing sample does not prove that a task used no CPU.

Select an exact successful Build with binjovictl release rpg-demo --build BUILD_ID --wait. Then use binjovictl status rpg-demo to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.