Port 157: KNET/VM Command/Message Protocol — Whispers Between Mainframes

Port 157 is assigned to the KNET/VM Command/Message Protocol, known in IANA's registry as knet-cmp. It operates on both TCP and UDP. If you have never heard of it, that is because the world it served has largely disappeared.

What KNET/VM Did

The KNET/VM Command/Message Protocol facilitated command and message passing between IBM VM/CMS systems.¹ VM, short for Virtual Machine, was IBM's family of mainframe operating systems that could run multiple virtual machines on a single physical machine, each with its own operating system instance. Most of these virtual machines ran CMS, a lightweight, single-user environment comparable to a personal computer.²

KNET/VM gave these systems a way to send commands and messages to each other over TCP/IP. In an era when IBM mainframes dominated enterprise computing and IBM's proprietary Systems Network Architecture (SNA) was the default networking stack, TCP/IP protocols like KNET/VM represented the early bridge between the mainframe world and the Internet world that would eventually replace it.³

The Registration

Port 157 appears in RFC 1340 ("Assigned Numbers," July 1992) with the reference code [77,GSM11].⁴ That code maps to Gary S. Malkin of Xylogics, Inc. in Burlington, Massachusetts.

Malkin was far better known for his other work. He authored the RIP Version 2 specifications that defined how routers exchange routing information across networks.⁵ He wrote the TFTP Option Extension that gave the venerable file transfer protocol the ability to negotiate parameters.⁶ He wrote "The Tao of IETF," the guide that welcomed newcomers into the Internet standards community and taught them how the process worked.⁷

And somewhere in the middle of all that, he registered port 157 for a protocol that let IBM mainframes talk to each other.

Gary Scott Malkin passed away on January 19, 2025, after a career that spanned Xylogics, Nortel, Spartacus, and Oracle.⁸ His name remains in RFC 1340, next to port 157, next to a protocol almost nobody remembers.

The Era It Belonged To

The late 1980s and early 1990s were a transitional moment for IBM mainframes. SNA had been the dominant networking architecture for large enterprises throughout the 1980s, but TCP/IP was gaining ground.⁹ IBM eventually produced TCP/IP stacks for VM/SP and VM/XA, supporting IPv4 networks through various interface systems including channel-to-channel links and specialized relay hardware.²

Protocols like KNET/VM were products of this transition. They existed in the space between IBM's proprietary networking world and the open Internet that was rapidly expanding. By the mid-1990s, TCP/IP had won decisively, and many of these bridge protocols became unnecessary. The mainframes themselves continued, eventually evolving into today's IBM Z systems, but the networking landscape around them transformed completely.

Technical Details

How to Check If Something Is Listening on Port 157

On most modern systems, nothing will be listening on port 157. But if you want to verify:

# macOS / Linux
sudo lsof -i :157

# Linux with ss
sudo ss -tlnp | grep :157

# Windows
netstat -an | findstr :157

# Scan a remote host with nmap
nmap -p 157 <hostname>

If something is listening on port 157, it is almost certainly not running the KNET/VM Command/Message Protocol. Investigate accordingly.

Why Ports Like This Matter

Port 157 is one of thousands of well-known port assignments that no longer see active use. These ports are archaeological markers. They tell you what mattered at a particular moment in the history of networking: which systems were dominant, which problems were urgent, which engineers cared enough to register a number.

The well-known port range (0-1023) is controlled by IANA and requires formal registration.¹⁰ Getting a number in this range meant your protocol was considered important enough to reserve a system-level port. Port 157 earned that designation. The fact that the protocol behind it has faded does not diminish what it represented: a moment when someone needed IBM mainframes to exchange commands over TCP/IP, and built a protocol to make it happen.