Customizing UNIX System Services on z/OS
IBM® Integration Bus requires the setup of some UNIX System Services system parameters.
About this task
This task is part of the larger task of customizing your z/OS® environment.
You can use the SETOMVS operator command for dynamic changes or the BPXPRMxx PARMLIB member for permanent changes. See the z/OS UNIX System Services section in the z/OS product documentation online.
Use the DISPLAY OMVS,OPTIONS command to display your current OMVS options.
Do not include the integration node addresses if you use the IEFUSI exit to limit the region size of OMVS address spaces.
- Set the UNIX System Services parameters
that are shown in the following table.
Description Parameter Value The maximum core dump file size (in bytes) that a process can create. Allow an unlimited size. MAXCORESIZE 2 147 483 647 The CPU time (in seconds) that a process is allowed to use. Allow an unlimited CPU time.
If you do not set MAXCPUTIME to the maximum value, you can set it on the TIME parameter of the integration node started task JCL. For more information, see Statements and parameters for BIPXPRMxx in the MVS™ Initialization Tuning and Reference of the z/OS product documentation online.
MAXCPUTIME 2 147 483 647 The address space region size. Set to the size of the biggest address space. MAXASSIZE > 1 073 741 824
A minimum value of 393 216 000 bytes is required.
The maximum number of processes for each user. MAXPROCUSER Set to a number greater than all integration nodes and associated integration servers, as well as any queue managers and channel initiators that are running with the same user ID. The maximum number of file descriptors that a single process can have open concurrently. MAXFILEPROC The number of descriptors includes all open files, directories, sockets, and pipes.
A minimum value of 65536 is required.
Specifies the maximum number of threads that a single process can have active. Depends on the definitions of message flows. MAXTHREADS MAXTHREADTASKS The value of MAXTHREADS and MAXTHREADTASKS depends on your application. To calculate the value that is needed for each message flow:
- Multiply the number of input nodes by the number of instances (extra threads +1).
- Sum the values of all message flows, and then add 10 to the sum.
- Add to the sum the number of threads that are used for each HTTP listener.
Specifies the maximum number of data space pages that can be allocated for memory mapping of z/OS UNIX files. This space is used by the Integration registry. MAXMMAPAREA Each integration node on the image requires 55000 pages. If you have many policies or service definitions, you might need to increase this value. MAXSHAREPAGES controls the maximum number of shared pages to be used for fork, shared memory, memory map files, and ptrace so you might need to adjust this value to accommodate adjustments to MAXMMAPAREA.
Deploying a message flow that starts an integration server in a new address space uses z/OS UNIX System Services Semaphore and SharedMemorySegment resources. Each new address space uses a semaphore and SharedMemorySegment. The SharedMemorySegment is deleted immediately after the new address space starts, but the semaphore remains for the life of the new address space.Certain z/OS UNIX System Services system parameters can affect the start of a new integration server address space, if you set them incorrectly. These parameters include:
You must set IPCSEMNIDS to a value four times the number of potential integration server address spaces on a system.
You must have one SharedMemorySegment for each integration server address space that is started. You must set IPCSEMNIDS to a value that exceeds the number of potential integration server address spaces on a system.
A control address space (BIPSERVICE and BIPBROKER processes) can be attached to many SharedMemorySegments - potentially, one for each integration server address space started for that integration node. You must set IPCSHMNSEGS to a value that exceeds the potential number of integration servers for each integration node.
- Ensure that you have sufficient space for temporary files.
The environment variable TMPDIR is the path name of the directory that is used for temporary files. If it is not set, the z/OS shell uses /tmp.
When IBM Integration Bus components start, sufficient space is required in the directory that is referenced by TMPDIR. In particular, Java™ requires sufficient space to hold all JAR files that are required by IBM Integration Bus.
If you do not allocate sufficient space, the integration server address spaces abend with a 2C1 code.
Allow at least 50 MB of space in this directory for IBM Integration Bus components. More space might be needed if you deploy large user-defined nodes or other JAR files to the integration node component.
- Define IBM Integration Bus files
as shared-library programs.
The shared library region is a z/OS feature that enables address spaces to share dynamic link library (DLL) files. This feature enables integration nodes to share DLLs, rather than each integration node loading the DLLs individually. The shared DLLs can be integration node DLLs, or DLLs from other products such as Java. The amount of real storage that is used by MVS, and the time it takes for each integration node to start, can thus be greatly reduced.If you plan to deploy to more than one integration server on z/OS, you can reduce the amount of storage that is required by the integration server address spaces. Set the shared-library extended attribute on the following files:
/usr/lpp/mqsi/bin/* /usr/lpp/mqsi/lil/* /usr/lpp/mqsi/lib/* /usr/lpp/mqsi/lib/wbimb/*To set the shared-library attribute, use the OMVS extattr command with the +1 option. For example:
extattr +l /usr/lpp/mqsi/bin/*To find out whether the shared-library extended attribute is set, use the ls -E command. For example, use the command ls -E bipimain to generate the following response:
-rwxr-x--- a-l- 1 USER GROUP 139264 Mar 15 10:05 bipimain
l(lowercase L, as in
a-l-) shows that the program is enabled to run in a shared address space.
For more information, see the z/OS product documentation online .
The storage that is reserved for the shared library region is allocated in each integration node address space when the first address space is started. The amount of storage that is allocated is controlled by the SHRLIBRGNSIZE parameter in z/OS, which is in the BPXPRMxx member of SYS1.PARMLIB. You can tune the amount of storage that is allocated for the shared library region. Investigate how much space you need, bearing in mind that other applications besides IBM Integration Bus might be using the shared library region. Then, adjust the SHRLIBRGNSIZE parameter accordingly.Use the following MVS command to check that you have enough SHRLIBRGNSIZE to contain all the shared-library programs that are to be used on the system:
If there is unused space in the shared library region, modify SHRLIBRGNSIZE to reduce the amount of storage that is allocated for the shared library region.
Storage is carved out of the high end of private storage of each address space that loads a system shared library object. The amount of storage that is allocated from each of these address spaces is based on the value of the SHRLIBRGNSIZE parameter in the BPXPRMxx PARMLIB member. If this value is too high, the storage that set aside for mapping the shared library region might interfere with the private storage requirements of individual address spaces. Therefore, specify the minimum size that is required to contain all of the shared library programs that are to be used on the system.Note: z/OS UNIX attempts to map the entire SHRLIBRGNSIZE into the private region, not just the portion that contains programs. If the private region is too small to map the entire SHRLIBRGNSIZE, this shared library region is not used. No message is issued to indicate what happened.
Use the SETOMVS operator command to change SHRLIBRGNSIZE dynamically, or the BPXPRMxx PARMLIB member for permanent changes. See the z/OS UNIX System Services section in the z/OS product documentation online.
- Set up administration log messages for z/OS.
To prevent the operator's console receiving unnecessary BIP messages, you must configure MPF to suppress all BIP messages, except for important messages. You do not need to have the
On z/OS, all address spaces have a job log where BIP messages issued by IBM Integration Bus appear. Additionally, all messages appear on the
syslogand important operator messages are filtered to the console by using MPF (Message Processing Facility).