Not long ago the OS/2 Museum acquired a boxed copy of the IBM PC LAN Program (PCLP) version 1.3 (1988) on 3.5″ floppies. The IBM PC Network Program (1985), later renamed to the IBM LAN Program, was IBM’s first PC LAN networking software, notable for using NETBIOS and the SMB protocol. Because of its reliance on the NETBIOS software interface, PCLP survived the transition from the original IBM PC Network hardware to Token Ring and later to Ethernet (“later” because IBM supported Token Ring first, not because Token Ring is older than Ethernet).

Rather unusually, it is easy to find a copy of the original PC Network Program and PC LAN Program 1.1 online, but not version 1.2 or the last one, 1.3. PC LAN Program 1.3 is notable for being sold by IBM until 1997 and overlapping with the OS/2 LAN Server in the market. In fact either the DOS LAN Requester shipped with LAN Server or PCLP 1.3 could be used as a LAN Server client.

PCLP 1.3 is also significantly different from the earlier PCLP releases in that it can still be used as a more or less unstructured peer-to-peer network, but also supports “Extended Services” with domains, dedicated servers, user logons, and remote booting (RPL/RIPL) of diskless workstations. At $225 (or $90 upgrade), PCLP 1.3 was not even all that expensive.

The catch with PCLP 1.3 is that came out in 1988, very shortly after DOS 4.0. It supports DOS 3.3 or 4.0 servers and workstations. Now the problem is that DOS 3.3 (at least IBM’s) only supports 32MB partitions, and DOS 4.0 is a memory hog. PCLP itself consumes quite a lot of memory and it is next to impossible to start a PCLP server and still run the user interface required to manage it (the interface can be also run remotely, but that’s an extra inconvenience):

The obvious solution would be to run PCLP 1.3 on top of DOS 5.0 with UMBs. But of course that does not work out of the box because PCLP is too tightly integrated with DOS (notably using the DOS 4.0 IFS interface which is not present in DOS 5.0). And, of course, given that PCLP was sold into the mid-1990s, IBM did have updates that made PCLP 1.3 compatible with DOS 5.0, and the updates are even mentioned in the IBM DOS 5.0 announcement letter. It is finding those updates that turned out to be nearly impossible.

PCLP 1.3 Version History

The newest file on the PCLP 1.3 installation floppies is dated June 16, 1988. The initial PCLP 1.3 release was scheduled for availability in July 1988.

There were PCLP versions 1.31, 1.32, 1.33, and 1.34. These were available in the form of CSDs (Corrective Service Diskettes) applied to the released 1.30 media. It is unclear if IBM also shipped updated installation media. Ads for PCLP 1.3 can be found in InfoWorld as late as September 1992, with part number 84X0076. There are references to 85X0076 being PCLP 1.33 or even PCLP 1.34, but the exact same part number was also used for the initial 1988 release.

The timeline of PCLP 1.31 and 1.32 is unknown. But it is known (page 65 in PDF) that there was:

  • PCLP 1.33, CSD IP00249, released May 15, 1990
  • PCLP 1.34, CSD IP00755, released June 26, 1991

It is obviously the PCLP 1.34 update that is of particular interest since it was released very shortly after DOS 5.0. But the PCLP 1.33 update would be useful too, since the IBM DOS 5.0 upgrade came with fixes for PCLP 1.33 that should be sufficient to make it compatible.


The CSDs were originally distributed through IBM service channels, but at least the 1.33 and 1.34 updates were also available on IBM’s BBS systems. Armed with the CSD numbers, we can see that the PCLP 1.34 update was also available on the IBM PC Company FTP (pccbbs FTP) as late as as August 1999. It should be a breeze to find those files, right? Well…

There are pccbbs FTP mirrors, but apparently none old enough to have captured the PCLP CSDs. I have also dug through countless 1990s shareware and IBM CDs in the OS/2 Museum’s archive, but without success.

Part of the problem may be that the PCLP product was either mostly orphaned within IBM or somehow a victim of IBM’s organization and reorganization. There is very little to be found about PCLP in IBM resources geared toward DOS, and next to nothing in resources from the IBM LAN Systems group. There are mentions that the PCLP CSDs were at one time available on IBM’s OS/2 BBS, which seems odd, but it’s reflected in the fact that the IP00755 floppy images once lived in the os2_fixes directory on the pccbbs FTP. Either way, the files appear to be gone.

The only thing that survived is an updated REDIR50.EXE, labeled as “Dos PCLP 1.34 database fix, IP00755”. Unfortunately that is a small fix to be applied to PCLP 1.34, not the actual PCLP 1.34 CSD.

Does that mean the CSDs are completely gone? Well, not quite. More searching turned up a different BBS file list with three archives with a very promising sounding description, “PCLP 1.33 to 1.34 (IP00755)”. Warez to the rescue?

The site owner kindly provided the three files. And sure enough, they turned to be exactly what the description said, with IBM DSK files (35IP7551.DSK, 35IP7552.DSK, and 35IP7553.DSK) inside. These appear to be unmodified floppy images distributed by IBM sometime in the early 1990s, and captured by warez couriers in 1994. Floppy images converted to the now common raw format are available here.

The CSD floppies can be used to either update an existing PCLP 1.3x installation, or to update the PCLP 1.3 installation media for new installs.

And the CSD floppies did their job—I was able to install PCLP 1.34 on top of IBM DOS 5.02, and using EMM386 get enough free memory that it’s possible to logon to the PCLP Extended Services on the server:

That also allows the PCLP management interface to run locally on the server:

After shelling out to DOS, there is about 260KB memory available, which is not a lot. But basic DOS operations like moving files around can be done, and the PCLP server configuration can be checked:


Still Missing

The whereabouts of CSD IP00249 are still unknown, as well as any earlier PCLP CSDs (updates to versions 1.31 and 1.32 from the late 1980s).

This entry was posted in Archiving, IBM, Networking, PC history. Bookmark the permalink.

9 Responses to PCLP CSD Hunt

  1. Is PCLP 1.3, like, the only known software to make use of the DOS IFS interface?

    I’m not sure why it wouldn’t work with DOS 5.0, given that it works with DOS 3.3 (which doesn’t use IFS). Is it hardcoded to try and use IFS whenever ver >= 4.0? In that case, would SETVER do the trick and allow it to work with DOS 5.0 out of the box?

    Related question: what is the purpose of the IFS interface anyway? Last time I checked, the interrupt calls it provides were essentially a replica of the network redirector interface; I know that IFSFUNC contains some network error messages, and I have also heard that while the redirector interface was never properly documented, the IFS interface was supposed to be standardized once for all and documented (however I have never seen any proper documentation). Was it really necessary to provide a whole new set of function calls for the IFS to work?

  2. Michal Necasek says:

    Yes, PCLP may well be the only IFS user. I think the at least some of the redirectors out there were tied to specific DOS versions enough that it could not be faked; Microsoft distributed updated REDIR.EXE for their own (and OEM) products with MS-DOS 5.0 as well. I haven’t tried it myself but I think if it were that easy, IBM would have mentioned that. MSCDEX.EXE likewise had to be updated to support DOS 5.0.

    As far as I know, the IFS interface was meant to provide a stable (not hopelessly tied to DOS internals and a specific version) redirector interface. But then IBM failed to document the IFS interface, which meant no one except IBM used it. I expect that’s why Microsoft dropped the IFS interface from DOS 5.0 again, and DOS 5.0 was really the last version with significant internal changes so from that point, writing to the “old” ugly redirector interface was more practical.

  3. Richard Wells says:

    IBM had plans to use the IFS for other products. See https://patents.google.com/patent/US5307497A/en for a patent showing how to stick DOS 4 into ROM and access the ROM through IFS.

  4. Michal Necasek says:

    That may have happened, there was ROM DOS 4.0. I don’t know off hand if it used the IFS interface. I’m also not entirely sure it would count as a “product” since it certainly wasn’t something one could install on top of DOS 5.0.

  5. Yuhong Bao says:

    I can’t imagine the DOS 3.x PCLP redirector working in DOS 5.0, as the redirector interface changed in DOS 4.0 as well.

  6. ForOldHack says:


    That is version 1.0, 1.1 and 1.2. When they upgraded to 1.1 on the AT at school, they upgraded the HD, and ran into the 3.3 32MB limit… I suggested they use OnTrack Disk Manager, and its associated driver, which apparently was transparent to PC Net… did you try that?

    I was trying to remember what kind of drive, you took a jumper off, and it doubled the speed …

  7. Michal Necasek says:

    The PCLP 1.2 archive showed up less than two weeks ago, but I have my own disks anyway. It’s only minimally different from PCLP 1.1 in any case (whereas PCLP 1.3 is quite a big jump).

    Yes, OnTrack Disk Manager or similar should work. PCLP does no direct filesystem access, everything goes through DOS, so it really ought to work. Haven’t tried it, and I now wonder how much memory that needs.

  8. ForOldHack says:

    I think they used OnTrack Disk Manager 3.1, OEM for HP, on a ESDI 330Mb drive, in a IBM AT 099. A Way lot of storage, jumping up from the 22.5MB Drive that they had in there… ( it was some drive that if you set the geometry at 615, 4, you got exactly 20MB, but if you set the drive at 640, 4, you got 22.5Mb… CMI model 6426)

    The ram was a problem too, they had 512 on the motherboard, and a 512 card, but needed 640, so the 512 card only got 128K used on it.

  9. Michal Necasek says:

    CMI 6426, that was the infamous original PC/AT hard disk that failed a lot, wasn’t it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.