OPS/MVS: The REXX Programming Language explained - Best Practice.

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

What are OPS/REXX best practices?

Environment

Component: OPS/MVS

Resolution

The OPS/REXX Interpreter

The OPS/REXX interpreter provided by OPS/MVS runs many times faster than the TSO EXEC command for similar programs. Also, when you use OPS/REXX in the AOF environment, all the code is pre-interpreted to speed up processing even further. OPS/REXX generally runs so speedily that most users do not need to rewrite functions in assembler language. OPS/REXX provides automation from the point where it intercepts messages and commands from JES and z/OS.

Uses of OPS/REXX in the OPS/MVS Product

The following components use OPS/REXX:

• The rules of the 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 the OPS/MVS address spaces) in both OPS/REXX and the TSO/E REXX language.

Similarities Between OPS/REXX and Standard REXX

Both OPS/REXX and the standard REXX language enable you to issue commands to various host environments. Both versions of REXX offer symbolic substitution that is simpler than in the TSO/E CLIST language or in z/OS JCL. The current version of OPS/REXX supports these standard REXX features:

• All REXX programming structures as defined in the book THE REXX LANGUAGE: A Practical Approach to Programming by M.F. Cowlishaw. For example, OPS/REXX supports counter variables on DO statements and the PROCEDURE statement.
• All standard SAA REXX functions plus most of the functions documented in the second edition of the book, except for the I/O functions (HARIN, CHAROUT, CHARS, LINEIN, LINEOUT, and LINES). Numbers with decimal points and exponents, as well as numeric digits with a precision up to 20 (default 9).
• Strings containing as many as 32,000 characters, including strings to ISPEXEC to support long commands and values of all REXX variables including global variables. OPS/REXX can build dynamic display areas in panels. The OPSMVS REXXMAXSTRINGLENGTH parameter enables you to use a lower maximum string length if you want. 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/R EXX 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 OPSMVS, 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. 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.

Characteristics of OPS/REXX Programs

• You can execute an OPS/REXX program in any of these ways:
• Explicitly, through the OPSEXEC (or OX ) command
• Implicitly, through the OPSIMEX (or OI ) command
• As batch jobs
• As started tasks

 

Use the OPSEXEC and OPSIMEX commands to execute OPS/REXX programs in source code or precompiled format. Use the OXCOMP and OICOMP commands to compile OPS/REXX programs without executing them. When used with the AOF, OPS/REXX programs have a special structure and are called rules. Outside the AOF environment, OPS/REXX programs are called programs.

Unless you have precompiled rules, the OPSMVS product compiles rules when you activate them with the ENABLE command and runs them strictly from their internal form (rather than reloading and reinterpreting them each time they are needed). Outside the AOF environment, OPS/REXX programs execute from source code or from staged internal forms.

Differences Between Precompiled and Source REXX Programs

The OPS/MVS product has always supported running OPS/REXX programs in source code format. Now, the product also supports storing and running precompiled OPS/REXX programs. You can issue OXCOMP and OICOMP commands to compile OPS/REXX programs without executing them; both commands store the compiled REXX code in the data set allocated to the OPSCOMP ddname. You can copy data sets containing precompiled
OPS/REXX programs with no restrictions. Precompiled OPS/REXX programs use exactly the same REXX functions as source code
programs, but the precompiled programs are loaded faster. When you call a precompiled program, OPS/REXX loads and executes it, eliminating the time needed to read the source code and compile it. In contrast, source code programs take more time to load because OPS/REXX has to read and compile the code first.    Differences Between Explicit and Implicit Program Execution The only difference between implicit and explicit program execution is how you specify the name of the program to execute and where OPS/REXX looks for the name:

• With explicit execution, you supply the name of the data set containing the program.
  
  
• With implicit execution, you provide only a program name. OPS/REXX then locates that program in the library or libraries allocated to ddname OPSEXEC or SYSEXEC.

How OPS/REXX Locates Stored OPS/REXX Programs

OPS/REXX programs can reside in OPSEXEC data set libraries or in data sets elsewhere in the SYSEXEC concatenation. Programs in data sets allocated to
OPSEXEC execute faster because OPS/REXX can execute them without compiling them first. When you invoke a program, OPS/REXX always looks for it first in the OPSEXEC libraries. This is true as long as you have allocated the OPSEXEC ddname. If the program is not there, OPS/REXX looks in the SYSEXEC libraries and, after finding it, reads, compiles, and runs it. Note: To avoid slowing down OPS/MVS processing, use the OPSEXEC DD, which prevents REXX code from being compiled at runtime.

Executing a Program that Calls External Routines

Compiling an OPS/REXX program also compiles all subroutines associated with it. The way OPS/MVS scans for external routines depends upon whether you are editing a sequential data set or the member of a partitioned data set. When you explicitly execute an OPS/REXX program that is not precompiled and that
resides in a partitioned data set, OPSMVS scans that data set to try to locate any external routines. If external routines are not found in the data set
containing this program, OPS/MVS then searches in the libraries concatenated under the SYSEXEC ddname.

When you explicitly execute a program residing in a sequential data set, OPSMVS scans only the SYSEXEC ddname for external routines. When you use either the !OI or !OX edit macro, you are explicitly executing a program. GREXX is the REXX used by OPSMVS when you us the OI or OX command processors.