Chapter 11. The EXECCOMM interface

Before we start to discuss File I/O operations in REXX procedures, we want to spend a few minutes on a very specific subject: EXECCOMM, or how does REXX provide an interface to let the outer world Query or Set REXX variables ?  The EXECCOMM interface is available to Assembler programmers and to other languages via the CSL (Callable Services Library) routines DMSCGR (Get REXX variable) and DMSCSR (Set REXX variable)(footnote).

Commands such as GLOBALV, XEDIT's EXTRACT, and quite some others that have options like VAR or STEM exploit this.

Through this interface, the REXX variables are not accessed "directly" but "copied" to an intermediate program buffer.  For example, when a variable is retrieved from the REXX program, REXX will copy it into a buffer of the requestor.  The requestor can ask for more than 1 variable at once, but when the buffer is too small it will have to repeat its request with a larger buffer. 

Many commands still let you choose to use EXECCOMM or not, and that's good, as the use of EXECCOMM isn't neutral to performance.

     'GLOBALV SETL MYVAR' myvar

is for example faster than

     'GLOBALV PUT MYVAR'

while

     'GLOBALV PUT MYVAR1 MYVAR2 ...MYVARn'

may become better performing than

     'GLOBALV SETL MYVAR1' myvar1
     'GLOBALV SETL MYVAR2' myvar2
     'GLOBALV SETL MYVARn' myvarn

Why is GLOBALV SETL faster than GLOBALV PUT ?  Well, when REXX has evaluated the GLOBALV command, it asks CMS to execute it.  Then, this is what happens:

  1. If PUT is used, GLOBALV will understand that it has to obtain the value of a REXX variable, and it uses the EXECCOMM interface for that purpose.
  2. If SETL is used, the data is passed immediately as a parameter to the command, and thus, GLOBALV has not to go back to REXX to ask for it.

Similarly,

     'EXECIO 1 DISKW ... (STRING' data-to-write

will perform better than:

     'EXECIO 1 DISKW ... (VAR xyz'

Indeed, in the first case, the data is immediately transferred as a parameter to the EXECIO command, while in the second case, EXECIO has to ask REXX for the data before it can write it to the file.

A command that uses the EXECCOMM interface is in fact a double command.

Should we avoid commands using EXECCOMM then ?

No, but if the commands are used many times in procedures that have to perform well, such as servers, then it could be important to use the fastest method.

In any case, we'll be horrified when we see something like this:

     myvar='This must be saved'
     'GLOBALV PUT MYVAR'
     record='A line to write to disk'
     'EXECIO 1 DISKW MY FILE A (VAR RECORD'
     record='one more line to write'
     'EXECIO 1 DISKW MY FILE A (VAR RECORD'
     record='And this is line 3 for our file'
     'EXECIO 1 DISKW MY FILE A (VAR RECORD'

We hope you understand why...

Commands frequently provide an alternative to the EXECCOMM interface by using the CMS stack.  Contrary to what you may think, the use of the stack is better performing than the EXECCOMM interface.  The best technique is always to pass the data directly as a parameter (such as with the STRING option of EXECIO), but the stack comes next.

The use of the stack has however some drawbacks:

A very last, but important remark: when you use the EXECCOMM interface, the command syntax becomes a bit less intuitive...

Question 20

What is wrong in this procedure ?

   /* Reading a file */
   address command
   'EXECIO 1 DISKR MY FILE A 1 (VAR' record  /* get record 1 */
   /* process this record here... */
   .............
   'EXECIO 1 DISKR MY FILE A 10 (VAR' record /* get record 10 */
   .............

We are ready now to study the Input/Output techniques that can be used with the REXX language.  These are covered in chapters 12 and 13.


Footnotes:

  For more information on CSL routines accessing REXX variables, see the CMS Application Development Reference  manual, or issue the command HELP ROUTINE MENU.
Back to text