| Introduction |
 |
EASY/Exit allows installations to take advantage of the 'hidden' functionality available in z/OS and DFSMShsm without the need for complex, hard-to-maintain assembler-language exit routines.
The simple IF-THEN-ELSE logic of the Storage Control Center rules language provides an easy-to-use way to implement useful, even critical, system features that would be difficult or impossible for most installations to provide otherwise. Unlike hand-coded exit routines, EASY/Exit rules can be dynamically modified, and come with extensive debugging and error recovery features.
| Description |
 |
z/OS, OS/390, and many IBM program products
provide exits which give installations the ability to extend the scope
and functionality of the system. Many companies gain a strategic advantage
over their competitors through the use of customized system and product
exits to provide critical features and function unavailable elsewhere.
However, the use of such exits has sometimes been problematic because
exits:
- must be coded in assembler language
- often run in an APF-authorized environment in key 0
- sometimes required an IPL to activate or remove
- usually require system programming specialists to develop and maintain
- rarely have imbedded recovery and debugging facilities
Eliminating the Need for Programming - EASY/Exit contains
code which interfaces with each supported exit point. This code performs
the required initialization and termination for the exit as well as establishing
a recovery environment in case of errors. Most importantly, though, the
code provides access to all of the exit’s input and output parameters
in the form of easy-to-use variables which can be examined, set, tested,
and manipulated without the need for any programming. The code established
by EASY/Exit has everything except the logic your installation wants to
implement, which you provide with a set of simple, flexible, IF-THEN-ELSE
rules.
The IF-THEN-ELSE Language - Your installation logic
is implemented with the same IF-THEN-ELSE rules language used by all DTS
Software products. EASY/Exit makes the input and output parameter information
available as symbolic fields to the rules language, along with many other
variables that may be useful in providing the required function.
For example, the following rule allows additional CPU time for critical
jobs running over the weekend. In this example, jobs whose names begin
with the characters ’PR’ (indicating, perhaps, an important
production job) are allowed up to 5 minutes of additional CPU time, in
one-minute increments, if the job is executing on a Saturday or Sunday.
During the week, the normal CPU time limitations apply.
DEFRULE MORETIME
IF &ENV = JOB_CPU
&JOBNAME = PR*
&JOBSDAY = (SATURDAY, SUNDAY)
&JOB_CPU_EXT LT 4
THEN SET &ADDITIONAL_TIME = 60 ISSUE WRITEMSG(USERMSG)
DEFMSG USERMSG
’CPU TIME WAS EXTENDED BY 60 SECONDS’
The rules language can be changed at anytime, and updated with a simple
DIF REFRESH command. The rules language has extensive debugging facilities,
so you can run test jobs to watch the flow of logic through the rules.
Consolidated Rules Logic - The rules used by various
exits can be consolidated into a single file, or grouped into different
members based on exit type. Each exit runs the rules language with environment
variables (&ENV, &ENVS) set to unique values. The rules can test
the environment variables, and set the other necessary variables accordingly.
Exits that Communicate - The product provides many
capabilities that are far beyond the scope of a typical exit. Most hand-coded
exits are used to make simple yes or no decisions and pass a return code
to the caller. In contrast, EASY/Exit allows installations to make much
more detailed and sophisticated decisions in the rules logic. The rules
can dynamically build messages and/or records, and write them:
- to the TSO or JOB that called the exit
- as SMF records
- directly to specified TSO users
- to log files allocated to the DIF started task (this can be done
from environments that don’t allow I/O). The log files can be
sequential or VSAM KSDS data sets.
- to MQSeries message queues
- to TCP/IP ports
Performance - Most of the products written by DTS Software
execute in very performance sensitive areas of the operating system. The
code used by EASY/Exit uses the same design methodologies and practices
as the rest of the DTS products. Our developers are always concerned about
performance, and we have been very successful at creating products with
very low overhead. In the usual case, the overhead of EASY/Exit processing
should be so low as to be unmeasurable.
EASY/Exit uses proven technology - The developers at
DTS Software have been writing highly sophisticated and functional system
software products for many years. EASY/Exit makes use of technologies
written for the company’s system software products to eliminate
the need for assembler-language coding and allow the use of exits in a
way that is much easier to use and much more reliable. Logic implemented
through EASY/Exit can be activated or removed instantly through the product’s
Dynamic Install Facility (DIF). No IPL is ever required.
Currently, EASY/Exit supports approximately 30 exits.
- z/OS Exits
- DFSMShsm Exits
- ABARS Exits
| Benefits |
 |
Capabilities Reinstated
- Recovers abilities lost with diminished Assembler skillets
- Replaces assembler exits with CLIST like language exits
Powerful Functionality
- Prevents production job failures (S322, S522, tape mounts)
- Exploits functionality of z/OS, DFHSM and ABARS exits
Ease of Use
- Simple English-language rules
- Installs from a CD, tape or web download
- No SMP/E or IPL necessary
| History |
 |
All DTS products rely on the Dynamic Install Facility (DIF). In fact, about 90% of the code in a DTS product is actually part of DIF – modules called “Common Service Routines”. Besides actually installing and removing products, DIF controls the rule compiler, console interface, memory management, record logging, and trace facilities.
Since DIF is capable of hooking almost anything in an operating system, the concept of creating a product that dynamically installs system exits was frequently discussed by our developers. The product would use small generic exits that handle everything except the exit logic required by an installation. The customer would simply code rules in a high-level IF-THEN-ELSE language that’s easy to change, and has far greater functionality and debugging capabilities than anyone would be willing to write using an in-house assembler exit.
The first version of the product was delivered in January 2003. Support for additional exits has been added over the years – usually at customer request.
|