James Allman | JA Technology Solutions LLC
Teaching the AS/400 to Talk to the Outside World
To move files between an AS/400 and the modem-driven, serial world it was never built for, I wrote the protocols, the asynchronous layer beneath them, and a send-and-expect layer to automate the exchange. The same job, connecting systems that were not meant to talk, is most of integration work today.
In the early to mid 1990s I needed to move files between an AS/400 and machines that had no idea what an AS/400 was. The platform was built for a different kind of network: IBM's own SNA protocols, with terminals and printers hung off twinaxial cable, talking synchronously to the host. What I needed was the opposite of that, the character-at-a-time, modem-and-serial world the PC and bulletin-board era ran on. So I built it: native Xmodem and Ymodem file transfer, a Zmodem implementation I never published, the asynchronous communications layer underneath them, and a scripting layer on top to automate the whole exchange.
I wrote about the low-level CRC routines behind those protocols in a separate piece on the AS/400 machine interface. This one is about the rest of it: making a platform designed for one kind of networking speak a completely different one, and automating the conversation so it could run unattended. That problem, connecting a system to a transport or a partner it was never designed for, is still most of what integration work is.
A platform built for a different network
The AS/400's networking assumptions came from the IBM world it was born into. Terminals were twinax-attached and synchronous, and host-to-host traffic ran over SNA. It was a coherent, reliable design for connecting IBM equipment to other IBM equipment.
Asynchronous serial communication was a different paradigm. Instead of structured synchronous frames, you have a stream of bytes arriving one at a time over an RS-232 line, usually through a modem, with no guarantee any of them arrive intact. The protocols that tamed that stream, Kermit and Xmodem and Ymodem and Zmodem, came from the terminal and bulletin-board world, not the mainframe one.
Bridging the two meant working at both ends of my own stack: low enough to handle the raw byte stream and its timing, and high enough to present a file-transfer tool someone could actually use.
Xmodem, Ymodem, and Zmodem, natively
Xmodem, Ymodem, and Zmodem are block-based file-transfer protocols. The sender breaks a file into numbered blocks, each block carries a checksum or CRC, and the receiver acknowledges good blocks and asks for a resend on bad ones. Zmodem added streaming, better recovery, and the ability to resume an interrupted transfer.
The hardest part was on the receiving side. The AS/400's input was block-based and buffered, built to hand a program a complete record at a time, but an asynchronous serial line delivers bytes with no record boundaries at all. To keep reception fast enough to stay with the sender, I triggered reads on sentinel values in the stream, the protocol's own framing characters, instead of waiting on the platform's block buffering. Getting that timing right was the difference between a transfer that kept pace and one that fell behind and failed.
Below that sat the protocol state machines themselves: framing blocks, validating CRCs, handling acknowledgements, timeouts, and retransmission. The CRC check runs on every block, so it has to be fast, which is why those particular routines dropped to the machine interface, the subject of the companion article. None of this shipped with the platform as something I could buy and bolt on; the business languages the AS/400 was built for were aimed at records and reports, not byte streams and line timing.
Scripting the conversation
Moving a single file by hand is one thing. The real requirement was unattended transfer: reach a remote system, wait for it to respond, work through whatever it expected, move the file, and confirm it arrived, with no person watching.
So I built a scripting layer on top of the transport, in the spirit of Procomm Plus and its ASPECT scripting language, or the Unix and POSIX expect utility: a send-and-expect model. The script sends a string, waits for an expected response, and only then sends the next, so it can hold a structured conversation with a remote system over an unstructured serial line. It was scriptable from CL, the AS/400's native control language, so these exchanges ran under the same job scheduling and operations tooling as everything else on the box.
That send-and-expect pattern is older than any of my code and still everywhere. It is how automated logins, health checks, and device provisioning get scripted today.
What it actually moved
None of this was an experiment. The toolset distributed data out to satellite point-of-sale systems and pulled their data back, and it carried supplier orders, invoices, statements, and similar business documents in and out of the AS/400. Strip away the dates and that is two familiar categories: retail store feeds and trading-partner paperwork, the same two kinds of data I still spend much of my time moving.
The same problem, today
The specifics are dated. Nobody is writing Zmodem for a new project, and the modems are long gone. The shape of the problem is not.
A business still constantly needs to move data between systems that were not designed to talk to each other, across whatever transport each one supports. Those supplier orders, invoices, and statements are EDI documents now, an 850 purchase order or an 810 invoice moving over AS2 or SFTP instead of a modem. The satellite POS feeds are store-and-host synchronization. The transports changed; the job did not.
The work is the same as it was on that serial line: understand both ends, build a reliable path between them, automate the handoff so it runs without a person, and verify that what arrived is what was sent. That is the core of the integration and EDI work I do now.
If you need two systems to talk
If you have two systems that need to exchange data and no convenient way to do it, whether that is an IBM i feeding a trading partner or a modern application that has to reach something far older, that is exactly the kind of problem I take on. Working through one of these connections on your own systems? Ask James. For more of the backstory, see The AS/400 Machine Interface, and Why IBM i Endures, and for the platform itself, IBM i: The Platform Decision-Makers Should Understand.