D.0 Appendix D. Running Multiple Versions of CMS Pipelines Concurrently This appendix describes how CMS Pipelines initialises itself and how you can use two or more versions of CMS Pipelines concurrently if you perform the initialisation explicitly. D.1 Basic Initialisation These steps are performed when the PIPE command is issued for the first time in a CMS session (assuming, for the moment, that the code is loaded from disk): 1. The PIPE MODULE is brought into the CMS transient area. This is a small bootstrap module. 2. The bootstrap module looks for the nucleus extension PIPMOD, which contains the main pipeline module. Initially, this module is not loaded as a nucleus extension. 3. The bootstrap module loads PIPELINE MODULE as a system nucleus extension under the name PIPMOD. (The VM/ESA pipeline is loaded from the module DMSPIPE instead.) 4. The bootstrap issues PIPMOD INSTALL to make the main pipeline module initialise itself. 5. The main pipeline module declares a (user) nucleus extension for PIPE. This nucleus extension will process future PIPE commands. 6. The bootstrap module regains control when the main module has been initialised. The bootstrap clears out the name of the module loaded in the transient area (to avoid a recursion) and then re-issues the original PIPE command to process the pipeline specification. This time the command is processed by the main pipeline module. A CMS ABEND will cause the PIPE nucleus extension to be dropped, because it is a user extension; but the PIPMOD nucleus extension will remain installed, because it is a system extension. A subsequent PIPE command will then bypass step 3. Because the main module is several hundred kilobytes in size, it is recommended that it be installed in a shared segment. For modern VM systems, use a logical segment. (The program directory for the Program Offering describes how to specify CMS Pipelines to DMKSNT, the system name table.) D.2 Initialisation of a Shared Segment This statement should be used to include the main pipeline module in a logical segment: MODULE PIPELINE ( SYSTEM SERVICE IMMCMD NAME PIPMOD When the main pipeline module is installed in a shared segment, the segment is attached to the virtual machine by the CMS command SEGMENT LOAD. This is normally performed in the system profile before any pipeline specifications have been issued. The main module is now installed as a nucleus extension by CMS. Thus, step 3 is bypassed when the pipeline is initialised on the first PIPE command. D.3 Co-residence The Program Offering version of CMS Pipelines can co-exist with the version shipped as part of Virtual Machine/Enterprise Systems Architecture from Release 1.1. The version used is determined by which of the two PIPE bootstrap modules is loaded into the transient area in step 1. Make sure the module you wish to use is first in the search order or installed as a nucleus extension. You can perform part or all of this initialisation procedure by hand to install a different module or to use a command name other than PIPE. Assuming you are running with the Program Offering level of CMS Pipelines and you wish to try some commands against the pipeline shipped in Virtual Machine/Enterprise Systems Architecture, you can issue these commands to make an EPIPE command: nucxload epipmod dmspipe (system service immcmd epipmod install epipe To use QPIPE to issue pipeline specifications to the Program Offering: nucxload qpipmod pipeline (system service immcmd qpipmod install qpipe D.3.1 Filter Packages The glue code in PIPNXF (DMSPFP in Virtual Machine/Enterprise Systems Architecture) assumes that the main pipeline module is installed as the nucleus extension PIPMOD. Explicit installation of a filter package is required to use it with a pipeline that resides in a different nucleus extension. Perform these steps to install the module FPACK as a filter package with a main pipeline module that is installed as MPIPE. As case is important in these commands, they should be issued from an EXEC that has issued the instruction Address Command. 1. Install the filter package module as a nucleus extension with SYSTEM and SERVICE attributes: NUCXLOAD FPACK ( SYSTEM SERVICE 2. Invoke the filter package with the argument as shown: FPACK 5785-RAC load MPIPE 3. Before the nucleus extension that contains the filter package can be dropped, the association from the main module must be broken (unless the main module itself is dropped before the filter package is): FPACK 5785-RAC drop MPIPE 4. You can now drop the filter package: NUCXDROP FPACK Warning: Results are unpredictable (but are likely to be catastrophic) if a filter package is dropped without the main pipeline module being notified. This leaves a dangling pointer to what was once the entry point table in the filter package. A program check is likely next time an entry point is to be resolved by that particular pipeline module.