[MUSIC] In z/OS UNIX, pipes are a communication mechanism for sending arrays of data between two processes. Pipes are conceptually like a sequential file processes can write into a pipe and other processes can read from the pipe. Pipes exist only during the time they're open, the storage needed for the pipes is obtained from a data space associated with the kernel address space. And there are two types of pipes, unnamed pipes are used between related processes so for example between a parent and a child process. An unnamed pipe is created by the pipe function, the pipe function also opens the pipe. The use no security checking is performed on unnamed pipes since they're available only to a process and it's children. And there's also named pipes which are also called FIFO, a FIFO resides in the hierarchical file system and can be referenced by a name, thus they can be used for communication between any two processes. Once processes are created, there are many ways to communicate between them, we've already talked about pipes being the most common way. Other ways include wait and execute, a parent process can wait on the exit of a child. Signals, one process can send the system or use a signal to another, the receiving process should be coded to receive and process the signal. There's shared memory, since processes run in different address spaces these services can be used to define specific memory to be shared, the kernel will keep these pages in a shared data space. Message queues, this is a technique similar to piping but with the capability of reading and writing a message at a time, rather than a string of characters. The kernel also uses a shared data space for these messages, and there's semaphore is which are used to control the use of shared memory by multiple processes they, are kept in the kernel process. The z/OS UNIX inter-process communication or IPC functions are shared memory, message queues, and semaphore. Users can invoke applications that create IPC resources and wait for IPC resources. IPC resources are not released when a process terminates or a user logs off, therefore it is possible that an IPC user might need assistance to remove an IPC resource using the shell's ipcrm Command. The ipcr sShell command can be used to display the IPC resources in a system, which users own the resources and which users are waiting for a resource. Frequently used z/OS UNIX programs can be placed into the z/OS link back area or the LPA, to improve performance. The shell's a good candidate for that because only one copy of it can be used by all requesters, saving space and I/O. When searching for a program with the sticky bit on z/OS UNIX will look in the user's step line, the link back area and the link list concatenation. In order to keep a z/OS UNIX program in LPA a number of things must be done. The file in the hierarchical file system that contains the program, must have the sticky bit set by an authorized user, the sticky bit can also be set on a directory level. It limits removing or renaming subdirectories or files to the owner or the super user. Also, the program must be link edited and placed in SYS1.LPALIB or a data set in LPA list, the program is copied to LPA during the next IPL. Threads provide support for multiple separate units of dispatch, able work within a process. A z/OS UNIX thread can be compared with the a z/OS task, the thread support allows application programmers to develop multitasking server applications that require multiple concurrent execution streams. A program using threads can have significant performance benefits and in multi-processor environment where each thread in the process can run on an individual processor. Threads are created with the p thread underscore create c function, since threads share address bace, there are services to protect the memory of the address base and to synchronize the execution of the threads. These are M-U-T-E-X, which is a structure associated with the variable, and used by threads to determine if a variable is in use, and condition variable used to synchronize the execution of the activities of the threads. So what are some of the differences between z/OS tasks and POSIX threads? Z/OS is a task hierarchy, in POSIX threads have no hierarchy except the initial thread which behaves differently from the other threads. Z/OS tasks usually run different programs or POSIX threads in a process run these same program. X/OS tasks can be independent or cooperating, POSIX threads must cooperate they do not operate independently. Z/OS allocates storage at task level and some stories can be shared between tasks and some not. The programs can be located in common storage, CSA or LPA in private area below the 16 megabyte line, or in private area above the 16 megabyte line. All POSIX threads in a process share all storage allocated to the process. Now this diagram shows the z/OS program management functions, and the equivalent functions in z/OS UNIX. Some of these similarities include the programs can reside in different libraries, and there is an automatic search to locate them. Both interfaces provide a method to replace the current executing program with a new program, and both sets of interfaces have ways to create work in separate address spaces. But there are also many differences, including with tasks, load, and program execution. And that's it for z/OS UNIX functions, in the next module we'll look at working with the z/OS UNIX environment. [MUSIC]
