	Subclass 1	Subclass 100
VIRTUAL MACHINE TASK OR PROCESS MANAGEMENT

Method, system and program products for enhancing input/output processing for operating system images of a computing environment

6996638

Abstract

An input/output subsystem is configured as a plurality of input/output subsystem images, each of which appears to a program as an independent input/output subsystem. An input/output subsystem image is identified by an input/output subsystem image identifier, which is used by various programs to designate the particular input/output subsystem image for which an I/O operation is to be performed. An operating system is provided with access to a plurality of input/output subsystem images of the input/output subsystem. One or more controls are provided to the operating system image to enable the operating system image to access the plurality of input/output subsystem images.

Claims

What is claimed is:

1. A computer implemented method of enhancing input/output (I/O) processing for operating system images of a computing environment, said method when executed comprising:

having an input/output subsystem of the computing environment, said input/output subsystem configured as a plurality of input/output subsystem images, wherein an input/output subsystem image appears to an operating system image of the computing environment as a complete input/output subsystem; and

providing one operating system image with concurrent access to multiple input/output subsystem images of the plurality of input/output subsystem images of an the input/output subsystem of the computing environment, wherein each input/output subsystem image of the multiple input/output subsystem images of the plurality of input/output subsystem images comprises a plurality of communications adapters.

2. The method of claim 1, wherein another operating system image of the computing environment is unaware that there is more than one input/output subsystem image.

3. The method of claim 2, wherein the one operating system image and the another operating system image are of a central processing complex of the computing environment, said central processing complex being coupled to the input/output subsystem.

4. The method of claim 1, wherein the providing comprises providing one or more controls to the one operating system image to enable the one operating system image to concurrently access the plurality of input/output subsystem images.

5. The method of claim 4, wherein the one or more controls comprise an enablement control set by the one operating system image to indicate that the one operating system image is able to concurrently access more than one input/output subsystem image.

6. The method of claim 4, wherein the one or more controls comprise an authorization list indicating the plurality of input/output subsystem images the one operating system image is allowed to access.

7. The method of claim 4, wherein the one or more controls comprise a multiple image facility (MIF) extension specifying a MIF image identifier to be used by the one operating system image in the plurality of input/output subsystem images the one operating system image is allowed to access.

8. The method of claim 1, further comprising specifying by the one operating system image a specific input/output subsystem image of the plurality of input/output subsystem images to be accessed by the one operating system image.

9. The method of claim 1, further comprising indicating by the one operating system image that a default input/output subsystem image is to be accessed by the one operating system image.

10. The method of claim 1, further comprising determining the multiple input/output subsystem images the one operating system image is authorized to access.

11. The method of claim 1, further comprising obtaining for the one operating system image information associated with one or more input/output subsystem images of the plurality of input/output subsystem images.

12. A system of enhancing input/output (I/O) processing for operating system images of a computing environment, said system comprising:

an input/output subsystem of the computing environment, said input/output subsystem configured as a plurality of input/output subsystem images, wherein an input/output subsystem image appears to an operating system image of the computing environment as a complete input/output subsystem; and

means for providing one operating system image with concurrent access to multiple input/output subsystem images of the plurality of input/output subsystem images of the input/output subsystem of the computing environment, wherein each input/output subsystem image of the multiple input/output subsystem images of the plurality of input/output subsystem images comprises a plurality of communications adapters.

13. The system of claim 12, wherein another operating system image of the computing environment is unaware that there is more than one input/output subsystem image.

14. The system of claim 13, wherein the one operating system image and the another operating system image are of a central processing complex of the computing environment, said central processing complex being coupled to the input/output subsystem.

15. The system of claim 12, wherein the means for providing comprises means for providing one or more controls to the one operating system image to enable the one operating system image to concurrently access the plurality of input/output subsystem images.

16. The system of claim 15, wherein the one or more controls comprise an enablement control set by the one operating system image to indicate that the one operating system image is able to concurrently access more than one input/output subsystem image.

17. The system of claim 15, wherein the one or more controls comprise an authorization list indicating the plurality of input/output subsystem images the one operating system image is allowed to access.

18. The system of claim 15, wherein the one or more controls comprise a multiple image facility (MIF) extension specifying a MIF image identifier to be used by the one operating system image in the plurality of input/output subsystem images the one operating system image is allowed to access.

19. The system of claim 12, further comprising means for specifying by the one operating system image a specific input/output subsystem image of the plurality of input/output subsystem images to be accessed by the one operating system image.

20. The system of claim 12, further comprising means for indicating by the one operating system image that a default input/output subsystem image is to be accessed by the one operating system image.

21. The system of claim 12, further comprising means for determining the multiple input/output subsystem images the one operating system image is authorized to access.

22. The system of claim 12, further comprising means for obtaining for the one operating system image information associated with one or more input/output subsystem images of the plurality of input/output subsystem images.

23. A system of enhancing input/output (I/O) processing for operating system images of a computing environment, said system comprising:

an operating system image of the computing environment; and

a plurality of input/output subsystem images of an input/output subsystem of the computing environment to which the operating system image has concurrent access, wherein each input/output subsystem image of multiple input/output subsystem images of the plurality of input/output subsystem images comprises a plurality of communications adapters, and wherein an input/output subsystem image appears to the operating system image of the computing environment as a complete input/output subsystem.

24. At least one program storage device readable by a machine embodying at least one program of instructions executable by the machine to perform a method of enhancing input/output (I/O) processing for operating system images of a computing environment, said method comprising:

having an input/output subsystem of the computing environment, said input/output subsystem configured as a plurality of input/output subsystem images, wherein an input/output subsystem image appears to an operating system image of the computing environment as a complete input/output subsystem; and

providing one operating system image with concurrent access to multiple input/output subsystem images of the plurality of input/output subsystem images of the input/output subsystem of the computing environment, wherein each input/output subsystem image of the multiple input/output subsystem images of the plurality of input/output subsystem images comprises a plurality of communications adapters.

25. The at least one program storage device of claim 24, wherein another operating system image of the computing environment is unaware that there is more than one input/output subsystem image.

26. The at least one program storage device of claim 25, wherein the one operating system image and the another one operating system image are of a central processing complex of the computing environment, said central processing complex being coupled to the input/output subsystem.

27. The at least one program storage device of claim 24, wherein the providing comprises providing one or more controls to the one operating system image to enable the operating system image to concurrently access the plurality of input/output subsystem images.

28. The at least one program storage device of claim 27, wherein the one or more controls comprise an enablement control set by the one operating system image to indicate that the one operating system image is able to concurrently access more than one input/output subsystem image.

29. The at least one program storage device of claim 27, wherein the one or more controls comprise an authorization list indicating the plurality of input/output subsystem images the one operating system image is allowed to access.

30. The at least one program storage device of claim 27, wherein the one or more controls comprise a multiple image facility (MIF) extension specifying a MIF image identifier to be used by the one operating system image in the plurality of input/output subsystem images the one operating system image is allowed to access.

31. The at least one program storage device of claim 24, wherein said method further comprises specifying by the one operating system image a specific input/output subsystem image of the plurality of input/output subsystem images to be accessed by the one operating system image.

32. The at least one program storage device of claim 24, wherein said method further comprises indicating by the one operating system image that a default input/output subsystem image is to be accessed by the one operating system image.

33. The at least one program storage device of claim 24, wherein said method further comprises determining the multiple input/output subsystem images the one operating system image is authorized to access.

34. The at least one program storage device of claim 24, wherein said method further comprises obtaining for the one operating system image information associated with one or more input/output subsystem images of the plurality of input/output subsystem images.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application contains subject matter which is related to the subject matter of the following applications, each of which is assigned to the same assignee as this application. Each of the below listed applications is hereby incorporated herein by reference in its entirety:

"MULTIPLE LOGICAL INPUT/OUTPUT SUBSYSTEM FACILITY," Brice et al., Ser. No. 10/436,021, filed herewith;

"MANAGING INPUT/OUTPUT SUBSYSTEM IMAGES OF AN INPUT/OUTPUT SUBSYSTEM," Brice et al., Ser. No. 10/435,773, filed herewith;

"METHOD, SYSTEM AND PROGRAM PRODUCTS FOR IDENTIFYING COMMUNICATIONS ADAPTERS OF A COMPUTING ENVIRONMENT," Brice et al., Ser. No. 10/436,385, filed herewith;

"MANAGING ACCESS, BY OPERATING SYSTEM IMAGES OF A COMPUTING ENVIRONMENT, OF INPUT/OUTPUT RESOURCES OF THE COMPUTING ENVIRONMENT," Brice et al., Ser. No. 10/436,240, filed herewith; and

"SHARING COMMUNICATIONS ADAPTERS ACROSS A PLURALITY OF INPUT/OUTPUT SUBSYSTEM IMAGES," Brice et al., Ser. No. 10/435,955, filed herewith.

TECHNICAL FIELD

This invention relates, in general, to input/output (I/O) processing, and in particular, to extending the functionality of input/output subsystems used in I/O processing.

BACKGROUND OF THE INVENTION

In various computing systems, such as the eServer zSeries, S/370-XA, ESA/370 and ESA/390 systems, offered by International Business Machines Corporation, Armonk, N.Y., each system footprint, referred to as a central processing complex (CPC), is limited to a maximum configuration of 256 I/O paths, such as, for example, 256 channel paths. One of the reasons for the constraint is that the unique identifier for each channel path configured to the CPC, referred to as the Channel Path Identifier (CHPID), is defined as an 8-bit binary number, which provides 256 unique CHPID values from zero to 255. Since this value is only 8-bits, only 256 paths with unique identifications are possible. One solution is to increase the size of the CHPID; however, this has serious consequences for the many programs that use the CHPID.

This 256-channel path limitation has restricted the ability to provide significant increases in the overall CPC in terms of the maximum processing capacity of the central processors provided by the CPC. Further, computing systems are being created in which the total computing capacity of the systems is increasing past the point where 256 channel paths are sufficient in order to provide adequate I/O bandwidth and I/O configuration flexibility necessary to fully utilize the increased numbers of central processors.

Thus, a need exists for a capability to extend the functionality of an input/output subsystem. In one example, a need exists for a facility that can provide more than 256 I/O paths in a manner that is minimally disruptive to the programs using the paths.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of enhancing input/output (I/O) processing for operating system images of a computing environment. The method includes, for instance, obtaining an operating system image of the computing environment; and providing the operating system image with access to a plurality of input/output subsystem images of an input/output subsystem of the computing environment.

In one example, another operating system image of the computing environment is unaware that there is more than one input/output subsystem image. The operating system image and the another operating system image are of a central processing complex of the computing environment, which is coupled to the input/output subsystem.

In a further example, the providing of the operating system image with access includes providing one or more controls to the operating system image to enable the operating system image to access the plurality of input/output subsystem images.

System and computer program products corresponding to the above-summarized methods are also described and claimed herein.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1a depicts one embodiment of a computing environment to incorporate and use one or more aspects of the present invention;

FIG. 1b depicts one example of an I/O path (e.g., a channel path) used for communications in the computing environment of FIG. 1a, in accordance with an aspect of the present invention;

FIG. 1c depicts one embodiment of an example of an I/O subsystem (e.g., a channel subsystem) of FIG. 1a being configured as a plurality of I/O subsystem (e.g., channel subsystem) images, in accordance with an aspect of the present invention;

FIG. 1d depicts further details of a multiple image facility (MIF) image of a channel subsystem image of FIG. 1c, in accordance with an aspect of the present invention;

FIG. 1e depicts further details of a channel path set (CPS) of a channel subsystem image of FIG. 1c, in accordance with an aspect of the present invention;

FIG. 2 depicts one embodiment of a plurality of logical partitions coupled to a plurality of channel subsystem images, in accordance with an aspect of the present invention;

FIG. 3 depicts one embodiment of associating physical channel numbers with logical channel numbers and channel subsystem images, in accordance with an aspect of the present invention;

FIG. 4a illustrates one example of the same physical channel being used by two channel subsystem images, as well as different channel subsystem images having the same channel numbers (CHPIDs) that refer to different physical channels, in accordance with an aspect of the present invention;

FIG. 4b is an illustration of a CHPID statement generating data structures in an I/O configuration data set (IOCDS), in accordance with an aspect of the present invention;

FIG. 4c illustrates the adding of additional information for channel subsystem images to a physical control unit data structure of the IOCDS, in accordance with an aspect of the present invention;

FIG. 4d illustrates that a device that is accessible by multiple channel subsystem images is represented in a subchannel data structure for each channel subsystem image, in accordance with an aspect of the present invention;

FIG. 5a depicts one embodiment of a request block for a change channel path configuration command, in accordance with an aspect of the present invention;

FIG. 5b depicts one embodiment of a response block for the change channel path configuration command, in accordance with an aspect of the present invention;

FIGS. 5c-5f depict various checks that are performed during execution of the change channel path configuration command, in accordance with an aspect of the present invention;

FIG. 6a depicts one embodiment of a request block for a change control unit configuration command, in accordance with an aspect of the present invention;

FIG. 6b depicts one embodiment of a response block for the change control unit configuration command, in accordance with an aspect of the present invention;

FIG. 6c depicts further details regarding a shared device cluster block of the response block of FIG. 6b, in accordance with an aspect of the present invention;

FIG. 6d depicts further details regarding a subchannel block of the response block of FIG. 6b, in accordance with an aspect of the present invention;

FIGS. 6e-6h illustrate various checks that are performed during execution of the change control unit configuration command, in accordance with an aspect of the present invention;

FIG. 7a depicts one embodiment of a request block for a change I/O device configuration command, in accordance with an aspect of the present invention;

FIG. 7b depicts one embodiment of a response block for the change I/O device configuration command, in accordance with an aspect of the present invention;

FIG. 7c depicts one embodiment of further details regarding a shared device cluster block of the response block of FIG. 7b, in accordance with an aspect of the present invention;

FIG. 7d depicts one example of further details of a subchannel block of the response block of FIG. 7b, in accordance with an aspect of the present invention;

FIGS. 7e-7h depict various checks that are performed during execution of the change I/O device configuration command, in accordance with an aspect of the present invention;

FIG. 8a depicts one embodiment of a request block for a store configuration component list command, in accordance with an aspect of the present invention;

FIG. 8b depicts one embodiment of a response block for the store configuration component list command, in accordance with an aspect of the present invention;

FIG. 9a depicts one embodiment of a request block for a store domain configuration component list command, in accordance with an aspect of the present invention;

FIG. 9b depicts one embodiment of a response block for a store domain configuration component list command, in accordance with an aspect of the present invention;

FIG. 10a depicts one embodiment of a control block associated with a configure channel path command and a deconfigure channel path command, in accordance with an aspect of the present invention;

FIG. 10b depicts one embodiment of a control block associated with a read channel path information command, in accordance with an aspect of the present invention;

FIG. 11a depicts one embodiment of a control block associated with a configure channel path function and a deconfigure channel path function, in accordance with an aspect of the present invention;

FIG. 11b depicts one embodiment of a control block associated with an image reset function, in accordance with an aspect of the present invention;

FIG. 12a depicts one embodiment of a request block for a set domain attributes command, in accordance with an aspect of the present invention;

FIG. 12b depicts one embodiment of a response block for the set domain attributes command, in accordance with an aspect of the present invention;

FIG. 13a depicts one embodiment of a request block for a store domain configuration attributes list command, in accordance with an aspect of the present invention;

FIG. 13b depicts one embodiment of a response block for the store domain configuration attributes list command, in accordance with an aspect of the present invention;

FIG. 14a depicts one embodiment of a request block for a store channel subsystem characteristics command, in accordance with an aspect of the present invention; and

FIG. 14b depicts one embodiment of a response block for the store channel subsystem characteristic command, in accordance with an aspect of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In accordance with an aspect of the present invention, a multiple logical input/output (I/O) subsystem facility is provided in which a physical input/output subsystem is configured as a plurality of input/output subsystem images in order to logically expand the functionality of the input/output subsystem. A configured I/O subsystem image appears to a program (e.g., an operating system) as an independent input/output subsystem.

One embodiment of a computing environment to incorporate and use one or more aspects of the present invention is described with reference to FIG. 1a. In one example, computing environment 100 is based on the z/Architecture, offered by International Business Machines Corporation, Armonk, N.Y. The z/Architecture is described in an IBM Publication entitled "z/Architecture Principles of Operation," Publication No. SA22-7832-01, October 2001, which is hereby incorporated herein by reference in its entirety.

As one example, computing environment 100 includes a central processor complex (CPC) 102 coupled to one or more input/output (I/O) devices 106 via one or more control units 108. Central processor complex 102 includes, for instance, one or more central processors 110, one or more partitions 112 (e.g., logical partitions (LP)), a logical partition hypervisor 114, and an input/output subsystem 115, each of which is described below.

Central processors 110 are physical processor resources allocated to the logical partition. In particular, each logical partition 112 has one or more logical processors, each of which represents all or a share of a physical processor 110 allocated to the partition. The logical processors of a particular partition 112 may be either dedicated to the partition, so that the underlying processor resource 110 is reserved for that partition; or shared with another partition, so that the underlying processor resource is potentially available to another partition.

A logical partition functions as a separate system and has one or more applications and a resident operating system therein, which may differ for each logical partition. In one embodiment, the operating system is the z/OS operating system, the z/VM operating system, the z/Linux operating system or the TPF operating system, offered by International Business Machines Corporation, Armonk, N.Y.

Logical partitions 112 are managed by a logical partition hypervisor 114, which is implemented by Licensed Internal Code running on processors 110. The logical partitions and logical partition hypervisor each comprise one or more programs residing in respective partitions of central storage associated with the central processors. One example of logical partition hypervisor 114 is the Processor Resource/System Manager (PR/SM), offered by International Business Machines Corporation, Armonk, N.Y. Further details regarding logical partitions are described in, for instance, Guyette et al., U.S. Pat. No. 4,564,903, entitled "Partitioned Multiprocessor Programming System," issued on Jan. 14, 1986; Bean et al., U.S. Pat. No. 4,843,541, entitled "Logical Resource Partitioning Of A Data Processing System," issued on Jun. 27, 1989; and Kubala, U.S. Pat. No. 5,564,040, entitled "Method And Apparatus For Providing A Server Function In A Logically Partitioned Hardware Machine," issued on Oct. 8, 1996, each of which is hereby incorporated herein by reference in its entirety.

Input/output subsystem 115 directs the flow of information between input/output devices 106 and main storage. It is coupled to the central processing complex, in that it can be a part of the central processing complex or separate therefrom. The I/O subsystem relieves the central processors of the task of communicating directly with the input/output devices and permits data processing to proceed concurrently with input/output processing. To provide communications, the I/O subsystem employs I/O communications adapters. There are various types of communications adapters including, for instance, channels, I/O adapters, PCI cards, Ethernet cards, Small Computer Storage Interface (SCSI) cards, etc. In the particular example described herein, the I/O communications adapters are channels, and therefore, the I/O subsystem is referred to herein as a channel subsystem. However, this is only one example. Other types of I/O subsystems can incorporate and use one or more aspects of the present invention.

The I/O subsystem uses one or more input/output paths as communication links in managing the flow of information to or from input/output devices 106. In this particular example, these paths are called channel paths, since the communications adapters are channels. Each channel path 116 (FIG. 1b) includes a channel 117 of channel subsystem 115, a control unit 108, a link 118 (e.g., serial or parallel) between the channel and control unit, and one or more I/O devices 106 coupled to the control unit. In other embodiments, channel paths may have multiple control units and/or other components. Further, in another example, it is also possible to have one or more dynamic switches as part of the channel path. A dynamic switch is coupled to a channel and a control unit and provides the capability of physically interconnecting any two links that are attached to the switch. Further details regarding channel subsystems are described in Casper et al., U.S. Pat. No. 5,526,484, entitled, "Method And System For Pipelining The Processing Of Channel Command Words," issued on Jun. 11, 1996, which is hereby incorporated herein by reference in its entirety.

A control unit may be accessible by the channel subsystem by more than one channel path. Similarly, an I/O device may be accessible by the channel subsystem through more than one control unit, each having one or more channel paths to the channel subsystem. The control unit accepts control signals from the channel subsystem, controls the timing of data transfer over the channel path, and provides indications concerning the status of the device. The control unit may be housed separately or it may be physically and logically integrated with the I/O device, the channel subsystem, or a central processor.

The I/O device attached to the control unit may be designed to perform certain limited operations, or it may perform many different operations. To accomplish its operations, the device uses detailed signal sequences peculiar to its type of device. The control unit decodes the commands received from the channel subsystem, interprets them for the particular type of device, and provides the signal sequence required for the performance of the operation.

In addition to one or more channels, a channel subsystem includes one or more subchannels. Each subchannel is provided for and dedicated to an I/O device, or group of I/O devices, coupled to the program through the channel subsystem. Each subchannel provides information concerning the associated I/O device, or group of I/O devices, and its attachment to the channel subsystem. The subchannel also provides information concerning I/O operations and functions involving the associated I/O device, or group of I/O devices. The subchannel provides a logical appearance of a device or group of devices to the program and is the means by which the channel subsystem provides information about associated I/O devices to the central processors, which obtain this information by executing I/O instructions. The subchannel has internal storage that includes information in the form of a channel command word (CCW) address, a channel path identifier, device number, count, status indication and I/O interruption subclass code, as well as information on path availability and functions pending or being performed. I/O operations are initiated with a device by the execution of I/O instructions that designate the subchannel associated with the device or devices.

Further details regarding a channel subsystem are described with reference to FIG. 1c. In accordance with an aspect of the present invention, channel subsystem 115 (or other I/O subsystem) is configured as a plurality of channel subsystem images 120 (or other I/O subsystem images), each identified by a channel subsystem image identifier (CSSID) (or other I/O subsystem identifier). In one example, the channel subsystem is configured, either by model dependent means, in which configuration controls are used during initialization, or by use of appropriate dynamic I/O configuration commands, as one to 256 channel subsystem images, as described in further detail below. Each channel subsystem image appears to a program as a complete channel subsystem. Each channel subsystem image may have from 1 to 256 unique channel paths, thereby increasing the maximum number of channel paths that may be configured to the channel subsystem from 256 to 65,536.

A channel subsystem image 120 includes, for instance, a multiple image facility (MIF) 122, which includes one or more (e.g., up to 16) MIF images, each identified by a MIF image identifier (IID). The multiple image facility allows each logical partition to achieve independent access to the channel paths, control units and I/O devices that are configured to and dynamically shared by multiple logical partitions.

As one example, each logical partition is configured to a different MIF image (see FIG. 2) in order to provide the logical partition with an independent set of controls for channel paths, control units and devices that are shared by other logical partitions. Various details regarding the multiple image facility are described in Brice, Jr. et al., U.S. Pat. No. 5,414,851, entitled "Method And Means For Sharing I/O Resources By A Plurality Of Operating Systems," issued on May 9, 1995, which is hereby incorporated herein by reference in its entirety.

As shown in FIG. 1d, for each MIF image, a separate set of channel path controls and a separate set of subchannel controls are provided by the channel subsystem. For each MIF image, each set of channel path controls for each configured channel path is called a channel path image 124. The collection of one or more channel path images associated with the channel paths that are configured to a MIF image is called a channel path image set 126. Further, for each MIF image, a separate subchannel, called a subchannel image 128, is provided for each I/O device or group of devices that is configured to the MIF image. A collection of one or more subchannel images that are configured to a MIF image is called a subchannel image set 130.

Referring back to FIG. 1c, in addition to a MIF, a channel subsystem image 120 also includes a channel path set (CPS) 134. Channel path set 134 includes, for instance, one to 256 channel paths 140 (FIG. 1e) configured to one or more channel path images in the associated MIF. Each channel path is identified by a channel path identifier (CHPID). Each channel path configured to a channel path set may be unique from other channel paths configured to other provided channel subsystem images. However, because as many as 256 channel subsystem images may be provided, the CHPID values assigned to channel paths in each of the channel path sets may not be unique. Therefore, each channel path is specified by a unique address formed by, for instance, a concatenation of CSSID with the channel path identifier assigned to the channel path. The image ID (IID) further identifies a channel path image for each configured channel path.

With the exception of certain channel subsystem interfaces used to control the resetting and configuration of channel paths, both the CSSID and IID values may be implicitly specified for the programs operating in the logical partitions, and are therefore, transparent to the programs. For instance, instead of programs that are operating in the logical partitions specifying the CSSID, the LPAR hypervisor implicitly specifies the CSSID configured to each LPAR. This is accomplished by using a Start Interpretative Execution (SIE) facility, as described in "IBM System/370 Extended Architecture Interpretative Execution," Publication No. SA22-7095, September 1985, which is hereby incorporated herein by reference in its entirety.

In one example, for I/O instructions that execute in Start Interpretive Execution (SIE) I/O-passthru mode, the LPAR hypervisor places the CSSID value into a SIE state description, used by the hypervisor and the SIE facility, to dispatch and control the programs operating in the logical partitions. The SIE state description is, for instance, an operand to a Start Interpretive Execution (SIE) instruction that includes various fields subsequently used to interpretively start an I/O instruction, in a manner that causes the CSSID value and other associated parameters to be passed to the channel subsystem transparently to the program operating in the logical partition or virtual machine. These fields include, for instance, the following:

(a) CSS-Authorization-Vector Origin (CAVO): When the MCSS facility is installed, this field includes a host-absolute/real address that when not zero points to an authorization vector that serves the dual purpose of enabling access to channel subsystem images, and specifying the default MIF image identifier to be used in association with the CSS image. The initial state of CAVO is zero. When a Multiple Channel Subsystem Enhanced (MCSSE) facility (described below) is enabled via a Set Domain Attributes CHSC command (also described below), the CPC places a non-zero CAVO in the SIE state description. When the MCSSE facility is disabled, the CAVO is set to zero. Therefore, the enablement of the MCSSE facility may be determined from the value of the CAVO.
The CSS-authorization vector includes a model dependent number of entries, with each entry corresponding to one CSS image, where entry zero corresponds to CSS image zero, entry one corresponds to CSS image one, and so on. The number of entries is equal to one plus the value of the highest CSSID provided on the machine, with the latter provided in the response of a Store Channel Subsystem Characteristics command (described below), when the MCSS facility is provided by the CPC. When an entry contains the number zero, the CSS image corresponding to the entry is not accessible. However, when an entry contains a non-zero number, that number is used as the MIF-image identifier in association with the CSS image. When a CSS image is accessible, its CSSID and corresponding IID may be specified in certain I/O or CHSC instructions or for other uses, by or on behalf of the program operating in a logical partition or virtual machine. For I/O instructions, the CSSID and IID are specified in a subsystem identifier (SID) and other implied operands.
When the CAVO is zero, the program operating in the logical partition or virtual machine, can access only the default channel subsystem, and thus, specifies a CSSID of zero in the SID.
(b) Default Channel Subsystem Image Identifier (CSSID): This field includes the default channel subsystem image identifier associated with the program operating in the logical partition or virtual machine.
(c) MIF Image Identifier: This field includes the default MIF image identifier associated with the program operating in a logical partition or virtual machine.

During the execution of high frequency I/O instructions that have an I/O passthru facility, the SIE I/O instruction passthru interpretation extensions for MCSS implicitly transmit the CSSID from the active SIE state description to the channel subsystem just as if the CSSID was specified in general register one, which is an implied operand for some I/O instructions. This implicit specification is also provided for the IID value.

For infrequently executed I/O instructions, execution of the instruction by the program operating in the logical partition causes the LPAR hypervisor to gain control, which stores the proper CSSID value (as well as the proper MIF IID value) into general register 1, and re-executes the I/O instruction on behalf of the program operating in the logical partition in a manner that is transparent to the program.

One type of instruction that uses general register 1 as an implied operand includes those instructions that reference a subchannel. For those I/O instructions, general register 1 includes a subsystem identification word (SID). In accordance with an aspect of the present invention, the subsystem identification word includes, for instance, the following fields:

(1) Channel Subsystem Id (CSSID), which specifies a binary number of the channel subsystem image containing the referenced subchannel;
(2) MIF IID, which specifies a binary number of the MIF image within the channel subsystem image containing the referenced subchannel. I/O instructions that expect an IID in the subsystem identification word (SID) are extended to expect a specification of the CSSID value of the associated channel subsystem image;
(3) Subchannel Number, which specifies a binary number of the subchannel within the specified channel subsystem image to be used for the function specified by the I/O instruction; and
(4) Multiple Channel Subsystem Bit (M), which indicates whether the CSSID is checked for validity. When M is one, the CSSID field is checked for a valid CSSID. If valid, the value in the CSSID field becomes the effective CSSID. If not valid, an appropriate response code may be stored. When M is zero, the default CSSID is the effective CSSID and the CSSID field is zero. In one example, this field is only used when MCSSE is enabled

As described above, in one example, the channel subsystem id specified in the subsystem identification word (and other request blocks) is checked for validity before it becomes an effective CSSID. When a valid CSSID is specified, the specified CSSID is the effective CSSID. When a CSSID is not specified, a default CSSID is used as the effective CSSID.

In one example, to check for validity, a CSSID of a SID is subject to range, existence and authorization checking. (A CSSID elsewhere in a program request block may or may not be subject to authorization checking.)

Range checking includes, for instance, verifying that the CSSID value is between a range of zero and h, where h is the highest CSSID provided on the model (e.g., 255).

Existence checking, in one example, verifies that a valid CSSID is defined in the I/O configuration definition, and thus, is in the configuration of the CPC. In one example, a Store Configuration Component List command (described below) is used to obtain the list of CSSID values provided on the CPC.

Authorization checking includes, for instance, verifying that a MIF-image combination (a channel subsystem image that has an associated MIF image), as identified by its CSSID, is authorized for use by a program in a logical partition. To successfully pass the authorization check, the CSSID-authorization vector of the logical partition is to have a CAV entry that represents the MIF-image combination.

There are various subchannel related I/O instructions, which use a SID and which the LPAR hypervisor and SIE MCSS extensions apply. These include, for instance, Cancel Subchannel, Clear Subchannel, Diagnose-CSI, Halt Subchannel, Modify Subchannel, Resume Subchannel, Signal Adapter, Start Subchannel, Store Subchannel, and Test Subchannel.

Other non-subchannel related I/O instructions are similarly enhanced to allow the CSSID for the target channel subsystem image to be specified in a manner that is transparent to the programs operating in the logical partitions. They include, for instance:

(a) Store Channel Report Word—With this instruction, general register 1 includes a CSSID identifying the channel subsystem image from which a channel report is to be retrieved. In one example, when a condition affecting multiple channel subsystem images is recognized, multiple channel report words (CRWs) may be made pending, one CRW for each of the affected channel subsystem images. In this case, multiple store channel report word instructions are issued to retrieve the CRWs.
(b) Reset Channel Path—The channel path reset facility is signaled to perform the channel path reset function on the channel path image designated by the contents of general register 1. In one example, general register 1 includes the channel subsystem image id identifying the channel subsystem image containing the designated channel path. In addition, general register 1, as observed by the LPAR hypervisor, when the CPC is operating in LPAR mode, includes a MIF image identifier designating the MIF image of the channel path to be reset. Additionally, a channel path identifier is specified designating the channel path image on which the channel path reset function is to be performed.
The LPAR hypervisor is responsible for ensuring that a valid CSSID is specified and to simulate an operand exception if the CSSID is not valid.

As described above, MCSS enables a channel subsystem to provide more than 256 channel paths. However, the software (e.g., operating systems and associated applications) using the channel subsystem only support up to 256 channel paths. This is due to the fact that the software is designed to support I/O path identifiers (e.g., CHPID values) that are 8-bit binary numbers, thereby providing 256 unique values from zero to 255.

Changing the size of the CHPID value would have serious consequences on the many programs using the CHPID. Thus, in accordance with an aspect of the present invention, a capability is provided that allows the hardware to have more than 256 channel paths, but does not require the software to support more than 256 CHPID numbers. In particular, a capability is provided that enables the hardware to identify a specific channel that is independent of the way the software identifies the same channel. In order to accomplish this, a capability is provided for identifying physical channels and for assigning logic CHPID numbers to those same physical channels.

To identify a physical channel, a physical channel identifier (PCHID) is assigned by the computer system to each possible location that can support a channel card or that can provide I/O or a logical interface. As examples, I/O connectivity includes S/390 I/O (e.g., ESCON or FICON, networking, and coupling interfaces); and logical interfaces, which include cryptographic attachments.

In one embodiment, a 16 bit value is used for the PCHID; however, many other values may be used. To assign the PCHID values to physical channels, a technique is used that employs the actual physical properties of the machine. For instance, sixteen PCHID values are assigned for each I/O slot because the most dense I/O card, in this example, provides sixteen interfaces. However, the technique is versatile in that new values can be added to the original sixteen per slot, if a more dense I/O card is provided.

Although one assignment technique is described herein, any assignment technique can be used to assign the PCHID values, as long as the technique is predictable and repeatable, so that other applications that support the machine can duplicate the assignments. One such application is an Order Process. For instance, when a new machine is ordered or a new I/O feature is ordered for an existing machine, an Order Process tool, referred to as a configurator, uses the repeatable technique to predict the PCHID values for the new I/O cards. The user then uses these predicted values to provide a configuration definition, prior to the actual install of the new machine or features.

Further details of how the PCHID assignment technique is used are described with reference to FIG. 3. As shown, there are three cooperating entities, an Order Process 300, a Customer 302 and a System 304. Order Process 300 is used by a Customer 302 to place an order 305 for a new machine or one or more new channels. The Order Process uses a PCHID assignment technique 306a to produce a report 308 showing the PCHID assignments of the physical channels of the machine. In this particular example, PCHID Z is shown. The customer uses this report and his unique configuration requirements 310, including, for instance, logical CSS (i.e., CSSID) and CHPID number to tie the physical PCHID to the logical CSS/CHPID using IOCP 312. In this particular example, CSS X and CHPID Y are associated with PCHID Z. This association is provided to the system in the form of an IOCDS 314 from IOCP, as described in further detail below. System 304 then uses the same PCHID assignment technique 306b used by the Order Process to locate the physical channel with the PCHID value Z. So, when an operating system 316 using Logical Channel Subsystem X (i.e., Channel Subsystem Image X) wants information or to do I/O operations on CHPID Y, the system Licensed Internal Code (LIC) 318 uses the physical channel 320 located at PCHID location Z 320 to satisfy that request.

In the embodiment described herein, when a PCHID value is assigned to a location, it is fixed and only changes by controlled service functions. One example of a controlled service function is a sparing action. A sparing action is when one port or interface on an I/O card fails and as a repair, the interface is moved to another port that was previously unused. In this case, the PCHID assigned to the failing port is reassigned to the spare port and vice versa. This automatic reassignment is performed to eliminate the need to change the I/O definition.

By having a unique PCHID value for each physical channel, the software can use instructions to both define the logical associations for specific physical resources and to query the machine using logical constructs (i.e., CHPID numbers) to determine the extent of the exploitation of the physical resource. For instance, the program can determine that the same physical channel is being used by several logical channel subsystems, as illustrated in FIG. 4a.

In FIG. 4a, the center column 400 illustrates an example of a plurality of physical channels in a machine, while the left and right columns 402 and 404, respectively, show different channel subsystem images (a.k.a., logical channel subsystems). It is shown that in the case of a physical channel being used by multiple channel subsystems (i.e., spanning), the same or different logical CHPID numbers refer to the same physical channel. Further, it is shown that different logical channel subsystems may have the same CHPID numbers that refer to different physical channels.

To define the I/O configuration, a program is used, in one example, to translate human generated syntax into binary data that can be used by the machine, when it is powered on, before there is a program to exploit dynamic I/O interfaces. (Dynamic I/O is another way to define I/O, as described below.) This program is referred to as an I/O configuration program (IOCP). Various details regarding the IOCP are described in "zSeries Input/Output Configuration Program User's Guide for IYP IOCP," IBM Publication No. SB10-7029-03b, Fourth Edition, Level 03b, December 2002, which is hereby incorporated herein by reference in its entirety. The I/O configuration program builds a configuration definition from input data statements and stores the definition in an I/O configuration data set (IOCDS), which is used by the channel subsystem. In one example, the input statements include the following:

1. An ID statement, which is an optional statement that defines a heading data for I/O configuration reports;
2. A RESOURCE statement, which specifies the channel subsystem images (CSS's) and CSSIDs to be configured, and the logical partitions to be defined within each of those CSSs;
3. One or more CHPID statements used to specify channel paths;
4. One or more control unit statements (CNTLUNIT) used to specify one or more control units attached to the channel paths;
5. One or more I/O device statements (IODEVICE) used to specify one or more I/O devices assigned to the control units. In one example, up to 256 I/O devices can be defined in an I/O device statement.

In accordance with an aspect of the present invention, one or more input statements of the IOCP have been enhanced to provide for the assignment of a PCHID to a logical channel subsystem and to a logical CHPID number. For example, the CHPID statement has been enhanced by adding a subkeyword to the PATH keyword of the CHPID statement to allow the assignment of a logical CHPID number to a logical channel subsystem. Further, a new keyword, referred to as PCHID, is added to the CHPID statement, which specifies the PCHID number of the physical channel being defined. As an example, with the following statement: CHPID PATH=(CSS(1),22),PCHID=101, the user has assigned the logical CHPID number of 22 and the Logical Channel Subsystem 1 to the physical channel located at PCHID 101.

As a further example, the CNTLUNIT statement has been enhanced to allow the definition of a single control unit to multiple logical channel subsystems. This is shown in the following statement: CNTLUNIT CUNUMBR=230, PATH=((CSS(1),20),(CSS(2),40)), in which control unit 230 is assigned to be accessed by CHPID 20 in CSS 1 and CHPID 40 in CSS 2.

The IOCP takes these human generated input statements (e.g., CHPID, Control Unit and I/O Device) that represent the actual channels, control units and devices that make up a given I/O configuration and generates a file, referred to as an IOCDS, which is made up of different kinds of data structures for a machine to read when it initializes. For MCSS, multiple channel subsystems are represented and the physical resources are represented in such a way that they have the ability to be either dedicated or spanned shared between channel subsystems.

One physical resource affected by MCSS is the channel. With MCSS, there are thousands of physical channels, but there are only 256 CHPIDs maintained per channel subsystem. Thus, a new data structure is created, called the PCHID member, to represent the physical channels. This structure includes the relevant physical information about the channel including, for instance: the PCHID number, the CHPID number assigned to this PCHID; the channel subsystem or systems for which PCHID is defined to have access; and for some channel types, the switch number to which this channel is connected. Because CHPID numbers may be repeated in each channel subsystem, there is a CHPID data structure for each channel subsystem. This data structure has an array of 256 entries, each entry indexed by the CHPID number. This structure also includes logical information that can vary based on the channel subsystem. This information includes, for instance: an indication that this CHPID is defined; a pointer back to the PCHID this CHPID is associated with; and a list of logical partitions that may access this CHPID. The combination of these two structures (i.e., the PCHID member and CHPID member) allows a physical channel to be dedicated or shared between logical partitions, as well as dedicated or spanned between channel subsystem images.

One example of an illustration of how a typical CHPID statement generates data structures in the IOCDS is shown in FIG. 4b. In this example, it is a spanning CHPID, or a single physical channel that is available to more than one channel subsystem image. The CHPID statement used is, for instance, CHPID PATH=(CSS(1,2,3), 22), PCHID=101, SWITCH=25. . . . Although three channel subsystem images are referenced, only two are shown in FIG. 4b for clarity. Note that the PCHID entry of physical channel 101 points to the entry of CHPID number 22 in CSS 1, CSS 2 and CSS 3. Also, each CHPID entry points back to the physical information in the PCHID data structure.

Another resource that is affected by MCSS is the physical control unit. For this, the data structure that represents the physical control unit is expanded to include connections for multiple channel subsystems. In one example, the additional fields in the data structure are dependent on the number of channel subsystems being defined with this configuration. Thus, if one configuration has one channel subsystem, then space for eight CHPIDs and eight Link Addresses are used. But, if another configuration has four channel subsystems, then space for 32 CHPIDs and 32 Link Addresses is used.

FIG. 4c illustrates one example of how additional information for each CSS is added to the physical control unit data structure. In one example, the control unit input statement is as follows: CNTLUNIT CUNUMBR=230, PATH=((CSS(1), 20), (CSS(2), 40)),. . . . Note that the PCU data structure has entries for CSS 1 and CSS 2, but no entry for CSS 3. This is because CSS 3 does not have access to control unit 230.

Yet another resource that is represented in the IOCDS is the I/O device. Each device or group of devices is represented by a data structure called a subchannel. Since each channel subsystem has its own set of subchannels, the data structures for devices are created on a channel subsystem basis. Thus, a single device that can be accessed from three channel subsystems has at least three subchannel entries in the IOCDS, one in each of those three channel subsystems, which allow the device to be independently accessed by the programs configured to each of the channel subsystems.

FIG. 4d illustrates that a device that is accessible for multiple channel subsystems is represented in the subchannel data structure for each channel subsystem, but that the subchannel number (index) can be different for each channel subsystem. One example of the input statement used for the I/O device is as follows: IODEVICE ADDRESS=280, CUNUMBR=230. . . . This device is defined on a control unit with access to CSS 1 and CSS 2, but not CSS 3. Thus, there are entries in the CSS 1 and CSS 2 data structures, but no entry in the CSS 3 data structure.

Data structures for channel subsystems not defined in the configuration are not created. This keeps the space used for a given configuration to a minimum.

The I/O configuration definition process is performed for each I/O resource (e.g., channels, control units and/or devices) within a channel subsystem and that collection of input definitions is called Channel Subsystem X (a.k.a., Channel Subsystem Image X). Then, if the customer wants multiple channel subsystems, the customer would repeat the process one or more times for a collection of I/O resources and each collection is called a new channel subsystem.

The LPAR hypervisor (or the I/O configuration process) then assigns one or more channel subsystem images to each configured logical partition. In order to assign channel subsystem images to logical partitions, the SIE state description is used by the hypervisor to configure channel subsystem resources to each of the logical processors associated with each logical partition. In one example, the LPAR hypervisor assigns a default channel subsystem image to each configured logical partition. As one example, the assignment is performed via the RESOURCE statement of IOCP.

The concept of assigning a logical CHPID and CSS to a physical channel allows for the definition of several hundred or thousands of physical channels to a maximum of 256 logical CHPIDs in several logical channel subsystems. This avoids system changes that would otherwise force the operating system to support greater than 256 CHPIDs and allows machines to be built with several hundred or even thousands of physical channels.

Management of an I/O configuration definition with multiple logical channel subsystems is, in one example, accomplished from a single, authorized logical partition. Thus, at least one program in an arbitrarily specified logical partition has an awareness of the overall MCSS extensions; however, other programs are protected from being impacted by the new capabilities. This enhanced management capability does not place additional operational requirements on programs in other logical partitions, nor even on other programs in the same logical partition. Thus, the management extensions employed to support a central processing complex that has MCSS can be localized to a single program in a single logical partition; no other programs need be made aware of MCSS.

In one example, the management is performed by a manager, which is a program that is authorized to perform the commands that provide the management functions. The commands used by the manager fall, for instance, into two categories: 1) Channel Subsystem Call (CHSC) commands, and 2) Service Call Logical Processor (SCLP) commands. Within the CHSC category, a subset of commands are also known as dynamic I/O (DIO) commands in that they have the ability to change the active I/O configuration definition without requiring a restart of the CPC or channel subsystem (e.g., re-IML or a re-IPL) to make the change become effective. The DIO CHSC commands remain oriented on I/O devices, control units and channel paths; however, with MCSS there are more places where these commands can have their particular effect. Management of the extension from a single channel subsystem to multiple channel subsystem images involves, for instance:

1) Modifying the set of applicable CHSC commands to be capable of operating on a specified channel subsystem image or a group of channel subsystem images, as called for according to the particular function of each command. Prior to MCSS, such a designation was unnecessary as there was only one, implicit channel subsystem on which to operate. With MCSS, a CHSC command that specifies an I/O device, a subchannel or a channel path is subject to having a qualifying CSSID parameter added in the request or in the response, if any, of the three are reported.
2) Modifying applicable channel path reconfiguration SCLP commands and LPAR hypervisor PCCALL functions to be capable of operating on a specified channel subsystem image;
3) Creating a new authorization scheme that is used to determine which logical partition has use and/or access to which channel subsystem image. In one example, an authorization vector (e.g., CAV, described herein) is used in the authorization scheme, when MCSSE (described below) is enabled.

Various CHSC commands that are extended for MCSS are described below. Examples of these CHSC commands, without the extensions, are described in Cwiakala et al., U.S. Pat. No. 5,170,472, entitled "Dynamically Changing A System I/O Configuration Definition," issued Dec. 8, 1992, which is hereby incorporated herein by reference in its entirety. In one example, the dynamic I/O commands that are enhanced include, for instance, a Change Channel Path Configuration command, a Change Control Unit Configuration Command and a Change I/O Device Configuration command, each of which is described in detail below.

The Change Channel Path Configuration command is used to add, modify or delete the description of a channel path in the I/O configuration definition. The change channel path configuration command can be executed asynchronously and is not interpretively executed. Specification of the operation to be performed and the information used to change the I/O configuration definition that is used by the channel subsystem to control I/O or message operations are provided in a command request block.

One example of a command request block for a change channel path configuration command is described with reference to FIG. 5a. In one example, the change channel path configuration request block includes the following fields:

(a) Length Field 502: This field indicates the length of this request block;

(b) Command Code 504: This field specifies the change channel path configuration command;

(c) Operation Code 506: The operation code indicates the type of channel path configuration operation that is to be performed. The fields of the request data area of the command request block that are used are dependent upon the operation to be performed. The contents of the request data area fields that are not specified as being examined for possible use in performing the requested operation are ignored. Examples of various operation codes are as follows:

0 Add the description of the specified channel path to the I/O configuration definition. When the MCSS facility is provided by the CPC, the location of the physical channel path designated by the PCHID field is specified for an add operation. When the channel path type field (CHPT), described below, specifies an internal channel path type, the PCHID field is ignored. The PCHID field is not examined for any other operation.
All of the fields except RCSSID are examined for use in performing the add operation.
Upon exit from configuration mode, given that this change remains intact, an I/O-resource-accessibility-information event is made pending for the MIF image affected by this operation, and thus, the affected channel subsystem and corresponding logical partition, to signal the added accessibility of the specified channel path.
1 Modify the description of the specified channel path in the I/O configuration definition. The type of modification is specified by the operation code qualifier (OCQ). This operation code is specified when the CPC is operating in LPAR mode.
The CHPID, OCQ, and CSSID fields are examined for use in performing a modify operation. Additional fields may be specified depending on the contents of the OCQ field. The fields that are used are identified in the description of the OCQ values.
2 Delete the description of the specified channel path from the I/O configuration definition.
The CHPID and CSSID fields are examined for use in performing the delete operation.
When the multiple channel subsystem facility is provided by the CPC, the delete operation is used to delete the last channel path from a channel subsystem image provided that the channel path is not present in any other channel subsystem image.

Successful add, modify, and delete operations cause the I/O-configuration-changed condition to be set in the channel subsystem. Successful add, modify, and delete operations cause the channel subsystem to retain the specified program parameter, replacing the current program parameter, if any, in the channel subsystem.

(d) Multiple Channel subsystem Bit (M) 508: When the multiple channel subsystem facility is provided by the CPC, and the M bit is one, the CSSID field is checked for a valid CSSID. If valid, the value in the CSSID field becomes the effective CSSID. If not valid, then a response code may be stored. When M is zero, the default CSSID is the effective CSSID, and the CSSID field is zero; otherwise a response code may be stored.

(e) Format (FMT) 510: The command-request-format field includes an unsigned integer whose value specifies the layout of the command-request block. In one example, this value is 0.

(f) Operation-Code Qualifier (OCQ) 512: This field includes a value that qualifies the operation specified by the OC field. The meaning of each value of the OCQ field is, for instance, as follows:

0 No qualification: The operation specified by the OC field is not qualified by the OCQ field. When the CPC is operating in LPAR mode, the OC field is qualified by the OCQ.
1 Unshared reconfigurable: The specified channel path is added to the I/O-configuration definition as an unshared channel path. The channel path can be configured to one MIF image within a channel subsystem image at a time. The channel path can be reconfigured to any other MIF image of the channel subsystem image for which reconfiguration access has been established.
The channel path can be configured to any one of the MIF images provided in the I/O-configuration definition that are specified in the reconfiguration-access bit mask.
One MIF image of the channel subsystem image is defined to have initial access to the channel path, when the MIF image is subsequently activated. The MIF image for which initial access is to be established is specified by the initial-access bit mask.
On some models, the OCQ value is not specified when the channel-path-type field indicates an internal-system-device channel.
This OCQ value may be specified when the OC field specifies an add operation (OC=0) and the CPC is operating in LPAR mode.
When an add operation that specifies this operation-code qualifier adds a channel path, the channel path cannot subsequently be spanned, in this example, even if it otherwise might have been had it been added using the shared (OCQ=3) operation-code qualifier.
2 Unshared non-reconfigurable: The specified channel path is added to the I/O-configuration definition as an unshared channel path. The channel path is configured to one MIF image of the channel subsystem image and can be subsequently deconfigured or configured to that MIF image. The channel path cannot be subsequently reconfigured to other MIF images, in one embodiment. The single MIF image to which the channel path can be configured is specified in the reconfiguration-access bit mask. The same MIF image may also be given access to the channel path, when the logical partition associated with the MIF image is activated.
The initial-access bit mask is used to specify the same MIF image as the reconfiguration-access bit mask, when initial access to the channel path is to be established.
This OCQ value may be specified, when the OC field specifies an add operation and the CPC is operating in LPAR mode.
When an add operation (OC=0) that specifies this operation-code qualifier adds a channel path, the channel path cannot subsequently be spanned, in this example, even if it otherwise might have been had it been added using the shared (OCQ=3) operation-code qualifier.
3 Shared: The channel path is added as a shared channel path provided that the CHPT field specifies an allowed channel type, such as, for instance, a serial channel, cluster-bus-peer channel, an emulated-I/O channel, a fibre-channel channel, as just some examples.
The channel path can be concurrently configured to multiple MIF images (as specified in the reconfiguration-access bit mask) and used to concurrently execute I/O-operations or message operations for all configured MIF images.
One channel-path image is added to the I/O-configuration definition for each MIF image specified in the reconfiguration-access bit mask.
The channel path is initially configured to each MIF image specified in the initial-access bit mask, when a logical partition that is associated with the MIF image is activated.
This OCQ value may be specified when the OC field specifies an add operation and the CPC is operating in LPAR mode.
4 Add access: The I/O configuration definition is modified by adding one or more MIF images to the current set of MIF-images that can be used to access the specified channel path. The specified channel path and MIF images are to be currently defined in the I/O-configuration definition of the specified channel subsystem image. MIF images can be added to the set of MIF-images to which the channel path may be subsequently reconfigured. Reconfiguration access may be added for both unshared reconfigurable channel paths and for shared channel paths.
The reconfiguration-access bit mask specifies the MIF images of the specified channel subsystem image for which reconfiguration access is to be added.
For each MIF image in the modified set of MIF-images that has reconfiguration access, the channel path may subsequently be configured as follows:
- Unshared Image-Reconfigurable Channel Path: The channel path can be configured to any one MIF image in the modified reconfiguration-access set of MIF-images at a time.
- Shared Channel Path: The channel path may be concurrently configured to any of the MIF images in the modified reconfiguration-access set.
The OCQ value may be specified when the CPC is operating in LPAR mode and the OC field specifies the modify operation.
The OCQ, CHPID, RABM, and CSSID fields are examined for use in performing this type of operation.
Upon exit from configuration mode, given that this change remains intact, an I/O-resource-accessibility-information event is made pending for the MIF image affected by this operation, and thus, the affected channel subsystem image and corresponding logical partition, to signal the added accessibility of the specified channel path.
5 Unconditional delete access: The I/O configuration definition is modified by deleting one or more MIF images from the current set of MIF-images of the specified channel subsystem image that can be used to access the specified channel path. The specified channel path and MIF images are to be currently defined in the I/O configuration definition. Reconfiguration access may be deleted for both unshared reconfigurable channel paths and for shared channel paths.
The reconfiguration access bit mask specifies the MIF images of the channel subsystem image for which reconfiguration access is to be deleted.
For each MIF image deleted from the set of MIF images that has reconfiguration access to the channel path, the channel path is deconfigured, if the MIF image currently has access to the channel path and cannot be subsequently configured to that MIF image.
When the specified channel path is a shared channel path, the corresponding channel path images are deleted. The channel path definition is not deleted from the current I/O configuration definition for either a shared or unshared channel path even when all MIF images have been deleted from the set of MIF-images that have reconfiguration access to the channel path.
This OCQ value may be specified when the CPC is operating in LPAR mode and the OC field specifies the modify operation.
The OCQ, CHPID, RABM and CSSID fields are examined for use in performing this type of operation.
6 Conditional delete access (Conditional): The I/O configuration definition is modified by deleting one or more MIF images from the current set of MIF images of the specified channel subsystem image that can be used to access the specified channel path, when none of the specified MIF images are currently configured to the channel path.
When none of the specified MIF images are configured to the specified channel path, reconfiguration access to the specified channel path for the specified MIF images is deleted just as when OCQ 5 is specified.
When one or more of the specified MIF images are configured to the specified channel path, reconfiguration access for the specified channel path is not modified. A response code and response code qualifier are stored in the command response block indicating that the requested change was not made.
The command request block specification conditions and requirements that are described for OCQ 5 apply equally to this OCQ value.
The OCQ value may be specified when the CPC is operating in LPAR mode and the OC field specifies the modify operation.
7 Add-CSS-image access: When the multiple channel subsystem facility is provided by the CPC, the I/O configuration definition is modified by adding a channel path to the target CSS image where the latter is specified by the CSSTD. The object channel path being added by this operation is a shared channel path. The CHPID value assigned to the object channel path is the same as the CHPID value of the referenced channel path specified by RCSSID.CHPID. The characteristics of the object channel path are determined from the referenced channel path. These characteristic include, for instance, the following:
- The channel-path type is to be a type that is supported as a spanned channel path by the CPC model.
- The referenced channel path is to be located in a channel subsystem image other than the target channel subsystem image.
- The referenced channel path identified by RCSSID.CHPID is to be already described in the I/O-configuration definition for the channel subsystem image.
- The referenced channel path identified by RCSSID.CHPID is not a managed channel path.
The characteristics of the referenced channel path are inherited, except the reconfiguration-access and initial-access bit masks, which are determined from the command for a given target channel subsystem image.
The CHPID, CSSID, RABM, IABM and RCSSfD fields are examined for use in performing this type of modify operation.
Upon exit from configuration mode, given that this change remains intact, an I/O-resource-accessibility-information event is made pending for the MIF image affected by this operation, and thus, the affected channel subsystem image and corresponding logical partition, to signal the added accessibility of the specified channel path.
8 Delete-CSS-image access: When the multiple channel subsystem facility is provided by the CPC, the I/O-configuration definition is modified by deleting a channel path from the target channel subsystem image, where the latter is specified by the CSSID. The object channel path being deleted by this operation is not to be only available to one channel subsystem image.
The CHPID and CSSID are examined for use in performing this type of modify operation.
This OCQ value may be specified when the CPC is operating in LPAR mode and the OC field specifies the modify operation.

(g) Override Bit (O) 514: The override bit allows the program to request a configuration change of an unusual nature that would normally be disallowed by the channel subsystem. The channel subsystem may nevertheless disallow the override request.

(h) Key 516: This field includes the storage-access key used by the channel subsystem to access the command-request block and the command-response block for asynchronous operations that are initiated by the command.

(i) Subsystem-Identification (SID) 518: This field specifies the CHSC subchannel that is used to perform operations that are asynchronous to CHSC execution.

(j) Program Parameter 520: This field includes a value that the program associates with this change-channel-path-configuration command.

(k) Channel Subsystem Image ID (CSSID) 522: When the multiple channel subsystem facility is provided by the CPC, this field indicates the CSSID of the target channel subsystem image with which the designated channel path specified in the CHPID field will be associated. The CSSID value is subject to range and existence checking.

(l) Reference Channel Subsystem Image ID (RCSSID) 524: When the multiple channel subsystem facility is provided by the CPC, this field includes the reference CSSID of a channel subsystem image from which the channel-path characteristics are copied for an add-CSS-image access modify operation (OCQ=7). The RCSSID value is subject to range and existence checking.

(m) Channel-Path Identifier (CHPID) 526: This field specifies the CHPID of the channel path that is the object of the change-channel-path-configuration command.

(n) Channel-Path Type (CHPT) 528: This field specifies the type of the specified channel path.

(o) Channel-Path Characteristics (CHPC) 530: This field specifies characteristics of the specified channel path. When one, the meaning of bits 0-7 is as follows, in one example:

Bits Meaning
0 CTCA: Providing that the CHPT field specifies a serial-I/O channel path, the specified channel path can be used to provide access to a channel-to-channel adapter in the CPC that contains the specified channel path.
1 When the dynamic-CHPID management facility is provided by the CPC or the channel path identified in the CHPID field is an internal-queued-direct-communication channel (as indicated by the contents of the CHPT field), the OC field specifies the add operation, and this bit is one, the CHPP field includes a parameter that is associated with the specified CHPID.
When the dynamic-CHPID management facility is provided by the CPC or when the channel identified in the CHPID field is an internal-queued-direct-communication channel (as indicated by the contents of the CHPT field), and the OC field specifies the modify or delete operation, this bit and the contents of the CHPP and LPC name fields are ignored.
When the dynamic-CHPID-management facility is not provided by the CPC and when the channel identified in the CHPID field is not an internal-queued-direct-communication channel (as indicated by the contents of the CHPT field), this bit is reserved and set to zero.
2 When the channel path identified in the CHPID field is an internal-coupling-peer channel (as indicated by the contents of the CHPT field), the OC field specifies the add operation, and this bit is one, the channel path identified in the ACSSID.ACHPID field (another internal-coupling-peer channel) is to be associated with the channel path identified in the CHPID field.
When the channel path identified in the CHPID field is an internal-coupling-peer channel (as indicated by the contents of the CHPT field), the OC field specifies the add operation, and this bit is zero, no channel path is to be associated with the channel path identified in the CHPID field and the content of the ACHPID and ACSSID fields are ignored.
When the channel path identified in the CHPID field is an internal-coupling peer channel (as indicated by the contents of the CHPT field), and the OC field specifies the modify or delete operation, this bit of the CHPC field and the content of the ACHPID and ACSSID fields are ignored.
When the channel path identified in the CHPID field is other than an internal-coupling-peer channel (as indicated by the contents of the CHPT field), this bit, the ACHPID and ACSSID fields are reserved and set to zeros.

(p) Channel Path Parameter (CHPP) 532: When bit 1 of the CHPC field is one, this field includes a parameter that is associated with the channel path identified in the CHPID field.

When the channel identified in the CHPID field is an internal-queued-direct-communication channel (as indicated by the contents of the CHPT field), bits 0-1, as one example, include a value that specifies the maximum frame size (MFS) to be used by the internal-queued-direct-communication channel.

Bits 2-7, as examples, also specify a parameter that the program associates with the channel path identified in the CHPID field. The contents of these bits have meaning to the program, except that when bit 7 of the CHPP field is one, it means that:

the specified CHPID is a managed CHPID,
when the CPC is operating in LPAR mode, a logical-partition-cluster name is provided,
when the CPC is operating in LPAR mode, the OCQ field includes the value 3, indicating that the specified CHPID is shared, and
a defined bit of the SWTV field is one, indicating that a switch is attached to the specified CHPID.

(q) Reconfiguration-Access Bit Mask (RABM) 534: When the CPC is operating in LPAR mode, this bit mask is used to indicate which MIF images are to be added or deleted from the set of MIF-images that have reconfiguration access to the specified channel path. For each MIF image that has reconfiguration access to the specified channel path, the channel path can be configured to the MIF image by use of the appropriate reconfiguration commands.

In one example, each bit in the reconfiguration-access bit mask represents a one-to-one correspondence with a MIF image of the channel subsystem image that is specified by the CSSID field.

When the OC field specifies the add operation or the OCQ field specifies add-CSS-image access operation or the add-access operation, a one in a bit position of this mask indicates that the correspondingly numbered MIF image is to be added to the set of MIF-images that have reconfiguration access to the specified channel path. When the correspondingly numbered bit is zero, the MIF image is not to be added to the set of MIF-images that have reconfiguration access to the specified channel path.

When the OC field specifies the modify operation and the OCQ field specifies a conditional delete-access operation, a one in a bit position of this mask indicates that the correspondingly numbered MIF image is to be deleted from the set of MIF-images that have reconfiguration access. The channel path is deconfigured, if the MIF image is not currently configured to the channel path. If the OCQ field specifies an unconditional delete-access operation, a one in a bit position of this mask indicates that the correspondingly number MIF image is to be deleted from the current set of MIF-images that have reconfiguration access. The channel path is deconfigured, if the MIF image currently has access to the channel path. Additionally, if the correspondingly number MIF image is currently in the set of MIF-images that have initial access to the channel path, then initial access for the MIF image is also deleted. When the correspondingly numbered bit is zero, the MIF image is not to be deleted from the set of MIF-images that have reconfiguration access to the specified channel path.

When the OC field specifies an add operation and the OCQ field specifies an unshared not-reconfigurable channel path, only one bit in this mask is set to one.

When the OC field specifies an add operation and the OCQ field specifies either an unshared reconfigurable or shared channel path, any bits that correspond to provided MIF images can be set to one. At least one bit that corresponds to a provided MIF image is to be set to one.

When the OC field specifies a modify operation, this mask is not to contain all zeros.

This bit mask is ignored when any of the following conditions exists: the OC field specifies a delete operation; the CPC is operating in BASIC mode; or the OCQ field specifies a delete-CSS-image access operation.

(r) Initial-Access Bit Mask (IABM) 536: When the CPC is operating in LPRAR mode, this bit mask is used to indicate which MIF images are to be placed into the set of MIF-images that have initial access to the specified channel path. The initial-access bit mask may specify all zeros.

When the OC field specifies an add operation or add CSS-image access, a one in a bit position of this mask indicates that the correspondingly numbered MIF image is to be added to the set of MIF-images that have initial access to the specified channel path. When the correspondingly numbered bit is zero, the MIF image is not to be added to the set of MIF-images that have initial access to the specified channel path.

When the OC field specifies an add operation and the OCQ field specifies an unshared reconfigurable or an unshared not-reconfigurable channel path, only one bit in this mask may be one and the correspondingly bit in the reconfiguration-access bit mask is also one.

When the OC field specifies an add operation and the OCQ field specifies shared, any bits for provided MIF images within the channel subsystem image may be set to one, when the correspondingly bit in the reconfiguration-access bit mask is also set to one.

When the dynamic-CHPID-management facility is provided by the CPC, and the OC field specifies the add operation, bit 1 o the CHPC field is one, and this is a managed CHPID as designated by the CHPP field, the initial access bit mask that corresponds to provided MIF images is set to zero.

For each MIF image that has initial-access to the specified channel path, the channel path is configured to the MIF image, when it is subsequently activated as part of a partition activation process. When the specified MIF image is currently active, the channel path is not configured to the MIF image unless the program operating in the logical partition executes an appropriate SCLP reconfiguration command.

This bit mask is ignored when the OC field specifies a modify, except OCQ=7, or delete operation, or the CPC is operating in BASIC mode.

(s) Logical Partition Cluster (LPC) Name 538: A logical-partition cluster is the collection of the logical partitions within a CPC that are associated with the same logical-partition-cluster name for a given type of logical-partition-cluster. The program declares a logical-partition-cluster name for a logical partition by means of a Diagnose instruction.

When the following conditions exist, this field includes the logical-partition-cluster name of the logical-partition cluster with which the specified channel path is to be associated: the dynamic CHPID management facility is provided by the CPC; the CPC is operating in LPAR mode; the OC field specifies the add operation; bit 1 of the CHPC field is one; bit 7 of the CHPP filed is one.

The contents and format of the logical-partition-cluster name are determined by the program.

(t) Switch Validity (SWTV) 540: When one, this field specifies that the SWTN field contains valid information.

(u) Physical Channel Identifier (PCHID) 541: When the multiple channel subsystem facility is provided by the CPC, this field includes an unsigned integer that represents a model-dependent identification of the physical location of a channel. PCHID is used for an initial add operation, except for the addition of an internal channel, such as an internal-queued-direct-communication channel and internal-coupling-peer channel. The PCHID field is ignored, when the CHPT field indicates any of the internal channel-path types. If a PCHID value is not recognized, a response-code may be stored.

(v) Switch Number (SWTN) 542: When a predefined bit of the SWTV field is one, this field includes a unique identifier of a switch on the specified channel path. When the CHPT field specifies a fibre-channel channel, the switch number (SWTN) designates the entry switch to a fibre-channel fabric.

(w) Associated Channel Subsystem ID (ACSSID) 544: When the multiple channel subsystem facility is provided by the CPC, this field includes the CSSID of a channel subsystem image that is associated with the CHPID of an internal-coupling-peer channel specified by the ACHPID field. The ACSSID is subject to range and existence checking.

(x) Associated Channel Path (ACHPID) 546: When the channel identified in the CHPID field is an internal-coupling-peer channel (as indicated by the contents of the CHPT field), the OC field specifies the add operation, conditions allow the addition, and bit 2 of the CHPC field is one, this field includes the CHPID of an internal-coupling-peer channel with which the channel specified in the CHPID field is to be associated.

When two internal-coupling-peer channels are associated in this way, it means that messages that are sent on either one of the channels are received on the other associated channel.

When the channel identified in the CHPID field is an internal-coupling-peer channel, the OC field specifies the delete operation, and conditions allow the deletion, the specified channel is deleted from the I/O-configuration definition. If another internal-coupling-peer channel is associated with the specified channel, when the specified channel is deleted, the status of the associated channel is affected as follows: If the associated channel path is configured to one or more MIF images, the associated channel path is deconfigured from those MIF images; the associated channel path enters a state where it is no longer associated with an internal coupling-peer-channel.

The ACSSID and ACHPID fields, taken together, reference a channel path in a channel subsystem image that may itself be a spanned channel path (call this spanning-group A). When such is the case, the ACSSID field may specify any of the CSSIDs that have the channel path specified by the ACHPID field defined. After the add of the channel path that references spanning-group A, the following requests are supported:

A modify add-CSS-image-access operation may be requested that specifies RCSSID as the previous ACSSID value, and CHPID as the previous ACHPID value, thus increasing the number of channel subsystem images where the ACHPID is spanned (i.e., increasing the size of spanning-group A).
A modify add-CSS-image-access operation may be requested that specifies RCSSID as the previous CSSID value, and CHPID as the previous CHPID value, thus increasing the number of channel subsystem images where the CHPID is spanned (call this spanning-group C).

Spanning-group C is not established until after the linkage is established between the first channel path of spanning-group C and the channel path of one of the channel subsystem images of spanning-group A.

The connectivity between spanning-group C and A is any-to-any. This connectivity remains intact as long as each spanning-group has at least one channel path defined.

One embodiment of a command-response block for the Change Channel Path Configuration command is described with reference to FIG. 5b. In one example, a command response block 560 includes the following fields:

(a) Length Field 562: This field specifies the length of the command-response block. The length depends on the response code that is stored as a result of the attempt to execute the change channel path configuration command.

(b) Response Code 564: This field includes an unsigned binary integer that describes the results of the attempt to execute the change channel path configuration command. When the response-code field indicates an unsuccessful attempt, no change is made to the I/O-configuration definition, the I/O-configuration-changed condition in the channel subsystem is not affected, and the contents of the program-parameter field are ignored.

When execution of the change channel path configuration command results in a predefined condition code being set, the channel subsystem has been given the initiative to asynchronously attempt to perform the requested change to the I/O-configuration definition. The completion of that attempt is indicated by means of a CHSC-subchannel I/O interruption with the results of the attempt specified by the response code in the command-response block.

(c) Format (FMT) 566: The command-response-format field includes an unsigned integer whose value specifies the layout of the command-response block.

(d) Response-Code Qualifier (RCQ) 568: When a response code other than a code indicating success is stored in the response-code field, this field includes either an architected value or a model dependent value that further describes the condition specified by the response code.

(e) Response Qualifier (RQ) 570: When the response-code field indicates that the requested configuration change has occurred, the response-qualifier field includes a value that provides information about conditions associated with that change. The meaning of each value is, for example, as follows:

0 There are no special conditions associated with the configuration change.
1 The information provided by the program for the configuration change does not match the physical configuration. This value may occur when the associated command request specifies an add (OC=0) operation.
2 The specified physical channel path (PCHID) is not installed. This value may occur when the associated command request specifies an add (OC=0) operation.

When the CPC is operating in LPAR mode, there are three cases when the execution of the change channel path configuration command can include an attempt to deconfigure a channel path from one or more MIF images.

1. The delete operation is requested, or delete-CSS-image access (OCQ=8) is specified, conditions allow the specified channel to be deleted, and the specified channel path is configured to one or more MIF images within a channel subsystem image. The machine attempts to deconfigure the specified channel path from those MIF images.
2. The delete operation is requested, conditions allow the specified channel path to be deleted, the specified channel path is an internal-coupling-peer channel, and an internal-coupling-peer channel that is associated with the specified channel path is configured to one or more MIF images in any one or more channel subsystem images. The machine attempts to deconfigure the associated channel path from those MIF images.
3. The modify-unconditional-delete access operation is requested, conditions allow reconfiguration access to the specified channel path to be removed from the specified MIF images, and the specified channel path is configured to one or more of the specified MIF images. The machine attempts to deconfigure the specified channel path from those MIF images.

In the above cases, when a channel path is deconfigured from a MIF image, a channel-path-permanent-error-with-facility-initialized channel report is made pending for that MIF image and the channel path is no longer available for use by the program operating in the logical partition with which the MIF image is associated.

In cases 2 and 3 above, when a channel path is deconfigured from a MIF image and it is the last available channel path associated with a subchannel, the subchannel is also made not available to the MIF image. A subchannel-installed-parameters-initialized channel report is made pending for each such subchannel for each affected logical partition.

Described in detail above is processing associated with a Change Channel Path Configuration Request command. As part of the processing to support MCSS, various error checking procedures are performed, as indicated in FIGS. 5c-5f and described below.

As shown in FIG. 5c, when the operation code is zero indicating the adding of a CHPID to the I/O configuration definition, checks are made related to the CSSID and PCHID. If the specified checking is successful, then the CHPID is added to the channel subsystem image.

Similarly, when the operation code equals one and the operation code qualifier is set to 7 (FIG. 5d), then various tests are performed on the CSSID, RCSSID, and CHPID. If the checking is unsuccessful, then appropriate response codes are provided. However, when the checking is successful, then the CHPID is added to the channel subsystem image and bound to the PCHID, which is already bound to the CHPID in the referenced channel subsystem image.

With reference to FIG. 5e, it is shown that when the operation code is equal to one and the operation code qualifier is set to 8, then testing of the CSSID and CHPID are performed. When those tests are successful, then the CHPID is deleted from the channel subsystem image identified by the CSSID.

Similarly, in FIG. 5f, it is indicated that when the operation code is equal to 2, then testing is performed on the CSSID and the CHPID specified by the CSSID. When that checking is successful, then the CHPID is deleted from the channel subsystem image identified by the CSSID and the entire configuration.

As indicated above, another command enhanced by MCSS is a Change Control Unit Configuration command. This command is used to add, modify, or delete the description of a control unit in the I/O-configuration definition. The change control unit configuration command can be executed asynchronously and is not interpretively executed, in one example. Specification of the operation to be performed and the information required to change the I/O-configuration definition are provided in a command-request block.

One embodiment of a request block for a change control unit configuration command is described with reference to FIG. 6a. In one example, a request block 600 includes, for instance:

(a) Length Field 602: This field specifies the length of the block.

(b) Command Code 604: This field specifies the change-control-unit-configuration command.

(c) Operation Code (OC) 606: This field includes a value that specifies the type of control unit configuration operation that is to be performed. The fields of the request-data area of the command request block that are used are dependent upon the operation to be performed. The meaning of each value is, for example, as follows:

0 Add the description of the specified control unit to the I/O-configuration definition.
1 Modify the description of the specified control unit in the I/O-configuration definition. The type of modification is specified by the operation-code qualifier (OCQ). The CUN field is used to identify the control unit for which the description is to be modified. Additional fields may be used, depending on the contents of the OCQ field. Additional fields that are used are identified in the descriptions of the OCQ values.
2 Delete the description of the specified control-unit image from the I/O-configuration definition. The effective CSSID is to specify the remaining channel subsystem image that contains the control-unit image. The CUN field is examined for use in performing the delete operation.
3 Store additional information: One or more subchannel blocks that could not be contained in the command response block for a previous change-control-unit-configuration command are requested.

Successful add, modify, and delete operations cause the I/O-configuration-changed condition to be set in the channel subsystem. Successful add, modify, and delete operations cause the channel subsystem to retain the specified program parameter, replacing the current program parameter, if any, in the channel subsystem.

(d) Multiple Channel Subsystem Bit (M) 608: When the multiple channel subsystem facility is provided by the CPC, then when M is one, the CSSID field is checked for a valid CSSID. If valid, the value in the CSSID field becomes the effective CSSID. When M is zero, the default CSSID is the effective CSSID.

(e) Format (FMT) 610: The command-request-format field includes an unsigned integer whose value specifies the layout of the command-request block. The request block described herein is format zero, as one example.

(f) Operation-Code Qualifier (OCQ) 611: This field includes a value that qualifies the operation specified by the OC field. The meaning of each value of the OCQ field is, for instance, as follows:

0 The operation specified by the OC field is not qualified by the OCQ field.
1 Add channel-path access: The I/O-configuration definition is modified by adding one or more channel paths to the current list of channel paths that can be used to access the specified control unit. When the multiple channel subsystem facility is provided by the CPC, this form of modification applies, when the specified control-unit image is defined to the channel subsystem image specified by the CSSID field.
Subchannels that are added as a result of the modify (add channel-path access) operation are in the initialized state and are not enabled.
When one or more channel paths that are in the configured state are placed on the list of channel paths that can be used to access the specified control unit, the corresponding bits of the path-installed mask (PIM) and the path-available mask (PAM) for subchannels associated with VO-devices that are described as being attached to the specified control unit are set to ones. If the channel paths are in the not-configured state, the appropriate PIM bits are set to ones.
This OCQ value may be specified, when the OC field specifies the modify operation.
The M-bit, CSSID field, CHPIDV, and CHPID fields are used for this modify operation. The FLA fields are used when the corresponding channel paths are channel-path types that adhere to the serial-I/O architectures, and the link-address portions of the FLA fields may be used (depending on the model), when the corresponding channel paths are fiber-extended channel paths, or fibre-channel channel paths.
2 Delete channel-path access: The I/O-configuration definition is modified by deleting one or more channel paths from the current list of channel paths that can be used to access the specified control unit.
Subchannels that are deleted as a result of the modify (delete channel-path access) operation have the device-number-valid bit set to zero.
When one or more channel paths are deleted from the list of channel paths that can be used to access the specified control unit, the corresponding bits of the path-installed mask (PIM) and the path-available mask (PAM) for subchannels associated with I/O-devices that are described as being attached to the specified control unit are set to zeros.
This OCQ value may be specified, when the OC field specifies the modify operation.
The M-bit, CSSID field, CHPIDV, and CHPID fields are used for this modify operation. The CHPIDV field is to contain at least one bit that is one. Each valid CHPID field specifies a channel path that is to be deleted from the list of channel paths for the specified control unit.
3 Add unit address: The I/O-configuration definition is modified by adding one or more unit addresses to the current list of unit addresses that are recognized by the specified control unit. Each added unit address becomes available to any logical partition that has channel-path accessibility to the control unit.
This OCQ value may be specified, when the OC field specifies the modify operation.
The unit-address field is used for this modify operation.
4 Delete unit address: The I/O configuration definition is modified by deleting one or more unit addresses from the current list of unit addresses that are recognized by the specified control unit. Each deleted unit address becomes unavailable to any logical partition that has channel-path accessibility to the control unit.
This OCQ value may be specified, when the OC field specifies the modify operation.
The unit-address field is used for this modify operation.
5 Modify the maximum-managed-channel-path (MMCP) value: The maximum number of managed channel paths to which the specified control unit can be attached is changed to the value specified in the MMCP field, provided that certain conditions are satisfied.
When the multiple channel subsystem (MCSS) facility is provided by the CPC, the effective CSSID associated with such a request may be used to determine the channel subsystem image to which the change is confined. Thus, the effective scope of a successful modification of the maximum-managed-channel-path of the specified control unit may be limited to the channel subsystem image specified on the request to change the MMCP value. Any other access of the control unit via a different channel subsystem image continues to observe the MMCP value that existed prior to the change. Another request via a different channel subsystem image may make its own, independent MMCP-change request.
This OCQ value may be specified, when the dynamic-CHPID management facility is provided by the CPC and the OC field specifies the modify operation. When the dynamic-CHPID-management facility is not provided by the CPC, the OCQ value of 5 is reserved.
The MMCP count, the M-bit and CSSID fields are used for this modify operation.
6 Add CU-image to CSS image: This operation-code qualifier applies when the multiple channel subsystem facility is provided by the CPC. The control unit is to already be in the I/O-configuration definition, and thus, at least one control-unit image is established, although not from the channel subsystem image specified by the effective CSSID. The I/O-configuration definition is modified by adding a control-unit image to the channel subsystem image specified by the effective CSSID, and thus, introducing access to the control unit from the channel subsystem image via one or more specified channel paths.
The M-bit, CSSID field, CHPIDV, CHPID, and MMCP fields are used for this modify operation. The FLA fields are used, when the corresponding channel paths are channel-path types that adhere to the serial-I/O architectures, and the link-address portions of the FLA fields may be used (depending on the model and presence of one or more switches, when applicable), when the corresponding channel paths are fiber-extended channel paths, or fibre-channel channel paths.
7 Delete CU-image from CSS image: This operation-code qualifier applies when the multiple channel subsystem facility is provided by the CPC. The I/O-configuration definition is modified by deleting a specified control-unit image from the channel subsystem image. If the specified control-unit image is not defined in the channel subsystem image, a response-code may be stored.
The M-bit and CSSID fields are used for this modify operation.

(g) Key 612: This field includes a storage access key used by the channel subsystem to access the command-request block and the command-response block for asynchronous operations that are initiated by the command.

(h) Subsystem ID (SID) 614: The SID field specifies the CHSC subchannel that is used to perform operations that are asynchronous to CHSC execution.

(i) Program Parameter 616: This field includes a value that the program associates with this change control unit configuration command.

(k) CSSID 618: When the multiple channel subsystem facility is provided by the CPC, this field may specify the CSSID used to locate the target channel subsystem image, and thus, locate the channel paths whose CHPIDs are specified. The CSSID value is subject to range and existence checking.

(k) Control-Unit Number (CUN) 620: This field specifies a number that is used to identify the control unit that is the object of the change control unit configuration command.

(l) Control-Unit-Interface Protocol (CUIP) 622: This field specifies the type of protocol used by the specified control unit to communicate on the attaching I/O-interfaces. The meaning of each value is, for instance, as follows:

0 Direct-Current (DC) interlocked (applies to parallel channels).
1 3-megabyte-per second data streaming (applies to parallel channels).
2 4.5 megabyte-per-second data streaming (applies to parallel channels).
3 Serial-I/O protocols.
4 Open System Adapter (OSA) protocols.

When the operation-code field specifies the add operation and one or more of the specified channel paths are an internal-system-device channel or fibre-channel-converted channel-path type, serial-I/O protocols are to be specified in the CUIP field.

In one example, the contents of the CUIP field have no meaning for certain channel-path types (e.g., those that are not parallel, serial-I/O, OSA, internal-system-device, or fibre-channel-converted channels).

(m) Control-Unit Characteristics (CUC) 624: This field specifies characteristics of the specified control unit. The meaning of bits 0-7 is, for instance, as follows:

Bits Meaning
0 Concurrency level of I/O requests: When zero, this bit specifies that the control unit supports only one I/O request at a time. When one, this bit specifies that the control unit supports multiple I/O requests concurrently.
The concurrency-level bit has meaning, when the channel paths to which the control unit is attached are parallel channels or fiber-extended channels (byte or block). Otherwise, the concurrency-level bit is ignored.
1 CTC-control-unit-type specification: When zero, bit 1 indicates that the specified control unit is not a FICON CTC control unit. When one, bit 1 indicates that the specified control unit is a FICON CTC control unit.
This bit is meaningful, when the OC field specifies the add operation. Otherwise this bit is ignored. When the specified control unit is a FICON CTC control unit the following conditions apply.
- The MMCP field is ignored.
- When the OC field specifies the modify operation, and the OCQ field specifies the modify-the-MMCP-value function, a response-code is stored in the response block.
- One CHPID field and its corresponding FLA field is specified as containing valid information.
- The channel-path type to which the specified control unit is attached is a fibre-channel path.

(n) Channel-Path-Identifier Validity (CHPIDV) 626: This field specifies which of the CHPID and FLA fields (if applicable) contain valid information. Bits 0-7 of the CHPIDV field correspond, from left to right, to each of the eight CHPID fields. When one, a CHPIDV bit specifies that the corresponding CHPID field contains a valid channel-path identifier.

When the OC field specifies the add operation, or the OC field specifies the modify operation and the OCQ field specifies add or delete channel-path access, the CHPIDV field is not to contain all zeros and the corresponding CHPID fields contain valid information; otherwise, the contents of the CHPID fields are ignored.

When the CHPID fields contain valid information and the corresponding channel paths are serial-I/O type, fibre-channel, fibre-channel-converted, internal-queued, direct-communication channels, or fiber-extended channels, the corresponding FLA fields contain valid information; otherwise, the contents of the FLA fields are ignored.

(o) Maximum Managed Channel Paths (MMCP) 628: When the dynamic-CHPID-management facility is provided by the CPC, this field includes an unsigned binary integer that is a count of the maximum number of managed channel paths to which the specified control unit can be attached.

(p) Channel-Path Identifier (CHPID) 630: This field includes up to eight channel-path identifiers. Each CHPID field that is specified as being valid by the contents of the CHPIDV field contains a unique channel-path identifier of a channel path that can be used to access the specified control unit. The effective CSSID specifies the channel subsystem image in which each valid channel path is located.

The order in which channel paths (other than preferred channel paths) are selected by the channel subsystem to access I/O-devices that are attached to the specified control unit is model dependent.

When the CPC is operating in LPAR mode, for a given I/O-configuration definition, the channel paths to which a control unit is attached are to be sharable, or all of the channel paths are not to be sharable.

(q) Full Link Address (FLA) 632: This field includes up to eight full link addresses for the specified control unit. Each address corresponds, one-for-one, with the CHPID field that is in the same relative position in the command-request block. The FLA fields have meaning when the control-unit is attached to a type of channel path that uses an interface protocol that requires use of a link address, a logical address, or both.

A full link address is the information that is contained in the destination-address field of frames that are received by the specified control unit, and in the source-address field of frames that are sent by the specified control unit.

Each address includes, for instance, a link address that is established based upon the channel-path type of the specified channel path and a logical address of the specified control unit on the specified channel path.

(r) Unit Addresses 634: This field describes the I/O-device unit addresses that are recognized by the control unit. A unit address includes, for instance, an Entry Type (ET) that includes a code that specifies the contents of the unit address. For example, when the entry type is equal to 1, the unit address field defines a single unit address, included in the field, that is recognized by the control unit.

As a further example, when the entry type is equal to 2, the unit address defines a range of unit addresses that are recognized by the control unit. The unit address field includes a unit address, which determines the beginning of the range, and a count parameter of the unit address field specifies one less than the number of consecutive unit addresses that make up the range.

Managed Channel-Path Specification Rules: The following rules apply when the requested I/O-configuration change affects the managed-path attributes of the specified control unit:

1. When the add operation is specified in the OC field and a non-zero MMCP value is specified:
- a. The specified MMCP value is to be seven or less.
- b. The number of bits that are one in the CHPIDV field which designate managed channel paths is to be equal to, or less than, the specified MMCP value.
- c. The sum of the number of bits that are one in the CHPIDV field which designate non-managed channel paths and the specified MMCP value is to be eight or less.
- d. When the CPC is operating in LPAR mode, every channel path designated by a bit that is one in the CHPIDV field is to be a shared channel path.
- e. Every channel path designated by a bit that is one in the CHPIDV field is to be one of the types that are allowed for the specified control unit when it is attached to managed channel paths.
2. When the modify operation is specified in the OC field, the modify MMCP operation is specified in the OCQ field, and the specified MMCP value is the same as the MMCP value that is currently in effect for the specified control unit, no operations are performed regarding managed channel paths and the command completes normally.
3. When the modify operation is specified in the OC field, the modify MMCP operation is specified in the OCQ field, and the specified MMCP value is different from the MMCP value that is currently in effect for the specified control unit:
- a. The specified MMCP value is to be seven or less.
- b. The sum of the number of non-managed channel paths currently configured to the specified control unit and the specified MMCP value is to be eight or less.
- c. When the CPC is operating in LPAR mode, every channel path that is currently configured to the specified control unit is to be a shared channel path. (This rule is enforced, when the MMCP value that is in effect for the specified control unit would change from zero to non-zero as a result of executing the command.)
- d. Every channel path currently configured to the specified control unit is to be one of the types that are allowed for the specified control unit when it is attached to managed channel paths. (This rule is enforced, when the MMCP value that is in effect for the specified control unit would change from zero to non-zero as a result of executing the command.)
- e. The sum of the number of non-managed channel paths currently configured to all of the control units of a shared device cluster that includes the specified control unit, and the MMCP values that are in effect for all of those control units except the specified control unit, and the specified MMCP value is to be eight or less.
- f. Every channel path currently configured to the control units of a shared device cluster that contains the specified control unit is to be one of the types that are allowed for the specified control unit when it is attached to managed channel paths. (This rule is enforced, when the sum of the MMCP values that are in effect for the control units of the shared device cluster would change from zero to non-zero as a result of executing the command.)
4. When the modify operation is specified in the OC field, the add-channel-path-access operation is specified in the OCQ field, and an MMCP value is in effect for either the specified control unit or one or more of the other control units of a shared device cluster that contains the specified control unit:
- a. The sum of the number of non-managed channel paths that are currently configured to the specified control unit, and the number of bits that are one in the CHPIDV field which designate non-managed channel paths, and the MMCP value that is in effect for the specified control unit is to be eight or less.
- b. The sum of the number of non-managed channel paths that are currently configured to all of the control units of a shared device cluster that includes the specified control unit, and the number of bits that are one in the CHPIDV field which designate non-managed channel paths, and the sum of all of the MMCP values that are in effect for all of the control units of the shared device cluster is to be eight or less.
- c. Every channel path designated by a bit that is one in the CHPIDV field is to be one of the types that are allowed for the specified control unit when it is attached to managed channel paths.

In one embodiment, a command-response block 650 (FIG. 6b) for a Change Control Unit Configuration command includes, for instance, the following:

(a) Length Field 652: This field specifies the length of the command-response block. The length depends on the response code that is stored in the response-code field as a result of the attempt to execute the change control unit configuration command.

(b) Response Code 654: This field includes an unsigned binary integer that describes the results of the attempt to execute the change control unit configuration command.

(c) Format (FMT) 656: The command-response-format field includes an unsigned integer whose value specifies the layout of the command-response block.

(d) Response-Modifier Code (RMC) 658: This field includes an unsigned integer that may provide additional information when the response code is other than an indication of success. The content of the RMC field is distinctive to each response code value. Not all response codes use the RMC field.

(e) Response-Code Qualifier (RCQ) 660: This field may contain a model dependent value that can be used to further describe the condition specified by the response code.

(f) Additional Information (A) 662: When one, this field specifies that the channel subsystem has additional subchannel blocks that cannot be contained in this command-response block. When zero, it specifies that the channel subsystem has no subchannel blocks in addition to those, if any, that are contained in this command-response block.

(g) Response Qualifier (RQ) 664: When the response-code field indicates that the requested configuration change has occurred, the response-qualifier field contains a value that provides information about conditions associated with that change. The meaning of each value is, for instance, as follows:

0 There are no special conditions associated with the configuration change.
1 The information provided by the program for the configuration change does not match the physical configuration.

(h) Shared-Device-Cluster (SDC) Blocks 666: This field includes one or more shared-device-cluster (SDC) blocks. Each SDC block that is specified as being valid describes a shared device cluster that contains one or more I/O-devices that are described as being attached to the control unit specified in the command-request block of the change-control-unit-configuration command that caused the SDC block to be created.

A shared device cluster is either a single control unit that can provide access to at least one I/O device, but does not share access to I/O devices with any other control unit, or it can be a collection of control units and I/O devices that are connected in such a way that for any division of the total collection of control units into two subsets, at least one I/O device is shared by at least one control unit from each subset.

One example of an SDC block is described with reference to FIG. 6c. An SDC block 666 includes, for instance, the following:

(aa) SDC Validity Bit (S) 670: When one, this bit specifies that the associated SDC block is valid. When zero, this bit specifies that the associated SDC block is not valid and there are no subsequent SDC blocks in the command response block that are valid.
(bb) Image ID Validity Bit (P) 672: When one, this bit specifies that the image ID field contains a valid MIF image identification code. When zero, this bit specifies that the contents of the image ID field are meaningless. The P bit can be one, when the CPC is operating in LPAR mode. When the SDC is associated with shared channel paths, this bit is set to zero.
(cc) Shared Device Cluster (SDC) Number 673: This field includes an SDC number that identifies the shared device cluster described by this SDC block. Within a channel subsystem image, every SDC has unique number.
(dd) MIF-Image ID (IID) 674: When the CPC is operating in LPAR mode and the P bit is one, this field includes the MIF-image identification (IID) code associated with the logical partition from which the specified SDC is recognized. The SDC blocks returned are from the same channel subsystem image that was specified in the corresponding command request.
(ee) Path Mask-1 (PM-1) 675: This field specifies the CHPID fields that identify the channel paths that are described in the I/O-configuration definition for the specified SDC. Each bit of the PM-1 field corresponds one-for-one, by rela