6. DATA SOURCES › 6.11 UNIX System Services (USS) Overview
6.11 UNIX System Services (USS) Overview
UNIX System Services (USS) is a fully functional
implementation of UNIX on the MVS and z/OS operating systems.
Both the execution of UNIX processes and the UNIX
hierarchical file system are supported. The UNIX
implementation supports the cloned address spaces via the
fork() command and the creation of program substeps via use
of the EXEC function. Use of the UNIX fork() command results
in the creation of a "child" address space that both executes
the same program and inherits identification information from
the "parent" address space. Use of the UNIX EXEC function
results in current step termination. A new step is then
initialized and maintained as the same step number of the
just-terminated step but is assigned a new substep number.
INTRODUCTION TO UNIX SYSTEM SERVICES (USS)
UNIX System Services (USS) allows two open systems interfaces
on the z/OS operating system: API, application programming
interface, and an optional interactive shell interface. UNIX
processors can execute in any environment, for example batch,
TSO/E, started tasks, or any other MVS application platform
within the API. These programs can request:
o Only z/OS services
o Only UNIX System Services
o Both z/OS and UNIX System Services
The optional shell interface is a command interface like
TSO/E with a programming language shell similar to REXX
(Restructured eXtended eXecutor). The shell supports the
following types of work:
o Programs run interactively by shell users
o Shell commands and scripts run interactively by shell
users
o Shell commands and scripts run as batch jobs
Support for UNIX System Services (USS) is provided by:
o USS component provides USS services in answer to requests
from programs and the shell.
o USS component contains the code supporting full-screen
applications, logging in from remote locations, and
automount support.
o USS Shell Utilities feature interprets both MVS requests
and interactive shell script commands from users or
programs.
o USS Debugger aids in debugging of C code.
The UNIX System Services (USS) component, kernal, must be
installed and started before USS can be used.
HIERARCHICAL FILE SYSTEM CONCEPTS
A unit of stored data is called a data set. In UNIX,
however, a unit of stored data is called a file. In UNIX
System Services (USS), files are managed by a hierarchical
file system known as HFS.
The hierarchical file system consists of:
o HFS files containing data or programs. These files are
kept in directories.
o Directories, which contain files, other directories or
both, arranged hierarchically.
o Additional local or remote files within directories of the
root file system.
HFS
Root Directory
|
+-------------+--------------+
| ] |
Directory file Directory
file file |
file +---------+---------+
file | | |
Directory file Directory
file file file
file file file
file file
Fig. 6-5
The HFS displayed in figure 6-5 appears to the z/OS catalog
as a single data set, arranged in a mountable file system.
The first system file mounted is called the root. Subsequent
file systems can be mounted within the root file system or on
a directory within a mounted file system. Each mountable
file system data set can reside on direct access storage.
Within UNIX System Services (USS), information in HFS files
is accessed by programs via system calls instead of the
standard access methods and macros. Specific data files are
accessed by using a path name to locate them.
POSIX and BFS
POSIX (Portable Operating System Interface) is a convention
used to define initial branches (directories) where
additional data is stored. To access a file, it is necessary
to know the structure of the file hierarchy. The complete
file name is called the path, which describes the exact
location of the file within the file tree.
BFS (Byte File System) for UNIX System Services (USS) has an
ordered sequence of bytes rather than records. BFS allows
data to be organized and used in a UNIX-like environment.
Within the Language Environment library, C library routines
provide the POSIX interfaces for BFS directories and files.
BFS was derived from the file systems that are present on
UNIX operating systems.
UNIX SYSTEM SERVICES (USS) AND LICENSED PROGRAMS
z/OS USS interacts with other licensed programs:
o APPC
Provides address spaces when a fork(), or spawn(), or USS
callable service is issued.
o C/C++ Compiler
Assembler interface for applications that do not use C/C++
runtime libraries.
o Language Environment (LE)
Executes shells and utilizes, or other XPG4-compliant
shell applications.
o Data Facility Storage Management Subsystem
o Resource Access Control Facility (RACF)
o Resource Measurement Facility (RMF)
o System Display and Search Facility (SDSF)
o Time Sharing Option Extensions (TSO/E)
o Transmission Control Program/Internet Protocol (TCP/IP)
o ISPF dialogs, for OEDIT, or ISPF/PDF for the Open MVS ISPF
Shell
o Book Manager READ/MVS, to use the OHELP online help
facility
UNIX SYSTEM SERVICES (USS) APPLICATION SERVICES
UNIX System Services (USS) Application services interprets
commands from interactive users or from programs called shell
scripts. It requests services in response to commands, and
provides a DBX debugger for C application programming.
It also provides:
o TSO/E command shell environment
o Application Development and execution shell environment
o Socket application support
o Remote login and inetd (start an application) function
CONCEPT OF FORK() AND SPAWN ()
Fork() is a function that creates child processes that
contain map areas. It also allows multiple processes to
share a map area; however, it is not shared memory. The
child process is then placed into a new address space called
the forked address space.
A spawn() will also start a child process in a new address
space. Logically, a spawn() replaces a fork() and EXEC
combination. Unlike a fork(), a spawn() calls the parent
process while specifying a name of a program in order to
start the child process. The implementation of spawn()
avoids system overhead use.
Types of processes can be user processes. The user processes
are associated with a specific user and Web server processes.
Processes may have more than one thread, which is a single
flow of control. An application structure with multiple
processes, made up of multiple threads, may be run parallel
and in independent sections for efficiency in utilizing
system resources.
STARTING UNIX SYSTEM SERVICES (USS)
UNIX System Services (USS) runs as a started procedure using
parameters defined during initialization. These parameters
can be customized for a specific environment. The USS
parameters are in SYS1.PARMLIB(BPXPRMxx). During the APPLY
process, a sample of the started procedure OMVS is installed
as member OMVS in SYS1.SAMPLIB, which requires little or no
customization. This procedure also determines which BPXPRMxx
member in SYS1.PARMLIB will be used during initialization.
These initialization parameters define processing controls,
and the root file system name to be used.
MICS SUPPORT FOR UNIX SYSTEM SERVICES (USS)
MICS support for UNIX System Services (USS) is provided with
two batch information area files. The USS Program File
(BAT_OE) is created from the SMF type 30 record (subtypes
2,3,and 4). These files are produced for every USS step,
substep, or interval completion. The USS Process Activity
FIle (BATOEP) is created from the SMF type 30 interval and
step termination records. These files are discussed in
detail in Sections 5.2.13 and 5.2.14.
The following sections describe various aspects of USS
available for address space accounting:
1 - UNIX System Services(USS)
Address Space Accounting
2 - UNIX System Services(USS)
EXEC Family of Functions
3 - UNIX System Services(USS)
File System Activity
