Multi-Environment Real-Time (MERT), later renamed UNIX Real-Time (UNIX-RT),^[3] is a hybrid time-sharing and real-time operating system developed in the 1970s at Bell Labs for use in embedded minicomputers (especially PDP-11s). A version named Duplex Multi Environment Real Time (DMERT) was the operating system for the AT&T 3B20D telephone switching minicomputer, designed for high availability;^[4][5][6] DMERT was later renamed Unix RTR (Real-Time Reliable).^[6]

A generalization of Bell Labs' time-sharing operating system Unix,^[7] MERT featured a redesigned, modular kernel that was able to run Unix programs and privileged real-time computing processes. These processes' data structures were isolated from other processes with message passing being the preferred form of interprocess communication (IPC), although shared memory was also implemented. MERT also had a custom file system with special support for large, contiguous, statically sized files, as used in real-time database applications. The design of MERT was influenced by Dijkstra's THE, Hansen's Monitor, and IBM's CP-67.^[2]

The MERT operating system was a four-layer design, in decreasing order of protection:^[2]

• Kernel: resource allocation of memory, CPU time and interrupts
• Kernel-mode processes including input/output (I/O) device drivers, file manager, swap manager, root process that connects the file manager to the disk (usually combined with the swap manager)
• Operating system supervisor
• User processes

The standard supervisor was MERT/UNIX, a Unix emulator with an extended system call interface and shell that enabled the use of MERT's custom IPC mechanisms, although an RSX-11 emulator also existed.^[2]

One interesting feature that DMERT – UNIX-RTR introduced was the notion of kernel processes. This is connected with its microkernelish architecture roots. In support, there is a separate command (/bin/kpkill) rather than (/bin/kill), that is used to send signals to kernel processes. It is likely there are two different system calls also (kill(2) and kpkill(2), the first to end a user process and the second to end a kernel process). It is unknown how much of the normal userland signaling mechanism is in place in /bin/kpkill, assuming there is a system call for it, it is not known if one can send various signals or simply send one. Also unknown is whether the kernel process has a way of catching the signals that are delivered to it. It may be that the UNIX-RTR developers implemented an entire signal and messaging application programming interface (API) for kernel processes.

If one has root on a UNIX-RTR system, they will surely soon find that their ls -l output is a bit different than expected. Namely, there are two completely new bits in the drwxr-xr-x field. They both take place in the first column, and are C (contiguous) and x (extents). Both of these have to do with contiguous data, however one may be to do with inodes and the other with non-metadata.

Example ls -l:

 drwxr-xr-x       root          64  Sun Dec 4   2003     /cft
 xrwxr-xr-x       root          64  Mon Dec 11  2013     /no5text
 Crwxr-xr-x       root         256  Tue Dec 12  2014     /no5data

AT&T, then Lucent, and now Alcatel-Lucent, are the vendor of the SPARC-based and Solaris-OEM package ATT3bem (which lives on Solaris SPARC in /opt/ATT3bem). This is a full 3B21D emulator (known as the 3B21E, the system behind the Very Compact Digital eXchange, or VCDX) which is meant to provide a production environment to the Administrative Module (AM) portion of the 5ESS switch. There are parts of the 5ESS that are not part of the 3B21D microcomputer at all: SMs and CMs. Under the emulator the workstation is referred to as the 'AW' (Administrative Workstation). The emulator installs with Solaris 2.6/SPARC and also comes with Solstice X.25 9.1 (SUNWconn), formerly known as SunLink X.25. The reason for packaging the X.25 stack with the 3B21D emulator is because the Bell System, regional Bell operating companies, and ILECs still use X.25 networks for their most critical of systems (telephone switches may live on X.25 or Datakit VCS II, a similar network developed at Bell Labs, but they do not have TCP/IP stacks).

The AT&T/Alcatel-Lucent emulator is not an easy program to get working correctly, even if one manages to have an image from a pulled working 5ESS hard disk 'dd' output file. First, there are quite a few bugs the user must navigate around in the installation process. Once this is done, there is a configuration file which connects peripherals to emulated peripherals. But there is scant documentation on the CD which describes this. The name of this file is em_devmap for SS5s, and em_devmap.ultra for Ultra60s.

In addition, one of the bugs mentioned in the install process is a broken script to fdisk and image hard disks correctly: certain things need to be written to certain offsets, because the /opt/ATT3bem/bin/3bem process expects, or seems to need, these hard-coded locations.

The emulator runs on SPARCstation-5s and UltraSPARC-60s. It is likely that the 3B21D is emulated faster on a modern SPARC than a 3B21D microcomputer's processor actually runs as measured in MIPS. The most difficult thing about having the emulator is acquiring a DMERT/UNIX-RTR hdd image to actually run. The operating system for the 5ESS is restricted to a few people, employees and customers of the vendor, who either work on it or write the code for it. Having an image of a running system, which can be obtained on eBay, pulled from a working 3B21D, and imaged to a file or put into an Ultra60 or SPARCstation-5, provides the resources to attempt to run the UNIX-RTR system.

The uname -a output of the Bourne shell running UNIX-RTR (Real-time Reliable) is:

 # uname -a
  <3B21D> <3B21D>

Though on 3B20D systems it will print 20 instead of 21, though 3B20Ds are rare, nowadays most non-VCDX 5ESSs are 3B21D hardware, not 3B20D (although they will run the software fine). The 3B20D uses the WE32000 processor while the 21 uses the WE32100. There may be some other differences, as well. One thing unusual about the processor is the direction the stack grows: up.

Manual page for falloc (which may be responsible for Contiguous or eXtent file space allocation):

     FALLOC(1)                   5ESS UNIX                   FALLOC(1)
     NAME
          falloc - allocate a contiguous file
     SYNOPSIS
          falloc filename size
     DESCRIPTION
          A contiguous file of the specified filename is allocated to
          be of 'size' (512 byte) blocks.
     DIAGNOSTICS
          The command complains a needed directory is not searchable,
          the final directory is not writable, the file already exists
          or there is not enough space for the file.

UNIX-RTR includes an atomic file swap command (atomsw, manual page below):

    ATOMSW(1)                   5ESS UNIX                   ATOMSW(1)
     NAME
          atomsw - Atomic switch files
     SYNOPSIS
          atomsw file1 file2
     DESCRIPTION
          Atomic switch of two files. The contents, permissions, and
          owners of two files are switched in a single operation. In
          case of a system fault during the operation of this command,
          file2 will either have its original contents, permissions
          and owner, or will have file1's contents, permissions and
          owner. Thus, file2 is considered precious. File1 may be
          truncated in case of a system fault.
     RESTRICTIONS
          Both files must exist. Both files must reside on the same
          file system. Neither file may be a "special device" (for
          example, a TTY port).
          To enter this command from the craft shell, switching file
          "/tmp/abc" with file "/tmp/xyz", enter for MML:
          EXC:ENVIR:UPROC,FN="/bin/atomsw",ARGS="/tmp/abc"-"/tmp/xyz";
          For PDS enter:
          EXC:ENVIR:UPROC,FN"/bin/atomsw",ARGS("/tmp/abc","/tmp/xyz")!
     NOTE
          File 1 may be lost during a system fault.
     FILES
          /bin/atomsw