User exits - syncsort_simulate_2000 - Latest

Syncsort™ Storage Management Portal 2000 Rules Language Guide

Product type
Software
Portfolio
Integrate
Product family
Syncsort™ software
Product
Syncsort™ Storage Management > Syncsort™ Simulate 2000
Version
Latest
ft:locale
en-US
Product name
Syncsort Storage Management
ft:title
Syncsort™ Storage Management Portal 2000 Rules Language Guide
Copyright
2025
First publish date
1991
ft:lastEdition
2025-11-28
ft:lastPublication
2025-11-28T15:31:25.787000
L1_Product_Gateway
Integrate
L2_Product_Segment
IBM Infrastructure
L3_Product_Brand
Precisely Syncsort
L4_Investment_Segment
Mainframe
L5_Product_Group
Mainframe Storage Optimization
L6_Product_Name
Syncsort Storage Management

The rules language can call installation user exits to perform functions that are not provided in the rules language. The exits run in the same operating environments as SIMULATE 2000. Since most of the environments are very restrictive, a call to technical support can help focus development efforts.

User exits fall into three basic categories:

  • exits that are used for conditional processing in the rules language
  • exits that perform updates in the rules language
  • product defined exits that are external to the rules language

The exits that are used for conditional processing in the rules language are called from the IF section of an IF-THEN-ELSE group. These exits allow your installation to examine information that is not available to the rules language - no symbolic field exists for the information you want to access. An exit can perform the conditional logic required by an IF-THEN-ELSE group, and then use the return code in Register 15 to fail or continue conditional processing for the group.

Exits that update information in the rules language can be called from the THEN or ELSE sections of an IF-THEN-ELSE group. These exits allow your installation to modify information that is not available to the rules language - no symbolic field exists for the information you want to modify. These exits are called via the SET statement.

Product defined exits have pre-defined exit names. No modifications to the rules language is required to activate a product defined exit - the exits are simply activated with the DIF ENABLE EXIT command. Since the product defined exits have unique input parameters and return code conditions, the product defined exits are documented in the appropriate sections of the product manuals. For example, the DIFLOGX exit documented in “Usingthe Log Overflow Exit” on page 4-6.

Writing, Assembling and Link-Editing User Exits

The following guidelines should be used when writing rules language user exits:

  • use standard savearea linkage conventions
  • must be reentrant and reusable
  • runs in the PSW key of the calling environment - usually PSW key 0 for SIMU-LATE 2000
  • on entry, register 0 contains the address of a 500 byte workarea that can be used by the exit.
  • on entry, register 1 contains the address of a 100 byte workarea that can be used by the exit. This workarea can be used to pass information to other exits.
  • a return code must be returned in register 15. When an exit is called from the IF section of an IF-THEN-ELSE group, a zero return code returns a TRUE condi-tion to the IF section, and processing will continue with the statements found in the IF section. A non-zero return code will fail the IF section, and processing will continue with an available ELSE section, the next IF-THEN-ELSE group, or the next DEFRULE statement.

When an exit is called from the THEN or ELSE sections with the SET statement, a zero return code will allow execution of any messages, SMF records and opera-tor commands associated with the SET statement. A non-zero return code will suppress messages, user and SMF records, and operator commands associated with the SET statement.

  • exits must be link-edited into the load library specified on the STEPLIB DD statement allocated in the DIF cataloged procedure, or linked to an installation linklist library.
  • exits should use the appropriate AMODE and RMODE required by the exit. If the exit accesses information found above the 16 megabyte line, the exit should be marked as AMODE=31 or AMODE=ANY.
  • processing in an exit is limited by the environment. No I/O or dynamic allocation requests can be performed for the SIMULATE 2000. Many other system services are limited by the locks held by at the time SVC 11 is issued.

Enabling Exits with the DIF EXIT command

Exits must be enabled in order to be called. The following DIF EXIT command can be used to enable an exit. An exit is associated with a specific product. If the exit is not enabled for a product, the conditional processing in an IF-THEN-ELSE group will ignore the CALLEXIT request and continue rules processing as if the statement did not exist. For more information about the DIF EXIT command, examine “EXIT” on page 7-17 in the Product Installation Guide.

F DIF,ENABLE EXIT product exit_name

The following DIF EXIT command can be issued to disable an exit.

F DIF,DISABLE EXIT product exit_name

Calling Exits in the Rules language

The exits that are used for conditional processing are called from the IF section of an IF-THEN-ELSE group. For example, the following rule calls JOBCLASS from the IF section.


DEFRULE RULE01 IF CLASS EQ A
CALLEXIT(JOBCLASS) THEN SET ALTDATE=2001.010
Exits that update information can be called from the THEN or ELSE sections of an IF-THEN-ELSE group. These exits are called via the SET statement. For example, the following rule calls JOBCLASS from the THEN section of an IF-THEN-ELSE group. Note: the WRITEMSG parameter on the SET statement that calls the exit is only performed when the exit returns a zero return code.

DEFRULE RULE02 IF CLASS EQ A
THEN SET USRFLDC1=CLASS1
SET CALLEXIT(JOBCLASS) WRITEMSG(MSG02)