AS400 Support

Do I need AS400 hardware maintenance, IBM i support, application help, or managed services?

Start with the risk

Start with the part of the system that is causing the risk. If the worry is physical, you are looking for hardware maintenance.

• The server itself
• Disk
• Tape drive
• Power supply
• HMC
• Parts coverage That conversation runs on specifics.

• Machine type and serial number
• Support eligibility
• Replacement parts
• Response time
• Whether IBM or a third party covers it

IBM i support is system administration

If the operating system is the issue, you need IBM i support. That usually means operating system work.

• Releases and PTFs
• Licensing
• Job queues and printers
• Backup configuration
• Security settings
• Performance
• Day-to-day system administration This is not the same as fixing the application that runs on IBM i.

Application support is business logic

If the business application is the pain point, you need application support. Application support reaches into the code and the habits around it.

• RPG, COBOL and CL programs
• Vendor ERP software
• Custom reports
• Integrations and data files
• Workflows only one person still understands

That last line is the real risk, and it is rarely on anyone's asset register.

Managed services are ongoing coverage

If you want someone to watch and manage the environment over time, you are asking for managed AS400 services. Managed coverage usually bundles the routine work.

• Monitoring
• Backups
• Patch planning
• Routine administration
• Escalation
• Documentation
• A named support plan

What machine type, IBM i version, and business application are currently running?

Have the system profile ready

A good AS400 support conversation gets much easier when you can identify the system. A provider will ask for most of this on the first call.

• IBM machine type and model
• Serial number
• IBM i release
• Processor and memory basics
• Storage layout
• Tape or backup method
• Whether the system is physical, virtualized or hosted
• Whether it sits in a high availability pair

Ask for the key IBM i details

If you have an internal IBM i administrator, ask them for a quick system profile. A few commands give you most of it.

• DSPSYSVAL QMODEL for the model
• DSPSYSVAL QSRLNBR for the serial number
• DSPPTF or GO LICPGM for release and installed programs

Then add whatever documentation exists for backup, printers, users, jobs and application dependencies. Usually less than anyone hoped.

Explain what the system does

The business application matters as much as the hardware. Tell the provider what the system actually runs.

• ERP or accounting
• Warehouse
• Manufacturing or distribution
• Custom RPG applications
• EDI
• Reporting
• Integrations with newer platforms Support gets much better when the provider understands what the system actually does for the business.

Is the system stable, at risk, out of support, or ready for an upgrade?

Stable systems still need prevention

When the system is stable, prevention is the cheapest work you will ever do.

• Confirm backups actually complete
• Document the environment
• Review hardware support status
• Check the IBM i release
• Agree a real escalation process

All five are easier now than during an outage, and considerably cheaper.

At-risk systems need triage

If the system is at risk, focus on the risk first. These are the warning signs worth acting on.

• Aging disks
• Failed backup jobs
• No recent restore test
• Passwords nobody has
• No current maintenance contract
• An old IBM i release
• One employee who understands the application
• Hardware that cannot be replaced quickly

Out of support can mean several things

If the system is out of support, do not treat that as one problem. It may mean the hardware is no longer covered, the IBM i release is old, the application vendor has moved on, or the person who built the custom code is gone. Each of those needs a different plan.

Upgrade planning is dependency planning

Once an upgrade is on the table, the support conversation widens.

• Migration planning
• Downtime tolerance
• Application testing
• Backup and restore testing
• Printer and device dependencies
• Third-party software
• Licensing

Then settle the destination: newer IBM Power hardware, hosting or a managed services option.

Can the support provider handle both old AS400 terminology and current IBM Power Systems?

They should translate the naming

Yes, and they should. Many businesses still say AS400 because that is the name everyone remembers. IBM now talks about IBM i running on IBM Power Systems. A useful provider can translate between those names without making you feel like you asked the wrong question.

They should know old and current IBM terms

A good provider is fluent in both the old vocabulary and the current one.

• AS400, iSeries and System i
• IBM i and AIX
• Power Systems
• Hardware maintenance and PTFs
• BRMS and tape
• High availability
• RPG applications
• Current migration options

Fluency across that whole range is rarer than the marketing suggests. Test it in the first call. You do not need all of those, but the provider should know how they fit together.

Good providers ask practical questions first

A good sign is a provider who asks practical questions before selling a solution: What does the system run? What version are you on? When was the last restore test? What breaks if this machine is down for a day? Who supports the application? What are you trying to avoid?

Weak providers rush the prescription

A weak sign is a provider who jumps straight to a replacement, hosting contract, or managed services package before understanding the workload. Sometimes you need a refresh. Sometimes you need maintenance. Sometimes you need documentation and backup discipline first.