Unix System Services & REXX

Most OMVS programming interfaces available through the C language are also supported through REXX, through the SYSCALL environment. Users who are authorized to use OMVS can invoke these APIs from either inside the OMVS environment or by setting up the REXX SYSCALL environment. See the GETPWENT EXEC for sample REXX code to set up the SYSCALL environment.

An example of using an OMVS facility in the MVS environment would be using the SLEEP function:

address syscall 'sleep 120' could be used in a REXX EXEC to wait 2 minutes in the OMVS environment. EXEC sleep can be used if the EXEC will be invoked from TSO or batch. This will only work if the userid making use of this EXEC is authorized to use OMVS.

The SH environment may be used to execute commands from the OMVS shell. Note that /bin/sh is used regardless of what shell program is in the user's OMVS profile.

Sample REXX Code

GETPWENT: list OMVS users. Can run from either inside or outside the OMVS environment.
GETRLIM: display limits for OMVS resources. Each resource has a current (or soft) limit and a maximum (or hard) limit.
SETRLIM: change the limits for an OMVS resource. Only "superusers" can change the maximum limit. Only runs inside the OMVS environment.
REXX: run one or more REXX commands. Can also be used from TSO.
WHEREIS: find the true location of a specified module in the current PATH
WHOAMI: attempts to identify the current execution environment: batch, tso, appc, omvs, started task. Oddly enough, there may be circumstances in working with OMVS when it is important to find this out. You may need to rename it since USS provides its own /bin/whoami after V2R4.
SYSINFO: displays information about the current operating environment
LISTENV: extracts environment variable settings. Similar REXX code could be used to make OMVS environment variable settings available for use by a REXX routine.
PIPE: sample use of pipes from REXX. Lists files and inodes for the current directory and any subdirectories.
REXXPS: displays processes "visible" to your uid. A "super-user" sees all processes. Other users only see processes with their own uid.
STAT: displays information about the specified OMVS file.
STATFS: displays information about the specified OMVS file system.
ERRTEXT: uses strerror to display text for specified errno and/or reason code
FIXMAN: uses groff to format man pages for use on z/OS Unix. The current directory is assumed to be a man# directory containing man page source. For example, fixman perl*.1 in directory man1 would create formatted man pages in the corresponding cat1 directory for all files matching the pattern perl*.i. Groff is available from GNU Troff.
BPXINIT: displays activity on USS initiators
URLINFO: given a URL, it retrieves the header information for the document. This EXEC uses the REXX socket interface of IBM's TCP/IP OS/390. Inspired by "TCP/IP Socket Programming with REXX" located on an earlier edition of IBM's REXX tutorial page. This may not work under USS running inside the original TSO address space. Works OK in other USS environments. This was not working on OS/390 V1R2.
MYSHELL: modeled after the TSO OSHELL EXEC. This EXEC uses the process-id to create unique temporary file names. It can be used from TSO (or TSO in batch) to run a command under the USS shell. Messages are copied to the same destination as TSO messages. For example, MYSHELL ls -l
RUNPGM: Similar to MYSHELL above, this EXEC executes a program using BPXBATCH. It is intended for use from TSO (or TSO in batch). For example, RUNPGM /bin/who -a

MORE EXAMPLES and more information can be found on the More Unix System Services & REXX page.

We are currently running z/OS 1.8. These samples work in our environment, but they may need to be reworked for a different environment.

You can also visit the REXX page or the OMVS page here.

These samples are provided "as is". No warranty or support is expressed or implied.

Comments or suggestions can be sent to the author.