[MUSIC] In this module, we're going to discuss units, processes, along with program execution, pipes, and threads. And let's get started by asking what are the functions and interfaces for z/OS UNIX System Services? The XPG 4.2 API is defined in a set of standards from the open group. This API defines some general operating system functions, as well as some functions that are specific to a UNIX system. Programs which conform to XPG 4.2 UNIX are fully supported by the UNIX System Services or USSAPI. The XPG 4.2 functions are defined in terms of C language bindings. When a z/OS UNIX program requests a system service, the following events take place. First of all, the application programmer codes a C language statement with a function request, for example, fork. Fork requests that a new process be created. During compilation of the program, a section of code called a stub is included in the compiled module. When the program is run, the stub identifies the runtime library or the RTL routine corresponding to the fork function and passes control to this routine. For some functions, the service can be performed by the library routine itself. For others such as fork, the library routine includes a call macro instruction that selects the appropriate callable service to request by name. The callable service named BPX 1 FRK in turn caused the appropriate z/OS service function. And finally, the z/OS UNIX kernel performs the requested service. The XPG 4.2 kernel is a z/OS address space which is started at IPL time and initialized with system parameters in a sys1.palm member. All files are allocated to the kernel, and all I/O operations resulting calls to the kernel. Interactive users of z/OS UNIX services can log on to TSO/E in and issue the command OMVS. The OMVS command schedules a local process which is FPR, which shares the TSO address space. Additional address spaces can be created by shell commands. The workload manager or WLM is used to start these address spaces. Users attached to z/OS through a TCP/IP network can use the log in or telnet capability to enter the z/OS system. Their identity is checked and he shall address spaces created for them. Additional address spaces can be created for them by the workload manager for their shell commands. z/OS provides support to allow an installation to re-customize and reinitialize the z/OS USS environment without repealing the system. The F OMVS, SHUTDOWN operator command, along with the F OMVS, RESTART operator command can be used to shut down and then reinitialize the USS environment. A process is created to run a program and associated resources to the program. In z/OS UNIX, a process resides in an address space and that is the basic unit of work that runs within that address space. A process is created by another process or by a request for a z/OS UNIX service. A process that creates a new process is called a parent process and the new process is called a child process. A child process can be created by the fork callable service. That process is identified by a process ID or a PID, and it is associated with its parent process by a parent process ID or PPD. There are different types of processes. Now, there's user processes which are associated with the user program or a Shell user. Kernel processes perform system functions for the kernel, and daemon processes perform continuous or periodic system functions. To get information about z/OS UNIX processes, the Shell command ps can be used. A z/OS UNIX user can use this command to display information about all the active processes. A superuser can display information about all the processes in the system by using the command ps -A. PS is a very useful command when finding processes and handling them. D OMVS, SID = NNNor A = NNN displays process information for the specified hexadecimal address space ID or ASID. If the specified ASID is not a z/OS UNIX Systems Services address base and error message will be issued. The operator can display the status of a particular envious process and its threads with the following command. D OMVS,PID =, and then the process ID. This shows information about each thread of a multithreaded application. The thread ID would be needed to cancel an individual thread. There are several ways to stop a z/OS UNIX process. One option is the operator modifying command. The term option allows a signal interface routine to receive control before termination. The force option prevents the signal interface routine from receiving control before the process is terminated. A special option SHUTDOWN = FORKINIT can be used to bring down the system cleanly. Now be aware, it cancels all current BPX AS address spaces created as a result of spawn of fork. The kill shell command can be used to cancel a process. A user can cancel their own processes and a system administrator or a superuser has authority to kill other users' processes. TERM sends a sick term signal and KILL sends a sick kill signal. And the z/OS CANCEL command can be used to cancel an address space that contains a z/OS UNIX process. If the address base contains multiple processes, CANCEL causes all of them to terminate. UNIX system services processes is new, a type PS to access the processes' panel, which allows authorized users to display information about the US UNIX processes. You can then use the command C to cancel the process and D to display information about the process. Use pre, short for prefix or other filters to limit the rows displayed to some processes. Use ARR for a range to place interesting columns on the first panel. Jobname to keep rows from jumping around. Now, next up, we're going to ask what is a daemon?
