From a post in LinkedIn  "IBM i no longer a category for IBM Redbooks"

On the topic of AS/400 population, future of RPG, and migration

What a great exchange above. Lots of wisdom being shared by such well-qualified people. Amazing that we have no independent knowledge about our own ecosystem. You would think that those committed to the platform would band together to speak with one voice. (COMMON??) We do not even know what our own population is, much less what the future holds from IBM. These fragmented "Groups" and forums are fine, but what we really need is a unified presence and a loud voice. Having access to the entire installed population would be a blessing for vendors like us, the users, IBM, consultants, everyone...

Working with an excellent marketing company, we learned that they have about 200K emails of AS/400 related people, and they estimate 80-100K companies with systems in the US. Their business is to manage and refine their list, and I lean toward their numbers.

As an ISV, we have historically delivered licensed, shrink-wrapped software directly to the customer. They install and run it locally. It performs as a Payment Server, talking directly to their card authorization network of choice and storing transactions securely, encrypted - locally.


In order to accommodate the requirement to help insulate our customers from the burdens of PCI compliance/audits/costs, we realized that we needed to have a CENTRAL Portal, through which their transactions would flow. This would obviously offload the storage of the encrypted cards on their systems. (3 years later, and after an 8 month audit, we are finally certified as secure to the PCI "Service Provider Level 1" standards.)

We are doing this by simply splitting the software into "client" and "server" components. The server side handles the storage and communications with the auth networks. So our business model is changing from licensed software to Software as a Service. (SaaS)

What we are doing is scaling back the "client component" to become only an API. While we do shadow the (non-sensitive) data on the user machine, very little logic remains at the customer site. For us, doing the heavy lifting on the server side at the Portal gives us greater ability to handle sensitive data on behalf of the customer, like our e-commerce Payment Landing Pages.

As a "middleware" vendor, we have the luxury of sitting between two APIs (interface to the order entry/billing and the interface that we certify to at the authorization networks.) Our transaction handling logic COULD be built in any language, but we will absolutely stick to our huge body of RPG for as long as the security auditors allow us. To be PCI compliant, you must be using the latest (ad supported) version of the firmware and OS...

Were we to have to leave RPG, we certainly would have good choices to consider. However, the cost of the recoding would be staggering. And we have excellent operational design documentation for our software. Pity the fool who doesn't and has to attempt a reverse engineer effort...

And the point is (FINALLY) that we are working to minimize the components on the local system. The benefit to the customer is that they have a lighter-weight component with smaller footprint. We have easier updates and support as their side does less.

We get the benefit that we can design and deploy lightweight clients for OTHER platforms, and focus on the logic being on our secure Portal. This is the classic "web services" approach, and will allow us, over time, to support other business divisions within our customer base who are not based on the AS/400 (call it whatever). Since our customers own their card data on file (unlike Gateways), they can use it from any platform they choose, and it is available from the "i", from their e-commerce Shopping Cart, and from other OS's, like Linux and the MS stuff.

WE are moving to be agile when the hammer comes down on the 'i", which is inevitable, though not near imminent. The people I fear for are the SMB AS/400 users whose entire business logic is coded into RPG within their out-of-support ERP system. Roughly half of our customers run home-grown or out-of-support ERP software. The real challenge will be reverse-engineering those rules and externalizing them for future flexibility. Once they have that, their next challenge will be to find a platform as scalable and stable as the venerable AS/400.