IBM OLIVER (CICS interactive test/debug)

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.

History

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."

IBM now markets a competing debugging and profiling product known as "Debug Tool for z/OS" that encompasses features of the OLIVER product (including storage protection^[1]) 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."

Technical details

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.

Non-invasive breakpoints

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.

Conditional pause

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"

Remote debugging

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

See also

• Software Testing portal
• Assembly language
• CICS
• Computer programming
• Core dump
• Debugger
• XPEDITER
• 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

Further reading

• "An introduction to memory damage problems" by Dr. Newcomer

References

External links

• IBM CICS official website hardware plus software required wild branch prior art