It seems logically like there would be, but I can't find much information.

I found an IBM AS/400 manual from 1997, OS/400 Internetwork Packet Exchange (IPX) Support V4R1, which briefly mentions using TELNET with IPX (page numbered 68, PDF page 80):

The jobs that are started by the Start IPX (STRIPX) command are the following:

Job Name Description
QIPX Main IPX job
QAPPCIPX APPC over IPX applications
QTVDEVMGR TELNET Device Manager job

A September 1997 IBM Software Announcement for IBM eNetwork Personal Communications Version 4.2 describes this feature:

TN5250 over IPX/SPX Socket: For 5250 emulation, provides support for Personal Communications as the client side of the connection using the transport protocol AF_IPX over an IPX/SPX socket

TN5250 is just a profile of TELNET, defined in RFC4777 (and its predecessors). Unlike TN3270, it does not use a custom TELNET option (29 for classic TN3270 and 49 for TN3270E), it is negotiated by a specific combination of standard TELNET options. So TN5250 over IPX requires plain TELNET over IPX as a prerequisite. But it isn't clear how TELNET was actually carried over IPX/SPX. Although a "Netware IPX Socket List" reports port 0x9072 as allocated for "SPX TELNET" by "UNIVEL" (Novell and AT&T's Unix subsidiary).

Some other IPX/SPX-based protocols I'm aware of, which while not TELNET perform a comparable function:

  • Novell's NACS (NetWare Asynchronous Communication Service) and NASI (NetWare Asynchronous Services Interface) – which may be two different names for the same thing. MS-DOS Kermit supported them. Ralf Brown's Interrupt List reports it as using INT 6B, and also mentions that Ungermann-Bass Net One was another product with the same API.
  • MS-Kermit also supports something else called "Novell TELAPI", which the Interrupt List also refers to. It also calls it "Novell LWP TELAPI", suggesting it may have something to do with Novell's "LAN Workplace Pro" product
  • I suppose Netware RCONSOLE is another thing which was conceptually similar. I found a buggy / probably non-functional implementation of an RCONSOLE server for FreeBSD. That code reports it uses SPX port 0x8104, which also agrees with the "Netware IPX Socket List" I quoted above.

Can anyone add anything to the above?

  • The traditional way to use an AS/400 is a 5250. Many ways have been devised to emulate this, one being an emulator on a PC. So this is just one of the ways that the emulator can access the AS/400 over a non-IBM network. it is somewhat comparable to what is necessary for having a smartphone access the internet over cell phone technologies May 18, 2023 at 6:54
  • re "equivalent to TELNET" - I assume you mean remote terminal access/remote command interpreter access. Given an API that allows task-to-task communication over a transport layer such as SPX, and a way to get characters to a command interpreter, it's fairly simple to implement passable remote terminal access. This of course depends on the appropriate OS facilities being available; it's unclear to me whether you're really interested in SPX or AS/400. I did it on RSX-11M (before DECnet virtual terminals existed) mostly to avoid having to walk from my office to the computer lab.
    – dave
    May 21, 2023 at 16:46
  • @another-dave whether someone could have done it is a different question from whether someone actually did do it May 22, 2023 at 15:36
  • And whether someone did it is different to knowing whether someone did it. I think I was the only one who knew I did. But that was really my point - it's an obvious thing to do, so we might not know whether it was done; not everything gets heralded, especially if done in a local context.
    – dave
    May 22, 2023 at 16:21

2 Answers 2


Novell Netware (which is the main thing that put IPX into existence) classically is a file and print sharing ecosystem (and some messaging). In the Netware ecosystem, there wasn't anything you could "log into" (maybe with the exception of the remote server console which was intended only for a limited user base and covered by a dedicated application) - So, initially, where was no need for a telnet-like protocol for a long time.

At the point where Netware added more connectivity into classical networking like IBM, DecNet, and Unix, most of its user base that had such ambitions had already switched to Netware over TCP/IP or used LAN Workplace which provided the best of both worlds.


IMS REAL/32 Multiuser DOS was one of the variants of Digital Research Concurrent DOS available in the 1990s. I set up one customer with it in 1996 specifically to use the IMS REAL/32 NET Client software to do terminal sessions over the network. My customer had a Netware network with a bunch of very low-end PCs and one server. They were so basic that not only did they not have hard drives, 10 of hem didn't even have floppy drives, just network boot ROMs. I actually had to install floppy drives on 10 of them in order to use the IMS client software.

Unfortunately, I am having trouble finding the specifics, as the system has long since been replaced. I did find one set of IMS REAL/32 documentation. The main manuals don't say anything (at least not that I have found so far) about networked terminals sessions. However, in addition to the main manuals is a small "Application and Release Notes" pamphlet, which includes a page of addendum to the main manuals, a bunch of application notes and "Notes on Multiport Drivers", which includes a list of drivers for supported serial port and network cards. Which includes this key detail:

  • IMSTERM for Netware Driver

This driver supports the IMSTERM for Netware terminal emulator. IMSTERM for Netware is similar in function to IMSTERM but uses a Novell network instead of serial lines to connect to the IMS Multiuser DOS host.

It requires the IPXnnnnn.COM driver to be loaded from the MCONFIG.SYS before the IMSTERM for Netware driver (IMSNWDRV.SYS).

IMSTERM was originally a serial terminal emulation program for PC-compatibles. Similar to using a PCMode terminal such as a Wyse 60, but on a PC. The big difference between PCMode terminals and ordinary ASCII terminals is that keystrokes were sent as scan codes instead of ASCII. The display codes were similar to native Wyse, Televideo, etc. IMSTERM for Netware sent the data over IPX. Not exactly telnet, but the same basic concept.

I have not been able to find all the necessary details. There was definitely some configuration needed in REAL/32 to tell it how many terminals and in the clients to tell each one which terminal # it was. But I know I had this working in 1996 and my customer was pleased with the results.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .