Retiring ASW on IBM i means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise library provenance, physical-file definitions and finance history. Compare required reports and documents with source evidence, test permissions and obtain business acceptance before scheduling shutdown.

This guide covers the retirement questions, a mock-data ArchiveHub demonstration and the validation work needed to define a project scope.

What keeping ASW read-only actually costs

Cost categories are a discovery checklist, not a guaranteed savings calculation. Verify support status, deployment, shared infrastructure and contract terms for the actual installation.

The partition looks cheap because it is already paid for. It isn't. A read-only AS/400 still carries:

  • IBM i hardware and operating system support, plus the eventual question of what happens when the machine reaches end of service and a like-for-like replacement makes no sense for a system nobody posts to.
  • RPG and CL skills. Every non-standard query still needs someone who can read the file layouts, write a Query/400 or adjust an RPG program. That knowledge usually sits with one or two people close to retirement.
  • 5250 access for auditors and tax advisers. Emulator licences, user profiles and object authorities have to be maintained for people who log on twice a year, and every one of those profiles is another account to review.
  • Backups, PTFs and security reviews on a platform that is outside the main IT estate and often outside the monitoring that covers everything else.
  • Spool-file archaeology. When the answer is in a report that was printed in 2018, someone has to rerun it against data that has to stay exactly as it was.

Which costs can be removed depends on shared infrastructure, contracts and the cost of operating the archive.

Scope, versions and evidence

This is an illustrative workflow, not a customer case study. Confirm the source release, deployment, modules, customisations and extraction permissions before using the mappings below. Tables and report labels describe the demonstration catalogue; native-report equivalence has not been independently certified. Use agreed source reports and representative records for acceptance testing.

An archive is not a replacement for every operational feature of the retired ERP. Document required historical tasks, excluded functions and any archive-derived calculations.

Historical data to scope for ASW on IBM i

ArchiveHub does not flatten ASW into a generic "transactions" table. The archive holds the physical files under their own names, organised by the libraries they came from (recording the actual library for each source file), with each field keeping its ASW name and description.

The general ledger is there in both forms ASW used: SROPST, the G/L transaction file, and SROLOGGL, the G/L transactions log that records who posted what and when. They are backed by SROKTO (chart of accounts) and SROBUD (G/L budget file). Payables sit in SROLTA (A/P transaction file) with SROLTAI for invoices, SROLPX as the settlement path index and SROLBA as the A/P batch input file. Suppliers come from SROLMA, with SRONPI for purchase order information and SROSUK for bank data. Receivables mirror that structure: SRODTA, SRODTAI, the SROVPX settlement index, the SROCMA customer file and SRONAD addresses, with SRONAM as the business partner file.

Beyond finance, SROFAM and SROFAD hold the fixed asset master and depreciation, SROEMA and SROPRL the payroll employee file and payroll register, and the project files MFPHHR (project header), MFPPEL (phase elements) and MFPPLI (phase lines) carry the project costing side.

Because field descriptions come across with the data, an analyst can search for a supplier number or a voucher type in ad-hoc queries using the same vocabulary the ASW screens used.

Explore the demonstration

Supplier Invoice Journal list in ArchiveHub Supplier Invoice Journal: archived ASW purchase invoices with approval details, filterable by supplier and period. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Supplier invoice detail page in ArchiveHub Supplier Invoice Journal detail: a single archived ASW supplier invoice opened from the journal. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Subledger to GL Reconciliation in ArchiveHub Subledger to GL Reconciliation: AR, AP, asset and payroll balances tied to the general ledger, period by period. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Explore the report reference catalogue

These mappings identify intended business workflows, not certified one-for-one equivalents. Confirm availability, source coverage, filters, currencies, dates and calculations for the selected release and implementation.

ArchiveHub ships with the following reports for ASW. Each one mirrors an inquiry or report ASW users already know.

Finance

  • Supplier Invoice Journal: reference workflow: the ASW Purchase Invoice Journal with approval (SROLTA / SROLTAI)
  • Supplier Payment History: reference workflow: the ASW Outgoing Payments Journal (SROLTA type 43 / SROLPX)
  • Supplier Aged Open Items: reference workflow: ASW Aged Open Items for suppliers at the archive cut-off (SROLTA)
  • Supplier Account Statement: reference workflow: the ASW Supplier Account Inquiry with balances and bank details (SROLMA / SRONAD / SROSUK)
  • Sales Invoice Journal: reference workflow: the ASW Sales Invoice and Credit Note Journal (SRODTA / SRODTAI)
  • Customer Receipts Journal: reference workflow: the ASW Incoming Payments Journal (SRODTA type 31 / SROVPX)
  • Customer Aged Open Items: reference workflow: ASW Aged Open Items for customers at the archive cut-off (SRODTA)
  • Customer Account Statement: reference workflow: the ASW Customer Account Inquiry with balances (SROCMA / SRONAD / SRODTA)
  • Voucher Journal: reference workflow: the ASW Voucher Journal by voucher type and number (SROPST / SROLOGGL)
  • GL Posting Log: reference workflow: the ASW GL Log of who posted what and when (SROLOGGL)
  • Balance Sheet and Income Statement: reference workflow: the ASW Financial Statements by account (SROPST / SROKTO)
  • Department Cost Report: reference workflow: the ASW Dimension Report, P&L by department and account (SROPST / SROKTO)
  • Budget vs Actual: reference workflow: the ASW Budget Comparison by account and period, debit + / credit - (SROBUD / SROPST)
  • Bank Account Cash Book: reference workflow: the ASW Bank Account Ledger with running balance (SROPST)
  • VAT Report: reference workflow: the ASW VAT Report by period (VAT lines from SROLOGGL)
  • Subledger to GL Reconciliation: reference workflow: the ASW reconciliation of the AR, AP, assets and payroll files to the GL by period

Assets

  • Fixed Asset Register: reference workflow: the ASW Fixed Asset Register at the cut-off (SROFAM / SROFAD)
  • Depreciation Run Report: reference workflow: the ASW Depreciation Run by period and asset (SROFAD)

Projects

  • Job Cost Detail: reference workflow: the ASW Project Cost Lines, planned vs actual (MFPPEL)
  • Project WIP Schedule: reference workflow: the ASW Contract Work in Progress schedule at the cut-off (MFPHHR / MFPPEL / SROPST)

Sales

  • Sales Statistics: reference workflow: ASW sales by product group and salesperson (SROPST dimensions 2-4)

HR

  • Employee Master: reference workflow: the ASW Personnel Master (SROEMA)
  • Payroll Register: reference workflow: the ASW Payroll Register by period and employee (SROPRL)

Core display screens

  • Display A/P Transaction: payables transaction display
  • Display A/R Transactions: receivables transaction display
  • Display G/L Transaction: general ledger transaction display
  • Display GL Master: chart of accounts display
  • Display Trial Balance: trial balance display
  • Display Customer Master: customer master display
  • Display Vendor Master: supplier master display
  • Display Project Master: project master display
  • Display Project Transaction: project transaction display

Source documents stay attached

Document types below illustrate the intended scope. Include source attachments and external repositories explicitly, and test retrieval and record linkage before decommissioning.

The archive is more than rows. Archived documents stay linked to their records: sales invoices and supplier invoices carry their PDFs, and project, customer, supplier, employee and fixed asset records keep their attached files. An auditor who opens an invoice in ArchiveHub sees the document next to the postings, without a separate document system.

Beyond the reports

Confirm these capabilities, configuration requirements and limits during the demonstration and scope review; the report catalogue alone does not validate them.

The out-of-the-box reports cover the usual questions. For everything else:

  • Ad-hoc query builder over the configured archived files, showing ASW field descriptions and suggesting joins, for example from SROLTA to SROLMA on the supplier.
  • Retention rules and purge with approval, so payroll and personal data can be deleted on schedule while the ledger stays.
  • Legal hold to suspend purging for anything under dispute or investigation.
  • Personal-data governance: agree the lawful retention, access and deletion requirements with the responsible privacy and records teams. Product features alone do not establish regulatory compliance.
  • Access controls: define and test permissions for the required companies, records and sensitive fields. Do not assume that system-level roles reproduce the original ERP permissions, particularly for payroll and HR data.
  • OData feeds into Excel, Power BI and SAP Analytics Cloud, if the old ASW history needs to sit next to S/4HANA figures.

How an ASW decommissioning runs

  1. Extract. The physical files are copied from their libraries with their field definitions and descriptions.
  2. Validate. Row counts are compared file by file. Balances must tie out: the AR and AP transaction files to their control accounts, the asset and payroll files to the GL, and the trial balance per period to what ASW itself reported.
  3. Parallel read access. Finance, tax and audit users work in ArchiveHub while the IBM i is still available, and confirm they can answer their usual questions.
  4. Retire after acceptance. Obtain documented sign-off for data reconciliation, document retrieval, user access, retention and legal holds, recovery and remaining integrations. Retire only the approved components; shared infrastructure may still be needed. End or reduce subscriptions, licences and support only where the contract permits. Budget for archive operation and any residual costs.

The result is a finance history that can be searched in a browser, with nobody needing to remember a 5250 menu option.

Questions about ASW on IBM i retirement

Must retiring ASW also retire the IBM i platform?

No. Inventory other applications, batch jobs, files and interfaces before retiring a partition or host. The application and the shared platform can have different shutdown dates.

What must be identified before validating ASW mappings?

Confirm the product owner, release, installed modules, source libraries and local changes. The demonstration file catalogue is not enough to establish coverage for an unidentified ASW installation.

What does this ArchiveHub demonstration prove?

The screenshots illustrate how selected records can be presented using mock data. They do not prove production completeness, customer outcomes or parity with every ASW on IBM i report. Request a demonstration against your own approved scope and acceptance cases.

Related retirement resources

For the broader project approach, see IBM i application decommissioning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this ASW on IBM i-specific scope rather than replace source-system validation.

Evidence and further reading

The report catalogue and screenshots originate from an internal mock-data demonstration. They are not vendor certification or customer implementation evidence.

For version-specific mappings, obtain the applicable vendor documentation and compare it with the installed system. No independently verified, release-specific mapping reference is supplied with this draft.

Fixed-price ASW on IBM i retirement engagement

ArchiveHub offers a fixed-price engagement for ASW on IBM i retirement and historical data access, based on an agreed scope, deliverables and acceptance criteria. Request a scoped proposal covering your source systems, data, documents, reporting and validation requirements. The proposal should specify included services, exclusions, ongoing platform or hosting charges, and how scope changes will be handled.

Discuss your ASW on IBM i retirement requirements with ArchiveHub

IBM i and AS/400 are trademarks of International Business Machines Corporation. ASW is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by the respective product owners.