Using OPS/REXX › Uses of OPS/REXX in the Product › Differences Between OPS/REXX and Standard REXX

Differences Between OPS/REXX and Standard REXX

In addition to the similarities listed above, there are several important differences between OPS/REXX and standard REXX. These include:

• In OPS/REXX, external subroutines are resolved and bound with the main program prior to execution. This characteristic provides a major performance benefit for OPS/REXX when calling external subroutines, particularly in the AOF rule environment. One negative aspect of this characteristic is that all subroutines must be available at the time an OPS/REXX program or AOF rule is compiled or enabled on any system, even if some subroutines are never actually called during execution in that environment. For example, consider the following code:

  if OPSINFO("SMFID") == "SYSA" then
    call EXTSUB1
  else
    call EXTSUB2
  

  Clearly, the EXTSUB1 subroutine is called only when the code executes on SYSA. Nevertheless, OPS/REXX requires the EXTSUB1 subroutine (or load module) to be available on every system. In TSO/E REXX, external subroutines are resolved only when they are called during execution.

  In CA OPS/MVS, you can use the OPSWXTRN keyword of the OPTIONS instruction to indicate to OPS/REXX which external subroutines, built-in functions, and load modules are not absolutely required to be present prior to execution. The presence of the OPSWXTRN keyword in an OPTIONS instruction allows programs containing this OPTIONS instruction to be used by both OPS/REXX and TSO/E REXX, so the portability of REXX code that uses this instruction is unaffected. For more information, see OPTIONS Instruction in this chapter.

• In the Cowlishaw definition of REXX, when a PULL instruction is executed and the external data queue is empty, a read is done from the default character input stream. In OPS/REXX, this is not practical because in a rule, the only possible default character input stream is the console. Prompting the operator for the next line of input would be undesirable to say the least. Therefore, in OPS/REXX a PULL on an empty external data queue results in a null (zero length) line being returned.
• The PUSH instruction is not implemented in OPS/REXX. Its use results in REXX error number 64, which is the unimplemented feature error. The QUEUE instruction is implemented in OPS/REXX, and in most cases, you can use it to accomplish the same results.
• Because OPS/REXX is required to run efficiently in different environments, some differences exist in REXX instructions such as the INTERPRET instruction, where a limited implementation is available. Since the INTERPRET instruction causes the compiler to be reinvoked, any storage required to process the instruction is retrieved from existing sources, to avoid dynamically getting storage. In most cases the VALUE function would serve as a much more efficient alternative to INTERPRET.
• When converting from date format B to any other format, standard REXX adds one day to the resulting date, whereas OPS/REXX does not.

  Note: For more information see the OPS/REXX DATE function in the Command and Function Reference.