DEFPROD - 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 DEFPROD statement defines installation dependent information required by the products. This statement is usually the first statement found in the rules language. Since all operands on the statement have defaults, the DEFPROD statement is not required.

The MSGSYSLOG, WTODC, and WTORC subparameters can be used to establish defaults for messages produced by the DEFMSG statement. These parameters control message routing. The DEFMSG statement can override the defaults established by the DEFPROD parameters.


DEFPROD ADDVOL( dadsm VSAM( option ) ) CONTINUE( options )
       DDNAME( IGNORE( ddname MESSAGE( msgname ) ) MAXSCAN( num ) LOG( ddname ) )
       MSG( ddname ) SAF TEST( ddname ) TRACE( ddname ) USER( ddname )
       LOG( ddname LEVEL( level ) ) LSPACE( options ) MAXLEVEL( num )
       MSG( options RULESET( name ) LEVEL( level ) LOG( option ) )
       WTODC( dcodes ) WTORC( rcodes ) OPTION( options )
       POOLNAME( INDEX( n ) ) PRIVATE( option ) REXX( INDD( ddname ) OUTDD( ddname ) LOADDD( ddname ) PRELOAD( list ) )
       RUNTIMEVAR( DDNAME( ddname ) option ) SMF( num LEVEL( level ) )
       SPECIFIC( type ) SUBSYS( type ) SYNTAX( option ) TRACE( options )
       UNDEFINED( YESNO( option ) ) USERID( userid LEVEL( level ) )
    

ADDVOL

Function: For installations running SRS, the ADDVOL(dadsm) subparameter determines whether SRS will call the DADSM pre-processing exit during ADDVOL volume selection. The product has a candidate volume list, and the IGGPRE00 exit can be called before allowing EOV to validate the problem.

Default: ADDVOL( NOIGGPRE00 )

Format: ADDVOL( IGGPRE00 ) or ADDVOL( NOIGGPRE00 )

ADDVOL VSAM: The ADDVOL VSAM subparameter determines how SRS allocates space on the ADDVOL function. Also, the INPUTCHECK option can be used to allow recovery on VSAM files that are allocated to multiple users.

By default, SRS extends the data set to the new volume using the secondary space value. When the operating system extends a VSAM file to a new volume, the CATALOG SVC obtains the primary space value on the new volume. The ADDVOL(VSAM(PRIMARY)) parameter can be specified to force SRS ADDVOL processing to perform in the same manner.

The DEFPROD ADDVOL(VSAM(INPUTCHECK)) parameter can be used in conjunction with the SKIP_ENQ symbolic field to allow recovery. After recovery, any other users allocated to the VSAM file will have the new volume dynamically added to the data set. When used in this manner, the SKIP_ENQ symbolic field should only be specified for VSAM allocations.

Default: ADDVOL( VSAM( SECONDARY ) )

Format: ADDVOL( VSAM( PRIMARY ) ) or ADDVOL( VSAM( INPUTCHECK ) )

CONTINUE

Function: After performing all action statements requested by an IF-THEN-ELSE group, the flow control statements can be used to terminate or continue rule processing. Once an IF-THEN-ELSE has successfully completed, the rules language can continue scanning at the next IF-THEN-ELSE, the next rule definition, a specific rule definition, or simply exit the rules language.

The CONTINUE parameter on the DEFPROD statement establishes the defaults for flow control processing. The CONTINUE parameters on the DEFRULE and DEFPROC statements can override the established defaults for the rule or procedure definition. Lastly, the CONTINUE statement can be used in an IF-THEN-ELSE to control flow processing.

By default, the product uses CONTINUE(RETURN,RETURN) for rule processing. The two operands establish the defaults for the THEN and ELSE sections of an IF-THEN-ELSE, respectively. If an IF group evaluates as false, and no ELSE section is coded, flow control always performs a NEXTIF request (that is, processing continues at the next IF).

Default: CONTINUE( RETURN , RETURN )

Format: EXIT, EXITDO, EXITPROC, NEXTIF, NEXTRULE, rulename

DDNAME (IGNORE / MESSAGE / MAXSCAN / LOG)

Function: The DDNAME IGNORE parameter sets the name of a DD statement that will force the product to bypass processing for the job step. For example, adding the following DD statement to a job step will allow the step to bypass all SIMULATE 2000 processing:

//PTLIGN DD DUMMY

Note: This bypass facility should be controlled. It is recommended that the DD name specified by this parameter remain controlled, or that an invalid DD name be specified to disable the bypass facility.

The MESSAGE parameter allows a message to be written when the ignore ddname is found in a job. The WRITEMSG parameter can be used to issue a message to the user or log file when the ignore ddname is found in a job (only one message per job). The associated DEFMSG statement is responsible for building and writing the message.

Default: PTLIGN (Default DDname for SIMULATE 2000)

Format: Any valid DD name, or an invalid name to disable the ignore function. If MESSAGE is specified, msgname points to an associated DEFMSG statement.

Function (LOG): The DDNAME LOG parameter sets the name of a DD statement that will force the product to write log messages produced by DIF common service routines. This DD statement is used for problem determination, and would only be used when requested by technical support. For example:

//PTLLOG DD DUMMY

Default: PTLLOG

Format: Any valid DD name

Function (MAXSCAN): The DDNAME(MAXSCAN(n)) parameter can be used to limit scanning for the Reserved DD names to the first n DD statements in the job step. Use this to limit overhead on jobs that perform a very high number of dynamic allocation requests.

Default: Scan all DD statements for the product’s Reserved DD statements

Format: An integer number

Function (MSG): The DDNAME MSG parameter sets the name of a DD statement that will force the product to bypass message level processing. This will allow all possible messages to be written by the product, regardless of message level. Example:

//PTLMSG DD DUMMY

Default: PTLMSG

Format: Any valid DD name

DDNAME (SAF / TEST / TRACE / USER)

Function (SAF): The DDNAME SAF parameter can be used to activate the SAF security interface. If activated, the interface checks whether the user can access the reserved DD functions available to a product. By default, the security check is not performed for reserved DD function requests.

If SAF has been specified and a job contains a reserved DD statement, the product issues a SAF call for READ authority to see if the user can use the reserved DD functions. The SAF call uses the FACILITY class, and the entity name will be the DIFDD.ddname. For example: DIFDD.PTLIGN

To use the SAF security interface, you must perform the following steps:

  • SETR CLASSACT(FACILITY) — turn on the class if necessary
  • RDEF FACILITY DIFDD.PTLIGN UACC(NONE) — define the ddname to RACF
  • PERMIT DIFDD.PTLIGN CLASS(FACILITY) ID(user) ACCESS(READ) — permit users to use the resource
  • SETR REFRESH RACLIST(FACILITY) — refresh the internal RACF FACILITY table

Default: NOSAF

Format: DEFPROD DDNAME( SAF )

Function (TEST): The DDNAME TEST parameter sets the name of a DD statement that will force the product to enable test rules. If a DEFRULE or DEFPROC statement specifies the TEST parameter, normal processing will skip the rule. By specifying the PTLTEST DD statement, a rule verification job can enable the rule for testing. For more information, examine the “TESTING AND DEBUGGING” chapter in the product’s user guide.

Example:

//PTLTEST DD DUMMY

Default: PTLTEST

Format: Any valid DD name

Function (TRACE): The DDNAME TRACE parameter sets the name of a DD statement that will force the product to write messages about the compare operations that occur during rules processing. This DD is used for problem determination.

Example:

//PTLTRACE DD DUMMY

Default: PTLTRACE

Format: Any valid DD name

Function (USER): The DDNAME USER parameter allows your company to establish an installation-defined DD statement for the product. The rules language can then test for the presence of the DD statement in the current step with the &RULE_USERDD symbolic field. For example:

IF RULE_USERDD THEN ...

Default: None

Format: Any valid DD name

LOG / LOG LEVEL

Function: Use a log data set to monitor events that occur during ACC or SRS processing. The product can write copies of messages to a log data set. This parameter establishes the defaults for the LOG parameter used on the DEFENV and DEFMSG statements, and the internal ACC messages.

Note: The LOG parameter on the DEFENV statement has precedence over the LOG parameter on the DEFPROD statement. Likewise, any LOG DDname specified on the device pool assigned to the DD statement sets the default DDname for messages produced in the pool.

Default: None

Format: Any valid DD name

LOG LEVEL — Function: When a DEFMSG statement uses the LOG parameter to route a copy of a message to a log data set, or a DEFENV or DEFPROD statement establishes a log data set for all messages in an environment, the LOG LEVEL subparameters on the DEFPROD, DEFENV and DEFPOOL statements determine whether a message gets written to the log data set.

Only messages that have the same importance or higher will be routed to the log data set. Message levels available:

  • I — Information
  • W — Warning
  • A — Action
  • E — Error
  • C — Catastrophic

The LOG LEVEL subparameters on the DEFPROD and DEFENV statements control log processing for allocation requests that are not associated with an ACC controlled allocation request — i.e., no rule has selected a device pool for the DD statement.

Any LOG LEVEL on DEFENV and DEFPOOL statements override the DEFPROD setting. If no LEVEL is specified on the DEFMSG statement, the product bypasses message level processing and a copy of the message will always be routed to the log data set.

Default: LOG(LEVEL(I))

Format: I, W, A, E, C

LSPACE

Function: The rules language has many functions that require the products to obtain the amount of space available on a volume. The first positional operand on the LSPACE parameter can be used to select which field returned by the LSPACE SVC should be used in the space calculation.

Type options:

  • TOTAL — use the available free space on the volume in the space algorithm
  • EXTENT — use the largest available extent

Default: LSPACE( TOTAL 5 1 )

Format: LSPACE( type )

ENQ (LSPACE ENQ): If another task is in the process of updating the VTOC, the LSPACE SVC used to obtain the space information will wait for the volume updates to complete. The ENQ keyword parameters can be used to ensure that a long wait is avoided for volumes that are held for extended periods of time.

By default, the DIF LSPACE interface will perform a RESERVE TEST to see if the volume is available before attempting the LSPACE SVC. With the defaults, the test will be performed 5 times (first positional parameter) at 1 second intervals (second positional parameter). If the volume is held over the interval, the space calculation algorithm will bypass the LSPACE processing. Maximum values for attempts and seconds are 255.

Default: LSPACE( ENQ (5,1) )

Format: ENQ ( num_attempts, interval_time )

WAIT (LSPACE WAIT): On IBM OS/390 and z/OS systems, the LSPACE interface has an I/O wait time parameter. If LSPACE cannot obtain the space information within the specified number of seconds, the request will be failed.

Default: LSPACE( WAIT( 0 ) ) — Use system default of 240 seconds

Format: Any numeric value from 1 to 255

MAXLEVEL

Function: The rules language can use CALLPROC and DO-END statements to implement a structured approach to rule development. During rule execution, the product examines the call depth to determine whether nested procedures are in a loop. By default, procedures are limited to 10 levels. The MAXLEVEL parameter can be used for rules that require more than 10 levels.

Default: MAXLEVEL( 10 )

Format: Any numeric value from 1 to 255

MSG (options)

Function: The MSG options control the messages produced by the ACC and SRS rules language. The subparameters establish the defaults for the MSG parameter used on the DEFENV and DEFMSG statements.

For all internal messages and any rule messages using eight-character message identifiers, the message level associated with the message will be displayed. If your installation requires that the level not be displayed, use MSG(NOCLASS) on the DEFPROD statement to disable level display. To disable the entire message id, specify MSG(NOMSGID).

By default, no message identifier is displayed with messages produced by the DEFMSG statement. If MSG(GENID) has been specified on the DEFMSG statement, the message name will automatically be added to the message text. If MSG(GENID) is used, the message level assigned with the DEFMSG LEVEL parameter will also be added — note that the name specified on the DEFMSG must be eight characters long to display the message level.

The SYSLOG parameter determines whether a message is written to the system log file for console messages. This parameter establishes the default for the SYSLOG parameter used on the DEFMSG statement. The SYSLOG parameter only applies to messages written to batch jobs and started tasks; messages written to TSO users are issued via the TPUT SVC interface.

Default: MSG(NOGENID,CLASS,MSGID,SYSLOG)

Format: CLASS or NOCLASS; GENID or NOGENID; SYSLOG or NOSYSLOG; MSGID or NOMSGID

MSG LEVEL: The MSG LEVEL subparameter on the DEFENV statement can be used to determine whether a message gets displayed. All internal messages have an assigned message level, which can be modified by the DIF MESSAGE command. The DEFMSG statement can use the LEVEL parameter to assign a message level.

Default: None

Format: I, W, A, E or C

MSG LOG: The MSG LOG subparameter determines whether messages written to a log data set should use a local DD statement, or use the system interfaces provided by DIF to write the message to the DD statement allocated in the DIF address space.

Default: MSG( LOG (SYSTEM) )

Format: LOCAL or SYSTEM

MSG RULESET

Function: The MSG RULESET subparameter establishes a special rule member for message processing. Whenever the product writes a message, the member name specified by RULESET will be processed. The symbolic name tables have been extended to include fields to control message processing.

Default: None

Format: RULESET( rulename )

MSG WTODC / WTORC

Function (WTODC): The MSG WTODC subparameter establishes the default descriptor codes used on messages using the WTO SVC interface.

Default: None

Format: One or more numbers with values between 1 and 16 (list individually, or separated by blanks or commas).

Function (WTORC): The MSG WTORC subparameter establishes the default routing codes used. Messages using WTORC(11) allow the product to write messages to the JES messages data set, or use the TPUT SVC interface. If additional routing codes are requested, the products will use the WTO SVC interface.

Default: WTORC(11)

Format: One or more numbers with values between 1 and 16 (list individually, or separated by blanks or commas).

POOLNAME INDEX

Function: The POOLNAME INDEX subparameter allows ACC and SRS to assign different pool definitions to the same DD statement. By default, an environment will not perform rule processing when a previous environment has assigned a pool definition to a DD statement so long as both environments are using the same index value.

By default, ACC and SRS share a pool index of 1, and rule processing only occurs one time. After a device pool is assigned to a DD statement, the pool definition will be used by all later environments.

If your installation requires separate rule members for ACC and SRS, the POOLNAME INDEX subparameter can be used to establish different pool indexes for each product. Example: ACC could use POOLNAME(INDEX(1)) in ACCRULES and SRS use POOLNAME(INDEX(2)) in SRSRULES. Note: This example requires that SRSRULES be specified on the START SRS command in DTS.R71.PARMLIB(START00).

Default: POOLNAME( INDEX( 1 ) )

Format: POOLNAME( INDEX( index_number ) )

REXX (INDD / OUTDD / LOADDD / PRELOAD)

Function (INDD): The REXX INDD parameter defines the name of a DD statement that will be used for input processing when a Rexx procedure makes a read request. This parameter is only used for Local Rules.

See: System and Local Rules and Calling Rexx Procedures.

Default: SYSTSIN

Format: Any valid DD name

Function (OUTDD): The REXX OUTDD parameter defines the name of a DD statement that will be used for output processing when a Rexx procedure makes a SAY or TRACE request. Only used for Local Rules.

Default: SYSTSPRT

Format: Any valid DD name

Function (LOADDD): The REXX LOADDD parameter defines the name of a DD statement that will be used to load the Rexx procedure. Only used for Local Rules.

Default: SYSEXEC

Format: Any valid DD name

Function (PRELOAD): When the compiler encounters a CALLREXX statement, the Rexx procedure is read from the SYSEXEC DD statement in the DIF address space and loaded into Extended CSA. The compiler does not parse the Rexx program. If the Rexx procedure makes calls to other Rexx procedures, preload those members with REXX(PRELOAD(...)). This parameter is only used for System Rules.

Default: None

Format: REXX( PRELOAD ( mod1, mod2, ... modn ) )

RUNTIMEVAR

Function: The rules language can write variables defined by DEFVAR statements to a VSAM file when rules execute in a non-authorized environment (typically rules running under SCC Monitor). The RUNTIMEVAR parameter specifies the DD statement allocated to the VSAM file. It also selects the type of IO requests made by the product: OUTPUT requires locking on the VSAM file; INPUT does not require locking.

Default: RUNTIMEVAR(DDNAME( DIFVAR) OUTPUT )

Format: RUNTIMEVAR( DDNAME( ddname ) IO_type )

SMF

Function: The SMF parameter on DEFPROD and DEFENV establishes the default for the SMF parameter used on the DEFPOOL statements. The SMF parameter on DEFENV has precedence over the DEFPROD value.

Default: None

Format: Specify a numeric value between 128-255.

SMF LEVEL: SMF records produced by DEFSMF statements can have installation-assigned record levels (I, W, A, E, C). Use the SMF LEVEL subparameter on DEFPROD, DEFENV, and DEFPOOL to establish thresholds; only records with the same or higher importance are written.

Default: None

Format: I, W, A, E or C

TRACE

Function: The TRACE parameter controls rule tracing during both rule compilation and execution. Three operands can be specified: COMPILE, SELECTIVE, and SET.

COMPILE — Enables an internal trace facility for pool build processing; trace messages are written to DIF’s message log during conversion.

SELECTIVE — Activates selective rule tracing. By default, the trace DD statement activates tracing for all rules used by the product (for example, //PTLTRACE DD DUMMY). To enable selective tracing, code TRACE(SELECTIVE) on DEFPROD and the TRACE parameter on each DEFRULE to be traced. Note: the trace DD statement is still required to activate tracing.

SET — Provides additional trace messages for SET statements.

Note: The TRACE parameter is used for problem determination and should only be used when requested by technical support.

Default: TRACE ( NOCOMPILE, NOSELECTIVE, SET )

Format: TRACE ( COMPILE | NOCOMPILE, SELECTIVE | NOSELECTIVE, SET | NOSET )

UNDEFINED

Function: When the rules language encounters a YES/NO type symbolic field that is not available at runtime, the YESNO option on the UNDEFINED parameter specifies how the rules treat the symbolic field. By default, runtime routines return a blank character. If NO is specified, the runtime routines will return the character string "NO".

Default: UNDEFINED( YESNO( BLANKS ) )

Format: BLANK or NO

USERID

Function: The USERID parameter on DEFPROD and DEFENV establishes the default for the USERID parameter used on DEFPOOL statements. The USERID on DEFENV has precedence over DEFPROD.

Default: None

Format: Any valid TSO userid name.

USERID LEVEL — Function: When a DEFMSG statement uses the USERID parameter to route a message to a TSO user, the LEVEL subparameters can be used to assign a message level. Use USERID(LEVEL(level)) on DEFPROD, DEFENV, and DEFPOOL to establish a threshold; only messages with the same or higher importance are routed to the TSO user.

Note: Normal internal and user-defined messages are not controlled by this parameter. Only messages specifically sent using the USERID parameter on the DEFMSG statement are affected.

Default: USERID( LEVEL( I ) )

Format: I, W, A, E or C