Using OPS/REXX › Uses of OPS/REXX in the Product

Uses of OPS/REXX in the Product

The following CA OPS/MVS components use OPS/REXX:

• The rules of the CA OPS/MVS AOF component are actually OPS/REXX programs that can respond automatically to system events. The availability of the OPS/REXX general purpose programming tools in rules gives you an unlimited ability to automate responses to these events.
• Important parts of OPSVIEW such as AOF EDIT, the ISPF Dialog Manager application with which you create and update rules, are written in OPS/REXX. The OPS/REXX interface to the Dialog Manager is as complete and powerful as that of TSO/E REXX.
• You can write AOF asynchronous procedures (which execute in CA OPS/MVS server address spaces) in both OPS/REXX and the TSO/E REXX language.
• OPS/REXX differs from other REXX implementations in processing numeric values and implementing NUMERIC DIGITS. OPS/REXX attempts to optimize numeric processing for values that fit in a 32 bit fullword as a signed integer. OPS/REXX always converts numeric values that fit in a signed fullword (integer values in the range -2147483648 through 2147483647) to binary values and performs register arithmetic on them irrespective of the NUMERIC DIGITS setting. For NUMERIC DIGITS settings, up to and including 10, in cases where the numeric value will fit in a signed fullword, OPS/REXX internally uses binary register arithmetic. This is one of the reasons why OPS/REXX significantly outperforms IBM REXX.

  The following example illustrates this difference:

  /* REXX */
  numeric digits 5
  a = 2147483646+1
  say a
  

  OPS/REXX output is: 2147483647

  IBM REXX output is: 2.1475E+9

  Note: OPS/REXX is not strictly correct in its numeric processing but the performance advantages are significant and CA does not intend to change OPS/REXX to comply with the REXX language definition in this case. For performance reasons CA recommends that, unless your REXX program requires greater precision, you allow NUMERIC DIGITS to default to 9.