IBM OLIVER (CICS interactive test/debug)
Screenshot of OLIVER - (CICS Interactive debug). COBOL example
|Stable release||n/a / 18 November 1994|
|Operating system||MVS, MVS/XA, MVS/ESA, DOS/VSE|
|Platform||IBM/360,370/390/ES9000 & later compatibles|
|Type||Debugger, Memory debugger, Hypervisor|
OLIVER (CICS interactive test/debug) was a proprietary testing and debugging toolkit for interactively testing programs designed to run on IBM's Customer Information Control System (CICS) on IBM's System/360/370/390 architecture.
OLIVER was written in 1972 by Ken Dakin, an independent CICS specialist (who also later produced SIMON (Batch Interactive test/debug), in response to a lack of suitable interactive debugging features in CICS. At the time, most CICS applications were written in IBM Basic assembly language and CICS had no features to prevent storage violations. As a result, errors in application programs frequently caused full CICS dumps and aborted the CICS session for all users. As more customers began using both COBOL and PL/I applications, the software supported these both at the assembly level and at source level from information collected at compile time.
Both OLIVER and SIMON were integrated with Viasoft Inc.'s static analyzer "VIA/Insight" to form the product "VIA/SmartTest", in the late 1980s. The combined product provided additional functionality to COBOL programmers, and the product is still in use at many IBM mainframe sites worldwide today, and is now (2012) distributed by Allen Systems Group as "ASG-SmartTest".
In 2012, IBM belatedly began marketing a similar debugging and profiling product known as "Debug Tool for z/OS" that encompasses many of the features of the OLIVER product (with the exception of storage protection) and its "sister" product SIMON for batch/TSO, claiming similar seamless debugging of mixed-language applications in the same session. It is described as "This sophisticated program debugger provides multiple conditional and unconditional breakpoints, step mode debugging, and the ability to monitor and update variables and storage. Debug Tool is an interactive source-level debugging tool for compiled applications in a variety of development environments".
OLIVER provided source and instruction level Program animation, instruction step ("single cycle"), conditional program breakpoint ("Pause") and storage alteration features for Assembler, COBOL and PL/I programs. High level language (HLL) users were able to see and modify variables directly at a breakpoint.
From the earliest version, OLIVER was a "full screen" debugger, incorporating a multi-line symbolic disassembler allowing program animation. Line commands provided allowed a pause/breakpoint to be set anywhere in the displayed program with a single keystroke. Registers were all displayed continuously (and automatically highlighted if any changes occurred). A "hyperlink-style" feature allowed memory to be displayed using an "L" (meaning load) line command in any register or other fullword memory display.
Oliver also provided fully automatic features to prevent application program errors such as:-
- Program Checks - all types (usually intercepted prior to them actually being executed)
- "Wild branch" - (entirely software detected)
- "illegal SVC" - (CICS applications were not allowed to use any operating system calls)
- "CICS AICA" Abends - ("program loop")
- excessive resource usage including:-
- loops involving repeated CICS macro calls (before a warning - "possible macro loop")
- exceeding a set limit of instructions (before a warning - "possible loop")
- excessive total storage for single transaction ("too much storage")
- illegal or potentially damaging CICS API requests (e.g. attempts to read into non-owned memory)
- - All CICS API calls were effectively "Shimmed" by OLIVER anyhow and checked for validity (If CEDF was also active, control would pass to it quite naturally while stepping through the API call).
It was possible to correct many errors and interactively alter the control flow of the executing application program while still running. This permitted more errors to be detected for each compilation (which, at the time, were often scheduled batch jobs with printed output, often requiring several hours "turnaround", before eventually re-loading the program (using CSMT/CEMT Newcopy) and retrying the failing transaction).
Whatever kind of program error was encountered, OLIVER always discovered it before actual execution took place and always (up to) the last 84 previous instruction locations were immediately available to diagnose the precise path leading to the specific error (true across linked modules of possibly mixed languages, dynamically loaded programs or even dynamically built runtime code). In the case of potential loops, it was possible to re-try until the next threshold was reached.
OLIVER additionally provided fully automatic storage protection features to prevent rogue applications from overwriting storage occupied by other applications ("storage violations", or buffer overflows), OLIVER included complete and automatic protection for CICS system tables and all other otherwise unprotected kernel code.
Instruction set simulator
OLIVER was an instruction set simulator that provided all functions through full simulation of the object code that was under total control of the OLIVER monitoring & execution engine (a form of 'type 2' hypervisor or virtual machine). OLIVER made extensive use of control tables in the execution engine to "reverse engineer" the target programs machine code to generate alternative, but fully protected, simulation code.
The simulation was deliberately limited to CICS application code and EXEC interface code (not the CICS kernel or operating system or hardware), including full instruction trace if required at machine code level. Oliver provided instruction path length metrics at any point during execution, providing a means Performance analysis to perform program optimization, that was important for time sensitive on-line transactions.
OLIVER was fully quasi-reentrant, allowing application programs to be "paused" at different breakpoints by multiple users simultaneously and was entirely "non-invasive" to the targeted application's object code (i.e. did not modify the run time program memory to provide breakpoints). This technique allowed later hardware protected CICS application programs to be monitored with essentially no change to the OLIVER kernel code - unlike many of its competitors - which had used invasive techniques which would no longer work for these programs because of the operating system program protection.
It was also possible to halt execution according to the state of memory or registers, enabling more targeted break-points (than simply pausing before a particular instruction every time it is executed).
Examples: Pause if -
- Register 5 = X'0000000A"
- filename = "File10"
OLIVER also permitted debugging of programs executing on "remote" terminals using a Master/slave technique and also debugging of asynchronous tasks associated with CICS transient data files that had no display terminal available.
Examples of commands
|program name||display "program" (source or disassembly)|
|(line command) "P"||Pause at this line (before execution)|
|(line command) "H"||hold display of this associated data line (watch)|
|"-"||show dissassembled program|
|"+"||show source program|
|(3270) PA1 key||execute single stmt/instruction|
|(line command) "L"||display memory at this address (hyperlink)|
|"Stmt"||switch to statement animation|
|"trace"||provide full instruction trace to CSSL TD queue|
- Software Testing portal
- Assembly language
- Computer programming
- Core dump
- instruction step
- Memory debugger
- Program animation
- Software testing
- SIMON (Batch Interactive test/debug)
- Storage violation
- Debug Tool for z/OS for z/OS and OS/390 
- "An introduction to memory damage problems" by Dr. Newcomer
- IBM CICS official website hardware plus software required wild branch prior art