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
- list OMVS users. Can run from either inside or outside the OMVS
- display limits for OMVS resources. Each resource has a current (or
soft) limit and a maximum (or hard) limit.
- change the limits for an OMVS resource. Only "superusers" can change
the maximum limit. Only runs inside the OMVS environment.
- run one or more REXX commands. Can also be used from TSO.
- find the true location of a specified module in the current PATH
- 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 Unix System Services provides its own /bin/whoami after
- displays information about the current operating environment
- extracts environment variable settings. Similar REXX code could be
used to make OMVS environment variable settings available for use by a
- sample use of pipes from REXX. Lists files and inodes for the current
directory and any subdirectories.
- displays processes "visible" to your uid. A "super-user" sees all
processes. Other users only see processes with their own uid.
- displays information about the specified OMVS file.
- displays information about the specified OMVS file system.
- uses strerror to display text for specified errno and/or reason code
- 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.
- displays activity on Unix System Services initiators
- 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
Unix System Services running inside the original TSO address space. Works OK in other Unix System Services
environments. This was not working on OS/390 V1R2.
- 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 Unix System Services shell. Messages are copied to the same destination
as TSO messages. For example, MYSHELL ls -l
- 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.