MPTMON

MPTMON, the Multi Processor Test Monitor, was the in-system debugger of ITT’s System 12 digital telephone exchange, which Alcatel later sold as Alcatel S12. A System 12 exchange had no central computer. Its control was spread across many Intel x86 “control elements” (CEs), and a conventional in-circuit emulator could only be clipped onto one processor at a time. MPTMON gave testers ICE-86-style commands that reached any processor in a running exchange from one terminal. Over time that command line became a small programming language, with symbols, parameterised macros, structured loops and conditionals, and a way to build a command at run time and execute it. MPTMON is catalogued here as a monitoring language for that reason: testers wrote programs in it to watch and control a live switch.

A note on sources. Almost everything known publicly about MPTMON comes from one document: the MPTMON User Manual, Alcatel document 211 31515 AAAA EA, edition 013, dated 15 June 1991. A copy of it circulates on document-sharing sites. No other public source discussing MPTMON was found: web searches, Wikipedia, the Internet Archive catalogue, GitHub and the online HOPL index were all tried. Code samples on this page come from the manual’s own examples. The manual’s two-column layout was flattened when it was extracted, so line breaks have been restored, but the commands themselves are unchanged.

History and Origins

System 12

ITT began designing System 1240 in 1977 at its Advanced Technology Center in Connecticut. It was one of the most ambitious digital switching projects of its day and reportedly cost about a billion dollars. Its distinguishing idea was fully distributed control. German-language sources stress that, unlike Siemens’ EWSD, System 12 had no coordination processor. Instead, many microprocessor-based control elements cooperated over the switching network. ITT’s Belgian subsidiary BTM installed the first production exchange at Brecht in August 1982. ITT’s German company Standard Elektrik Lorenz (SEL) in Stuttgart developed the variant sold to the Deutsche Bundespost. After ITT’s attempt to sell System 12 in the United States failed in 1985–86, the telecom business was sold to France’s CGE and became part of Alcatel in 1987.

Software for such a machine is hard to test. A fault might involve messages passing between processes on several control elements, and the exchange cannot simply be stopped. Engineers already knew Intel’s ICE-86 in-circuit emulator, but it worked on one processor through a hardware pod. MPTMON’s preface says it was written “for testers which have experience in integration testing using ICE86 as test support tool.”

Who built it, and when

The 1991 manual lists five SEL Stuttgart engineers as responsible for MPTMON’s design and maintenance:

The manual gives no date for the first release. The encyclopedia catalogue dates MPTMON to the 1970s, but no source supports that. MPTMON emulates the ICE-86, which was itself a product of about 1979. The first System 12 exchange went into service in 1982. The earliest date in MPTMON material is an example report stamped 28 October 1984 in Stuttgart. That date comes from a test exchange’s clock, which was not always reliable, since another log in the manual gives the wrong weekday for a 1990 date. Library macros reproduced in the manual were written in autumn 1986. The manual also refers to “the first release of MPTMON V2.6 (User Guide edition 11)”, so by 1991 the tool had been through at least two major version lines and a dozen manual editions. A mid-1980s origin is the most the evidence supports, and that is why this page gives c. 1984.

Design Philosophy

The manual states MPTMON’s main constraint plainly: it “runs in real time and [is] not able to halt the processor.” Several design choices follow from that:

• Controller and Slave. A dedicated Permanent Test Control Element (PTCE) runs the MPTMON Controller. The Controller handles parsing, syntax checks, expression evaluation, macros and compound commands. Every other processor runs a small MPTMON Slave, which executes only primitive requests such as “read memory” or “write memory” and sends back a response buffer. The two communicate over a User Controlled Path (UCP) through the exchange itself.
• Software breakpoints only. MPTMON sets a breakpoint by patching code so that a procedure in the Slave is called. The manual notes that “MPTMON on its own, can’t offer any HW breakpoint features like ICE does”. Register values are therefore only “a snapshot of the micro processor status at that moment when a SW breakpoint is matched.”
• ICE-86 familiarity. MPTMON adopts ICE-86 register names and, in the manual’s words, “the full set of ICE86” operators, so that testers who knew the emulator could start using it straight away. The manual points out where it differs. For example, it gives SEG and OFF a different priority so that SEG.A:OFF.B builds a new pointer, something ICE-86 did not allow.
• Terse, terminal-sized syntax. A command line may not exceed 80 upper-case characters, “i.e. one screen line”. Only the first two or three characters of a keyword are evaluated, so DEF MACRO and DEF MAC mean the same thing.

Key Features

Syntax basics

Every command follows one pattern: a main keyword, symbol reference or macro reference, then an optional specifier, parameters and a ; comment:

[MAIN-CMD [CMD-SPEC]] [parameter,...] [;comment] cr

Expressions can be nested deeply. One example in the manual follows a pointer chain through exchange memory:

WOR(POI(POI 407F:6)+18)

The manual says MPTMON has over 100 commands. They are grouped into test-session, control-element, memory display and modify, symbol, macro, compound, breakpoint, message, call, software trace, hardware trace, display, library, file, MMC (man-machine communication), event-handling, work-area and resident-macro-table commands.

Built-in keywords

Besides commands, MPTMON defines synonym keywords that stand for values. Examples include TRUE and FALSE, PTCE, and LWA, a 2048-byte “local work area” intended as scratch memory for macros. IEC holds the internal error code and EVC the event code. PID is the process on breakpoint. CBU is a 32-byte call buffer and MSG the last received message. TMC gives the target machine code: 0 for an 8086, 1 for an 80286 or 80386 in real mode, 2 for an 80286 in virtual mode, and 3 for an 80386 in virtual 16-bit mode.

Symbols with stack scoping

DEF creates or overwrites a symbol. ADD pushes a new one onto a symbol stack without checking for an existing symbol of the same name. When a macro exits, the stack is cut back, so symbols created with ADD act as local variables:

DEF .LOOPI = 1                    ;defines a temp. symbol
DEF .MPTMON = 867B:0              ;a GSM start address
DEF .VN = POI(POI 407F:6)+24      ;a table pointer, etc.
ADD .A,.B,.C=5,.D,.E              ;a set of local symbols

Parameterised macros

A macro is a named block of commands ended by EM. It can take up to ten text parameters, %0 to %9. %N gives the number of actual parameters and %L the length of the first one. %Q stops and prompts the operator for input. From the manual:

DEF MACRO LCE_ID (network-address)
ACT %0
WRI 'LCE_ID OF NA ', %0, WOR .DLS+42
EM

DEF MAC TEST
WRI 'ENTER CE NETWORK ADDRESS -----',&
ACT %Q
WRI 'NETWORK ADDRESS IS = ',WOR ROMD
DAC
EM

ACT activates a control element and DAC deactivates it. Macros may call other macros, but “a macro shall not invoke itself recursively.” Macros can be kept in memory, in libraries or in “resident macro tables”. The manual says the tables serve “a special application of MPTMON to implement user defined Macro Languages.”

Compound commands

MPTMON has structured control flow. Each clause goes on its own line, or inside a macro it can be separated by a backslash:

Here is a manual example that walks through network addresses and reads a word on each control element:

DEF .NA = 5
REPEAT
WHILE .NA > 0
.NA=.NA-1
WRI 'NETWORK ADDRESS = ',.NA
ACT .NA
WOR 867B:5
DAC
END

These loops run on a processor inside a live exchange, and the manual warns about what can go wrong. A REPEAT loop with no internal wait state (no Slave access, no output, no event scan) will “cause a boot of the PTCE processor forced by the sanity timer.” A COUNT loop that runs for more than about 8 seconds without target or I/O access may be killed by the operating system’s process audit. Long loops are expected to call EVE to check for events.

Run-time evaluation

The %(expr) construct replaces itself with the text of an expression’s value. With it a program can build new symbol names, or build a command in memory and then run it. Both examples are from the manual:

DEF .A=0
BAS=T
COU 16T                ;define 16 symbols
DEF .ABS%(.A) = .A
.A=.A+1
END
REM .A                 ;symbol .ABS13 has value 13T

BYT LWA = 'EVA 0'      ;compose text in memory
BAS=A                  ;output base is ASCII
%(BYT LWA LEN 5)       ;execute EVA command stored in memory

This gave a test-monitor command line much of what an eval gives a scripting language.

Debugging and exchange-specific facilities

• Disassembler and line assembler for 8086/80286 code, using ITT’s SRASM assembler syntax. The V3.9 change list says both were extended, but the extracted text of the manual does not make clear whether that included 80386 instructions. Its PAT command patches code instruction by instruction in a running CE.
• Software and hardware tracing. Commands trace the messages of a process (TRC PID), System Support Machine (SSM) calls, database relations, and the whole environment of a Finite Message Machine (FMM, the System 12 software module) (TRC ENV). With additional TRF trace boards, MPTMON can also trace executed code.
• Operating-system awareness. FET FMM, FET SSM, FET REL and FET PID locate software modules, database relations and processes, and load their addresses into the register keywords for use in later commands.
• MMC integration. MPTMON can send commands to the exchange’s man-machine dialogue, read back translated reports through the RBF keyword, and scan them in macros.
• Batch processing. Command files and macros can run as background batch processes.

Evolution

The 1991 manual lists the changes between “the first release of MPTMON V2.6” and V3.9 “re-delivered for SKR 6”. These show what the tool was being used for:

• New keywords (TMC, MP, ROMD, IDT, GDT, LDT) so that macros could be “as independent as possible from the hardware of the selected CE” in a Release 6 exchange that mixed 8086, 80286 and 80386 boards.
• A change to the priority of AND and OR, and a new XOR operator.
• Pointer comparisons redefined as unsigned comparisons on the offset.
• Loading of 80386 target CEs, with a hand-off to the ROM Debug Monitor (RODEM).
• New tracing commands (TRC PID, TRC ENV, SSM and database tracing) and variable-length, cyclic trace buffers.
• Password control over changes to non-default macro libraries, and read-only authorisation by default for sessions started from a system VDU.
• A macro-driven HELP command.
• The end of Hewlett-Packard terminal support. Because the HP terminal “was the only one with a proper handling of formatted screens, menus and forms,” the screen-form commands were removed. The manual’s reference list names Tandberg, DEC VT100 and Olivetti terminals.

No public information was found on any MPTMON version after V3.9.

Current Relevance

MPTMON was internal tooling. It was never sold separately and never published outside ITT, SEL and Alcatel. No source says when it was retired, though its “Historical” status in the catalogue fits a tool tied to 8086–80386 System 12 hardware of the 1980s and early 1990s. Alcatel 1000 S12 exchanges stayed in service in public networks long after that, but no public source says whether later generations of the platform kept MPTMON or replaced it.

No implementation, emulator or source code is publicly available. The 1991 user manual is the only surviving public record.

Why It Matters

MPTMON is a good example of a common pattern: a debugger’s command line slowly turns into a programming language. It started as an ICE-86 workalike. Testers needed to repeat procedures across dozens of processors in a machine that could not be stopped, so it gained variables, local scope, macros with prompts, structured loops, and a way to build and run code at run time. It also had to respect the real-time limits of a telephone exchange. Few other languages had to warn programmers that a tight loop would make the hardware watchdog reboot the processor.

It also shows how the large switching systems of the 1980s were built. CHILL, the CCITT language for switching software, appears in the manual’s own abbreviation list, but these systems also relied on in-house tools and languages, most of which were never documented outside the companies that made them.

Sources

• MPTMON User Manual, Alcatel / SEL Stuttgart, document 211 31515 AAAA EA, edition 013, 15 June 1991 (213 pages). This is the source for all MPTMON-specific facts on this page.
• Wikipedia, “ITT System 12” and German Wikipedia, “System 12”, for System 12 design dates, the Brecht installation, SEL’s role and the formation of Alcatel.
• CPU Shack and Intel’s ICE-86A operating instructions (May 1981) for the ICE-86’s era and purpose.