 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "SIMMON" – news ·newspapers ·books ·scholar ·JSTOR(July 2015) (Learn how and when to remove this message) |
SIMMON (Simulation Monitor) was aproprietarysoftware testing system developed in the late 1960s in the IBM Product Test Laboratory, then atPoughkeepsie, New York It was designed for the then-new line ofSystem/360 computers as a vehicle for testing the software that IBM was developing for thatarchitecture. SIMMON was first described at the IBMSimSymp 1968 symposium, held at Rye, New York.[1]
SIMMON was ahypervisor, similar to theIBM CP-40 system that was being independently developed at theCambridge Scientific Center at about that same time. The chief difference from CP-40 was that SIMMON supported a singlevirtual machine for testing of a singleguest program running there. CP-40 supported many virtual machines fortime-sharing production work. CP-40 evolved by many stages into the presentVM/CMS operating system. SIMMON was a useful test vehicle for many years.
SIMMON was designed to dynamically include independently developed programs (test tools) for testing the target guest program. The SIMMONkernel maintained control over the hardware (and the guest) and coordinated invocation of the test tools.
Two modes of operation were provided:
In this mode, eachinstruction in theguest program wassimulated without ever passing control directly to the guest. As anInstruction Set Simulator, SIMMON was unusual in that it simulated the same architecture as that on which it was running, i.e. that of theIBM System/360/370. While an order of magnitude slower than Interrupt mode (below), it allowed close attention to the operation of the guest. This would be the mode used by variousinstruction trace test tools.
Interrupt mode (a/k/a Bump mode) constrained theguest program to run inuser program state, with the SIMMONkernel handling all hardwareinterrupts and simulating all privileged instructions the guest attempted to execute. This mode could be used, for example, by a test tool to simulate a hardware device.
These were some test tools that were developed for use with SIMMON.
(ERrorGENeration andTest):This test tool was developed to test thedevice support error recovery in IBM'sPCP (Primary Control Program) operating system, then being developed. It used a novel and very efficienttable-drivenfinite-state machine (FSM) to inject simulated errors and verify that the operating system followed the detailed specifications of actions to be taken to attempt recovery.
The table driven FSM aspect was granted U.S.Patent[1]Archived 2017-02-15 at theWayback Machine in October, 1972.
MAPPER (not to be confused with the Unisys product of the same name) was astatisticalperformance analysis tool.It operated by allowing the program under test to run inInterrupt mode, but also used the system timer to periodically interrupt it. The addresses where the tested program was interrupted were recorded and later summarized and tabulated in the form of a map, showing the density of interrupts over the memory addresses. The result resemblednuclear scintigraphy images, showing the parts of the program most frequently used under the test conditions.
HOTSPOTS was aninstruction trace tool written to help identify performance problem areas inIBM's MFT operating system.Branch trace data was written to tape, then summarized. The report took the form of a listing similar to astorage dump, with program entry points and exit points identified, including frequency of use for each instruction sequence.
These data identified theMemory Management component as consuming about 20% of CPU resources, and was used to justify atask force to try to improve the performance.
While not a specific test tool, the distorted timing relationships while running under SIMMON found a number of problems, particularly in theinput/output sections. Unless a SIMMON tool was put in place to normalize and delay I/O events, these would appear to the guest program as happening unnaturally quickly.
Programs under test -- so-calledguest programs -- had to be capable of stand-alone operation on the bare hardware. SIMMON provided services for the test tools, but not for the guest.
These were some of the programs that had been tested using SIMMON: