IBM OLIVER (CICS interactive test/debug)

IBM OLIVER (CICS interactive test/debug)

Screenshot of OLIVER - (CICS Interactive debug). COBOL example
Developer(s) Ken Dakin
APT Ltd
Initial release 1972
Stable release n/a / 18 November 1994 (1994-11-18)
Operating system MVS, MVS/XA, MVS/ESA, DOS/VSE
Platform IBM/360,370/390/ES9000 & later compatibles
Type Debugger, Memory debugger, Hypervisor
License Proprietary software
Website n/a

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:-

  • 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")
- 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 -

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

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

See also

Further reading

References

  1. ↑ IBM APAR PI06312

External links

This article is issued from Wikipedia - version of the Sunday, March 06, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.