Calling Rexx procedures - 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 used by the products has been designed for optimum performance in restrictive environments. With the introduction of Monitor, customers may want capabilities that are not available in the rules language. Most notably, the ability to perform I/O to data sets.

The CALLREXX statement gives the rules language a gateway to Rexx. While the CALLREXX statement cannot pass parameters directly to a Rexx procedure, parameters can be passed in user fields: &USRFLDCn and &USRFLDNn. The following CALLREXX statement would execute the HELLO Rexx procedure.

CALLREXX(HELLO)

The Rexx gateway also provides functions that give a Rexx procedure access to all the DIF and product symbolic fields, as well as the ability to set the symbolic fields and route messages using DIF facilities. The interface functions provided by the Rexx Gateway are:

#GET The #GET function can be used to obtain a symbolic field from DIF or the product. The #GET function has two parameters: the field name and field type. Only the field name is required. The field types are NUMERIC, CHARACTER, VAR and YESNO. For example, the fol-lowing Rexx statement compares the current job name to “XYZ”.

IF #GET('JOBNAME') = 'XYZ' THEN DO ...

#SET The #SET subroutine can be used to modify a symbolic field. The set request will only be performed for symbolic fields that allow updates. The #SET subroutine has three parameters: the field name, the new value and the field type. The field name and new value are required fields. The field types are NUMERIC, CHARACTER, VAR and YESNO. For example, the following Rexx statements force the data and index components names to end with DATA and INDEX.

IF #GET('ENV') = 'IDCAMS' THEN DO
CALL #SET 'D:DSNAME', #GET('DSNAME') || '.DATA' CALL #SET 'I:DSNAME', #GET('DSNAME') || '.INDEX'
#MSG The #MSG subroutine can be used to write messages using the DIF message facility. This facility allows messages to be routed to LOG files in DIF, TSO users, console messages, and even as SMF records. The first parameter is the text field. The message text is followed by the message options. These are the same options that are defined on the DEFMSG statement: MSGLOG, USERID, LEVEL, SMFRID,

WTODC, and WTORC. For information about the message options, examine “DEFMSG” on page 5-49.

CALL #MSG 'HELLO WORLD’,WTORC(2,11),WTODC(2)

Rexx in Local Environments

The Monitor uses Local Rules. In Local Rules environments, the Rexx procedure is obtained from the DD statement specified by the DEFPROD REXX(LOADDD(...)) parameter which defaults to SYSEXEC. The DD must be allocated in the current job step. For more information about rules, examine “System and Local Rules” on page 3-1.

Rexx in System Environments

Most products run in a shared environment, which require System Rules. In these environments, the rules compiler is executed by the DIF START and REFRESH commands. When the compiler encounters a CALLREXX statement, the Rexx procedure is read from the SYSEXEC DD statement allocated in the DIF started task and placed into Extended CSA. Note: The compiler does not parse the Rexx program. If the Rexx procedure makes calls other Rexx procedures, you must preload the called Rexx procedure with the DEFPROD REXX(PRELOAD( ... )) parameter in the rule language.