ACTION - syncsort_simulate_2000

When processing DEFRULE, DEFPROC and DO-END statements -- the product evaluates the if_expressions found in the IF section of IF-THEN-ELSE groups. Once all conditions within an IF section have been met, the product performs the requested action_statements and the flow_control_statements.

The following structure displays a typical IF-THEN-ELSE definition:


IF if_expression_1 if_expression_2
...
if_expression_n
THEN action_statements
flow_control_statements
ELSE action_statements
flow_control_statements

Action statements can also reside outside an IF-THEN-ELSE structure. For example, the DO-END and DEFPROC statements can issue action statements and not use conditional processing.

One or more of the following action_statements can be used by DEFRULE, DEFPROC or DO-END.

CALLPROC — Execute a procedure defined by DEFPROC
CALLEXIT — Call an installation user exit
CALLREXX — Call a REXX procedure
CALLRULES — Call another rule for processing
DO-END — Execute an in-line procedure
ISSUE — Write a message, SMF record, or issue an operator command
SET — Modify JCL, SVC 99 parameters, or IDCAMS parameters
USERULES — Transfer rule processing to another member

CALLPROC( procname )

Function: The CALLPROC statement performs the procedure defined by a DEFPROC statement. A procedure has all the capabilities and characteristics of a rule definition with two exceptions.

Rule scanning does not directly process a DEFPROC procedure — another rule definition or procedure must request execution with a CALLPROC statement.
When IF processing successfully completes an IF-THEN-ELSE with a procedure definition, the default continuation is an EXITPROC instead of an EXIT.

Both CALLPROC and DO-END statements can be used to implement nested IF processing, or execute a series of action statements. If your language contains multiple DO-END statements that perform the same function, you may wish to convert the DO-END statements to a single procedure and use the CALLPROC statement.

Default: None

Format:

CALLPROC(<procname>)

CALLEXIT( exitname )

Function: The CALLEXIT parameter can be used to pass control to a user exit. The exitname specifies the name of the exit to be called. For the statement to function correctly, the exit must be enabled by the DIF (Dynamic Install Facility) before the CALLEXIT parameter is processed. For more information, examine “User Exits” on page 3-46.

Default: None

Format:

CALLEXIT(<exitname>)

CALLREXX( rexxname )

Function: The CALLREXX parameter can be used to pass control to a Rexx procedure.

While the CALLREXX statement cannot pass parameters directly to rexxname, parameters can be passed in user fields: &USRFLDCn and &USRFLDNn. DIF provides functions that give the 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. For more information, examine “Calling Rexx Procedures” on page 3-43.

Note:

The following applies to Rexx usage and local/system rules:

For Local Rules environments, the Rexx procedure is obtained from the DD statement specified by the DEFPROD REXX(LOADDD(<ddname>)) parameter which defaults to SYSEXEC. The DD must be allocated in the current job step. Monitor uses Local Rules.
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 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, you must use the DEFPROD REXX(PRELOAD(...)) parameter to preload the member for Rexx processing.

For more information, examine “System and Local Rules” on page 3-1.

Default: None

Format:

CALLREXX(<rexxname>)

CALLRULES( rulename )

Function: The rules language can use the CALLRULES statement to call another rule member. The member is a PDS member name in the SCC rules library: DTS.R71.RULELIB. After processing, the called rule member returns control to the member issuing the CALLRULES.


DEFRULE CALLCP01 IF &ACCT EQ GD*
THEN CALLRULES(COMP01)

Note:

When a DIF REFRESH command processes the primary rule member for a product, the rules compiler analyzes all the USERULES and CALLRULES statements to produce a rule set. USERULES and CALLRULES statements can be processed up to a call depth of 10.

If you wish to transfer control to another rule member, examine USE-RULES(rulename).

Default: None

Format:

CALLRULES(<rulename>)

DO-END

Function: The DO-END statement is essentially an in-line procedure. The statement can be used to implement nested IF processing, or execute a series of action statements. A DO-END has all the capabilities and characteristics of a rule definition with one exception.

When IF processing successfully completes an IF-THEN-ELSE with a DO-END definition, the default continuation is an EXITDO instead of an EXIT.

If your language contains multiple DO-END statements that perform the same function, you may wish to convert the DO-END statements to a single procedure and use the CALLPROC statement.

Default: None

Format:


DO
  IF_THEN_ELSE statements
  action_statements
  flow_control_statements
END

ISSUE

Function: The ISSUE statement can write SMF records, route messages, and issue operator commands. Since messages can be logged to a data set, the ISSUE statement can be used to monitor events that occur during product processing.

The ISSUE statement has three keyword parameters:

OPERCMD
WRITEMSG
WRITESMF

OPERCMD

The OPERCMD operand can be used to execute an operator command. The name of one or more DEFCMD statements can be specified by the OPERCMD operand. The DEFCMD statement(s) are responsible for building and issuing the command.

WRITEMSG

The WRITEMSG operand can be used to write a message. The name of one or more DEFMSG statements can be specified by the WRITEMSG operand. The DEFMSG statement(s) are responsible for building and writing the message.

WRITESMF

The WRITESMF operand can be used to produce SMF record(s). The name of one or more DEFSMF statements can be specified by the WRITESMF operand. The DEFSMF statement(s) are responsible for building and writing the SMF record.

Default: None

Format:


ISSUE
  OPERCMD(cmd1,cmd,...)
  WRITEMSG(msg1,msg2,...)
  WRITESMF(smf1,smf2,...)

SET

Function: The SET statement contains a set_expression and three keyword parameters: OPERCMD, WRITEMSG and WRITESMF. The SET statement can use the expression to control SIMULATE 2000. For example, the ALTDATE and ALTTIME fields can be used to establish a modified clock.

set_expression

The SET statement modifies the data field associated with a symbolic field name. Not all symbolic fields can be updated. The tables found in “SYMBOLIC FIELDS can be used to determine which fields can be modified.

SIMULATE 2000 has several symbolic names that perform specific functions. These fields support the alternate time and date, control the product’s audit capabilities, and determine whether a user can use special DD statements. For a complete list of the symbolic fields that support SIMULATE 2000 functions, see “Symbolic Names for Internal Fields” in the SIMULATE 2000 User’s Guide.

The ALTDATE field is a good example. After the rules language is finished, the product examines the internal data fields. If an alternate date has been requested, SIMULATE 2000 will provide a modified clock for the job.


SET ALTDATE=2010.100

After modifying a field, the SET can also write messages to the user, write SMF records, and issue operator commands. These facilities are only invoked when the expression truly modifies the data. For example, if the following SET expression sets the RESCAN parameter, the message MSG5 is only issued once for the job step.


SET RESCAN = YES WRITEMSG(MSG5)

Note: If you wish to always produce a message, SMF record, or operator command, examine the ISSUE action statement. An unconditional write is produced using the ISSUE; conditional writes are affected using the SET.

OPERCMD

WRITEMSG

WRITESMF

Default: None

Format:


SET
  set_expression
  OPERCMD(cmd1,cmd,...)
  WRITEMSG(msg1,msg2,...)
  WRITESMF(smf1,smf2,...)

USERULES( rulename )

Function: The rules language can use the USERULES statement to transfer control to a different rule member. This facility might be useful for service bureaus or very large installations.

Systems programming could control the product installation and global rule definitions, but different groups could be responsible for their own storage management.

For example, an installation that supports three companies might use account information to transfer control to separate rule members. During START or REFRESH processing, the rule conversion routine would automatically convert the members specified by the USERULES operands. During allocation, the rules language might perform installation-wide rule processing, then use the following rule to pass control to the appropriate rules member.


DEFRULE XFERCNTL IF &ACCT EQ GD*
THEN USERULES(COMP01)
IF &ACCT EQ CF*
THEN USERULES(COMP02)
IF &ACCT EQ HE*
THEN USERULES(COMP03)

Note: When a DIF REFRESH command processes the primary rule member for a product, the rules compiler analyzes all the USERULES and CALLRULES statements to produce a rule set. USERULES and CALLRULES statements can be processed up to a call depth of 10.

If you wish to transfer control to another rule member, examine “USE-RULES(rulename).

Default: None

Format:

USERULES(<rulename>)

ACTION - syncsort_simulate_2000 - Latest

Syncsort™ Storage Management Portal 2000 Rules Language Guide

DO-END

ISSUE

SET