AS/400 application retirement with governed reporting.

The situation

A long-running order, manufacturing, distribution, finance or service application has been replaced, but it still runs on an IBM i partition for historical inquiry and reporting. Business users may call it “the AS/400” or “iSeries” even though the current operating environment is IBM i. A small number of specialists know the menus, report parameters, library conventions and short field codes needed to answer old questions.

The retirement objective is to preserve approved business history and evidence while removing reliance on the application. The platform may host other workloads, so success does not necessarily mean powering down the partition. It can mean isolating and retiring one application’s libraries, jobs, interfaces, credentials and support obligations while governed historical reporting continues elsewhere.

Dependencies that a table export can miss

IBM i applications are assembled from typed objects and operational conventions. Physical files store records; logical files can define alternate sequences, selections and joins; and a database file may contain multiple members. Business meaning can also live in DDS, RPG, COBOL or CL code, copybooks, data areas, menus and configuration objects.

• Library resolution: identical object names can exist in different libraries, while the library list determines which object a program uses.
• File members: member or library names may represent a company, site, year or environment even when that value is absent from each record.
• Encoded data: short fields, packed decimals, century indicators, blank conventions and application codes require interpretation.
• Generated output: invoices, statements, labels, operational reports and job evidence may survive as spooled files rather than database rows.
• Integrated file system: documents, images, exports and interface files may reside in IFS paths or external content products.
• Operational coupling: scheduled jobs, data queues, journals, interfaces, replication and shared services can keep an apparently dormant application active.
• Authority model: user profiles, group profiles, authorization lists, adopted authority and menu security may encode boundaries that should not be flattened in the historical service.

The governed-reporting pattern

1. Separate the application from the platform. Inventory the application libraries, objects, jobs, IFS paths, output queues, interfaces and shared dependencies. Identify which platform services support other workloads.
2. Observe real historical tasks. Have business users demonstrate searches, menus, reports and print output. Record inputs, code meanings, calculations, drill paths and authorization rules.
3. Map objects into business entities. Reconstruct orders, shipments, invoices, payments, inventory movements, work orders or other approved records from physical files, logical definitions, members, reference data and output.
4. Preserve provenance during extraction. Log source partition, library, file, member, key, selection criteria, extraction time and transformation version. Use a controlled point-in-time and delta approach.
5. Publish governed reports and inquiry. Give authorized users familiar search keys, readable labels, related-record navigation, retained documents and approved reports. Maintain lineage without requiring knowledge of IBM i object names.
6. Validate and isolate. Reconcile the history, test representative tasks, redirect or stop dependencies and obtain authorization before the application is disabled.

The target does not need to emulate every display file. Preserve the business intent of the historical tasks. If an RPG or COBOL program calculates a report value, decide explicitly whether to retain the original output, reimplement and validate the calculation, or expose the underlying transactions with an explanation of the change.

Validation and reconciliation

A controlled validation pack should connect technical completeness to business usability:

• object and record inventories by library, physical file and member;
• counts by company, site, status, fiscal period or other approved dimensions;
• control totals for quantities, values, debits, credits or balances where applicable;
• primary and related-key tests across headers, details, codes and transactions;
• logical-file selections, joins and ordering reproduced where they support an approved task;
• spooled-output, IFS and document inventories with readable-file checks;
• side-by-side tests of selected legacy reports and replacement results;
• business scenarios completed without green-screen or specialist intervention.

Testing must include edge cases: reversed or cancelled activity, reused codes, unusual dates, multiple members and older records created under different program versions. Known gaps should be recorded with their impact and approved disposition.

Shutdown or isolation decision gates

Risks and lessons

• Do not treat AS/400 as one application. A partition can host unrelated workloads and shared services; inventory before changing platform components.
• Preserve member and library context. It may be essential provenance rather than incidental technical metadata.
• Inventory output early. Spooled files and IFS documents often contain the historical artifact users actually request.
• Make implicit rules explicit. Specialist knowledge hidden in code, menus and operating practice must become documented mappings and acceptance criteria.
• Distinguish recovery from access. Save files or tape copies can support recovery, but typically require a compatible environment and skills before users can retrieve information.
• Monitor after cutover. Unexpected calls to jobs, files, queues or interfaces reveal dependencies that interviews may miss.
• Plan disposition deliberately. Keeping a partition running is not a retention policy; record classes, holds and authorized deletion need owners.

Questions to apply to your IBM i landscape

• Is the target one application, several applications or an entire partition?
• Which libraries, files, members, programs and IFS locations produce the history users need?
• Which reports depend on RPG, COBOL, DDS, logical-file definitions or specialist operating knowledge?
• Are important invoices, statements or reports stored only as spooled output or external documents?
• What other workloads share jobs, queues, identity, network paths or platform services?
• What evidence would business and technical owners require before disabling routine access?
• Can retained save media be restored and interpreted under a documented future operating model?

Related planning resources

Use the AS/400 and IBM i decommissioning guide for object-level discovery, review the historical data platform, and apply the ERP decommissioning readiness checklist. The historical reporting acceptance-test template helps convert green-screen tasks and legacy reports into testable scenarios.