HK1193883A - Deconfigure storage class memory command - Google Patents

Description

Deconfiguration storage class memory command

Technical Field

One or more aspects of the present invention relate generally to secondary storage of a computing environment, and more particularly to management aspects of secondary storage.

Background

The computing environment may include a main memory, also referred to as primary storage, and a secondary storage. The main memory is a memory accessible by the processor, which may be randomly addressed, for example, by an absolute address. Main storage is considered fast-access storage, as compared to secondary storage, such as direct-access storage device (DASD) or storage class memory, and addressing of main storage is considered simpler than addressing of DASD or storage class memory.

Storage class memory, which is an external storage space outside of classic main memory, provides faster access than direct access storage devices. Unlike DASD, storage class memory is typically not implemented as a mechanical arm spinning disk, but rather as a non-mechanical solid state component. Typically, storage class memory is implemented as a bank of solid state devices connected to a computing system through several input/output (I/O) adapters used to map the technology of the I/O devices to the storage bus of the central processing unit.

Disclosure of Invention

The shortcomings of the prior art are overcome and advantages of the present invention are provided through the provision of a computer program product for executing a deconfigure (deconfigure) storage class memory command in a computing environment that includes main storage and storage class memory. The computer program product includes a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method comprises the following steps: for example, obtaining, by an input/output (I/O) subsystem, a request block comprising a command code indicating a deconfigure storage class memory command and a Storage Class Memory (SCM) increment request list comprising one or more entries, each entry configured to include a total size field indicating a number of increments of storage class memory to be deconfigure and a starting SCM address indicating a starting location of a deconfigure storage class memory increment; based on the command code, initiating a deconfiguration process for deconfiguring storage class memory, the process configured to deallocate the requested number of storage class memory increments specified in the total size value, wherein the initiating includes performing one or more validity checks; in response to the one or more validity checks being successful, continuing to perform a deconfiguration process of the storage class memory, wherein the one or more validity checks include determining that an increment of the storage class memory to be deconfigured is in a configured state; and storing a response code in a response field of a response block, the response code indicating whether the deconfiguration process was initiated, the response block including a length code indicating a length of the response block.

Methods and systems relating to one or more aspects of the present invention are also described and claimed herein. Also, services relating to one or more aspects of the present invention 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.

Drawings

Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following 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 another embodiment of a computing environment to incorporate and use one or more aspects of the present invention;

FIG. 2A depicts one embodiment of an extended asynchronous data mover operation request block, used in accordance with an aspect of the present invention;

FIG. 2B depicts one embodiment of an extended asynchronous data mover operational block, used in accordance with an aspect of the present invention;

FIG. 2C depicts one embodiment of an extended asynchronous data mover request block, used in accordance with an aspect of the present invention;

FIG. 2D depicts one embodiment of an extended asynchronous data mover response block, used in accordance with an aspect of the present invention;

FIG. 2E depicts one embodiment of an extended asynchronous data mover movement specification block, used in accordance with an aspect of the present invention;

FIG. 2F depicts one embodiment of an extended asynchronous data mover indirect data address word, used in accordance with an aspect of the present invention;

FIG. 3A depicts one embodiment of a start subchannel instruction, used in accordance with an aspect of the present invention;

FIG. 3B depicts one embodiment of the logic associated with starting a subchannel instruction, in accordance with an aspect of the present invention;

FIG. 3C depicts one embodiment of a clear subchannel instruction, used in accordance with an aspect of the present invention;

FIG. 3D depicts one embodiment of a test subchannel instruction, used in accordance with an aspect of the present invention;

FIG. 3E depicts one embodiment of a modify subchannel instruction, used in accordance with an aspect of the present invention;

FIG. 3F depicts one embodiment of a store subchannel instruction, used in accordance with an aspect of the present invention;

FIG. 4A depicts one embodiment of an extended asynchronous data mover subchannel information block, used in accordance with an aspect of the present invention;

FIG. 4B depicts one embodiment of an extended asynchronous data mover path management control word, used in accordance with an aspect of the present invention;

FIG. 4C depicts one embodiment of a subchannel status word, used in accordance with an aspect of the present invention;

FIG. 4D depicts one embodiment of an extended asynchronous data mover extended status word used in accordance with an aspect of the present invention;

FIG. 5A depicts one embodiment of a storage class memory information request block, used in accordance with an aspect of the present invention;

FIG. 5B depicts one embodiment of a storage class memory information response block, used in accordance with an aspect of the present invention;

FIG. 5C depicts one embodiment of a storage class memory address list entry, used in accordance with an aspect of the present invention;

FIG. 5D depicts one embodiment of the logic associated with a store storage class memory information command, in accordance with an aspect of the present invention;

FIG. 6A depicts one example of a state diagram representing various states of storage class memory, in accordance with an aspect of the present invention;

FIG. 6B depicts one embodiment of a state diagram, showing operational states and data states, in accordance with an aspect of the present invention;

FIG. 7A depicts one embodiment of a configuration storage class memory request block, used in accordance with an aspect of the present invention;

FIG. 7B depicts one embodiment of a configure storage class memory response block, used in accordance with an aspect of the present invention;

7C-7D illustrate one embodiment of the logic associated with configuring storage class memory commands, used in accordance with an aspect of the present invention;

FIG. 8A illustrates one example of a notification response block used in accordance with an aspect of the present invention;

FIG. 8B depicts one embodiment of a store event information request block, used in accordance with an aspect of the present invention;

FIG. 8C depicts one embodiment of a store event information response block, used in accordance with an aspect of the present invention;

FIG. 9A depicts one embodiment of a block of deconfiguration storage class memory requests, used in accordance with an aspect of the present invention;

FIG. 9B depicts one embodiment of a storage class memory delta request list entry, used in accordance with an aspect of the present invention;

FIG. 9C depicts one embodiment of a deconfigure storage class memory response block, used in accordance with an aspect of the present invention;

9D-9E illustrate one embodiment of the logic associated with a deconfigure storage class memory command used in accordance with an aspect of the present invention;

FIG. 10 depicts one embodiment of a computer program product incorporating one or more aspects of the present invention;

FIG. 11 depicts one embodiment of a host computer system incorporating and using one or more aspects of the present invention;

FIG. 12 depicts yet another example of a computer system incorporating and using one or more aspects of the present invention;

FIG. 13 illustrates another example of a computer system including a computer network that incorporates and uses one or more aspects of the present invention;

FIG. 14 depicts one embodiment of various components of a computer system to incorporate and use one or more aspects of the present invention;

FIG. 15A depicts one embodiment of an execution unit of the computer system of FIG. 14 to incorporate and use one or more aspects of the present invention;

FIG. 15B depicts one embodiment of a branching unit of the computer system of FIG. 14 that incorporates and uses one or more aspects of the present invention;

FIG. 15C depicts one embodiment of a load/store unit of the computer system of FIG. 14 incorporating and using one or more aspects of the present invention; and

FIG. 16 illustrates one embodiment of an emulated host computer system incorporating and using one or more aspects of the present invention.

Detailed Description

In accordance with one or more embodiments, an abstraction for storage class memory is provided that hides the implementation details of storage class memory from programs (e.g., operating systems) and provides a standard channel programming interface to perform specific actions, such as controlling data movement between main storage and storage class memory.

In one example, a facility known as an Extended Asynchronous Data Mover (EADM) facility is provided that allows programs to request transfers of blocks of data between main storage and storage class memory, as well as request other operations. Aspects relating to the facility will be described in detail below.

Also, associated with the EADM facility is an optional facility known as an EAMD release facility. When installed, the EADM release facility provides a means for a program to specify that it no longer requires data to be retained in one or more storage class memory chunks. Whether a release operation is supported for all storage class memory blocks or only for a subset of the storage class memory depends on the model.

Once a block of storage class memory has been freed, the program may pass new data into the block, otherwise subsequent requests to transfer data from the block to main memory will fail.

One embodiment of a computing environment to incorporate and use one or more aspects of the present invention will be described with reference to FIG. 1A. Computing environment 100 is based on, for example, International Business machines corporation, Armonk, N.YProvided withAn example of this is in 8 months 2010 under the IBM publication number SA22-7832-08 entitled "z/architecture principles of Operation Described in publications. In one example, a method is based onIncludes the zEnterprise196 (z 196) system offered by International Business machines corporation.Andand zEnterprise196 and z196 are registered trademarks of International Business machines corporation, Armonk, N.Y.. Other names used herein may also be registered trademarks, trademarks or product names of International Business machines corporation or other companies.

As one example, computing environment 100 includes one or more central processing units 102 connected to a main memory 104 via one or more buses 106. One or more central processing units may execute an operating system 108, such as that provided by International Business machines corporationAnd (4) operating the system. In other examples, one or more central processing units may execute other operating systems or not.Is a registered trademark of international business machines corporation, armonk, new york, usa.

Central processing unit 102 and main memory 104 may also be coupled to I/O hub 120 via one or more connections 122 (e.g., a bus or other connection). The I/O hub provides a connection to one or more I/O adapters 130, which in turn are coupled to one or more solid state devices 140. Adapters and solid state devices are implementations of storage class memory (e.g., flash memory). The I/O hub is part of an I/O subsystem 145 that facilitates one or more aspects of an embodiment.

In yet another embodiment, as shown in FIG. 1B, the computing environment 150 may include a Central Processing Complex (CPC) 152 based on the data provided by International Business machines corporationThe central processing complex 152 includes, for example, one or more partitions 154, a hypervisor 156, one or more central processors 158, and one or more components of an input/output subsystem 160. In this example, partitions 154 are logical partitions (e.g., LPARs) that each include a set of system hardware resources that are virtualized as a separate system.

Each logical partition 154 can function as a separate system. That is, each logical partition may be independently reset, initially loaded with an operating system or other control code, and operated with a different program, as needed. An operating system or application program running in a logical partition appears to have access to a complete and complete system, but in practice, only a portion of it is available. The combination of hardware and Licensed Internal Code (LIC), referred to as firmware, protects programs in one logical partition from program interference in a different logical partition. This allows several different logical partitions to operate in a time-sliced manner on a single or multiple physical processors. As used herein, firmware includes, for example, microcode, and/or macrocode of a processor (or the entity performing the process). It includes hardware-level instructions and/or data structures, such as those used in implementing higher-level machine code. In one embodiment, it comprises, for example, proprietary code, which is typically delivered as microcode that includes trusted software or microcode specific to the underlying hardware and controls operating system access to the system hardware.

In this example, several logical partitions have a resident Operating System (OS) 170, which may be different for one or more logical partitions. In one embodiment, at least one logical partition is executing that is provided by International Business machines corporation, Armonk, N.Y.And (4) operating the system.

Logical partitions 154 are managed by a hypervisor 156, which is implemented by firmware running on a central processor 158. Logical partitions 154 and hypervisor 156 each comprise one or more programs that reside in respective portions of main memory 159 associated with the central processors. An example of hypervisor 156 is a processor resource/system manager (RP/SM) provided by International Business machines corporation of Armonk, N.Y.^TM）。

Central processors 158 are physical processor resources assigned to logical partitions. For example, logical partition 154 includes one or more logical processors, each of which represents all or a portion of the physical processor resources 158 allocated to the partition. The logical processors of a particular partition 154 may be dedicated to that partition, such that the underlying processor resources are reserved for that partition; or shared with other partitions such that the underlying processor resources are potentially accessible by another partition.

Input/output subsystem 160 (only a portion of which is depicted) provides a connection to storage class memory 180. In this example, an address space is provided for storage class memory that renders the memory flat (flat) hiding details of the physical implementation from the program. As an example, there is one address space for the entire system of storage class memory, but from a configuration perspective (e.g., LPAR or virtualized customer (guest) in another embodiment), there is an address space in which storage class memory increments are populated for each configuration of the system. The storage class memory address space is separate and apart from the main memory address space.

In thatIn one particular example of the present invention, the I/O subsystem includes a channel subsystem that directs the flow of information not only between the I/O peripheral control units (and devices) and main memory, but also between storage class memory and main memory. However, the I/O subsystem may not be a channel subsystem.

In the case of a channel subsystem, the subchannel is used to perform EADM operations. These sub-channels are referred to as Asynchronous Data Mover (ADM) type sub-channels and are associated with EADM operations, rather than I/O devices, as are other I/O type sub-channels. The sub-channels of an ADM type do not contain a device number nor channel path information. The number of sub-channels provided to a configured ADM type is model dependent. The sub-channels of the ADM type are addressed by a subsystem identification word (SID).

An ADM type subchannel is used by an extended asynchronous data mover facility that is an extension of the channel subsystem. As described herein, the EADM facility allows programs to request movement of data chunks between main storage and storage class memory, as well as perform other operations, such as clearing storage class memory chunks or releasing storage class memory chunks. In one embodiment, when an EADM installation is installed:

one or more sub-channels of ADM type are provided, which are used for EADM operations.

EADM operations are specified by a specified EADM operation block (AOB). The AOB includes an EADM request block (ARQB) and an EADM response block (ARSB), and specifies a list of EADM Move Specification Blocks (MSBs). For move operations, the MSB contains information about the data block to be moved, such as block size, source and destination locations of the block, and direction of data movement.

The maximum number of MSBs that can be specified by an AOB is model dependent. The MSB may specify the maximum block count to be shifted or operated on, which is also model dependent.

The program initiates EADM operations by issuing a start subchannel instruction that specifies a subchannel of the ADM type and an EADM Operation Request Block (ORB). The EADM ORB, in turn, specifies an AOB. This instruction passes the contents of the EADM ORB to the specified sub-channel.

When a start subchannel is issued to initiate an EADM operation, the channel subsystem asynchronously performs the specified operation.

As observed by the program, the presence within the storage class is block-parallel at the minimum block size depending on the model. This model dependent value is referred to as the SCM block parallel size.

When the EADM operation is complete, the I/O interruption is made pending to the program for the subchannel of the ADM type on which the operation was initiated.

The EADM ORB includes a specification of the address of the AOB to be used and the subchannel. AOBs are specified, for example, on 4 byte boundaries and can be up to 4 kbytes in size. If more MSBs are needed than an AOB that is suitable for 4 kbytes, the AOB may specify a list of MSBs that is extended to additional storage areas by using the address of the next MSB in the specified list, rather than specifying the MSBs of the storage area to be used for data transfer.

The first EADM operation is started by the channel subsystem using the information in the specified EADM ORB and the ARQB in the specified AOB to obtain the MSB. The MSB includes information that specifies and controls the EADM operation to be processed.

Each EADM operation is represented by one MSB. The MSB may specify, for example, the transfer of a block of data from main storage to storage class memory; transfer of a block of data from storage class memory to main memory; clearing blocks of the storage-class memory; and the release of the block of storage class memory.

The new MSB may be used if the memory blocks to be transferred are not contiguous in main memory, or the MSB may use indirect addressing by specifying a list of EADM indirect data address words (AIDAW) to specify non-contiguous blocks.

Since the MSB specifies only one direction of data transmission, a new MSB may be used when there is a change in the transmission direction.

The end of an EADM operation is typically indicated by a combined channel side and device side status condition. This combination of states represents a combination of primary and secondary states that indicates that the subchannel is available for another start function after the states are cleared.

The EADM operation may be terminated prematurely by a clear subchannel instruction. Execution of the clear subchannel instruction terminates execution of the AOB at the subchannel, clears the subchannel of the indication of the AOB in execution, and asynchronously performs a clear function.

Further details regarding the EADM ORB and related control structures will be described below with reference to FIGS. 2A-2F. Referring initially to FIG. 2A, one embodiment of an EADM ORB is depicted.

As an example, the EADM ORB200 includes:

interrupt parameters 202: this field is left unmodified in the subchannel until replaced by a subsequent modify subchannel or start subchannel instruction. These bits are placed in the I/O interrupt code when an I/O interrupt occurs for a subchannel and when the interrupt request is cleared by, for example, execution of a test pending interrupt.

Subchannel key 204: this field forms the sub-channel key for the EADM operation specified by the ARQB and applies to the get ARQB, the get MSB, the store ARSB, and for accessing main memory for data transfer. The value of this field is a defined value; otherwise, a program verify condition is identified by the channel subsystem or an operand exception is identified.

ORB extension control (X) 205: this field specifies whether the ORB is extended. When a subchannel of the ADM type is specified, this field is a specified value; otherwise, an operand exception or program check condition is identified.

EADM operation Block (AOB) Address 206: this field specifies the address of the EADM operation Block (AOB). If a particular bit of the field does not include a defined value, an operand exception or a program verify condition is identified.

If this field specifies a location that is protected from acquisition or specifies a location outside the configuration, the start function is not initiated. In this case, the subchannel becomes a state pending in primary, secondary and warning states.

Channel subsystem (CSS) priority 208: this field includes the channel subsystem priority number assigned to the specified subchannel and is used to order the selection of a subchannel of the ADM type when the start function is to be initiated for one or more subchannels that start in flight.

Storage Class Memory (SCM) priority 210: this field includes a storage-level memory priority (SCM) number that specifies a priority level to be applied to all EADM operations associated with the start function.

Whether the content of the SCM priority field is recognized by the EADM facility is model dependent. On models that do not recognize this field, the field contents are ignored and all EADM operations associated with the start function are assigned an implicit priority number.

Format (FMT) 212: this field specifies the layout of the ORB. When a subchannel of the ADM type is specified, this field will include the specified value; otherwise, an operand exception is identified or a specific condition code is set.

The EADM operation block (AOB) specified by the EADM AOB address 206 of the EADM ORB includes information that is used to initiate an EADM operation. In one example AOBs are allocated on 4 kbyte boundaries and are variable in length.

In one example, as shown in FIG. 2B, EADM AOB220 includes three parts: EADM request block (ARQB) 222; EADM response Block (ARSB) 224; and MSB region 226 containing up to a defined number (e.g., 124) of MSBs. But the ARQB may specify that more MSBs than defined are used when the MSB branch is used (i.e., by using a branch in the MSB to the next MSB flag).

One embodiment of the EADM request block (ARQB) 222 is described with reference to FIG. 2C. In one example, the ARQB222 includes:

format (FMT) 230: this field specifies the layout of the ARQB. The value of this field is a defined value; otherwise, the program check condition is recognized by the channel subsystem and a command code error is indicated in the exception qualifier code field of the ARSB.

The command code 232: this field will specify the EADM move Block command; otherwise, the program verify condition is recognized by the channel subsystem and a command code error is indicated in the exception modifier code field of the ARSB.

MSB count 234: this field specifies the count of MSBs that make up the EADM request. The maximum MSB count that can be specified is model dependent. The value of this field is greater than zero and less than or equal to the maximum MSB count value depending on the model; otherwise, a program check condition is identified by the channel subsystem and an MSB count error is indicated in the exception modifier code field of the ARSB.

In addition to the EADM request block, the EADM ORB also specifies an EADM response block (ARSB). In this embodiment, the EADM response block is meaningful only when an abnormal condition is identified. In particular, the ARSB is significant only when the alarm status is present in the EADM subchannel status word (SCSW), the EADM Extended Status Word (ESW) is significant, and the EADM response block storage (R) bit is a 1 in the EADM Extended Report Word (ERW) (each of these cases will be described below). When ARSB is meaningless, the contents of ARSB in AOB are unpredictable.

If the program is stored to the ARSB while the associated subchannel is active, unpredictable results may occur.

When the ARSB is stored, the amount of data that has been transferred (if any) is unpredictable.

One embodiment of an EADM response block is described with reference to FIG. 2D. In one example, the ARSB224 comprises:

format (FMT) 240: this field specifies the layout of the ARSB. When the ARSB is stored, the value of this field is stored as a defined value.

Abnormality flag (EF) 242: this field, when set, indicates the reason for the exception that the ARSB is stored when it is stored. Exemplary causes of abnormalities include:

and (3) program inspection: a programming error is detected.

Protection and inspection: memory access is prevented by a protection mechanism. The protection is adapted for fetching of ARQB, MSB, AIDAW and data to be transferred to the storage class memory and for storing information in the ARSB and data transferred from the storage class memory.

And (3) channel data checking: an incorrect storage error has been detected for data contained in main memory and currently used to perform an EADM operation. This condition may be indicated when detected, even if the data is not used at the time of prefetching. Channel data check is indicated when the data or associated key has an invalid Check Block Code (CBC) in main memory when the data is referenced by the channel subsystem.

And (3) channel control checking: the lane control checks are caused by any machine faults affecting the control of the lane subsystem. This case includes an invalid CBC on ARQB, ARSB, MSB, AIDAW or the corresponding related key. This condition may be indicated when an invalid CBC is detected on a prefetched ARQB, MSB, AIDAW or corresponding related key, even if the ARQB, MSB or AIDAW is not used.

Extended asynchronous data mobility facility checking: an incorrect error has been detected with respect to data contained in the storage class memory and currently used in the execution of the EADM operation.

Exception Control Block Identifier (ECBI) 244: when storing the ARSB, this field is a multi-bit mask whose bits, when set, specify any single or combination of the following components associated with the identified exception specified by the EF field:

one or more control blocks

Main memory data area

Storage class memory

The bits that may be set represent, for example, an EADM move specification block, an EADM indirect data address, data in main memory, and/or data in storage class memory.

The bits in the ECBI field describe the components associated with a single exception condition. This field contains, for example, zero if no component can be identified for the exception condition.

Field Validity Flag (FVF) 246: when the ARSB is stored, this field includes a multi-bit mask whose bits indicate the validity of a particular field in the ARSB. When the validity bit is set, the corresponding field is already stored and available for recovery purposes. The bits that may be set represent, for example, a failed MSB address field, a failed AIDAW field, a failed main-storage address field, and/or a failed storage class memory address field.

Exception modifier code (EQC) 248: when the ARSB is stored, this field includes a code value that further describes the exception specified by the exception flag field. The code values may represent, for example:

no additional description is provided. For this case, the Exception Control Block Identifier (ECBI) field and those fields verified by the field validity flags field may identify the control block for which the exception was identified.

And (3) format error: the format specified by the format field is saved. For this case, the Exception Control Block Identifier (ECBI) field and those fields verified by the field validity flags field may identify the control block for which an exception has been identified.

Command code error: the value specified in the command code field of the ARQB is not identified.

MSB count error: the value specified in the MSB count field of the ARQB is zero or exceeds the MSB maximum value that may be specified depending on the model.

Marking error: the flag bit specified by the flag field is saved. For this case, the Exception Control Block Identifier (ECBI) field and those fields verified by the field validity flags field identify the control block for which an exception has been identified.

Operation code error: specifying a saved opcode value. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified.

Block size error: specifying a saved block size value. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified.

Block count error: the value specified in the MSB's block count field is zero or exceeds the maximum count of model-dependent blocks that can be specified by the MSB. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified.

Main memory address specification error: the main memory address is specified on an incorrect boundary. Such an address may have been specified by the MSB or by the AIDAW. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag field indicates that the failed main memory address field is valid, the field contains the main memory address for which an exception has been identified.

Storage class memory address specification error: storage class memory addresses are specified on incorrect boundaries. Such an address is specified by the MSB. If the field validity flag indicates that the failing MSB address field is valid, this field contains the MSB address for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag field indicates that the failed storage class memory address field is valid, the field contains the storage class memory address for which an exception has been identified.

Main memory address exception: the EADM facility attempts to use an address that is not available in the configuration or wrap around (wrap) maximum memory address. Such an address may have been specified by the MSB or from an increase in main memory address during the data transfer. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the AIDAW address for which an exception has been identified. If the field validity flag field indicates that the failed main memory address field is valid, the field contains the main memory address for which an exception has been identified.

Storage class memory address exception: the EADM facility attempts to use storage class memory addresses that are not available in the configuration. Such an address may have been specified by the MSB or result from incrementing a storage class memory address during a data transfer. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag field indicates that the failed storage class memory address field is valid, the field contains the storage class memory address for which an exception has been identified.

Main memory error: an incorrect main memory error is detected. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag indicates that the failed main memory address field is valid, the field contains the main memory address for which an exception has been identified.

MSB list error: the AOB specifies the MSB list across a 4 kbyte boundary without specifying a branch across the boundary to the next MSB (BNM), or the MSB is the last MSB in the specified MSB list and the BNM is specified by the MSB. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified.

MSB branch error: the AOB specifies a MSB list, where the MSB (branch source MSB) specifies the branch to the next MSB (BNM), and the MSB that is the branch target also specifies the BNM. If the field validity flag field indicates that the MSB address field that failed is valid, this field contains the address of the branch source MSB for which an exception has been identified.

Aid aw list error: the MSB specifies a list of EADM indirect data address words (AIDAW) that cross a 4 kbyte boundary without specifying a branch to the next awidaw (bna) that crosses the boundary. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified.

Aid aw branch error: the MSB specifies an EADM indirect data address word (AIDAW) list, where AIDAW (branch source AIDAW) specifies a branch to source AIDAW (BNA) and AIDAW as the branch target also specifies a BNA. If the field validity flags field specifies that the MSB address field that failed is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the branch source AIDAW for which an exception has been identified.

Storage class memory temporary error: a recoverable storage class memory error is detected. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. The field validity flags field contains the address of the AIDAW for which an exception has been identified if it is valid when it indicates a failed AIDAW address. If the field validity flag field indicates that the failed storage class memory address field is valid, the field contains the storage class memory address for which an exception has been identified.

The release operation does not support errors: the release operation is specified for storage class memory for which the release operation is not supported. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag field indicates that the failed storage class memory address field is valid, the field contains the storage class memory address for which an exception has been identified.

Releasing data read errors: a read operation is specified for a storage class memory for which the last successful operation is a release operation. If the field validity flag field indicates that the failing MSB address field is valid, this field contains the address of the MSB for which an exception has been identified. If the field validity flags field indicates that the failed AIDAW address field is valid, this field contains the address of the AIDAW for which an exception has been identified. If the field validity flag field indicates that the failed storage class memory address field is valid, the field contains the storage class memory address for which an exception has been identified.

Failed MSB address 250: when the specified bit of the field validity flag field is set, this field indicates the address of the MSB for which an exception has been identified.

Failed AIDAW address 252: when the specified bit of the field validity flags field is set, this field indicates the address of the AIDAW for which an exception has been identified.

Failed main memory address 254: when the specified bit of the field validity flag field is set, this field indicates the address of the block of main memory for which an exception has been identified.

Failed storage class memory address 256: when the specified bit of the field validity flag field is set, this field includes the SMC address (e.g., 64 bits) of the block of storage class memory for which the exception has been identified.

In addition to the EADM request block and the EADMDM response block, the EADM operation block (AOB) also specifies one or more EADM Move Specification Blocks (MSBs). An AOB may contain up to, for example, 124 MSBs. However, the program may specify more than 124 MSBs by specifying a larger number of MSBs in the count field of the ARQB and by branching to the continuation of the MSB list using a branch to next MSB (bnm) flag. There may be continuations of multiple MSB lists, but in one embodiment, none of the continuations may cross a 4K byte boundary without using a BNM to cross the boundary. The continuation of the MSB is not required to be continuous. Each continuation of the MSB list, if specified to start on a 4 kbyte boundary, may contain up to 128 MSBs. The total number of MSBs in the MSB list is specified by the MSB count field in the ARQB.

The EADM move specification block describes, for example, a memory block to be moved between main storage and storage class memory, or an operation to be performed on the memory block. One embodiment of the MSB226 is described with reference to fig. 2E and includes, for example:

format (FMT) 260: this field specifies the layout of the MSB. The value of this field is a defined value; otherwise, an MSB format error is indicated in the exception modifier code field of the ARSB.

Operation Code (OC) 262: this field specifies the operation to be performed. In one example, when the specified bit of the flags field is a defined value, as described below, the field specifies the operation to be performed. Exemplary operations include:

clearing the storage-class memory: when the code is specified, the storage class memory specified by the storage class memory address, block size, and block count fields is cleared (e.g., set to zero). The main memory address field is meaningless for this operation.

Reading: when the code is designated, the data is designated to be transferred from storage class memory to main memory. The block count, block size, main memory address, and storage class memory address fields are meaningful for this operation.

Writing: when the code is designated, the data is designated to be transferred from main storage to storage class memory. The block count, block size, main memory address, and storage class memory address fields are meaningful to the operation.

Releasing: when the code is specified and the EADM release facility is installed, the storage class memory specified by the storage class memory address, block size, and block count fields is released. The main memory address field is not meaningful for this operation. This code is retained when the EADM release facility is not installed.

If the reserved value is specified, the program verify condition is recognized by the channel subsystem and an opcode error is indicated in the exception modifier code field of the ARSB.

When the designated flag bit of the flag field is not a defined value, the field is retained and not verified.

The mark 264: this field identifies one or more flags that may be set. The reserved flag bit is set to a defined value; otherwise, a flag error is indicated in the exception modifier code field of the ARSB. Exemplary flags include:

branch to the next msb (bnm): when set, the flag indicates that the MSB does not specify EADM operation and is not used to transfer data. Instead, the main memory address field specifies the address of the next MSB to be used to specify the EADM operation.

When the BNM flag is set (e.g., 1) and the main memory address field specifies the MSB in which the BNM flag is also set, the program verify condition is identified by the channel subsystem, the address of the branch source MSB is stored in the failing MSB address field of the ARSB, and an MSB branch error is indicated in the exception modifier code field of the ARSB.

If the MSB ends at a 4K byte boundary, the AOB specifies an additional MSB, and the BNM flag is not set, the program verify condition is identified by the channel subsystem, the address of the MSB is stored in the ARSB's failing MSB address field, and an MSB list error is indicated in the ARSB's exception modifier code field.

If the MSB is the last MSB in the specified MSB list and the BNM flag is set, the program verify condition is identified by the channel subsystem, the address of the MSB is stored in the failing MSB address field of the ARSB, and an MSB list error is indicated in the exception modifier code field of the ARSB.

When the BNM flag is set, the remaining flags, the opcode field, the block size field, the block set count field, and the storage class memory address are meaningless.

Indirect addressing: when set, the flag indicates that the main-memory address field specifies an address of an EAM indirect data address word (AIDAW) or an address of a first AIDAW of an AIDAW list of one or more main-memory locations to be used for data transfers, respectively. When not set, the flag indicates that the main memory address field specifies the address of the main memory location to be used for the data transfer.

Block Size (BS) 266: this field specifies the size and boundary of the block of data to be transferred for both main storage and storage class memory, or the size and boundary of the block of storage class memory to be operated on (e.g., cleared or freed).

4K: when the code value is a defined value, the data block to be transferred is on a 4 kbyte boundary and is 4 kbytes in size.

1M: when the code value is another defined value, the data block to be transferred is on a 1 mbyte boundary and is 1 mbyte in size.

If a reserved value is specified, the program verify condition is recognized by the channel subsystem and a block size error is indicated in the exception modifier code field of the ARSB.

This field is ignored when the BNM flag is set.

Block count 268: this field includes a count of data blocks to be transferred or operated on (e.g., cleared or freed). Based on the block size field, this is a count of 4 kbytes or 1 Mbyte blocks.

The value of this field will be greater than zero and less than or equal to the model-dependent maximum block count that can be specified by the MSB; otherwise, the program verify condition is identified by the channel subsystem and a block count error is indicated in the exception modifier code field of the ARSB.

This field is reserved and not verified when the BNM flag is set.

Main memory address 270: when the opcode field is meaningful (e.g., BNM flag is not set) and specifies a read or write operation, and the indirect addressing indicator in the flag field is not set, this field includes the main memory address to be used for the data transfer, and the following applies:

When a block size field specifies a 4 kbyte block, the specified bits of this field contain a defined value (e.g., zero); otherwise, the program verify condition is identified by the channel subsystem and a main memory specification error is indicated in the exception modifier code field of the ARSB.

When a block size field specifies a 1 Mbyte block, the specified bits of the field contain a defined value (e.g., zero); otherwise, the program verify condition is identified by the channel subsystem and a main memory specification error is indicated in the exception modifier code field of the ARSB.

When the operation code field makes sense and specifies a read or write operation, and the indirect addressing indicator in the flags field is set, this field includes the main memory address of the AIDAW or the address of the first of the AIDAW list to be used for the data transfer. For this case, a particular bit of this field contains a defined value; otherwise, the program verify condition is identified by the channel subsystem and a main memory specification error is indicated in the exception modifier code field of the ARSB.

When the BNM flag is set, the opcode is meaningless and the MSB does not specify an EADM operation. Instead, this field includes the main memory address specifying the next MSB of the EADM operation. For this case, the designated bits of this field contain a defined value; otherwise, the program verify condition is identified by the channel subsystem and a main memory specification error is indicated in the exception modifier code field of the ARSB.

Storage class memory address 272: when the opcode field makes sense, this field includes the (e.g., 64-bit) storage class memory address to be used for data transfers or to be operated on (e.g., cleared, freed), and the following applies:

when a block size field specifies a 4 kbyte block, the specified bits of this field contain a defined value (e.g., zero); otherwise, the program verify condition is identified by the channel subsystem and a storage class memory specification error is indicated in the exception modifier code field of the ARSB.

When a block size field specifies a 1 Mbyte block, the specified bits of the field contain a defined value; otherwise, the program verify condition is identified by the channel subsystem and a storage class memory specification error is indicated in the exception modifier code field of the ARSB.

This field is reserved and not verified when the BNM flag is set.

As indicated above, the EADM indirect data address word may be specified. The EADM indirect data address word (AIDAW) allows programs to specify data block transfers between non-contiguous blocks of storage class memory and main storage. When the indirect addressing flag in the MSB is set, an AIDAW or AIDAW list is specified by the MSB.

The amount of data transmitted by a single AIDAW is specified by the block size field in the MSB. The number of AIDAWs in the AIDAW list is the sum of the number specified by the block count field in the MSB plus the number of AIDAWs that specify branches to the next AIDAW. The data transfers may be processed in a different order than specified in the AIDAW list. Moreover, data transfers specified by multiple AIDAWs in the AIDAW list may be processed in parallel.

AIDAW is assigned, for example, on a quad-word boundary. The AIDAW list may be any length, but in one example does not cross a 4 kbyte boundary unless a branch to the next AIDAW (bna) is specified to cross a boundary. It is not required that the AIDAW as the branch target is consecutive with the AIDAW of the specified BNA. However, the program should create the AIDAW list in as few 4 kbyte blocks as possible; otherwise, performance degradation may occur.

Referring to FIG. 2F, in one example, the EADM indirect data address word 280 includes:

mark 282: exemplary flags include:

branching to the next AIDAW (BNA) indicates that, when set, the main-memory address field does not specify the main-memory address to be used to transfer the data. Instead, the main memory address field specifies the address of the next AIDAW to be used to transfer the data.

When the BNA flag is set and the main-memory address field specifies an AIDAW in which the BNA flag is also set, the address of the MSB is stored in the failing MSB address field of the ARSB, the address of the branch source AIDAW is stored in the failing main-memory address field of the ARSB, and an AIDAW branch error is indicated in the exception modifier code field of the ARSB.

If the AIDAW ends at a 4K byte boundary, the MSB specifies an additional AIDAW, and the BNA flag is not set, the address of the MSB is stored in the failing MSB address field of the ARSB, the address of the AIDAW is stored in the failing main-memory address field of the ARSB, and an AIDAW list error is indicated in the exception modifier code field of the ARSB.

Main memory address 284: when the BNA field is not set, the field includes the main memory address to be used for the data transfer, and the following applies:

when the block size field in the MSB specifies a 4 kbyte block, the specified bits of this field contain a defined value (e.g., zero); otherwise, the program verify condition is identified by the channel subroutine, and a main memory specification error is indicated in the exception modifier code field of the ARSB.

When the block size in the MSB specifies a 1 mbyte block, the specified bits of this field contain a defined value (e.g., zero); otherwise, the program verify condition is identified by the channel subroutine, and a main memory specification error is indicated in the exception modifier code field of the ARSB.

When the BNA flag is set, this field includes the main memory address of the next AIDAW to be used for data transfer.

As described above, EADM operations are specified by a Start subchannel instruction. That is, the program initiates an EADM operation by issuing a start subchannel instruction that specifies a subchannel of the ADM type and an EADM ORB. Execution of the instructions passes the contents of the EADM ORB to the specified sub-channel. The EADM ORB includes the specification of the subchannel key (for protection) and the address of the AOB to be used.

In one example, as shown in FIG. 3A, the start subchannel instruction 300 includes an operation code 302 that specifies a start subchannel function, a first operand 304, which is a hint operand located, for example, in general register 1, that includes a subsystem identifier that specifies the subchannel of the ADM type to be started; and a second operand 306, which is the logical address of the EADM ORB. The EADM ORB specifies parameters for controlling the start function. During the start of execution of the subchannel, the contents of the EADM ORB are placed in the specified subchannel before the condition code is set. If starting the execution of a subchannel results in setting a condition code other than the code indicating success, the contents of the EADM ORB are not placed in the specified subchannel.

After execution of the start subchannel for an ADM type subchannel, the channel subsystem asynchronously executes a start function to initiate an EADM operation with the EADM facility. The start functions include, for example, the following:

1. ARQB is obtained from AOB.

2. The EADM operation specified by the ARQB and its specified MSB is performed.

3. The completion information in the ARSB is conditionally stored in the AOB.

4. So that the sub-channel of the ADM type becomes state pending, indicating the completion of the start function.

In one embodiment, referring to FIG. 3B, when the start subchannel execution instruction is executed and the SID specifies a subchannel of an ADM type and the second operand specifies an EADM ORB, the EADM operation is specified at step 320. The parameters in the EADM ORB are passed to the specified sub-channel at step 322, and the channel subsystem is requested to perform a start function with the EADM facility at step 324. At step 326, the channel subsystem asynchronously performs the start function by initiating an EADM operation using information at the subchannel (including information passed during execution of the start subchannel instruction).

The performance of an EADM operation (e.g., a first operation) includes obtaining an AOB using information from an eadmorrb at step 328, and the information is used in the AOB to obtain an EADM request block (ARQB) and to specify one or more EADM Move Specification Blocks (MSBs) at step 330. One or more specified MSBs are then retrieved from main memory at step 332, and the information specified in the MSBs is used to control the requested EADM operation. The first operation is said to start when the channel subsystem attempts to begin a data transfer or attempts a clear or release operation.

The channel subsystem performs the operation requested in the MSB at step 334. The process is asynchronous to the execution of the start process.

When the EADM operation initiated by the start subchannel ends at step 336, the channel subsystem generates a status condition at step 338. The generation of these conditions is brought to the attention of the program by an I/O interrupt at step 339. The program may also query for these conditions by executing a test pending interrupt instruction.

The generated status condition is presented to the program in the form of an EADM subchannel status word (SCSW). By executing the test subchannel instruction, the EADM SCSW is stored as part of an EADM Interrupt Response Block (IRB).

When an EADM operation specified in an EADM operation Block (AOB) is ended, the channel subsystem generates primary and secondary interrupt states. EADM operations may be terminated by a clear subchannel or an exception condition may be identified when a start function is executed.

For move operations, the processing of the MSB by the channel subsystem controls the flow of information units to or from main memory. To change the direction of data movement during MSB processing, a new MSB is required. The ARQB specifies the count of MSBs that make up the request.

Each EADM operation is represented by one MSB. The MSB may specify any one of the following:

Transfer of data blocks from main storage to storage class memory.

Transfer of data blocks from storage class memory to main storage.

Clearing blocks of storage class memory.

When the EADM release facility is installed, the blocks of storage class memory are released.

If the memory blocks to be transferred for move operations are not contiguous in main memory, a new MSB may be used, or the MSB may use indirect addresses by specifying an EADM indirect data address word (AIDAW) list to specify non-contiguous blocks. Since the MSB may specify data transfer in only one direction, a new MSB is to be used when there is a change in the data transfer direction.

The following are features of the EADM data transfer:

data transfers may be processed out of order of the specified MSB list.

The data transfers specified by the multiple MSBs in the MSB list may be processed in parallel.

Data transfers may be processed out of order in the specified AIDAW list.

Data transfers specified in multiple AIDAWs in the AIDAW list may be processed simultaneously.

Accesses to main and storage class memory need not be single access references and need not be executed in a left-to-right direction, as viewed by programs and other CPUs.

If two or more EADM operations are currently active and address the same SCM location, main memory location, or both, the operations may be performed simultaneously and the content from the different operations may be interleaved; however:

For input operations, the data of each block stored by the EADM facility to the main memory, whose size is equal to the SCM block parallel size, consists of data transferred from the storage class memory by only one parallel EADM operation.

For output operations, each block of storage class memory located on a boundary and having a size equal to the SCM block parallel size contains data specified by only one parallel EADM operation.

The above is true regardless of whether an EADM operation is specified by a single AOB and handled by the same instance of the initiating function, or an EADM operation is specified by a different AOB and handled by a different instance of the initiating function.

When an EADM operation is active for a subchannel, it is unpredictable whether changes made by the program to ARQB, MSB, AIDAW, and transfer data associated with the active operation are observed by the EADM facility.

When all blocks specified by all MSBs specified by an AOB have been transferred or cleared or released, a subchannel generates a state, which is stored in the subchannel and requests an I/O interrupt for an ADM type subchannel.

The end of an EADM operation is typically indicated by a combined status condition of the channel and the device terminal. The state combination represents a combination of primary and secondary states that indicates that after the states are cleared, the subchannel is available for another start function.

As described above, the MSB may specify a data transfer operation, a clear operation, or a release operation, each of which is described below.

When a move operation is requested, one or more blocks of data are moved between main storage and storage class memory. For example, for a read operation, SCM data is retrieved from an SSD that provides content specified by a specified SCM address, which is then stored in main memory. For write operations, this process is preserved. An adapter that controls the SSD performs storage. In further detail, to perform a move operation, system firmware first translates a given SCM address to an adapter address (e.g., a logical volume address, where the logical volume includes one or more SSDs). For example, a translation table associating SCM addresses with adapter addresses is used. The system firmware then submits one or more corresponding adapter move commands (e.g., read or write) to one or more I/O adapters. The adapter move command contains a main memory address, an adapter address, and a transfer size. The adapter then uses another translation table to locate one or more physical SSD addresses, which correspond to the adapter addresses. The I/O adapter implements the move operation by retrieving data from the main memory and storing it in the SSD, or retrieving data from the SSD and storing it in the main memory. Additional details are provided in the co-filed patent application entitled "Firmware Management of Storage Class Memory" entitled POU290110090US 1.

When a clear operation is performed, the specified storage class memory increment is cleared by setting the contents to zero.

Also, when a release operation is performed, one or more standard TRIM commands may be submitted to the SSD containing the corresponding SCM address. The TRIM command allows the program to give hints about block usage, allowing better garbage collection by the SSD. The TRIM command allows the operating system to notify the SSD of which memory blocks are no longer considered in use and can be eliminated.

EADM operations may be interrupted prematurely by clear subchannel instructions. Execution of the clear subchannel instruction terminates execution of the AOB at the subchannel, clears the subchannel of the indication of the AOB in execution, and asynchronously performs a clear function. When the flush function is performed, the data transfer is terminated and the amount of data transferred is unpredictable before the subchannel becomes state pending. Execution of the flush function does not result in state generation, but causes the channel subsystem to have the I/O interruption pending.

In one embodiment, referring to FIG. 3C, clear subchannel instructions 350 include operation code 352 that specifies a clear subchannel function. The subchannel to be cleared is specified by a subsystem identification word, for example, in a general purpose register. The purge function for a subchannel of the ADM type includes:

1. Ensuring that the current data transfer is terminated.

2. Modify fields at the subchannel and conditionally modify the ARSB. For example, the subchannel status word is modified to indicate a clear function in the function control field and in the active control field. The ARSB may be modified to reflect any detected errors.

3. Causing the subchannel to become state pending indicating completion of the purge function.

Other instructions that may specify a subchannel of the ADM type may also be issued, including testing the subchannel, modifying the subchannel, and storing the subchannel, each as described below.

Referring to FIG. 3D, in one example, test subchannel instructions 360 include, for example, operation code 362, which specifies test subchannel functions; a first operand 364, which is an implied operand located, for example, in general register 1, that includes a subsystem identification word specifying the subchannel to be tested; and a second operand 366, which is a logical address of an Information Response Block (IRB) in which information is stored.

When testing a subchannel is performed and a subchannel of the ADM type is specified, the subchannel is status pending and the information is stored in the specified EADM IRB (interrupt response block), the specified condition code is set. When the subchannel is not status pending and the status information is stored in the specified EADMIRB, the defined condition code is set. When a subchannel is not provided or enabled, no action is taken.

In one example, the EADM IRB includes a Subchannel Status Word (SSW) and an Extended Status Word (ESW), and an extended control word that may provide additional model-dependent information that describes conditions that may exist in the facility. After discussing various instructions that may specify the sub-channels of an ADM type, each of these words is further described below.

Referring to FIG. 3E, in one embodiment, modify subchannel instructions 370 include operation code 372, which indicates to modify subchannel functions; a first operand 374, which is a hint operand located, for example, in general register 1, that includes a subsystem identification word that specifies the subchannel to be modified; and a second operand 376, which is the logical address of the subchannel block of information (SCHIB) associated with the subchannel.

When modifying a subchannel is performed and a subchannel of an ADM type is specified, and information from the specified subchannel information block (scheb) is placed in the subchannel, a specific condition code is set. When a subchannel is state pending, no action is taken and a defined state code is set. When a subchannel is busy with a start or clear function, no action is taken.

Referring to FIG. 3F, an example of a store subchannel instruction is described. In one example, store subchannel instructions 380 include operation code 380 that identifies a store subchannel function; a first operand 384, which is a hint operand located, for example, in general register 1, that includes a subsystem identification word that specifies the subchannel for which information is being stored; and a second operand 386, which is the logical address of SCHIB.

When a store subchannel is issued and a subchannel of the ADM type is specified, and the scheb is stored, the specified condition code is set. When the specified subchannel is not provisioned in the channel subsystem, no action is taken.

An example of a sub-channel information block for a sub-channel of ADM type, eadm (schib), is described with reference to fig. 4A. In one example, the EADM SCHIB400 includes a model-dependent region 401 that includes model-dependent information. Also, the SCHIB400 includes a Path Management Control Word (PMCW) 402, and a subchannel status word (SCSW) 404, each of which will be described below.

In one embodiment, the EADM PMCW402 includes the following fields, such as shown in FIG. 4B:

interrupt parameters 410: this field includes the interrupt parameters stored in the I/O interrupt code. The interrupt parameter may be set to any value by the start subchannel and the modify subchannel. The initial value of the interrupt parameter field in the subchannel is zero.

Interruption Subclass (ISC) 412: this field includes a number of bits, which are unsigned binary integers within a specified range, corresponding to the bit positions of the I/O interrupt subclass mask bits in the specified control registers of each CPU in the configuration. The setting of the mask bits in the control registers of the CPU controls the recognition by the CPU of the interrupt request associated with the subchannel. The ISC may be set to a value by the modify subchannel. The initial value of the ISC field in the subchannel is, for example, zero.

Enable (E) 414: when set, this field indicates that the subchannel is enabled for all EADM functions.

Subchannel Type (ST) 416: this field indicates the subchannel type. Depending on the model and configuration, one or more of the following subchannel types may be provided: an I/O subchannel or an ADM subchannel.

The value of this field is determined when the subchannel is configured and cannot be changed by the modifying subchannel.

When the modify subchannel instruction is executed and formulates a subchannel of an ADM type, the ST will indicate an ADM subchannel; otherwise, an operand exception is identified.

Referring to FIG. 4A, the subchannel information block also includes a subchannel status word 404. The EADM subchannel status word (SCSW) provides an indication to the program that describes the status of the ADM type subchannel and associated EADM operations. In one example, as shown in FIG. 4C, the subchannel status word 404 includes:

subchannel key (key) 420: when the EADM Start function indicator is set in the function control field (described below), this field includes the storage access key used by the channel subsystem. When the start subchannel is executed, these bits are the same as the keys specified in the EADM ORB.

Extended status word format (L) 422: when the status pending indicator of the status control field (described below) is set, this field, when set, indicates that the format-0 ESW has been stored. When an interrupt condition is cleared by the test subchannel, including any of the following indications, the format-0 ESW is stored:

Program inspection

Protection verification

Channel data checking

Channel control verification

Extended Asynchronous Data Mobile Facility (EADMF)

Delay Condition Code (CC) 424: when the EADM Start function indicator is set and the status pending indicator is also set, this field indicates that the subchannel is the general reason for status pending when the test subchannel or the store subchannel is executed. The delay condition code makes sense when a subchannel is state pending in any state combination and only when the start function indicator of the function control field in SCSW is set.

As set, the delay condition code is used to indicate whether a situation is encountered that prevents a subchannel from becoming active when it is initially pending.

Exemplary delay condition codes include:

normal I/O interrupts have been presented.

The status exists in the EADM SCSW, which is generated by the channel subsystem for the case that the EADM Start function is blocked from being successfully started. That is, the subchannel does not transition to the subchannel active state.

CCW format (F) 426: this field is stored as a defined value when the EADM start function indicator is set.

Pre-acquisition (P) 428: this field is stored as a defined value when the EADM start function indicator is set.

Extended control (E) 430: when set, this field indicates that model-dependent information is stored in an EADM Extension Control Word (ECW).

Function Control (FC) 432: the function control field indicates an EADM function indicated at the subchannel. Exemplary functions include:

EADM Start function: when set, indicates that an EADM start function has been requested and is pending or in-progress at a subchannel of an ADM type. When a condition code that is successful for starting a subchannel is set, the EADM start function is indicated in the subchannel. When testing of a subchannel is performed and the subchannel is status pending, the EADM start function is cleared on the subchannel. During execution of the clear subchannel, the EADM start function is also cleared at the subchannel.

EADM clear function: when set, indicates that an EADM clear function has been requested and is pending or in-progress at a subchannel of an ADM type. When a successful condition code is set for clearing the subchannel, the EADM clear function is indicated at the subchannel. When testing of the subchannel is performed and the subchannel is status pending, the EADM clear function indicates clear at the subchannel.

Activity Control (AC) 434: the activity control field indicates the current progress of the EADM function previously accepted at the subchannel.

When testing a subchannel is performed and the subchannel is status pending, all conditions represented by bits in the active control field are reset at a subchannel of the ADM type.

Exemplary activities include:

start pending: when set, indicates that the subchannel is initially pending. The channel subsystem may or may not be in the process of performing an EADM start function. When a successful condition code is set for the start subchannel, the subsystem becomes start pending. When the EADM start function is executed and the channel subsystem determines that a condition preventing acquisition of ARQB exists, the sub-channel remains pending.

When any of the following occurs, the subchannel is no longer initially pending,

the channel subsystem attempts to initiate the first data transfer specified by the AOB.

Clean subchannel is performed.

Test subchannel State conditions at the clear subchannel.

Clearing pending: when set, the subchannel is clear pending. The channel subsystem may or may not be in the process of performing the EADM clearing function. When the specified condition code is set for clearing a subchannel, the subchannel becomes clear pending.

A subchannel is no longer clear pending when any of the following occurs:

The EADM clear function is performed.

Test subchannel clear status pending condition alone.

Active of the subchannel: when set, indicates that a subchannel of the ADM type is subchannel active. A sub-channel of ADM type is said to be sub-channel active when the channel subsystem attempts to initiate the first data transfer or perform the first operation (see which occurs first) specified by the AOB.

A subchannel is no longer active when any of the following occurs:

subchannel change-to-state pending.

The clear subchannel is executed.

State Control (SC) 436: the state control field provides a program with a digest level indication of the interrupt condition described by the information in the subchannel states and device state fields. More than one state control indicator may be set as a result of conditions at the subchannel.

Exemplary state controls include:

and (4) warning state: when set, indicates that an alarm interrupt condition exists. When an alarm condition occurs in the subchannel, an alarm interrupt condition is identified. An alarm state is generated by the channel subsystem under any of the following conditions:

the sub-channel of the ADM type is start pending and the status condition prevents the initiation of the first data transfer.

The subchannel is active and the exception condition reported as subchannel status has terminated the EADM operation.

When a test subchannel or a purge subchannel is executed, the alarm state is purged at the subchannel.

Primary state: when set, indicates that a primary state exists. A primary interrupt condition is identified when a primary state occurs in the subchannel. The primary interrupt condition is a requested interrupt condition that, when accompanied by a secondary interrupt condition, indicates that the EADM start function is complete at the subchannel.

The primary interrupt condition is cleared at the subchannel when either the test subchannel or the clear subchannel is executed.

And (3) secondary state: when set, indicates that a secondary interrupt condition exists. A secondary interrupt condition is identified when a secondary state occurs in the subchannel. A secondary interrupt condition is a requested interrupt condition that, when accompanied by a primary interrupt condition, indicates completion of the EADM start function at the subchannel.

The secondary interrupt condition is cleared at the subchannel when the test subchannel or the clear subchannel is executed.

The state is pending: when set, information is available indicating that the subchannel is status pending and describing the cause of the interrupt condition. When testing a subchannel is performed to store EADM SCSW in the set status pending bit, all EADM SCSW indications are cleared at the subchannel to place the subchannel in an idle state. During execution of the clear subchannel, the state pending condition is also cleared at the subchannel.

When the state is pending, all accesses to the main and storage class memories for the sub-channel ARSB are terminated.

Subchannel state 438: the subchannel state condition of the ADM type is detected by the channel subsystem and stored in the subchannel state field. The subchannel status field is meaningful when the subchannel is status pending. In addition to conditions caused by equipment failures, sub-channel states may be generated only when the channel subsystem is involved in the processing of the EADB functions.

Examples of state conditions include:

program inspection: program verification occurs when a programming error is detected by the channel subsystem.

Protection test: protection checks occur when the channel subsystem attempts to make a memory access that is blocked by the protection mechanism. The protection is adapted to acquire the ARQB, MSB, AIDAW, and data to be transferred to the storage class memory, and to the information storage in the ARSB and data transferred from the storage class memory.

Channel data verification: the lane data check indicates that an incorrect storage error is checked for data fetches from main memory or data stores into main memory.

Channel control test: the channel control check indicates that an incorrect storage error is detected for acquisition or storage of the AOB, MSB or AIDAW, or that the channel subsystem has encountered a machine failure and the failure affects EADM operation.

Extended Asynchronous Data Movement (EADM) facility verification: the EADM facility check indicates that an error was checked by the EADM facility for data transfers to or from storage class memory, or for performing operations on storage class memory.

When a program verify, protection verify, channel data verify, channel control verify, or EADM facility verify condition is identified by the channel subsystem, EADM operation is terminated and the channel becomes state pending, having primary, secondary, and alarm states.

EADM operation Block Address 440: this field indicates the EADM operation block address.

Device status 442: this includes the device side or the channel side.

When the ESW format 422 of the subchannel status word is set and the subchannel is status pending, an EADM subchannel extension status word (EADM ESW) is provided that specifies additional information about the subchannel of the ADM type.

In one example, referring to FIG. 4D, the EADM subchannel expansion status word 450 includes:

EADM subchannel deregistration 452: in one example, EADM subchannel deregistration comprises:

extended Status Flag (ESF): when its bit is one, this field specifies that an error has been detected by the channel subsystem.

Examples of extended status flags include:

Key checking: when set, a Check Block Code (CBC) indicating that the channel subsystem has detected an invalid on the associated storage key when referencing data in the EADM operation block (AOB), EADM Move Specification Block (MSB), or EADM indirect data Address word (AIDAW).

AOB address validity: when set, indicates that the address stored in the AOB address field of SCSW cannot be used for recovery purposes.

The EADM extension report word 454, which includes, for example:

an EADM operation block error indicator, when set, indicating that an exception status stored in the EADM SCSW is associated with a specified EADM operation block (AOB); and the EADM response block store (R) indicator, when set, indicates that the EADM response block (ARSB) is stored.

When the extended control indicator of SCSW and the extended status word format indicator of SCSW are set, the EADM extended control word provides additional information that depends on the nature of the model, which describes the conditions that may exist in the EADM facility.

Further, the following Channel Report Word (CRW) may be reported for a subchannel of ADM type; the parameters of the subchannel installation are initialized; the parameters of the subchannel installation are restored; the subchannel is available; subchannel event information is pending.

Unsolicited events and failures occurring in the EADM facility may be reported by the channel event information pending CRW.

An extended asynchronous data mover facility is described in detail above for moving blocks of data between main storage and storage class memory, and performing other operations on storage class memory. In one embodiment, information about the EADM facilities and storage class memory is obtained using EADM commands. In particular, since storage class memory is not directly accessible, the ability is provided to determine whether storage class memory is allocated and, if so, to obtain information about the configuration. In particular, in one example, the ability is provided to communicate with a control program (e.g., an operating system) whether storage class memory has been allocated and, if so, how much and where. The ability to determine available storage class memory is referred to herein as discovery, and one example of discovery functionality is provided by a Storage Class Memory (SCM) information (SSI) command.

Storage class memory information (SSI) commands are used to obtain information about storage class memory and extended asynchronous data mover facilities. The SSI command returns the following information obtained from, for example, the channel subsystem.

Features of an EADM installation comprising:

maximum count of Move Specification Blocks (MSBs) per AOB.

Maximum block count per MSB.

2. Storage class memory, comprising:

SCM increment size.

A list of SCM address increments within the SCM address space.

Maximum SCM address depending on the model.

The store SCM information command is executed, which is synchronous, without changing any information contained in the channel subsystem.

Further information regarding the SSI command will be described with reference to fig. 5A-5D. Referring first to FIG. 5A, in one embodiment, a command request block 500 for storing an SCM information command includes, for example:

length 502: a value specifying the length of the command request fast.

The command code 504: a value specifying a command code for storing an SCM information command.

Format (FMT) 506: a value specifying the format of the command request block.

Continue token 508: the value of the continuation point recovered from the incomplete previous response may be requested. If the value of the continue token is zero, a new start is made. If the value of the continue token is non-zero and not recognized, a new start is made.

One embodiment of the response block 520 for the SSI command will be described with reference to fig. 5B and includes, for example:

Length 522: a value indicating the byte length of the command response block.

Response code 524: a value describing the result of attempting to execute the SSI command. The response code value specifies the length of the response block. For example, if the selected response code is stored, the length indicates 96+ Nx16 bytes, where N is the number of storage class memory address list entries, as described below. In one example, N is in the range of 1 ≦ N ≦ 248.

Format (FMT) 526: a value indicating the format of the command response block. The value of this field is, for example, zero.

RQ 528: in response to the modifier value, as described below:

there is no responsive modification.

The designated continuation token is not recognized and is treated as if zero had been designated.

Maximum block count per MSB (MBC) 530: a value indicating the maximum value that can be used in the chunk count field of the move specification chunk (MSB).

Maximum SCM Address (MSA) 532: indicating a value of the maximum SCM address that depends on the model. Which is the SCM address of the last byte in the highest addressable SCM increment.

SCM Increment Size (IS) 534: a value representing the size of each SCM increment in the SCM address list and being, for example, a power of 2.

Maximum MSB Count (MMC) 536: a value indicating the maximum count of Move Specification Blocks (MSBs) that can be specified in an EADM operation block (AOB).

Maximum configurable SCM increment (MCI) 538: may be configured to a maximum number of values requesting a configured SCM delta.

In one embodiment, MCI does not exceed 2^(64-IS). For example, for an SCM increment size of 16 Gbytes, MCI ≦ 2^(64-34)Since all 16 gigabytes of SCM increments can be addressed in the addressing constraints of 64-bit addresses. Also, ((MCI +1) × IS) -1 does not exceed the maximum SCM address depending on the model.

The number of SCM increments (NICs) configured reduces the Total Size (TS) that can be specified when a successful configure storage class memory command as described below is executed, such that TS ≦ (MCI-NCI). However, based on the overall capacity of the system and the allocations that have been made to other configurations, the number of SCM increments in the initialization state may or may not be able to fully satisfy the request in order to otherwise effectively configure the MCI bounds to the requested configuration.

Total initialization SCM increment for CPC 540: a value representing a number of SCM increments in an initialization state for a system (e.g., for a Central Processing Complex (CPC)). If the system is logically partitioned, this is the number of total available increments that are/can be allocated by the partition.

Total uninitialized SCM increments for CPC 542: indicating the number of SCM increments in the uninitialized state for the system (e.g., for the CPC).

SCM measurement block size 514: the SCM measures the value of the Block Size (BS) in bytes of the block. In one example, it is a power of 2 and the largest SCM measurement block size is, for example, 4096 bytes.

Maximum number of SCM resource components 546: a value that is the maximum number of SCM resource components (RPs) on the CPC (e.g., I/O adapters). Each SCM delta is associated with an SCM resource component. Each SCM resource (e.g., one or more I/O adapters and one or more SSDs) includes one or more components. The maximum number of SCM resource elements is e.g. 509.

In one example, the term "resource unit" is defined for obtaining measurement information related to storage class memory. Each SCM delta may be assigned to multiple adapters, and each adapter has some usage/measurement data that can be communicated with. Thus, each measurement block returned is identified by the tuple consisting of the delta identifier plus the resource identifier.

SCM data unit size 548: depending on the value of the model, it indicates the number of bytes included in the SCM data unit. In one example, a data unit is defined for obtaining measurement information related to storage class memory. The reported count is a count of data units rather than bytes.

Continue token 550: depending on the value of the model, subsequent issuance of the command by this value SSI may continue at the continuation point represented by the token. The content of the continuation token is model dependent.

Storage class memory address list 552: starting point of SCM address list. When the stored response code is a predetermined value, multiple SCM Address List Entries (SALEs) are stored (e.g., (Length-96)/16 SALEs are stored).

In one example, the number of SALEs stored depends on the number of SCM increments in the requester's configuration, the state of each of them when a command is executed, and the channel subsystem model. Zero or more SALEs are stored, and in one example, the actual number stored is determined by subtracting 96 from the size (length) of the response block and dividing the result by 16.

Each SCM Address List Entry (SALE) represents an SCM increment occupying a range of SCM addresses. The starting SCM address of the SCM increment, represented by the SALE, is contained in the SALE and is the SCM address of the first byte of the corresponding SCM increment. In one example, the end address is calculated by adding the SCM increment size in bytes to the starting SCM address and then subtracting by one. This is the SCM address of the last byte of the SCM increment. In one embodiment, the storage class memory represented by SALE IS a contiguous set of SCM byte locations, starting at a natural 2IS byte boundary.

The SALE is stored when the corresponding SCM delta is in a configuration state and space is available in the response block for the SALE. If space in the SCM address list of the response block is exhausted, a value is stored in the continue token and execution is completed with the particular response code.

Two or more SALEs are stored in their SCM addresses in ascending order.

One embodiment of SALE is described with reference to FIG. 5C. In one embodiment, the SALE552 includes, for example:

SCM Address (SA) 560: the value of the starting SCM address, which IS byte 0 in SCM address space corresponding to the SCM increment, IS aligned on a natural boundary determined by the SCM increment size (2 IS bytes).

Persistence attribute (P) 562: as a value indicating the current persistence rule applicable to the SCM delta. Any location in the SCM delta inherits the persistence rule. Possible persistence rules include:

rule 1-data is retained when power is off.

Rule 2-retain data until power-on reset or IML.

Operational status 564: a value indicating the operating state of the storage class memory increment represented by SALE. The operational state is valid only when the relevant SCM delta is in the configuration state.

Examples of operating states include:

operational (Op): the storage class memory represented by SALE is available for all I/O operations. The operable state is entered upon successful configuration and may be re-entered upon exit from a temporary or permanent error state.

Temporary Error (TE): the storage class memory represented by SALE cannot be used for any I/O operation. The data state is invalid, but the data content in the transition from operational to temporary error is preserved. A temporary error state is entered from the operational state when access to the SCM delta is not present.

Permanent Error (PE) storage class memory, represented by SALE, is not available for any I/O operation. The data state is invalid and data is lost. When an uncorrectable error condition is identified, a permanent error state is entered from either the temporary error state or the operational state.

When operation is complete to set a permanent error indication in the exception identifier code of the EADM response block, at least the corresponding SCM delta has entered a permanent error state. However, more than one SCM increment may enter a permanent error state.

When the SCM delta is not in an operational state, I/O operations referencing a location in the delta to set a temporary or permanent error in an exception identifier code of the EADM response block, identifying an extended asynchronous data mobile facility check.

Data state 566: a value indicating the data state of the contents of the storage class memory increment represented by SALE. The data state is valid when the associated SCM delta is in a configured and operational state.

Exemplary data states include:

the content of the zero-SCM increments is all zero.

The content of the valid-SCM delta is the accumulation of all successful write-type operations. The locations in the increments that are not written remain zeroed or unpredictable.

Unpredictability-the contents of the SCM delta prior to any write type I/O operation are unknown. After one or more write-type operations have been performed, even if the successfully written locations cause the data state of the SCM increment to become valid, the data content of other unwritten locations remains unpredictable.

With the first successful write, a transition occurs from a zeroed or unpredictable to a valid state. Due to any difference between the size of the data written and the size of the target SCM delta, the change to valid does not describe the actual situation of any data location that has not yet been written. Such locations that have not been accessed for writing are still effectively described as zeroed or unpredictable.

Grade 568: a value indicating the conceptual quality of the storage class memory increment represented by SALE. The hierarchy is valid only when the SCM increment is in a configured and operational state. A zero value means no rank. A non-zero value in the specified range indicates that there is a rank. In this example, a rank value of 1 is the highest or best rank. The rank value of 15 is the lowest or worst rank. Otherwise, SCMs with higher ranking are preferred over SCMs with lower ranking.

R570: this field indicates the SCM delta identification release operation. The following behaviors are relevant:

1. the freed block is written before being read, otherwise if the read precedes the write, a read operation error is identified. For such errors, the SCM increment remains in an operational state.

2. Once initially configured, the data state is zeroed.

3. A program may perform a special operation, called a release, which places the specified block in a release condition.

Resource ID 572: the non-zero value is a Resource Identifier (RID) of the resource providing the SCM delta represented by the able. When RID is zero, no resource ID is indicated. In one particular example, the RID represents as many adapters and SSDs that provide storage for SCM increments. The RID may represent a composite entity because specific RAID algorithms may be applied, or performance may be improved by allowing parallel I/O operations across multiple adapters/SSDs to stripe (striping).

Further details regarding the configuration state of the storage class memory, as well as the operation and data state of the storage class memory address list will be described below.

First, with reference to fig. 6A, the configuration states and events/actions that result in transitions within these states are described. As shown, the SCM states are configuration, standby, and reserved. The SCM may be placed on standby by the reservation and then from standby to configuration. From configuration, the SCM may be deconfigured and enter a reserved state.

Referring to FIG. 6B, operational states and events that result in transitions within those states are illustrated. The SCM delta will be in a standby state to be configured and in an operational state after the configuration action is successfully completed. The first write to the SCM increment in the zeroed state moves it to the active state. An intervening power-down and power-up for an SCM increment not indicated as having a rule 1 persistence moves the SCM increment to an unpredictable state.

The error (E) may cause a transition to a Temporary Error (TE) state or a Permanent Error (PE) state, depending on the particular details of the error that depend on the model. The acquisition (a) of the connection may cause a transition from a temporary error state to an operational (Op) state. Deconfiguration of the SCM increment may occur regardless of its operating state.

Fig. 6B also shows the data states when in the operational state depending on how the operational state was entered. When configured and in an operational state, the data state is valid and applied to the corresponding SCM delta. The valid data state is zeroed, unpredictable, and valid. The following are various possible data states upon entry into the operational state:

from Standby-set to zero (z)

From temporary error-effectiveness (v)

From permanent errors-unpredictable (u) or zeroed (v)

From operational-valid (V) -first write

From operational-unpredictable (u) -power cycling and persistence is not rule 1.

When not in the operating state, the data state is invalid.

When configured for the first time and before the first write, the data of the SCM increment is in a zeroed state, meaning that its contents are all zero.

While the data content of the SCM delta is not changed when moved to or in a temporary error state, the delta is inaccessible. Thus, it may be descriptive to say that the data is invalid, but not overly meaningful due to lack of program accessibility. Thus, the data state is invalid in this scenario. Also, based on the error causing the transition from operational to temporary error, if data integrity is affected, a permanent error state is entered, the data state remains invalid, and data is lost. If parallel repair can move the SCM delta from a permanent error state to an operational state without being both deconfigured and subsequently reconfigured, the original data is still lost and the data state is unpredictable or zeroed, depending on the model.

The persistence of the SCM delta and its RAS (reliability, accessibility, and serviceability) features may also determine the change from valid to unpredictable data states. If persistence is exceeded, a transition from a valid to an unpredictable data state may be expected.

With the first successful write, a change from a zeroed or unpredictable data state to a valid data state occurs. The change to valid does not describe the actual situation of any data locations that have not yet been written due to any difference between the written data size and the target SCM delta size. Such locations, between first write accesses, are still effectively described as zeroed or unpredictable.

After the SCM delta is configured, unsolicited notifications are made pending when any one or more events occur that may be observed in the response to store SCM information commands. Examples are as follows:

1. the operational state changes from operational to temporary or permanent errors, but is not reported in failed operations.

2. The operating state changes from temporary error to operational.

3. The operating state changes from a temporary error to a permanent error.

4. The grade changes.

Examples where unsolicited notifications do not become pending include the following:

1. The data state changes from zeroed or unpredictable to valid.

2. And finishing the command of configuring the storage class memory.

3. The deallocate storage class memory command is complete.

When a notification is pending, the program observes the notification and may issue a store SCM information command to obtain the information. The store SCM information command may also be issued at other times at which the program will require information about the SCM and/or SALE.

In one example, the notification includes a machine check interrupt issued to the program with a corresponding CRW indicating the event report. The program issues a CHSC store event information command and retrieves a response block with a content code that signals a storage class memory change notification.

In one embodiment, a Store SCM Information (SSI) command is a channel subsystem command issued by a program (e.g., an operating system) to obtain information about storage class memory and/or SCM address list entries. In one example, a program issues a channel subsystem call instruction, and an SSI command is indicated in the command block of the instruction, which is issued to the channel subsystem. The command is executed at the channel subsystem and the response is returned at the response block, which is the remainder of the 4K byte control block (i.e., the requested information is stored in the main memory area specified for the response block). Further details regarding the operation of this command are described with reference to FIG. 5D.

First, the program generates the request block indicated above to request storage of the SCM information command at step 580. The request block is obtained by the channel subsystem at step 582 and one or more validity checks are made to verify the validity of the request block (e.g., valid length field, valid command request block format, command installed, etc.). If the request is not valid at query 584, a response code indicating the question is placed in the response block at step 586 and the response block is returned at step 592.

However, if the request is valid at INQUIRY 584, the channel subsystem retrieves information from the machine (e.g., processor, etc.) at step 588 and populates the response block at step 590. A response block is returned at step 592. For example, information is contained in non-volatile memory of the machine and, during system initialization, is loaded by firmware into main memory that is only accessible by firmware. The channel subsystem (i.e., firmware in this example) retrieves the information by reading it from main memory that is only accessible by firmware, and fills the response block.

In response to receiving information about storage class memory or not receiving the information, a determination may be made to change the configuration of the storage class memory. This determination may be made manually or automatically by a program or other entity. As described below, the configuration may be changed by adding or deleting deltas.

In one example, to configure storage class memory, a configure storage class memory command is used. The command requests the amount of storage class memory to be configured from the available pool of the system. This amount is specified as a size, encoded as a count of SCM increments.

Unless expressly stated otherwise, the number of SCM increments used to satisfy the request is in an initialized state. If the requested number of SCM increments is such that the maximum configurable SCM increment limit is exceeded, a particular response code is provided.

The content of each increment is zero with a valid CBC. The applicable persistent rules associated with each configured SCM delta are set by, for example, a manual control.

One embodiment of a command request block for a configure storage class memory command is shown in FIG. 7A. In one example, configuring storage class memory request block 700 includes:

length 702: a value indicating the length of the command request block length.

The command code 704: a value indicating a command code for configuring a storage class memory command.

Format (FMT) 706: a value indicating the format of the command request block.

Total Size (TS) 708: a value indicating the size of the requested storage class memory encoded as a count of SCM increments. The count of SMC increments that have been configured plus TS should not exceed the maximum configurable SCM increment (MCI) limit. If the number of SCM increments in the initialization state is less than the specified total size, a specific response code is provided.

Asynchronous Completion Correlator (ACC) 710: the values returned in the asynchronous completion notification field of the notification response are described below. The correlator is used to recover the original thread of the start request.

One embodiment of a command response block for configuring storage class memory commands is depicted in FIG. 7B. In one embodiment, the command response block 730 includes:

length 732: a value indicating the length of the command response block.

Response code 734: a value is described that describes the result of an attempt to execute a configure storage class memory command.

If the defined response code is stored in the response code field, an asynchronous process is initiated to complete the processing of the command. If a response code other than the defined code is stored in the response code field, no SCM delta is configured, no asynchronous process is initiated, and no subsequent notification is made. Completion of the asynchronous process is indicated in the notification response.

Format (FMT) 746: a value indicating the format of the command response block.

A configure storage class memory command is issued by a program to request the amount of storage class memory to be configured into the SCM address space. One embodiment of the logic for configuring an SCM will be described with reference to fig. 7C.

Initially, the program issues a channel subsystem call instruction at step 740, which includes a configure SCM command. At step 742, the request block to configure the SCM command is obtained by the channel subsystem, and the channel subsystem attempts to execute the command at step 744. If attempting to execute the command at inquiry 746 results in a response code that does not indicate success, then the response code is placed in the response block of the configure SCM command at step 748 and the response block is returned at step 750.

If a successful response code is indicated at query 746, the response code is placed in the response block at step 752 and the response block is returned at step 754. In this example, a successful response code indicates that the request fast length field is valid; commands are available in the system; the command request block has a valid format; the channel subsystem can execute commands (i.e., not busy); the total size of the request does not exceed the maximum configurable SCM increment limit of the requested configuration; and the total size of the request does not exceed the number of SCM increments in the initialization state.

In addition, an asynchronous process to complete the configuration is initiated at step 756. Further details regarding this process are described with reference to FIG. 7D.

In one embodiment, the asynchronous processing performs configuration to assign one or more deltas at step 760. For example, for each configured SCM increment, internal controls are changed to allow the newly configured increment to be accessible by I/O move requests to the partition. In particular, in response to the channel subsystem receiving the CHSC configuration command, the channel subsystem's firmware checks the internal table to confirm that there are enough increments to satisfy the request and to ensure that the request does not exceed the maximum configurable SCM increment for configuration. If the request is valid, the firmware updates one or more tables to assign the delta to the configuration and places the delta into an operable state for the configuration. The delta may then be accessed by an I/O move request (as described above) from the configuration. Completion of the asynchronous process is indicated in the notification response at step 762.

Notification response data for the configure storage class memory command is returned in the response block of the Store Event Information (SEI) command. One embodiment of a format for configuring a notification response block for a storage class memory command is described with reference to FIG. 8A.

In one embodiment, configuring the notify response block 800 for storage class memory commands includes:

length 802: a value indicating the length of the command response block.

Response code 804: the value of the result of the attempt to execute the store event information CHSC command is described.

Format (FMT) 806: a value indicating the format of the command response block.

The notification type 808: indicating that this is a value for an EADM related notification.

P810: when set, specifies that the channel subsystem has pending event information in addition to the information provided in response to the CHSC command.

V812: when set, the designated channel subsystem has identified an overflow condition and the event information has been lost.

Content code 814: a value indicating that this is a response to completion of execution of the asynchronous process initiated by the configure storage class memory command request.

Secondary response code 816: values of results of attempting to execute the configure SCM command are further described.

When the secondary response code is a specified value, the full amount of storage class memory, such as the start request, has been allocated. Otherwise, a response code may be provided indicating, for example, an invalid length field, a configuration SCM command is not installed, a configuration SCM command block has an invalid format, the total request size will exceed the MCI limit, the total size of the request exceeds the number of SCM increments in the initialization state, the channel subsystem is busy.

Asynchronous Completion Correlator (ACC) 818: the value initially specified in the corresponding command request block.

One embodiment of a store event information command for returning a notify response block for a configure storage class memory command is described with reference to FIGS. 8B-8C.

The store event information command is used to store event information that has been made pending by the channel subsystem. Typically, the command is executed as a result of a procedure that has received an event information pending channel report.

Execution of the store event information command may change the information contained in the channel subsystem. The store event information command is executed synchronously.

One embodiment of a command request block for a store event information command is described with reference to FIG. 8B. In one example, request block 830 includes:

length 832: this field specifies the length of the command request block.

Command code 834: this field specifies the store event information command.

Format (FMT) 836: a value specifying the format of the command request block.

Notification Type Selection Mask (NTSM) 838: a mask, each bit position of which corresponds to a Logical Processor Selector (LPS) value of the same digital value. In one embodiment, bit 0 is ignored and is assumed to be 1. When a bit position in the specified range starting from 1 is zero, the notification type corresponding to that bit position is not stored in the response block and is discarded if identified as pending. When such a bit is a 1, the notification type corresponding to the bit position may be stored in the response block.

In one embodiment, referring to FIG. 8C, the response block 850 for the store event information command is described as follows:

length 852: a value specifying the initial length of the command response block. The completion length depends on the response code that was stored as a result of attempting to execute the store event information command.

If a response code other than the code indicating success is stored in the response code field, no information is stored in the response data area.

If a response code indicating success is stored in the response code field, event information is stored in the response data area.

Response code 854: a value describing the result of attempting to execute the store event information command.

For the store event information command, the response data area includes a fixed length portion and a variable length portion.

For a specified format response, when NT is non-zero, the format depends on the particular notification type and the format of the field-dependent content code depends on the combination of the particular notification type and the Content Code (CC) field.

Format (FMT) 856 is a value indicating the format of the command response block.

Notification Type (NT) 858: a value indicating the Notification Type (NT). Specific values for configuring SCM commands are provided.

F, a mark 860: when set, the designated channel subsystem has pending event information in addition to the information provided in response to the CHSC command. The program may obtain additional information by executing the store event information command again. When not set, the flag specifies that the channel subsystem does not have additional pending event information.

V-marker 862: when set, the designated channel subsystem has identified an overflow condition and event information has been lost. An overflow condition is identified when event information not contained in the response data area is the most recent pending information. The overflow does not affect the information contained in the response data area.

Content Code (CC) 864: a value describing the type of information contained in the response data area. In one example, the value indicates a storage class memory change notification in which one or more SCM increments have changed status or state.

Content code dependency field 866: this field includes additional information about the event.

Successful notification of a configuration change may cause the program to issue a store SCM information command to obtain details about the configuration.

In addition to increasing storage class memory, storage class memory may also be decreased. The deconfigure storage class memory command requests that the amount of storage class memory be removed from the SCM address space requesting the configuration. The SCM delta to be deconfigured will be in a configuration state.

As described herein, an SCM delta to be deconfigured is specified in the SCM delta request list. One or more consecutive SCM increments may be specified in a SCM Increment Request List Entry (SIRLE). A separate SIRLE may be designated for each list of deltas (also referred to as extents), which is not consecutive with any other delta list.

Regardless of the persistence rule, successful deconfiguration of the SCM increment places the increment in an uninitialized state. When zeroing is complete, the SCM delta transitions from an uninitialized state to an initialized state.

One embodiment of a command request block for a deconfigure storage class memory command is shown in figure 9A. The command request block 900 for deconfiguring storage class memory commands includes, for example:

length 902: a value specifying the length of the command request block. In one embodiment, the length is 32+ (N × 16) bytes, where N is the SCM increment request list item (SIRLE) count. In this example the length is divisible by 16 and is in the range (32+ 1X 16). ltoreq.L 1. ltoreq.32 + 253X 16.

The command code 904: specifying a value for a command code for a deconfigure storage class memory command.

Format (FMT) 906: a value specifying the format of the command request is fast.

Asynchronous Completion Correlator (ACC) 908: the value returned in the asynchronous completion notification as described above.

SCM delta request list 910: this field includes the SCM delta request list (SIRL). The SCM delta request list includes one or more items (SIRLE). The length of the SIRL is determined from the value of the length field.

An SCM delta request list item (SIRLE) specifies the size and location of a specified section of storage class memory (e.g., a delta list). A sector or SCM sector is a specified size of storage class memory.

Referring to fig. 9B, in one example, SIRLE920 includes:

total Size (TS) 922: the size of the storage class memory to be de-configured, encoded as a count of SCM increments, is specified.

Start SCM Address (SA) 924: this value is the SCM address and is the location in SCM address space from which the first or only SCM increment deconfigured by SIRLE is removed. In this example, the lowest bit position that will constitute the offset within the first SCM increment is ignored and assumed to be zero.

When the overall size is greater than 1, each additional SCM increment beyond the first increment is located at an SCM address that is divisible by the SCM increment size, which includes the configured SCM increment, and which is located consecutive to the last byte of the previous SCM increment. In other words, at the next successive position.

If the space described by the combination of the starting location and the total size is not an SCM delta that is completely full of configuration, the specified response code is provided, no SCM delta is configured, no asynchronous process is initiated, and no subsequent notification occurs.

Upon successful completion, each deconfigured SCM increment enters a reserved state and is then zeroed before being placed in a standby state.

The command response block for the deconfigure storage class memory command is shown in figure 9C. In one embodiment, the command response block 950 includes:

length 952: a value indicating the length of the command response block.

Response code 954: the value of the result of attempting to execute the deconfigure storage class memory command is described.

If a response code specifying a value is stored in the response code field, an asynchronous process is initiated to complete the processing of the command. If a response code other than the specified value is stored in the response code field, no SCM delta is deconfigured, no asynchronous process is initiated, and no subsequent notification is made. Completion of the asynchronous process is indicated in the notification response.

Before the synchronous portion of the deconfigure storage class memory command completes with the specified response code, all entries in the SCM delta request list are checked to ensure that all specified SCM deltas are in the configured state.

Format (FMT) 956: a value indicating the format of the command response block. One embodiment of the logic associated with deconfiguring an SCM command is described with reference to FIGS. 9D-9E.

Initially, the program issues a channel subsystem call instruction including a deconfigure SCM command at step 970. The request block to deconfigure the SCM command at step 972 is retrieved by the channel subsystem and the channel subsystem attempts to execute the command at step 974. If attempting to execute the command at query 976 results in a response code that does not indicate success, then the response code is placed in the response block of the deconfigure SCM command at step 978, and the response block is returned at step 980.

If a successful response code is indicated at query 976, then the response code is placed in the response block at step 982 and the response block is returned at step 984. In this example, a successful response code indicates that the length of the request block is valid; commands are available in the system; the command request block has a valid format; the channel subsystem can execute commands (i.e., not busy); and the SCM increment is originally in the configured state.

Further, an asynchronous process is initiated that completes the deconfiguration at step 986. Further details regarding this process will be described with reference to fig. 9E.

In one embodiment, the asynchronous processing performs deconfiguration at step 900. For example, one or more deltas are deallocated. The SCM increment is moved from the configuration state to the reserved state. Once in the reservation state, the zeroing process then occurs, and when complete, the SCM delta transitions to the standby state. Completion of the asynchronous process is indicated in the notification response at step 992.

Notification response data for the deconfigure storage class memory command is returned in the response block of the Store Event Information (SEI) CHSC command. An example of the response block is described with reference to fig. 8A. However, the content code in this example indicates that this is a response to completion of execution of the asynchronous process initiated by the deconfigure storage class memory command request. Similarly, the secondary response code also describes the result of attempting to execute a deconfigure storage class memory command.

In yet another embodiment, allocation and deallocation of storage deltas may be requested via a panel presented to a user. For example, the service element is used to provide a graphical interface through which a user can specify parameters for the system. For storage class memory, a panel called the storage class memory allocation panel allows a user to perform the following operations:

1. Specifying a Maximum Configurable Increment (MCI) for a given configuration;

2. assigning an increment to the configuration;

3. the delta is deallocated from the configuration.

The panel also allows viewing of configuration delta allocation and MCI, as well as the number of deltas in the available, unavailable, and uninitialized pools. When the delta allocation changes due to actions at the SE or when the size of one pool changes, a notification is sent to the configuration.

The facility for managing storage class memory is described in detail above. It provides an abstraction to allow programs to access memory without specific knowledge of the memory. According to one or more aspects of the present invention, the capability is provided to move data between the primary storage and the SCM; to clear or release the SCM; to configure or de-configure an SCM; and to discover the configuration of the SCM. Other capabilities are also provided.

In one embodiment, storage class memory is presented to user-level programs as flat memory space, independent of its physical implementation across multiple devices and I/O adapters.

Details about channel subsystems and/or ADM facilities are described in the following documents: U.S. Pat. No. 5377337 entitled "Method and means for improving Virtual Addressing Control By Software Users Over AHardware Page Transfer Control Entity", issued 27.12.1994, By Antongini et al; U.S. Ser. No. 544802 entitled "Asynchronous Co-Process data Mover Method and Means" by Brent et al, published 8, 15, 1995; and U.S. Pat. No. 5526484 entitled "Method and System for the Processing of channel Command Words", issued 11.6.1996.

In addition, further information about the channel subsystem and instructions associated therewith (forSpecific implementations of) are provided as follows:

input/output (I/O)

The terms "input" and "output" are used to describe data transfers between an I/O device and main memory. Operations involving this type of transfer are referred to as I/O operations. The facilities used to control I/O operations are collectively referred to as the channel subsystem. (I/O devices and their control units attached to the channel subsystem.)

Channel subsystem

The channel subsystem directs the flow of information between the I/O devices and main memory. It relieves the CPU of the task of communicating directly with the I/O device and allows data processing to proceed in parallel with I/O processing. The channel subsystem uses one or more channel paths as communication links to manage the flow of information to and from the I/O devices. As part of the I/O processing, the channel subsystem also performs path management operations by testing channel path availability, selecting an available channel path, and initiating I/O operations performed by the device.

Within the channel subsystem are subchannels. One subchannel is provided and dedicated to each I/O device accessible to the program through the channel subsystem.

Multiple sub-channel group facilities are optional facilities. When installed, the subchannel is partitioned into a plurality of subchannel groups, and each subchannel group may provide a dedicated subchannel to an I/O device. Depending on the model and interface used, some I/O devices may only be allowed to be accessed via a particular subchannel set.

Each subchannel provides information regarding the associated I/O device and its connection to the channel subsystem. The subchannel also provides information regarding I/O operations and other functions involving the associated I/O device. A subchannel is the means by which the channel subsystem provides information about the associated I/O device to the CPU, which obtains the information by executing I/O instructions. The actual number of subchannels provided depends on the model and configuration; the maximum addressability in each subchannel set is 0-65535.

The I/O devices are attached to the channel subsystem by the control unit via the channel path. The control unit may be attached to the channel subsystem through more than one channel path, and the I/O device may be attached to more than one control unit. In summary, a single I/O device may be accessed by the channel subsystem via a subchannel through up to 8 different channel paths, depending on the model and configuration. The total number of channel paths provided by the channel subsystem depends on the model and configuration; the maximum addressability is 0-255.

The performance of a channel subsystem depends on its use and the system model in which it is implemented. Channel paths are provided with different data transfer capabilities and I/O devices (e.g., tape units or disk storage) designed to transfer data only at a particular rate may operate on a channel path that can allow at least that data rate.

The channel subsystem contains the common facilities for control of I/O operations. When these facilities are provided in the form of separate autonomous devices specifically designed to control I/O devices, the I/O operations completely overlap with the activities in the CPU. The only main memory cycles required by the channel subsystem during an I/O operation are those required to transfer data and control information to or from a final location in main memory, as well as those required to access the subchannel by the channel subsystem when the subchannel is implemented as part of main memory that is not addressable. These loops do not delay the CPU program except when the CPU and channel subsystem simultaneously attempt to reference the same main memory area.

Sub-channel group

When multiple subchannel-group facilities are installed, the subchannels are partitioned into multiple subchannel groups. There may be up to 4 subchannel groups, each identified by a subchannel group identifier (SSID). When multiple subchannel-set facilities are not installed, there is only one subchannel set, which has an SSID of zero. When multiple subchannel set facilities are not enabled, only subchannel set zeros are visible to the program.

Sub-channel

The subchannel provides the logical appearance of the device to the program and contains the information needed to maintain a single I/O operation. The subchannel is comprised of internal storage containing information in the form of channel-program designations, channel-path identifiers, device numbers, counts, status indications, and I/O interrupt subclass code, as well as information regarding path availability and functions pending or being performed. I/O operations are initiated for a device by executing I/O instructions that specify a subchannel associated with the device.

Each device is accessible through one subchannel in each channel subsystem to which it is assigned during configuration at installation. The device may be a physically identifiable unit or may be placed inside the control unit. For example, in a particular disk storage device, each actuator used to retrieve data is considered a device. In all cases, from the point of view of the channel subsystem, the device is an entity uniquely associated with a subchannel, and is responsive to selection by the channel subsystem through use of a communication protocol defined for the type of channel path through which the device is accessible.

On some models, subchannels are provided in blocks. On these models, more subchannels can be provided than additional devices. The subchannel that is provisioned, but does not have a device assigned to it, is used by the channel subsystem to perform any function, and is indicated by storing the associated device number valid bit as a zero in the subchannel information block of the subchannel.

The number of subchannels provided by the channel subsystem is independent of the number of channel paths provided to the associated device. For example, devices that can be accessed through an alternate channel path are still represented by a single subchannel. When the subchannel-set facility is installed, each subchannel is addressed using a 16-bit binary subchannel number and a two-bit SSID.

After I/O processing at the SUBCHANNEL has been requested by the execution of START SUBCHANNEL, the CPU is freed up for other work, and the channel subsystem assembles or unpacks the data and synchronizes the transfer of data bytes between the I/O device and main memory. To accomplish this, the channel subsystem maintains and updates addresses, as well as counts that describe the destination or source of the data in main memory. Similarly, when an I/O device provides a signal that should be brought to the attention of a program, the channel subsystem translates the signal into state information and stores the information in the subchannel, where it can be retrieved by the program.

Attachment of input/output devices

Channel path

The channel subsystem communicates with the I/O devices over a channel path between the channel subsystem and the control unit. The control unit may be accessible to the channel subsystem via more than one channel path. Similarly, I/O devices may be accessed by the channel subsystem through more than one control unit, each having one or more channel paths to the channel subsystem.

Devices attached to the channel subsystem through multiple channel paths configured to the sub-channels may be accessed by the channel subsystem using any available channel path. Similarly, a device having a dynamic reconnect feature and operating in a multipath mode may be initialized to operate such that when the logic reconnects to the channel subsystem to continue the chain of I/O operations, the device may select any available channel paths configured to the subchannel.

The channel subsystem may include more than one type of channel path. Examples of the types of channel paths used by the channel subsystem are ESCON I/O interfaces, FICON converted I/O interfaces, and IBM System/360 and System/370I/O interfaces. The term "serial I/O interface" is used to refer to ESCON I/O interfaces, FICON converted I/O interfaces. The term "parallel I/O interface" is used to refer to the IBM System/360 and System/370I/O interfaces.

The ESCON I/O Interface is described in System library, IBM Enterprise Systems Architecture/390ESCON I/O Interface, SA 22-7202.

The FICON I/O interface is described in the ANSI Standard document Fibre Channel-Single-ByteCommand Code Sets-2 (FC-SB-2).

IBM System/360and System/370I/O Interface systems libraries are described in IBM System/360and System/370I/O Interface Channel to Control Unit OEMI, GA 22-6974.

Depending on the type of channel path, the facilities provided by the channel path, and the I/O devices, I/O operations may occur in one of three modes: frame multiplexing mode, burst mode, and byte multiplexing mode.

In frame multiplexing mode, the I/O device may remain logically connected to the channel path during execution of the channel program. The facilities of a channel path capable of operating in frame multiplexing mode may be shared by several I/O devices operating in parallel. In this mode, information needed to complete an I/O operation is divided into frames that may be interleaved with frames from I/O operations for other I/O devices. During this time, multiple I/O devices are considered to be logically connected to the channel path.

In burst mode, an I/O device monopolizes a channel path and remains logically connected to the channel path for transfer of a burst of information. During the time that the burst is transmitted, no devices can communicate on the channel path. The burst may consist of several bytes, an entire block of data, a sequence of blocks with associated control and status information (the block length may be zero), or status information for exclusive channel paths. The facilities of the channel path that can operate in burst mode may be shared by several I/O devices operating in parallel.

Some channel paths may tolerate data transfer misses of about half a minute during burst mode operation, such as occurs when a long gap on a tape is read. When the data transfer loss exceeds a predetermined limit, a device failure may be indicated.

In byte-multiplexing mode, the I/O device may remain logically connected to the channel path only for a short interval of time. The facilities of a channel path capable of operating in byte multiplexing mode may be shared by several I/O devices operating in parallel. In this mode, all I/O operations are divided into short time intervals during which only one piece of information is transferred over the channel path. During such an interval, only one device and its associated sub-channel are logically connected to the channel path. Intervals associated with parallel operation of multiple I/O devices are ordered in response to a demand from the devices. The channel subsystem facilities associated with the subchannel exercise their control for any one operation only for the time required to transfer the information segment. A segment may consist of a single byte of data, a number of bytes of data, a status report from the device, or a control sequence for initiating a new operation.

Typically, devices with high data transfer rate requirements operate using a channel path in frame multiplexing mode, slower devices operate in burst mode, and the slowest device operates in byte multiplexing mode. Some control units have manual switches for setting the desired operating mode.

I/O operations that occur on a channel path of the parallel I/O interface type may occur in burst mode or byte-multiplexed mode, depending on the facilities provided by the channel path and the I/O devices. For improved performance, some channel paths and control units may be provided with facilities for high speed transmission and data streaming. A description of these two facilities is obtained with reference to the System library, public IBM System/360and System/370I/O interface channel to Control Unit OEMI, GA 22-6974.

I/O operations occurring on a serial I/O interface type channel path may occur in either frame multiplexing mode or burst mode. For improved performance, some control units attached to the serial I/O interface provide the ability to provide sense data (sense data) to the program in parallel with the presentation unit verify status, if allowed to do so by the program.

Access to the device through the sub-channels may be limited to a single channel path type, depending on the control unit or channel subsystem.

The above modes and features only affect the protocol and transmission rate for transmitting information on the path of the channel. The CPU or channel programs do not observe an impact on the way these programs are executed.

Control unit

The control unit provides the logical capabilities needed to operate and control the I/O devices and adapts the characteristics of each device so that it can respond to the standard form of control provided by the channel subsystem.

Communication between the control unit and the channel subsystem occurs over the channel path. The control unit receives control signals from the channel subsystem, controls the timing of data transfers across the channel path, and provides indications of the status of the device.

The I/O device attached to the control unit may be designed to perform only certain limited operations, or it may perform many different operations. Typical operations move the recording medium and record data. To accomplish its operation, the device requires a detailed signal sequence specific to its device type. The control unit decodes commands received from the channel subsystem, interprets them as intended for a particular type of device, and provides the sequence of signals required to perform the operation.

The control unit may be located separately or it may be physically and logically integrated with the I/O devices, channel subsystem, or CPU. In the case of most mechatronic devices, a well-defined interface exists between the device and the control unit due to differences in the types of devices required by the control unit and the device. These mechatronic devices are typically of the type in which only one device of a group attached to a control unit is required to transfer data (e.g., tape cells or disk access devices) at a time, and the control unit is shared among several I/O devices. On the other hand, in some electronic I/O devices, such as channel-to-channel adapters, the control unit does not have its own identity.

From a programmer's perspective, most of the functions performed by the control unit may be combined with those performed by the I/O devices. Thus, generally, no particular reference to control unit functionality is made in this specification; the execution of I/O operations is described as if the I/O devices were communicating directly with the channel subsystem. The control unit is only referenced when emphasizing the functions performed by the control unit or describing how sharing the control unit among several devices may affect the performance of I/O operations.

I/O device

Input/output (I/O) devices provide a means of communication between external memory, data processing systems, or between systems and their environment. I/O devices include devices such as tape units, direct access storage devices (e.g., disks), display units, typewriter-keyboard devices, printers, remote processing devices, and sensor-based devices. The I/O device may be a physically separate device or it may share devices with other I/O devices.

Most types of I/O devices, such as printers or tape devices, use external media and these devices are physically distinguishable and identifiable. Other types are completely electronic and do not directly handle physical recording media. For example, a channel-to-channel adapter provides data transfer between two channel paths, and the data never reaches a physical recording medium outside of the main memory. Similarly, the communications controller may handle the transmission of information between the data processing system and the remote station, and its inputs and outputs are signals on the transmission line.

In the simplest case, the I/O devices are attached to a control unit and can be accessed from a channel path. The switching device may be used to make some devices accessible from two or more channel paths by switching the device between control units and by switching the control units between channel paths. Such switching devices provide multiple paths through which I/O devices may be accessed. Multiple channel paths to the I/O devices are provided to improve performance or I/O availability or both within the system. The management of multiple channel paths to a device is under the control of the channel subsystem and the device, but the channel paths may be indirectly controlled by the program.

I/O addressing

4 different types of I/O addressing are provided by the channel subsystem for the necessary addressing of the various components: a channel path identifier, a subchannel number, a device number, and although not visible to the program, an address that depends on the channel path type. When a multi-subchannel-set facility is installed, a subchannel-set identifier (SSID) is also used in the I/O addressing.

Subchannel group identifier

A Subchannel Set Identifier (SSID) is a two-bit value assigned to each provisioned subchannel set.

Channel path identifier

The channel path identifier (CHPID) is a system-unique 8-bit value assigned to each installed channel path of the system. The CHPID is used to address the channel path. The CHPID is specified by the second operand address of RESETCHANNEL PATH (reset channel path) and is used to specify the channel path to be reset. When a STORE SUBCHANNEL is executed, the channel path via which a device can be accessed is identified in a channel information block (SCHIB), each device being identified by its associated CHPID. The CHPID can also be used in operator messages when it is desired to identify a particular channel path. The system model may provide up to 256 channel paths. The maximum number of channel paths and the assignment of CHPIDs to channel paths depends on the system model.

Subchannel number

The subchannel number is a 16-bit value unique to the system used to address the subchannel. This value is unique within the subchannel set of the channel subsystem. The subchannel is addressed by 8I/O instructions: canncelsubchannel, CLEAR SUBCHANNEL, HALT SUBCHANNEL, MODIFY SUBCHANNEL, RESUME SUBCHANNEL, start SUBCHANNEL, STORE SUBCHANNEL, and TEST SUBCHANNEL. All I/O functions with respect to a particular I/O device are specified by the program by specifying the subchannel assigned to the I/O device. The subchannels in each subchannel group are always assigned subchannel numbers within a single range of consecutive numbers. The lowest numbered subchannel is subchannel 0. The highest numbered subchannel of the channel subsystem has a subchannel number equal to 1 less than the number of provided subchannels. Up to 65536 subchannels may be provided in each subchannel group. Typically, the subchannel numbers are used only for communication between the CPU program and the channel subsystem.

Equipment number

Each subchannel having an I/O device assigned thereto also contains a parameter called the device number. The device number is a 16-bit value that is assigned as one of the parameters of the subchannel when the device is assigned to the subchannel. The device number uniquely identifies the device to the program.

The device number provides a means of identifying the device regardless of any restrictions imposed by the system model, configuration, or channel path protocol. The device number is used in communications that occur between the system and the system operator with respect to the device. For example, the device number is entered by the system operator to specify the input device to be used for initial program loading.

Description of the programming: the device number is assigned at device installation time and may have any value. However, the user must comply with any restrictions on the assignment of device numbers, which may be required by the control program, the support program, or a particular control unit or I/O device.

Device identifier

The device identifier is an address used by the channel subsystem to communicate with the I/O device, which is not apparent to the program (ap parent). The type of device identifier used depends on the particular channel path type and protocol provided. Each subchannel contains one or more device identifiers.

For a channel path of the parallel I/O interface type, the device identifier is called the device address and consists of an 8-bit value. For the ESCON I/O interface, the device identifier consists of a 4-bit control unit address and an 8-bit device address. For FICON I/O interfaces, the device identifier consists of an 8-bit control unit image ID and an 8-bit device address. For FICON-converted I/O interfaces, the device identifier consists of a 4-bit control unit address and an 8-bit device address.

The device address identifies the particular I/O device (and control unit on the parallel IO interface) associated with the subchannel. The device address may identify, for example, a particular tape drive, disk access device, or transmission line. Any number in the range 0-255 may be assigned as a device address.

Fibre channel expansion

The fibre channel expansion (FCX) facility is an optional facility that provides for the formation of channel programs consisting of Transport Control Words (TCWs) that specify Transport Command Control Blocks (TCCBs) and Transport Status Blocks (TSBs). The TCCB includes a Transport Command Area (TCA) containing a list of up to 30I/O commands in the form of Device Command Words (DCWs). The TCW and its TCCB may specify a read or write operation. In addition to the IRB, the TSB contains completion status and other information associated with the TCW channel program.

The FCX facility provides the ability to specify, directly or indirectly, any or all of the TCCB, the input data storage area, and the output data storage area. When a storage region is directly specified, the TCW specifies the location of a single, contiguous block of storage. When a memory region is indirectly designated, the TCW specifies the location of one or more lists of Transfer Indirect Data Address Words (TIDAWs). The list of TIDAWs and the storage area specified by each TIDAW in the list are bounded across a 4K byte boundary.

The FCX facility also provides an inquiry operation, which may be initiated by a cancel subchannel (CANCELLSUBCHANNEL) instruction to determine the status of the I/O operation.

I/O command word

The I/O command word specifies a command and contains information related to the command. When the FCX facility has been installed, there are two basic forms of I/O command words, which are Channel Command Words (CCWs) and Device Command Words (DCWs).

The CCW is 8 bytes in length and specifies the command to be executed. For commands that initiate a particular operation, the CCW also specifies the memory region associated with the operation, the count of data bytes, the actions to be taken when the command is completed, and other options. All I/O devices identify the CCWs.

The DCW is 8 bytes in length and specifies the command to be executed, the count of data bytes, and other options. I/O devices that support FCX identify DCWs.

Transmission Command Word (TCW)

The TCW specifies a Transport Command Control Block (TCCB) which contains a list of commands to be transferred to and executed by the I/O device. The TCW also specifies a storage area for commands in the TCCB, and a Transport Status Block (TSB) containing the status of the I/O operations.

Channel program organization

When the FCX facility is not installed, there is a single form of channel program, which is a CCW channel program. When the FCX facility has been installed, there is an additional form of channel program, which is a TCW channel program. Both forms of channel programming are described below.

CCW channel program

A channel program consisting of one or more CCWs is referred to as a CCW Channel Program (CCP). Such channel programs contain one or more CCWs that are logically connected and arranged for sequential execution by the channel subsystem.

TCW channel program

A channel program consisting of a single TCW is referred to as a TCW channel program. The TCW specifies a Transport Command Control Block (TCCB) which contains 1 to 30 DCWs. DCWs within the TCCB are logically connected and arranged for sequential execution. For DCWs that specify control information, the TCCB also contains control information for these commands. The TCW also specifies one or more storage areas for DCWs that specify data transfers from or to the device, and the location of a Transport Status Block (TSB) for completion status. The TCCB and the storage area for data transfer may be designated as continuous or discontinuous storage.

The TCW also specifies the TSB for completion status.

Execution of I/O operations

I/O operations are initiated and controlled by information having 4 types of formats: instruction STARTSUBCHANNEL, transfer command word, I/O command word, and sequence. The STARTSUBCHANNEL instruction is executed by the CPU and is part of a CPU program that oversees the flow of requests for I/O operations from other programs that manage or process I/O data.

When START SUBCHANNEL is executed, the parameters are passed to the target SUBCHANNEL, requesting that the channel subsystem perform the START function with the I/O device associated with the SUBCHANNEL. The channel subsystem performs the start function by using information at the subchannel, including information passed during execution of the startchannel instruction, to find an accessible channel path to the device. Once a device has been selected, the execution of I/O operations is accomplished by the decoding and execution of a CCW by the channel subsystem and the I/O device for a CCW channel program, or by the transmission of a TCCB by the channel subsystem to the I/O device and the decoding and execution of a DCW by the device for a TCW channel program. The I/O command words and the transport command words are fetched from the main memory, although the modifier bits in the command code of the CCWDCW may specify the device-dependent conditions for the performance of the operation at the device.

Device-specific operations, such as rewinding tape or placing an access mechanism on a disk drive, are specified by commands that are decoded and executed by the I/O device. The commands may be passed into the device as modifier bits in the command code of the control command, transmitted to the device as data during a control or write operation, or made available to the device by other means.

Start function initiation

The CPU program initiates an I/O operation by instructing START SUBCHANNEL. The instruction passes the contents of the Operation Request Block (ORB) to the subchannel. If the ORB specifies a CCW channel program, the contents of the ORB include the subchannel key, the address of the first CCW to be executed, and a specification of the format of the CCW. The CCW specifies the commands to be executed and the memory region (if any) to be used. If the ORB specifies a TCW channel program, the contents of the ORB include the subchannel key and the address of the TCW to be executed. The TCW specifies a TCCB that contains the commands to be transmitted to the device for execution, one or more storage areas (if any) to be used for data transfer, and a TSB that contains the status of the I/O operation.

When the ORB contents have been passed to the SUBCHANNEL, execution of START SUBCHANNEL completes. The result of the instruction execution is indicated by the condition code set in the program status word.

When the facility becomes available and the ORB specifies a CCW channel program, the channel subsystem fetches the first CCW and decodes it according to the format bits specified in the ORB. If the format bit is zero, format 0CCW is specified. If the format bit is 1, a format 1CCW is specified. Format 0 and format 1 CCWs contain the same information, but the fields are arranged differently in format 1 CCWs so that a 31-bit address can be directly specified in the CCW. When a facility becomes available and the ORB specifies a TCW channel program, the channel subsystem acquires the specified TCW and transmits the specified TCCB to the device. The memory region designated by the TCW for transferring data to or from the device is a 64-bit address.

Subchannel mode of operation

There are two subchannel modes of operation. When the FCX facility is installed and the START function is set at the SUBCHANNEL as a result of execution of the START SUBCHANNEL instruction that specifies the TCW channel program, the SUBCHANNEL enters transmission mode. The subchannel remains in the transmission mode until the start function is reset at the subchannel. At all other times, the subchannel is in command mode.

Path management

If the ORB specifies a CCW channel program and the first CCW passes a specific validation test and does not have a halt flag specified as 1, or if the ORB specifies a TCW channel program and the specified TCW passes a specific validation test, the channel subsystem attempts device selection by selecting a channel path from an alternate set of channel paths. The control unit that recognizes the device identifier logically connects itself to the channel path and responds to its selection.

If the ORB specifies a CCW channel program, the channel subsystem sends the command code portion of the CCW over the channel path, and the device responds with status bytes indicating whether the command can be executed. The control unit may be logically disconnected from the channel path at this point, or it may remain connected to initiate the data transfer.

If the ORB specifies a TCW channel program, the channel subsystem uses the information in the specified TCW to transfer the TCCB to the control unit. The contents of the TCCB are ignored by the channel subsystem and are only meaningful to the control unit and I/O devices.

If no attempted selection occurs as a result of a busy indication or channel inoperability condition, the channel subsystem attempts to select a device over an alternate channel path (if available). When a selection has been attempted on all of the alternative paths and the busy condition persists, the operation remains pending until the channel is free. If a channel inoperability condition is detected on one or more paths that the device selection is attempted, the program is alerted by a subsequent I/O interruption. I/O interrupts occur at the execution of the channel program (assuming the device is selected on an alternate channel path) or as a result of execution being aborted as detected on all channel paths for which device selection was attempted because of a path inoperability condition.

Channel program execution

If a command is initiated on the device and command execution does not require any data to be transferred to or from the device, the device may signal the end of the operation immediately upon receipt of the command code. In operations involving data transfer, a subchannel is established so that the channel subsystem will respond to service requests from the device and take further control of the operation.

I/O operations may involve data transfers to or from one storage region specified by a single CCW or TCW, or to or from several discrete storage regions. In the latter case, typically a list of CCWs is used for the execution of I/O operations, each CCW specifying a contiguous storage area and the CCWs being coupled by a data link (charging). The data link is specified by a flag in the CCW and causes the channel subsystem to fetch another CCW once the storage area specified by the current CCW is exhausted or filled. The storage area specified by the CCW fetched on the data link belongs to an I/O operation already in progress at the I/O device and the I/O device is not notified when a new CCW is fetched.

Provisions are provided in the CCW format to allow the programmer to specify that the channel subsystem requests I/O interrupts as soon as possible when the CCW is decoded, thereby informing the CPU program that the link has advanced at least as far as the CCW has advanced at the channel program.

To supplement dynamic address translation in the CPU, CCW indirect data addressing and modified CCW indirect data addressing are provided.

When the ORB indicates that a CCW channel program and CCW indirection is used, a flag in the CCW specifies that the indirection data address list is used to specify the storage area for the CCW. Each time the boundary of a memory block is reached, the list is referenced to determine the next memory block to be used. The ORB specifies whether the size of each memory block is 2 kbytes or 4 kbytes.

When the ORB specifies a CCW channel program and modified CCW indirection is used, a flag in the ORB and a flag in the CCW indicate that the modified indirection data address list is to be used to specify a storage area for the CCW. Each time the byte count specified for a memory block is reached, the list is referenced to determine the next memory block to be used. Unlike when indirect data addressing is used, blocks can be specified on any boundary and can be up to 4K in length, assuming that data transfers across a 4K byte boundary are unspecified.

When the ORB specifies a TCW channel program and transport indirection data addressing is used, a flag in the TCW indicates whether the transport indirection list of data addresses is used to specify a storage area containing the TCCB and whether the transport indirection list of data addresses is used to specify a data storage area associated with a DCW in the TCCB. Each time the count of bytes specified for a memory block is reached, the corresponding transfer indirection data address list is referenced to determine the next memory block to be used.

CCW indirect data addressing and modified CCW indirect data addressing allow substantially the same sequence of CCWs to be used for programs running with dynamic address translation active in the CPU as would be used if the CPU were running with equivalent continuous real storage. CCW indirect data addressing allows programs to specify data blocks having up to 2⁶⁴-an absolute memory address of 1, regardless of whether format 0 or format 1CCW is specified in the ORB. Modified CCW indirect data addressing allows programs to specify data blocks having up to 2⁶⁴-an absolute memory address of 1, regardless of whether format 0 or format 1CCW is specified in the ORB.

In general, the execution of an I/O operation or chain of operations involves participation at up to 3 levels:

1. in addition to effects due to the integration of the CPU and channel subsystem, the CPU is busy during the execution of STARTSUBCHANNEL, which continues until the addressed subchannel has been passed the ORB contents.

2. For a new START SUBCHANNEL, the SUBCHANNEL is busy from the time the ORB contents are received until the primary interrupt condition is cleared at the SUBCHANNEL.

3. The I/O device is busy since the first operation is initiated at the device until the subchannel becomes suspended or a secondary interrupt condition is placed at the subchannel. In the case of a suspended subchannel, the device becomes busy again when execution of the suspended channel program resumes.

I/O operation termination

The end of an I/O operation is generally indicated by two state conditions: a channel side and a device side. The channel-side condition indicates that the I/O device has received or provided all of the data associated with the operation and that the channel subsystem facility is no longer needed. This condition is referred to as a primary interrupt condition, and in this case the channel side is the primary state. In general, a primary interrupt condition is any interrupt condition that involves an I/O operation and signals the end of the I/O operation or subchannel of the chain of I/O operations at all.

The device side signal indicates that the I/O device has finished executing and is ready to perform another operation. This condition is referred to as a secondary interrupt condition, and the device end in this case is in the secondary state. Typically a secondary interrupt condition is any interrupt condition that involves an I/O operation and signals the end at the device of the I/O operation or chain of operations. The secondary interrupt condition may occur in parallel with or later than the primary interrupt condition.

In parallel with the initial or secondary interrupt condition, both the channel subsystem and/or the I/O device may provide an indication of an unusual condition.

The condition signaling the end of the I/O operation may be brought to the attention of the program by an I/O interrupt, or by a programming inquiry of the channel subsystem when the CPU is disabled for an I/O interrupt. In the former case, these conditions result in the storage of I/O interrupt code, which contains information about the interrupt source. In the latter case, the interrupt code is stored as a result of testing the execution of the pending interrupt (TESTPENDING INTERRUPTION).

When a primary interrupt condition is identified, the channel subsystem attempts to notify the program by way of an interrupt request that the subchannel contain information describing the end of the I/O operation at the subchannel. For command mode interrupts, this information identifies the last CCW used, and may provide its remaining byte count, thus describing the section of main memory used. For a transport mode interrupt, this information identifies the current TCW and the TSB associated with the channel program, which contains additional state regarding the I/O operation, such as the remaining byte count. In addition to information about the channel program, both the channel subsystem and the I/O devices may provide additional indications of unusual conditions as part of an initial or secondary interrupt condition. The information contained at the SUBCHANNEL may be stored by execution of a TEST SUBCHANNEL (TEST SUBCHANNEL) or execution of a STORE SUBCHANNEL (STORE SUBCHANNEL). When stored, this information is referred to as a subchannel status word (SCSW).

Linking when using CCW channel programs

When the ORB specifies a CCW channel program, facilities are provided to enable the program to initiate execution of the chain of I/O operations using a single START SUBCHANNEL instruction. When the current CCW specifies a command link and no unusual condition is detected during execution, receipt of a device-side signal causes the channel subsystem to acquire a new CCW. If the CCW passes a particular validation test and the pause tag is not specified as a 1 in the new CCW, execution of the new command is initiated at the device. If the CCW fails the validity test, the new command is not initiated, the command chain is halted, and the state associated with the new CCW causes an interrupt condition to be generated. If the pause flag is specified as 1 and this value is valid due to the 1 value in the pause control (bit 4 of word 1 of the associated ORB), execution of the new command is not initiated and the command chain is ended.

Execution of the new command is initiated by the channel subsystem in the same manner as the previous operation. An end signal, which occurs at the end of an operation caused by the CCW specifying the command chain, is made unavailable to the program, and the channel subsystem continues execution of the channel program when another I/O operation is initiated by the command chain. But if an unusual condition has been detected, the command chain is suppressed, the channel program is terminated, an interrupt condition is generated, and an end signal causing the termination is made available to the program.

The suspend and resume functions provide the program with control over the execution of the channel program. The initiation of the pause function is controlled by the setting of the pause control bit in the ORB. When the pause control bit in the ORB is 1 and the pause flag in the first CCW or in the CCW fetched during the command chain is 1, the pause function is signaled to the channel subsystem during execution of the channel program.

A pause occurs when the channel subsystem fetches a CCW with a pause flag effectively specified as 1 (due to the 1 value of the pause control bit in the ORB). Commands in the CCW are not issued to I/O devices and the devices are signaled that the command chain is finished. A subsequent RESUMESUBCHANNEL instruction notifies the channel subsystem that the CCW that generated the pause may have been modified, and that the channel subsystem must reacquire the CCW and check the current setting of the pause flag. If the halt flag is found to be zero in the CCW, the channel subsystem resumes execution of the command chain for the I/O device.

Chaining when using TCW channel programs

When the ORB specifies a TCW channel program, facilities are also provided for the program to initiate execution of the device chain of operations using a single START SUBCHANNEL instruction. Command chaining may be specified for those DCWs specified by a single TCW. When the current DCW specifies a command chain and no unusual condition is detected during operation, successful execution of the DCW is identified such that the next DCW in the current TCCB is processed.

If the next DCW passes a particular validity test, execution of the new command is initiated at the device and the DCW becomes the current DCW. If the DCW fails the validity test, the new command is not initiated, the command link is suppressed, the channel program is terminated, and a status-causing interrupt condition associated with the new DCW is generated.

The execution of the new command is initiated in the same way as the previous operation. So that an end signal occurring at the end of an operation caused by a DCW other than the last designated DCW is not available to the program. Execution of the channel program continues when another I/O operation is initiated by the command chain. However, if an unusual condition is detected, the command chain is suppressed, the channel program is terminated, an interrupt condition is generated, and a state is made available to the program identifying the unusual condition.

Early termination of I/O operations

Channel program execution may be terminated prematurely by CANCEL SUBCHANNEL, HALT SUBCHANNEL, or CLEAR SUBCHANNEL. If the channel program is not initiated at the device, execution of the CANCEL SUBCHANNEL causes the channel subsystem to terminate the start function at the SUBCHANNEL. When the start function is terminated by execution of the CANCEL SUBCHANNEL, the channel subsystem sets condition code 0 in response to the CANCEL SUBCHANNEL instruction. Execution of halt channel causes the channel subsystem to issue a halt signal to the I/O device and to terminate channel program execution at the subchannel. When the execution of the channel program is terminated by the execution of the HALT SUBCHANNEL, the program is notified of the termination by way of an I/O interrupt request. When the subchannel is in the command mode, an interrupt request is generated when the device assumes a state for interrupted operation. When the subchannel is in transmission mode, an interrupt request is immediately generated. If, however, a pause signal is issued to the device during the command chaining period received at the device but before the next command is transmitted to the device, an interrupt request is generated after the device is signaled. In the latter case, the device status field of SCSW will contain zero. Execution of the CLEAR SUBCHANNEL CLEARs the executing channel program's indication from the SUBCHANNEL, causes the channel subsystem to issue a CLEAR signal to the I/O device, and causes the channel subsystem to generate an I/O interrupt request to notify the program of the completion of the CLEAR function.

I/O interrupts

The conditions that cause an I/O interrupt request are asynchronous to the activity in the CPU and more than one condition may occur simultaneously. The condition is retained in the SUBCHANNEL until cleared by the TEST SUBCHANNEL or CLEAR SUBCHANNEL, or reset by the I/O system.

When an I/O interruption condition has been identified by the channel subsystem and indicated at the subchannel, the I/O interruption request is made pending for the I/O interruption subchannel specified at the subchannel. The I/O interruption subclass for which an interrupt becomes pending is programmed controlled by using MODIFY SUBCHANNEL. Pending I/O interrupts may be accepted by any CPU enabled for interrupts from its I/O interrupt subclass. Each CPU has 8 mask bits in the control register 6 that control its enablement for each of the 8I/O interrupt sub-classes, where the I/O mask, i.e., bit 6 in the PSW, is the main I/O interrupt mask for the CPU.

When an I/O interrupt occurs in a CPU, I/O interrupt code is stored in an I/O communication area of the CPU and the I/O interrupt request is cleared. The I/O interrupt code identifies a subchannel for which an interrupt is pending. The condition that caused the interrupt request to be generated may then be explicitly retrieved from the SUBCHANNEL by either the TEST SUBCHANNEL or the storage SUBCHANNEL.

Pending I/O interrupt requests may also be cleared by TEST PENDING INTERRUPTION when the corresponding I/O interrupt subclass is enabled but PSW causes I/O interrupts to be disabled, or may also be disabled by TESSTUBCHANNEL when the CPU is disabled for I/O interrupts from the corresponding I/O interrupt subclass. Pending I/O interruption requests may also be cleared by CLEARUBCHANNEL. Both CLEAR SUBCHANNEL and TEST SUBCHANNEL also CLEAR the reserved interrupt condition at the SUBCHANNEL.

Generally, unless the interrupt request is cleared by CLEAR SUBCHANNEL, the program issues testschannel to obtain information about the execution of the operation.

Clearing sub-channels

The designated subchannel is cleared, the current start or stop function (if any) is terminated at the designated subchannel, and the channel subsystem is signaled to asynchronously perform the clear function at the designated subchannel and at the associated device.

General register 1 contains a subsystem identification word (SID) that specifies the subchannel to be cleared.

If the start or pause function is in progress, it terminates at the subchannel.

So that the subchannel is no longer state pending. All activity, as indicated by the activity control field of SCSW, is cleared at the subchannel unless the subchannel is made clear pending. Any function in progress, as indicated in the function control field of SCSW, is cleared at the subchannel, except for the clear function to be performed as a result of execution of the instruction.

When the subchannel runs in transport mode and condition code 2 is set, the CPU may signal the channel subsystem to asynchronously perform the inquiry function and end the instruction.

The channel subsystem is signaled to asynchronously perform the flush function. The purge function is summarized in the "related functions" section below, and is described in detail hereinafter.

Condition code 0 is set to indicate that the action described above has been taken.

Related function

After CLEAR SUBCHANNEL execution, the channel subsystem asynchronously performs the flush function. If conditions permit, the channel subsystem selects a channel path and attempts to issue a clear signal to the device to terminate the I/O operation (if any). The subchannel then becomes state pending. The conditions encountered by the channel subsystem that preclude issuing a clear signal to the device do not prevent the subchannel from becoming status pending.

When a subchannel becomes status pending as a result of performing the flush function, the data transfer (if any) with the associated device has been terminated. SCSW stored when the generated state is cleared by TEST SUBCHANNEL has the clear function bit stored as 1. If the channel subsystem can determine that a clear signal is issued to the device, the clear pending bit is stored as a zero in the SCSW. Otherwise, the clear pending bit is stored as a 1 and other indications are provided that describe further details of the conditions encountered.

For the start function terminated by CLEAR SUBCHANNEL, no measurement data is accumulated and the device connection time is not stored in the extended status word for the SUBCHANNEL.

Special conditions

When a SUBCHANNEL is not operable for CLEAR SUBCHANNEL, condition code 3 is set and no other action is taken. A SUBCHANNEL is inoperable for CLEAR SUBCHANNEL when it is not provisioned in the channel subsystem, has no valid device number assigned to it, or is not enabled.

CLEAR subennanel may encounter the following or following program exceptions. When a multi-subchannel set facility is not installed, bits 32-47 of general register 1 must contain 0001 hex; otherwise, an operand exception is identified.

When the multiple subchannel set facility has been installed, bits 32-44 of general register 1 must contain a zero, bits 45-46 must contain a valid value, and bit 47 must contain a value of 1; otherwise, an operand exception is identified.

The generated condition code:

the 0 function is started

1－

2－

3 is not operable

Program exception:

an operand

Privileged operation

Cleaning function

With the CLEAR SUBCHANNEL executed, the channel subsystem performs a CLEAR function. The execution of the flush function includes (1) performing a path management operation, (2) modifying a field at the subchannel, (3) issuing a flush signal to the associated device, and (4) causing the subchannel to become state pending, indicating completion of the flush function.

Clear function path management

A path management operation is performed as part of the purge function to check the channel path conditions for the associated subchannel and attempt to select an available channel path on which a purge signal may be issued to the associated device.

The channel path conditions are examined in the following order:

1. the channel path in use is selected if the channel subsystem is actively communicating with or attempting to establish active communication with the device to be signaled.

2. If the channel subsystem is in the process of accepting a no longer busy indication from the device to be signaled (which will not cause the interrupt condition to be identified) and the associated sub-channel has no loyalty (allegiance) to any channel path, the channel path in use is selected.

3. A channel path is selected if the associated subchannel has dedicated loyalty to that channel path.

4. One of the channel paths is selected if the associated subchannel has operational loyalty to one or more of the channel paths.

5. If the associated subchannel is not loyal to any channel path, if the last used channel path is indicated, and if the channel path is available for selection, the channel path is selected. If the channel path is not available for selection, no channel path is selected, or a channel path is selected from a set of channel paths available for selection (if any) (although the last used channel path is not indicated).

6. If the associated subchannel has no loyalty to any of the channel paths, if the last used channel path is not indicated, and if there are one or more channel paths available for selection, one of the channel paths is selected.

If none of the above listed channel path conditions are tried, no channel path is selected. For item 4, for item 5, which is under specified conditions, and for item 6, the channel subsystem selects a channel path from a set of channel paths. In these cases, the channel subsystem may attempt to select a channel path if the following conditions do not apply:

1. a channel path termination condition exists for a channel path.

2. For parallel or ESCON channel paths: another subchannel may have significant loyalty to the channel path.

For FICON channel paths: the channel path is currently used to communicate with the maximum number of sub-channels that may have parallel active communications.

3. The device to be signaled is attached to the type 1 control unit and the subchannel for another device attached to the same control unit has loyalty to the same channel path unless the loyalty is a working loyalty and the primary status has been accepted by the subchannel.

4. The device to be signaled is attached to a type 3 control unit and the sub-channel for another device attached to the same control unit has dedicated loyalty to the same channel path.

Clear function subchannel modification

During the execution of the flush function, the path management control indication at the subchannel is modified. Effectively, the modification occurs after attempting to select a channel path but before attempting to select a device to issue a clear signal. The modified path management control indication is as follows:

1. the state of all 8 possible channel paths at a subchannel is set to be operational for that subchannel.

2. The last used path indication is reset to indicate that there is no last used channel path.

3. The path inoperability condition (if any) is reset.

Clear function signaling and completion

After attempting to select a channel path and modification of the path management control field, the channel subsystem attempts to select a device to issue a clear signal if conditions permit. The conditions associated with the subchannel and the selected channel path (if any) affect whether (1) an attempt is made to issue a clear signal, and (2) whether the attempt to issue a clear signal was successful. Regardless of these conditions, the subchannel is then set state pending and execution of the clear function is complete. These conditions and their effect on the purge function are described as follows:

No attempt is made to issue a clear signal: the channel subsystem does not attempt to issue a clear signal to the device if any of the following conditions exist:

1. the channel path is not selected.

2. The selected channel path is no longer available for selection.

3. A channel path termination condition exists for the selected channel path.

4. For parallel and ESCON channel paths: the selected channel path is currently used to actively communicate with a different device. For FICON channel paths: the selected channel path is currently used to actively communicate with the maximum number of devices that may have concurrent active communication.

5. The device to be signaled is attached to the type 1 control unit and the subchannel for another device attached to the same control unit has loyalty to the same channel path unless the loyalty is a working loyalty and the primary status has been accepted by the subchannel.

6. The device to be signaled is attached to the type 3 control unit and the subchannel for another device attached to the same control unit has dedicated loyalty to the same path.

If any of the conditions described above exist, the subchannel remains clear pending and is set to status pending, and execution of the clear function completes.

The attempt to signal a clear was not successful: when the channel subsystem attempts to signal a clear to the device, the attempt may be unsuccessful due to the following conditions:

1. the control unit or device prompts for a busy condition when the channel subsystem attempts to select a device to issue a clear signal.

2. A path inoperability condition is identified when the channel subsystem attempts to select a device to issue a clear signal.

3. When the channel subsystem attempts to issue a clear signal, an error condition is encountered.

If any of the above conditions exist and the channel subsystem determines that the attempt to issue a clear signal was unsuccessful, or cannot determine whether the attempt was successful, the subchannel remains clear pending and is set to status pending and execution of the clear function is complete.

The attempt to signal a clear was successful: when the channel subsystem determines that the attempt to issue a clear signal was successful, the subchannel is no longer clear pending and is set to status pending and execution of the clear function is complete. When a subchannel becomes state pending, I/O operations (if any) for the associated device have been terminated.

Description of the programming: any non-zero state presented to the channel subsystem by the device after the flush function is performed is communicated to the program as an unsolicited alarm state, except only on the control unit side. The unsolicited state, which contains only control unit side or zero state, is not presented to the program.

Modifying a subchannel

The information contained in the subchannel information block (SCHIB) is placed in a program-modifiable field at the subchannel. As a result, for this subchannel, the program affects certain aspects of I/O processing with respect to the cleanup, pause, resume, and start functions and certain I/O support functions.

General register 1 contains a subsystem identification word (SID) that specifies the subchannel to be modified, as specified by the specific fields of the scheb. The second operand address is the logical address of SCHIB and must be specified on a word boundary; otherwise, identifying the specification exception.

The channel subsystem operations that may be affected due to the placement of the SCHIB information in the subchannel are:

I/O processing (E field)

Interrupt handling (interrupt parameters and ISC field)

Path management (D, LPM and POM field)

Monitoring and address bound check (measurement-block index, LM and MM fields)

Measurement Block Format control (F field)

Extended measurement word mode Enable (X field)

Parallel sensing facility (S field)

Measuring Block Address (MBA)

Bits 0, 6, and 7 of word 1, and bits 0-28 of word 6 of the SCHIB operand must be zero, and bits 9 and 10 of word 1 must not be 1 at the same time. When the extended I/O measurement block facility is installed and a Format 1 measurement block is specified, bits 26-31 of word 11 must be specified as zeros. When the extended I/O measurement block facility is not installed, bit 29 of word 6 must be designated zero; otherwise, an operand exception is identified. When the extended I/O measurement word facility is not installed, or installed but not enabled, bit 30 of word 6 must be designated zero; otherwise, an operand exception is identified. The remaining fields of the SCHIB are ignored and do not affect the processing of MODIFY SUBCHANNEL.

Condition code 0 is set to indicate that information from the SCHIB has been placed in the program modifiable field at the subchannel, unless the device number valid bit (V) at the designated subchannel is zero, condition code 0 is set and information from the SCHIB is not placed in the program modifiable field.

Special conditions

When the subchannel is status pending, condition code 1 is set and no other action is taken.

When a clear, pause, or start function is performed at a subchannel, condition code 2 is set and no other action is taken.

When a SUBCHANNEL is not operable for MODIFY SUBCHANNEL, condition code 3 is set and no other action is taken. A SUBCHANNEL is inoperable with MODIFY SUBCHANNEL when a SUBCHANNEL is not provided in the channel subsystem.

The MODIFY SUBCHANNEL may encounter program exceptions as described or listed below.

In word 1 of SCHIB, bits 0, 1, 6, and 7 must be zero, and bits 9 and 10 must not both be zero when the address bound verification facility is installed. In word 6 of SHICB, bits 0-28 must be zeros. Otherwise, an operand exception is identified.

When the extended I/O measurement block facility is installed and the Format 1 measurement block is specified, bits 26-31 of word 11 must be specified as zeros; otherwise, an operand exception is identified. When the extended I/O measurement block facility is not installed, bit 29 of word 6 must be designated zero; otherwise, an operand exception is identified. When the extended I/O measurement word facility is not installed, or installed but not enabled, bit 30 of word 6 must be designated zero; otherwise, an operand exception is identified.

When a multi-subchannel set facility is not installed, bits 32-47 of general register 1 must contain 0001 hex; otherwise, an operand exception is identified.

When the multi-lane group facility is installed, bits 32-44 of general register 1 must contain a zero, bits 45-46 must contain a valid value, and bit 47 must contain a value of 1; otherwise, an operand exception is identified.

The second operand must be specified on a word boundary; otherwise, a specification exception is identified. Execution of MODIFYSUBCHANNEL is suppressed on all addressing and protection exceptions.

The generated condition code:

0 function completion

1 State pending

2 busy

3 is not operable

Program exception:

access (get, operand 2)

An operand

Privileged operation

Specification of

Description of the programming:

1. if the device signals an I/O error alarm when the associated subchannel is disabled, the channel subsystem issues a clear signal to the device and discards the I/O error alarm indication without generating an I/O interruption condition.

2. If the device assumes an unsolicited state while the associated subchannel is disabled, that state is discarded by the channel subsystem without generating an I/O interrupt condition. However, if the state present includes a cell check, the channel subsystem issues a clear signal for the associated subchannel and no I/O interrupt condition is generated. This should be considered when the program uses MODIFY SUBCHANNEL to enable the SUBCHANNEL. For example, the media on the associated device that exists when the subchannel is disabled may have been replaced and, therefore, the program should verify the integrity of the media.

3. It is suggested that when the MODIFY SUBCHANNEL sets condition code 0, the program checks the contents of the SUBCHANNEL by subsequently issuing a STORE SUBCHANNEL. Using storagchannels is a method of determining whether a given subchannel has changed. Failure to verify a subchannel after modify channel set condition code 0 may result in a condition that the program does not expect to occur.

START SUBCHANNEL

The channel subsystem is signaled to asynchronously execute the start function for the associated device, and the execution parameters contained in the specified ORB are placed in the specified subchannel.

General register 1 contains a subsystem identification word that specifies the subchannel to be started. The second operand address is the logical address of the ORB and must be specified on a word boundary; otherwise, a specification exception is identified.

The execution parameters contained in the ORB are placed at the subchannel.

When START SUBCHANNEL is executed, the SUBCHANNEL is state-pending, having only secondary state, and the extended status word format bit (L) is zero, the state-pending condition is discarded at the SUBCHANNEL.

The subchannel is made to become initially pending and an initial function is indicated at the subchannel. If the second operand specifies the command mode ORB, the subchannel remains in command mode. If the second operand specifies the transfer mode ORB, the subchannel enters transfer mode. When the subchannel enters transport mode, LPUM is set to zero if no previous dedicated loyalty exists; otherwise LPUM is not changed.

Logically, the path inoperability condition (if any) at the subchannel is cleared before condition code 0 is set.

The channel subsystem is signaled to asynchronously perform the start function. The start function is conceptualized in the following subsection "related functions" and is described in detail later.

Condition code 0 is set to indicate that the above-described action has been taken.

Related function

After START SUBCHANNEL execution, the channel subsystem asynchronously performs the START function.

The validity of the ORB content is checked except for fields that must contain all zeros. On some models, the fields of the ORB that must contain zeros are checked asynchronously, not during execution of the instruction. When invalid fields are asynchronously detected, the subchannel becomes state pending, with primary, secondary and alarm states, and delay condition code 1 and program check are indicated. In this case, the I/O operation or chain of I/O operations is not initiated at the device, and when SCSW is cleared by the execution of TEST SUBCHANNEL, the condition is stored as a start pending bit indication of 1.

On some models, path availability is tested asynchronously, rather than during execution of instructions. When no channel path is available for selection, the subchannel becomes state pending, having primary and secondary states, and a delay condition code of 3 is indicated. The I/O operation or chain of I/O operations is not initiated at the device, and when SCCW is cleared by the execution of TEST SUBCHANNEL, this condition is stored at the Start pending bit indication of 1.

If the conditions permit, a channel path is selected and execution of the channel program specified in the ORB is initiated.

Special conditions

When START SUBCHANNEL is executed and the SUBCHANNEL is status pending, condition code 1 is set and no other action is taken. On some models, condition code 1 is not set when a subchannel is state-pending only in the secondary state; instead, the state pending condition is discarded.

When the start, pause, or clear function is currently in progress at the subchannel, condition code 2 is set and no other action is taken.

When a SUBCHANNEL is not operable for START SUBCHANNEL, condition code 3 is set and no other action is taken. If a SUBCHANNEL is not provisioned in the channel subsystem, has no valid device number associated with it or is not enabled, the SUBCHANNEL is not operable with START SUBCHANNEL.

In some models, a subchannel is also inoperable for startubchannel when no channel path is available for selection. In these models, the lack of available channel paths is detected as part of the START SUBCHANNEL execution. On other models, channel path availability is only tested as part of the asynchronous start function.

START SUBCHANNEL may encounter a program exception as described or listed below.

In word 1 of the command pattern ORB, bits 26-30 must be zeros, and in word 2 of the command pattern ORB, bit 0 must be zeros. Otherwise, on some models, operand exceptions are identified. On other models, an I/O interrupt condition is generated, indicating program verification, as part of the asynchronous start function.

START SUBCHANNEL may also encounter program exceptions listed below. When a multi-subchannel set facility is not installed, bits 32-47 of general register 1 must contain 0001 hex; otherwise, an operand exception is identified.

When the multiple subchannel set facility is installed, bits 32-44 of general register 1 must contain a zero, bits 45-46 must contain a valid value, and bit 47 must contain a value of 1; otherwise, an operand exception is identified.

The second operand must be specified on a word boundary; otherwise, a specification exception is identified. Execution of startubchannel is suppressed on all addressing and protection exceptions.

The generated condition code:

0 function Start

1 State pending

2 busy

3 is not operable

Program exception

Access (get, operand 2)

An operand

Privileged operation

Specification of

Start and resume functions

The start and restore function initiates I/O operations as described below. The start function applies to a subchannel operating in either a command mode or a transport mode. The resume function is applicable only to subchannels operating in command mode.

After execution of the START SUBCHANNE and RESUME SUBCHANNEL, the channel subsystem performs START and RESUME functions, respectively, to initiate I/O operations for the associated device. The execution of the start or resume function includes: (1) perform a path management operation, (2) perform an I/O operation or chain of I/O operations with the associated device, and (3) make the subchannel status pending, indicating completion of the start function. The START function initiates execution of the channel program specified in the ORB, which in turn is specified as an operand of START SUBCHANNEL, as opposed to initiating the resume function of the suspended channel program (if any) at the CCW that caused the suspension; otherwise, the resume function is performed as if it were the start function.

Start and resume function path management

Path management is performed by the channel subsystem in performing a start or restore function to select an available channel path that can be used for device selection to initiate I/O operations with the device. The actions taken are as follows:

1. If a subchannel is currently start pending and the device is active, the start function remains pending at the subchannel until accepting a secondary state from the associated device for the previous start function and causing the subchannel to start pending on its own. When the state is accepted and no alarm interrupt condition is described, the subchannel is not made state pending and the execution pending start function is then initiated. If the state describes an alarm interrupt condition, the subchannel becomes state pending with secondary and alarm states, the pending start function is not enabled, the delay condition code 1 is set, and the start pending bit remains 1. If the subchannel currently begins pending on its own, the start function is initiated as described below.

2. If there is dedicated loyalty to the channel path on the subchannel, the channel subsystem selects that path for device selection. If a busy condition is encountered in attempting to select a device and there is dedicated loyalty on the subchannel, the start function remains pending until the internal indication of busy is reset for that channel path. When the busy internal indication is reset, a pending start function is initiated on the channel path.

3. A channel path is not selected if no channel path is available for selection and no dedicated loyalty to the channel path exists in the subchannel.

4. If all of the alternative channel paths have been attempted and one or more of them are used for active communication with other devices, or if the channel subsystem encounters a control unit busy or device busy condition on one or more of these channel paths, or a combination of these conditions on one or more of these channel paths, the start function remains pending on the subchannel until a channel path, control unit or device becomes available under appropriate circumstances.

5. If (1) a start function is initiated on a channel path, a device is connected to a type 1 control unit, and (2) no other device is connected to the same control unit, a subchannel of the control unit has dedicated loyalty to the same channel path or operational loyalty to the same channel path, wherein a primary status for the subchannel has not been received, then the channel path is selected, if it is available for selection; otherwise, the channel path is not selected. However, if another channel path to the device is available for selection and there is no loyalty as described above, then the channel path is selected. If no other channel paths are available for selection, the start and restore functions remain pending, if appropriate, until a channel path becomes available.

6. If a device is connected to a type 3 control unit and if at least one other device is connected to the same control unit, the sub-channel of that control unit has dedicated loyalty to the same channel path, an alternative channel path may be selected or the start function may remain pending until the dedicated loyalty for that other device is cleared.

7. If a channel path is selected and a busy indication is received during a first command selected by the device to initiate execution of a pending CCW channel program or a TCCB transmitting a pending TCW channel program, the channel path receiving the busy indication is not reused for that device or control unit (depending on the device busy or control unit busy indication received) until the internal indication of busy is reset.

8. If during an attempt to select a device to initiate execution of a first command implied by the start specification or recovery function of the CCW channel program or to initiate transmission of a TCCB to the start function of the TCW channel program (as described in action 7 above), the channel subsystem receives a busy indication that it performs one of the following actions:

a. if the device is designated to operate in multipath mode and the received busy indication is that the device is busy, the start or resume function remains pending until the internal indication of busy is reset.

b. If the device is designated to operate in a multi-path mode and the control unit is busy receiving a busy indication, or if the device is designated to operate in a single-path mode, the channel subsystem attempts device selection by selecting an alternative channel path and continues path management operations until a start or recovery function is initiated or device selection has been attempted on all channel paths that are alternative. If the channel subsystem has not initiated the start or restore function after all of the alternative channel paths have been selected, the start or restore function remains pending until the busy internal indication is reset.

c. If the subchannel has dedicated loyalty, then action 2 on pages 15-20 is applied.

9. When the device appears to be inoperable and the corresponding channel path is operable for the subchannel during an attempt to select to transfer the first command of the CCW channel program or to transfer the TCCB of the TCW channel program, a path inoperable condition is identified and the state of the channel path is changed at the subchannel from operable for the subchannel to inoperable for the subchannel. The path inoperability condition (if any) on the subchannel is preserved until the subchannel subsequently becomes clear pending, start pending, or resume pending (if the subchannel is suspended), at which point the path inoperability condition is cleared. However, if the corresponding channel path is not operable for the subchannel, the path inoperable condition is not identified. When the device appears inoperable during an attempt to select to transmit the first command or TCCB on the alternative channel path, one of the following actions occurs:

a. If dedicated loyalty exists with the channel path, it is the only channel path to choose from; thus, further attempts to initiate the start or resume function are abandoned and an interrupt condition is identified.

b. If dedicated loyalty does not exist and there are alternative channel paths that have not yet been tried, one of the channel paths is selected to try the device to select and transmit the first command of the CCW channel program or the TCCB of the TCW channel program.

c. If there is no dedicated loyalty, there are no alternative channel paths that have not yet been attempted, and the device appears to be operational on at least one channel path that has been attempted, the start and restore function remains pending on the subchannel until a channel path, control unit, or device becomes available as appropriate.

d. If there is no dedicated loyalty, there are no alternative channel paths that have not yet been attempted, and the device appears to be unavailable on all channel paths that have been attempted, further attempts to initiate the start or resume function are aborted and an interruption condition is identified.

10. When a subchannel is active and an I/O operation is to be initiated for a device, all device selections are made according to the LPUM indication if a multipath mode is not specified on the subchannel. For example, if a command link is specified for a CCW channel program, the channel subsystem transfers the first and all subsequent commands of the described I/O operation chain on the same channel path.

Execution of I/O operations

After selecting a channel path, the channel subsystem initiates execution of an I/O operation for the associated device if conditions permit. The execution of the additional I/O operations may be subsequent to the initiation and execution of the first I/O operation.

For a subchannel operating in command mode, the channel subsystem may execute seven types of commands: write, read back, control, sense ID, and transfer in channel. Each command initiates a corresponding I/O operation, except for transfers in the channel. The subchannel is active from the time the first command is accepted until a primary interrupt condition is identified on the subchannel, except during a time when execution of the channel program is suspended on the subchannel. If a primary interrupt condition is identified before accepting the first command, the subchannel will not become active. Typically, the primary interrupt condition is caused by a channel end signal or, in the case of command chaining, a channel end signal for the last CCW in the chain. The device is active until a secondary interrupt condition is identified in the subchannel. Typically, the secondary interrupt condition is caused by a device end signal or, in the case of command chaining, a device end signal for the last CCW in the chain. For a subchannel operating in transport mode, the channel subsystem may transmit six types of commands to perform: write, read, control, sense ID, and query. Each command initiates a corresponding device operation. When one or more commands are sent to the I/O device in the TCCB, the subchannel remains pending until the primary status occurs.

Description of the Programming

In single path mode, all transfers of commands, data, and status for an I/O operation or chain of I/O operations occur on the channel path on which the first command is transferred to the device.

When the device has the dynamic reconnect feature installed, an I/O operation or chain of I/O operations may be performed in a multipath mode. To operate in multipath mode, a MODIFY SUBCHANNEL must have been previously performed for the SUBCHANNEL for which bit 13 of word 1 of SCHIB is designated as 1. Furthermore, the device must be set for multipath mode by executing a specific mode-dependent command that is appropriate for that type of device. The general procedure for handling multipath mode operation is as follows:

1. is provided with

a. The command to set the type of multipath mode must be successfully executed by the device on each channel path that is a member of the set multipath group; otherwise, the multipath mode of operation may give unpredictable results on the subchannel. If for any reason one or more physically available channel paths to a device are not included in the multipath group, these channel paths must not be available for selection when the subchannel operates in the multipath mode. The channel path may be made unavailable for selection by setting the corresponding LPM bit to zero in the SCHIB before performing modified channel or in the ORB before performing START SUBCHANNEL.

b. When a command to set the multipath mode type is transmitted to the device, only a single channel path logic must be available to avoid alternative channel path selection to perform the start function; otherwise, the channel subsystem may detect a device busy condition on more than one channel path, which may lead to unpredictable results for subsequent multipath mode operation. This type of setup procedure should be used whenever the membership of a multipath group is changed.

2. Leaving multipath mode

To leave the multi-path mode and continue processing in the single-path mode, either of the following two procedures may be used:

a. the command to resolve the multipath pattern type may be performed for any channel path of the multipath group. This command must be followed by: (1) MODIFY SUBCHANNEL is performed and bit 13 of word 1 of the scheb is designated as zero, or (2) only the single channel path is designated as logically available in the LPM. When the device is operating in single path mode, it must not be possible to perform a start function on a subchannel operating in multi-path mode with multiple channel paths available for selection; otherwise, unpredictable results of this or a subsequent start function may occur on the subchannel.

b. A command to relinquish the multi-path mode type is executed on each channel path of the multi-path group (as opposed to a setting). This command must be followed by: (1) MODIFY SUBCHANNEL is performed and bit 13 of word 1 of the scheb is designated as zero, or (2) only a single channel path is designated as logically available in the LPM. When the device is operating in single path mode, it must not be possible to perform a start function on a subchannel operating in multi-path mode with multiple channel paths available for selection; otherwise, unpredictable results of this or a subsequent start function may occur on the subchannel.

Data chunking

Data recorded by an I/O device is divided into blocks. The length of the block depends on the device; for example, a block may be a card, a print line, or information recorded between two adjacent spaces of a tape.

The maximum amount of information that can be transferred in one I/O operation is one block. When the associated main storage area is exhausted or the end of the block is reached, the I/O operation is terminated, whichever occurs first. For certain operations, such as writing on tape units or on an interrogation station, the blocks are undefined and the amount of information transferred is only program controlled.

Operation request block

The operation-request block (ORB) is an operand of START SUBCHANNEL. The ORB specifies the parameters used in controlling this particular start function. These parameters include an interrupt parameter, a subchannel key, the address of the first CCW or TCW, an operation control bit, a priority control number, and a designation of logical availability of a channel path to a designated device.

When START SUBCHANNEL is executed, the contents of ORB are placed in the specified SUBCHANNEL before condition code 0 is set. If execution would bring a non-zero condition code, the contents of the ORB would not be placed in the specified subchannel.

The two rightmost bits of the ORB address must be zero, placing the ORB on word boundaries; otherwise, a specification exception is identified. When a fibre channel extension (FCX) facility is installed, the channel program type control (B) (word 1, bit 13) of the ORB specifies the type of channel program specified by the ORB. When B is zero, ORB specifies a CCW channel program. When B is 1, ORB specifies the TCW channel program. Only I/O devices that support FCX can recognize the TCW channel program.

When executing START SUBCHANNEL, if the contents of the ORB of the specified CCW channel program are placed in the specified SUBCHANNEL, the SUBCHANNEL remains in command mode. Thus, such ORBs are also referred to as command mode ORBs. At execution START CHANNEL, if the contents of the ORB of the specified TCW channel program are placed in a subchannel, the subchannel enters transport mode. Thus, such ORBs are also referred to as transport mode ORBs.

TEST PENDING INTERRUPTION

The I/O interrupt code for the pending I/O interrupt on the subchannel is stored in the location specified by the second operand address and the pending I/O interrupt request is cleared.

When the second operand address is not zero, it is the logical address of the location where the double word I/O interrupt code consisting of words 0 and 1 is stored. The second operand address must be specified on a word boundary; otherwise, a specification exception is identified.

If the second operand address is zero, the three-word I/O interrupt code consisting of words 0-2 is stored in real location 184-. In this case, low address protection and key control protection are not applied.

When the second operand address is zero in the access register mode, it is unpredictable whether access register translation occurs in access register B2. If translation occurs, the resulting address space control element is not used; that is, the interrupt code is still stored in real location 184- > 195.

Pending I/O interrupt requests are accepted only for those I/O interrupt subclasses allowed by the I/O interrupt subclass mask in the control register 6 of the CPU executing the instruction. If there is no I/O interrupt request allowed by the control register 6, the I/O interrupt code is not stored, the second operand location is not modified, and the condition code 0 is set.

If the pending I/O interruption request is accepted, the I/O interruption code is stored, the pending I/O interruption request is cleared, and condition code 1 is set. The I/O interruption code is stored the same as would be stored if the I/O interruption occurred. However, the PSW is not swapped as it would when an I/O interruption occurred. The execution of the instruction is defined as follows:

subsystem identification word (SID)

Bits 32-63 of the SID are placed in word 0.

Interruption parameters: word 1 includes a program specified four word parameter and is passed into word 0 of the ORB or PMCW. When the device exhibits an alarm state and the interrupt parameter has not previously been passed to the SUBCHANNEL by executing STARTSUBCHANNEL or MODIFY SUBCHANNEL, this field contains zero.

Interrupt identifier word: when word 2 is stored, it contains an interrupt identifier word that also identifies the source of the I/O interrupt. Word 2 is only stored when the second operand address is zero.

The interrupt identifier is defined as follows:

a site (A): bit 0 of the interrupt identification word specifies the type of pending I/O interrupt request that is cleared. When bit 0 is zero, the I/O interrupt request is associated with a subchannel.

I/O Interruption Subclass (ISC): bit positions 2-4 of the interrupt identifier word comprise unsigned binary integers ranging from 0-7 that specify the I/O interrupt subclass associated with the subchannel for which pending interrupt requests are cleared. The remaining bit positions are reserved and stored as zeros.

Special conditions

TEST PENDING interrupt may encounter a program exception as described or listed below.

The second operand must be specified on a word boundary; otherwise, a specification exception is identified.

TEST PENDING execution of INTERRUPTION is suppressed on all addressing and protection exceptions.

The generated condition code:

0 interrupt code is not stored

1 interrupt code is stored

2—

3—

Program exception:

access (store, operand 2, second operation address is only non-zero)

Privileged operation

Specification of

Description of the Programming

1. When an I/O interrupt is masked, TEST PENDING INTERRUPTION should be performed only for the second operand address of zero. Otherwise, if an I/O interrupt occurs, the I/O interrupt code of the instruction store may be lost. The I/O interrupt code identifying TEST PENDING the source of the I/O interrupt occurring after INTTERUPTION is also stored in real location 184-.

2. When the second operand address is zero in the access register mode, an access exception is identified if an access register translation occurs and the access register is in error. This exception may be avoided by zeroing the B2 field or placing 00000000hex, 00000001hex, or any other valid content in the access register.

STORE SUBCHANNEL

The control and status information for the specified subchannel is stored in the specified SCHIB.

General register 1 contains a subsystem identification word that specifies the subchannel for which information is to be stored. The second operand address is the logical address of SCHIB and must be specified on a word boundary; otherwise, a specification exception is identified.

When the extended I/O measurement block facility is not installed, the information stored in the SCHIB is composed of three words of a path management control word, an SCSC, and model-dependent information. When the extended I/O measurement block facility has been installed, the information stored in the SCHIB consists of one word of the path management control word, SCSW, measurement block address field, and model-dependent information.

Execution of the STORE SUBCHANNEL does not change any information at the SUBCHANNEL.

Condition code 0 is set to indicate that the control and status information for the specified subchannel has been stored in the SCHIB. When execution of the STORE SUBCHANNEL results in the setting of condition code 0, the information in the SCHIB indicates a consistent status of the SUBCHANNEL.

Special conditions

When the designated SUBCHANNEL is not operable for the STORE SUBCHANNEL, condition code 3 is set and no other action is taken. If a SUBCHANNEL is not provided in the channel subsystem, the SUBCHANNEL is inoperable with the STORE SUBCHANNEL.

STORE SUBCHANNEL may encounter program exceptions described or listed below.

When a multi-subchannel set facility is not installed, bits 32-47 of general register 1 must contain 0001 hex; otherwise, an operand exception is identified.

When the multi-subchannel set facility has been installed, bits 32-44 of general register 1 must contain a zero, bits 45-46 must contain a valid value, and bit 47 must contain a value of 1; otherwise, an operand exception is identified.

The second operand must be specified on a word boundary; otherwise, a specification exception is identified.

The generated condition code:

0SCHIB is stored

1—

2—

3 is not operable

Program exception

Access (store, operand 2)

An operand

Privileged operation

Specification of

Description of the Programming

1. The device status stored in SCSW may include device busy, control unit busy, or control unit end indication.

2. The information stored in the SCHIB is retrieved from the subchannel. The STORE SUBCHANNEL instruction does not cause the channel subsystem to interrogate the addressed device.

STORE SUBCHANNEL can be executed at any time to sample the conditions present in the SUBCHANNEL without causing any pending status conditions to clear.

4. Repeated execution of the STORE SUBCHANNEL should be avoided without intermediate delay (e.g., to determine when the SUBCHANNEL changes state) because repeated accesses by the CPU to the SUBCHANNEL would delay or prevent the channel subsystem from accessing the SUBCHANNEL to update the SUBCHANNEL.

TEST SUBCHANNEL

Control and status information for the subchannel is stored in the designated IRB. General register 1 contains a subsystem identification word that specifies the subchannel for which information is to be stored. The second operand address is the logical address of the IRB and must be specified on a word boundary; otherwise, a specification exception is identified.

The information stored in the IRB consists of an SCSW word, an extended status word and an extended control word.

If the subchannel is status pending, the status pending bit of the status control field is stored as 1. Whether a SUBCHANNEL is status pending has an impact on the function performed when executing the TEST SUBCHANNEL.

When a SUBCHANNEL is status pending and TEST SUBCHANNEL is executed, the information is stored in the IRB, as described above, followed by clearing of the specific conditions and indications present in the SUBCHANNEL. If the subchannel is in transport mode, the clearing of these conditions, in particular the start function, places the subchannel in command mode. If an I/O interruption request is pending for a subchannel, the request is cleared. Condition code 0 is set to indicate that these actions have been taken.

When a SUBCHANNEL is not status pending and a TEST SUBCHANNEL is executed, the information is stored in the IRB and no condition or indication is cleared. Condition code 1 is set to indicate that these actions have been taken.

Special conditions

When a SUBCHANNEL is not operable for TEST SUBCHANNEL, condition code 3 is set and no other action is taken. A SUBCHANNEL is not operable with a TEST SUBCHANNEL if it is not provisioned, has no valid device number associated with it, or is not enabled.

TEST SUBCHANNEL may encounter program exceptions as described or listed below.

When a multi-subchannel set facility is not installed, bits 32-47 of general register 1 must contain 0001 hex; otherwise, an operand exception is identified.

When the multiple subchannel set facility has been installed, bits 32-44 of general register 1 must contain a zero, bits 45-46 must contain a valid value, and bit 47 must contain a value of 1; otherwise, an operand exception is identified.

The second operand must be specified on a word boundary; otherwise, a specification exception is identified.

The state of the SUBCHANNEL is not changed when the execution of the TEST SUBCHANNEL ends on the addressing and protection exceptions. Generating a condition code:

0IRB is stored; subchannel status pending

1IRB is stored; subchannel is not status pending

2—

3 is not operable

Program exception:

access (store, operand 2)

An operand

Privileged operation

Specification of

Description of the Programming

The device status stored in SCSW may include an indication that the device is busy, the control unit is busy, or the control unit is finished.

2. The information stored in the IRB is obtained from the subchannel. The TEST SUBCHANNEL instruction does not cause the channel subsystem to interrogate the addressed device.

3. When an I/O interrupt occurs, this is the result of a state pending condition at the SUBCHANNEL, and a TEST SUBCHANNEL is typically performed to clear the state. TEST SUBCHANNEL may also be performed at any other time to sample conditions present in the SUBCHANNEL.

4. Repeated execution of the TEST SUBCHANNEL to determine when the start function has been completed should be avoided because certain conditions exist under which completion of the start function may or may not be indicated. For example, if the channel subsystem holds the interface control checking (IFCC) condition invalid (abeyance) (for any SUBCHANNEL) because another SUBCHANNEL is already state pending, and if the start function tested by the TEST SUBCHANNEL only has the channel path with the IFCC condition as the only alternative path, the start function may not be activated until the state pending condition in the other SUBCHANNEL is cleared, thereby allowing the IFCC condition to be indicated at the SUBCHANNEL to which it applies.

5. Repeated executions of the TEST SUBCHANNEL should be avoided without intermediate delays, for example, to determine when the SUBCHANNEL changes state, since repeated accesses by the CPU to the SUBCHANNEL would delay or prevent access by the channel subsystem to the SUBCHANNEL. Executing TEST SUBCHANNEL by multiple CPUs at approximately the same time may have the same effect and should also be avoided.

6. The priority of I/O interrupt processing by the CPU may be modified by executing TEST SUBCHANNEL. When the TEST SUBCHANNEL is executed and the designated SUBCHANNEL has an I/O interrupt request pending, the I/O interrupt request is cleared and SCSW is stored, regardless of any priority previously established. The relative priority of the remaining I/O interrupt requests does not change.

As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present disclosure may be embodied in the form of: may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software, and may be referred to herein generally as a "circuit," module "or" system. Furthermore, in some embodiments, the invention may also be embodied in the form of a computer program product in one or more computer-readable media having computer-readable program code embodied in the medium.

Any combination of one or more computer-readable media may be employed. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Referring now to FIG. 10, in one example, a computer program product 1000 includes, for instance, one or more non-transitory computer-readable storage media 1002 having computer-readable program code means or logic 1004 stored thereon to provide and facilitate one or more aspects of the present invention.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The present invention is described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means (instructions) which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition to the foregoing, one or more aspects of the present invention may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of a user's environment. For example, a service provider can create, maintain, support, etc., computer code and/or computer infrastructure that performs one or more aspects of the present invention for one or more users. The service provider, in turn, may accept payment from the user, for example, according to a subscription and/or fee agreement. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.

In one aspect of the invention, an application may be deployed to perform one or more aspects of the invention. As one example, deploying an application comprises providing a computer infrastructure operable to perform one or more aspects of the present invention.

As yet another aspect of the present invention, a computing infrastructure may be deployed comprising integrating computer-readable code into a computer system, wherein the code in combination with the computing system is capable of performing one or more aspects of the present invention.

As yet another aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system includes a computer-readable medium, wherein the computer medium includes one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.

While various embodiments are described above, these are only examples. For example, computing environments of other architectures may incorporate and use one or more aspects of the present invention. By way of example, servers other than z196 servers can include, use, and/or benefit from one or more aspects of the present invention. Further, other instructions and/or commands may be used; and the instructions and/or commands may include additional, less and/or different information than described herein. Many variations are possible.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, a data processing system suitable for storing and/or executing program code will be used that includes at least two processors coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, DASD, magnetic tape, CDs, DVDs, thumb drives, and other storage media) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the available types of network adapters.

Referring to FIG. 11, representative components of a host computer system 5000 to implement one or more aspects of the present invention are depicted. The representative host computer 5000 includes one or more CPUs 5001 in communication with computer memory (i.e., central storage) 5002, and I/O interfaces to storage media devices 5011 and networks 5010 for communicating with other computers or SANs and the like. The CPU5001 conforms to an architecture having an architectural instruction set and architectural functions. The CPU5001 may have Dynamic Address Translation (DAT) 5003 for translating program addresses (virtual addresses) to real addresses of memory. A DAT typically includes a Translation Lookaside Buffer (TLB) 5007 for caching translations so that later accesses to a block of computer memory 5002 do not require the delay of address translation. Typically, a cache 5009 is used between the computer memory 5002 and the processor 5001. The cache 5009 may be hierarchical, having a large cache available to more than one CPU, and smaller, faster (lower level) caches between the large cache and each CPU. In some embodiments, the lower level cache is split to provide separate lower level caches for instruction fetching and data accesses. In one embodiment, instructions are fetched from memory 5002 by instruction fetch unit 5004 via cache 5009. The instructions are decoded in the instruction decode unit 5006 and (in some embodiments, with other instructions) sent to the one or more instruction execution units 5008. Typically, several execution units 5008 are used, such as an arithmetic execution unit, a floating point execution unit, and a branch instruction execution unit. The instruction is executed by the execution unit, accessing operands from registers or memory specified by the instruction, as needed. If an operand is to be accessed (loaded or stored) from memory 5002, load/store unit 5005 typically handles the access under the control of the instruction being executed. The instructions may be executed in hardware circuitry, or in internal microcode (firmware), or in a combination thereof.

Note that the computer system includes information in local (or main) memory, as well as addressing, protection, and reference and change records. Some aspects of addressing include address format, concept of address space, various types of addresses, and the manner in which one type of address is translated to another type of address. Some main memories include permanently allocated memory locations. The main memory provides the system with fast-access data storage that is directly addressable. Both data and programs will be loaded into main memory (from the input device) before they can be processed.

The main memory may include one or more smaller, faster-access cache memories, sometimes referred to as caches. The cache is typically physically associated with the CPU or I/O processor. The effects of the physical structure and use of different storage media are not typically observed by a program except in terms of performance.

Separate caches for instruction and data operands may be maintained. Information in a cache may be maintained as contiguous bytes on integer boundaries called cache blocks or cache lines (or simply lines). The model may provide an EXTRACT CACHE ATTRIBUTE instruction that returns the byte size of the CACHE line. The model may also provide PREFETCH DATA (prefetch data) and PREFETCH DATA relative issue (prefetch longer data) instructions that enable prefetching for storage into a data or instruction cache, or release of data from the cache.

The memory is considered to be a long horizontal string of bits. For most operations, accesses to memory are made in left-to-right order. The bit string is subdivided into units of eight bits. The eight-bit unit is called a byte, which is the basic building block for all information formats. Each byte location in memory is identified by a unique non-negative integer, which is the address of the byte location, or simply, the byte address. Adjacent byte positions have consecutive addresses, starting at 0 on the left and proceeding in left to right order. The address is an unsigned binary integer and is 24, 31 or 64 bits.

Information is transferred between the memory and the CPU or channel subsystem one byte or a group of bytes at a time. Unless otherwise specified, for example in z/Architecture O R, a group of bytes in memory is addressed by the leftmost byte of the group. The number of bytes in a group may be implied or explicitly specified by the operation to be performed. When used in CPU operations, a group of bytes is called a field. Within each group of bytes, e.g., in the z/Architecture O R, the bits are numbered in left-to-right order. In z/Architecture O R, the leftmost bits are sometimes referred to as "high order" bits and the rightmost bits as "low order" bits. However, the number of bits is not a memory address. Only bytes can be addressed. To operate on a single bit of a byte in memory, the entire byte is accessed. The bits on the bytes are numbered 0 to 7 from left to right (e.g., in z/Architecture. RTM.). The bits in the address are numbered 8-31 or 40-63 for a 24-bit address, 1-31 or 33-63 for a 31-bit address, and 0-63 for a 64-bit address. In any other fixed length format of a plurality of bytes, the bits that make up the format are numbered consecutively starting from 0. For error detection, and preferably for correction, one or more check bits may be passed with each byte or group of bytes. Such check bits are automatically generated by the machine and cannot be directly controlled by the program. The storage capacity is expressed in number of bytes. When the length of a memory operand field is implied by the opcode of the instruction, the field is said to have a fixed length, which may be one, two, four, eight, or sixteen bytes. Larger fields may be implied for some instructions. When the length of the memory operand field is not implied but explicitly indicated, the field is said to have a variable length. Variable length operands may be variable in length in increments of one byte (or for some instructions, in multiples of two bytes or other multiples). When information is placed in memory, only the contents of those byte locations included in the specified field are replaced, even though the width of the physical path to memory may be greater than the length of the field being stored.

Some units of information are located on integer limits in memory. For a unit of information, a bound is said to be an integer when its memory address is a multiple of the length of the unit in bytes. Special names are given to fields of 2, 4, 8 and 16 bytes on the integer limit. A halfword is a set of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a set of four consecutive bytes on a four-byte boundary. A doubleword is a set of eight consecutive bytes on an eight-byte boundary. A quad word (quadword) is a set of 16 contiguous bytes on a 16-byte boundary. When a memory address specifies a halfword, a word, a doubleword, and a quadword, the binary representation of the address includes one, two, three, or four rightmost zero bits, respectively. The instruction will be on a two-byte integer boundary. Most instructions have memory operands that do not have boundary alignment requirements.

On devices that implement separate caches for instructions and data operands, significant delays may be experienced if a program stores in a cache line and an instruction is subsequently fetched from the cache line, regardless of whether the store alters the subsequently fetched instruction.

In one embodiment, the invention may be implemented by software (sometimes referred to as licensed internal code, firmware, microcode, millicode, picocode, etc., any of which would be consistent with the invention). Referring to fig. 11, software program code embodying the present invention is typically accessed by the processor 5001 of the host system 5000 from a long term storage media device 5011, such as a CD-ROM drive, tape drive or hard drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or may be distributed to users of other computer systems from the computer memory 5002 or storage devices of one computer system over the network 5010 for use by users of such other systems.

The software program code includes an operating system which controls the function and interaction of the various computer components and one or more application programs. The program code is typically paged from the storage media device 5011 to the relatively higher speed computer memory 5002 where it is available to the processor 5001. Techniques and methods for embodying software program code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. When the program code is created and stored on a tangible medium, including but not limited to an electronic memory module (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., it is often referred to as a "computer program product". The computer program product medium is typically readable by processing circuitry preferably located in a computer system for execution by the processing circuitry.

FIG. 12 illustrates a representative workstation or server hardware system in which the present invention may be implemented. The system 5020 of fig. 12 includes a representative base computer system (base computer system) 5021, such as a personal computer, workstation or server, including optional peripherals. A basic computer system 5021 comprises one or more processors 5026 and a bus used to connect and enable communication between the processors 5026 and other components of the system 5021, in accordance with known techniques. The bus connects the processor 5026 to memory 5025 and long-term storage 5027 which may comprise a hard disk drive (including any of magnetic media, CD, DVD, and flash memory, for example) or a tape drive, for example. The system 5021 can also include a user interface adapter that connects the microprocessor 5026 via the bus to one or more interface devices, such as a keyboard 5024, a mouse 5023, a printer/scanner 5030, and/or other interface devices, which can be any user interface device, such as a touch-sensitive screen, a digital input pad (digitized entry pad), etc. The bus may also connect a display device 5022, such as an LCD screen or monitor, to the microprocessor 5026 via a display adapter.

The system 5021 may communicate with other computers or networks of computers via a network adapter capable of communicating 5028 with a network 5029. Exemplary network adapters are communications channels, token ring, Ethernet or modems. Alternatively, the system 5021 may communicate using a wireless interface, such as a CDPD (cellular digital packet data) card. The system 5021 can be associated with such other computers in a Local Area Network (LAN) or a Wide Area Network (WAN), or the system 5021 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as suitable communication hardware and software, are known in the art.

Figure 13 illustrates a data processing network 5040 in which the present invention may be implemented. The data processing network 5040 may include a plurality of separate networks, such as wireless and wired networks, each of which may include a plurality of separate workstations 5041, 5042, 5043, 5044. Further, those skilled in the art will appreciate that one or more LANs may be included, wherein a LAN may include a plurality of intelligent workstations coupled to a host processor.

Still referring to FIG. 13, the network may also include mainframe computers or servers, such as a gateway computer (client server 5046) or application server (remote server 5048, which may access a data repository and may also be accessed directly from a workstation 5045). The gateway computer 5046 serves as a point of entry into each individual network. When connecting one networking protocol to another, a gateway is required. The gateway 5046 may preferably be coupled to another network (e.g., the internet 5047) by a communications link. The gateway 5046 may also be directly coupled to one or more workstations 5041, 5042, 5043, 5044 using a communications link. The gateway computer may be implemented using an IBM eServer TMSystemz O R server available from International Business machines corporation.

Referring concurrently to fig. 12 and 13, software programming code which may embody the present invention may be accessed by the processor 5026 of the system 5020 from long-term storage media 5027, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or from the memory or storage of one computer system over a network to users 5050, 5051 of other computer systems for use by users of such other systems.

Alternatively, the programming code may be embodied in the memory 5025 and accessed by the processor 5026 using a processor bus. Such programming code includes an operating system which controls the function and interaction of the various computer components and one or more application programs 5032. Program code is typically paged from the storage medium 5027 to high-speed memory 5025 where it is available for processing by the processor 5026. Techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. Program code, when created and stored on tangible media, including but not limited to electronic memory modules (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., is commonly referred to as a "computer program product". The computer program product medium is typically readable by a processing circuit, preferably located in a computer system, for execution by the processing circuit.

The cache most readily used by the processor (which is typically faster and smaller than the other caches of the processor) is the lowest level (L1 or level 1) cache, and main storage (main memory) is the highest level cache (L3 if there are three levels). The lowest level cache is often divided into an instruction cache (I-cache) that holds the machine instructions to be executed, and a data cache (D-cache) that holds the data operands.

Referring to FIG. 14, an exemplary processor embodiment is shown for the processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks in order to improve processor performance. The cache 5053 is a cache buffer that holds cache lines of memory data that are likely to be used. Typical cache lines are 64, 128 or 256 bytes of memory data. A separate cache is typically used for caching instructions rather than data. Cache coherency (synchronization of copies of lines in memory and cache) is typically provided by various "snoop" algorithms well known in the art. The main memory 5025 of the processor system is commonly referred to as a cache. In a processor system having 4 levels of cache 5053, main memory 5025 is sometimes referred to as a level 5 (L5) cache, because it is typically faster and maintains only a portion of the non-volatile storage (DASD, tape, etc.) that is available to the computer system. Main memory 5025 may "cache" pages of data paged in and out of main memory 5025 by the operating system.

Program counter (instruction counter) 5061 keeps track of the address of the current instruction to be executed. The program counter in the z/Architecture O R processor is 64 bits and may be truncated to 31 or 24 bits to support the previous addressing limits. The program counter is typically embodied in the computer's PSW (program status word) so that it persists during context transitions. Thus, an in-progress program having a program counter value may be interrupted by, for example, an operating system (context switch from a program environment to an operating system environment). When a program is inactive, the PSW of the program maintains a program counter value, and while the operating system executes, the program counter (in the PSW) of the operating system is used. Typically, the program counter is incremented by an amount equal to the number of bytes of the current instruction. RISC (reduced instruction set computing) instructions are typically of fixed length, while CISC (Complex instruction set computing) instructions are typically of variable length. The instructions of IBMz/Architecture O R are CISC instructions having a length of 2, 4, or 6 bytes. Program counter 5061 is modified by, for example, a context switch operation or a branch taken operation of a branch instruction. In a context switch operation, the current program counter value is saved in a program status word along with other status information about the program being executed (such as condition codes), and a new program counter value is loaded and points to the instruction of the new program module to be executed. A branch taken operation is performed to allow the program to make a decision or loop within the program by loading the result of the branch instruction into the program counter 5061.

Typically, instructions are fetched on behalf of the processor 5026 using an instruction fetch unit 5055. The fetch unit may fetch a "next sequence of instructions," a target instruction of a branch taken instruction, or a first instruction of a context-switched program. Present instruction fetch units typically use prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions will be used. For example, the fetch unit may fetch 16 bytes of instructions, including the next sequential instruction and additional bytes of further sequential instructions.

The fetched instructions are then executed by the processor 5026. In one embodiment, the fetched instructions are passed to the dispatch unit 5056 of the fetch unit. The dispatch unit decodes the instructions and forwards information about the decoded instructions to the appropriate units 5057, 5058, 5060. The execution unit 5057 will typically receive information from the instruction fetch unit 5055 regarding decoded arithmetic instructions, and will perform arithmetic operations on operands according to the opcode of the instruction. Operands are preferably provided to the execution unit 5057 from storage 5025, architectural registers 5059, or from an immediate field (immediate field) of the instruction being executed. The results of the execution, when stored, are stored in storage 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, etc.).

The processor 5026 typically has one or more units 5057, 5058, 5060 for performing the function of instructions. Referring to fig. 15A, an execution unit 5057 may communicate with architected general registers 5059, decode/dispatch unit 5056, load store unit 5060, and other 5065 processor units via interface logic 5071. The execution unit 5057 may use several register circuits 5067, 5068, 5069 to hold information that the Arithmetic Logic Unit (ALU) 5066 is to operate on. The ALU performs arithmetic operations such as add, subtract, multiply, divide, and logical operations such as AND, OR, and exclusive OR (XOR), rotate, and shift. Preferably, the ALU supports specialized operations that are design dependent. Other circuitry may provide other architectural tools 5072, including condition codes and recovery support logic, for example. Typically, the results of the ALU operations are held in output register circuitry 5070, which may forward the results to a variety of other processing functions. There are many processor unit arrangements and this description is intended only to provide a representative understanding of one embodiment.

For example, ADD instructions will be executed in an execution unit 5057 having arithmetic and logical functionality, while floating point instructions will be executed in floating point execution with dedicated floating point capabilities, for example. Preferably, the execution unit operates on the operands identified by the instruction by executing the function defined by the opcode on the operands. For example, an ADD instruction may be executed by the execution unit 5057 on operands found in two registers 5059 identified by register fields of the instruction.

The execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, which may be a third register or one of the two source registers. The execution unit preferably utilizes an Arithmetic Logic Unit (ALU) 5066, which can perform a variety of logical functions, such as shifting, rotating, and, OR, XOR, and any of a variety of algebraic functions, including addition, subtraction, multiplication, and division. Some ALUs 5066 are designed for scalar operations and some for floating point. Depending on the architecture, the data may be big endien (where the least significant byte is at the most significant byte address) or little endien (where the least significant byte is at the least significant byte address). IBMz/Architecture O R is the big end. Depending on the architecture, the signed field may be sign and magnitude, 1's complement, or 2's complement. A 2's complement number is advantageous in that the ALU does not need to design subtraction capability because only addition in the ALU is required, whether negative or positive in the 2's complement. The numbers are typically described in shorthand, where a 12-bit field defines the address of a block of 4096 bytes, and are typically described as a 4Kbyte block, for example.

Referring to FIG. 15B, branch instruction information for executing a branch instruction is typically sent to a branch unit 5058, which often predicts branch outcome before other conditional operations are completed, using a branch prediction algorithm such as branch history table 5082. Before the conditional operation completes, the target of the current branch instruction will be fetched and speculatively executed. When the conditional operation completes, the speculatively executed branch instruction is either completed or discarded based on the condition of the conditional operation and the speculative result. Typical branch instructions may test the condition code and branch to a target address if the condition code satisfies the branch requirement of the branch instruction, the branch address may be calculated based on a number including, for example, a number found in a register field or an immediate field of the instruction. The branch unit 5058 may utilize an ALU5074 having a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. The branch unit 5058 may communicate with, for example, general registers 5059, decode dispatch unit 5056, or other circuitry 5073.

Execution of a set of instructions may be interrupted for a number of reasons including, for example, a context switch initiated by the operating system, a program exception or error causing a context switch, an I/O interrupt signal causing a context switch, or multi-threaded activity of multiple programs (in a multi-threaded environment). Preferably, the context switch action saves state information about the currently executing program and then loads state information about another program being invoked. The state information may be stored, for example, in hardware registers or memory. The state information preferably includes a program counter value pointing to the next instruction to be executed, condition codes, memory translation information and architectural register contents. The context translation activities may be implemented by hardware circuitry, application programs, operating system programs, or firmware code (microcode, pico code, or Licensed Internal Code (LIC)), alone or in combination.

The processor accesses operands according to the instruction defined method. An instruction may provide an immediate operand using the value of a portion of the instruction, may provide one or more register fields that explicitly point to general purpose registers or special purpose registers (e.g., floating point registers). The instruction may utilize the implied register determined by the opcode field as an operand. The instruction may utilize memory locations for operands. The memory location of the operand may be provided by a register, an immediate field, or a combination of a register and an immediate field, as exemplified by the z/Architecture o R long displacement facility (facility), where the instruction defines a base register, an index register, and an immediate field (displacement field) that add together to provide, for example, the address of the operand in memory. Unless otherwise indicated, a location herein typically means a location in main memory (main storage).

Referring to fig. 16C, the processor accesses the memory using the load/store unit 5060. The load/store unit 5060 may perform a load operation by obtaining the address of a target operand in memory 5053 and loading the operand into a register 5059 or other memory 5053 location, or may perform a store operation by obtaining the address of a target operand in memory 5053 and storing data obtained from a register 5059 or another memory 5053 location in the target operand location in memory 5053. The load/store unit 5060 may be speculative and may access memory in an out-of-order relative to instruction order, but the load/store unit 5060 will maintain the appearance to a program that instructions are executed in order. The load/store unit 5060 may communicate with general registers 5059, decryption/dispatch unit 5056, cache/memory interface 5053 or other elements 5083, and includes various register circuits, ALUs 5085 and control logic 5090 to calculate memory addresses and provide pipeline order to keep operations in order. Some operations may be out of order, but the load/store unit provides functionality such that operations that are performed out of order appear to the program as if they were performed in order, as is well known in the art.

Preferably, the addresses that are "seen" by the application are commonly referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses". These virtual addresses are virtual in that they are redirected to a physical memory location by one of a variety of Dynamic Address Translation (DAT) techniques including, but not limited to, simply prefixing the virtual address with an offset value, translating the virtual address via one or more translation tables, preferably including at least one segment table and a page table (alone or in combination), preferably the segment table having an entry pointing to the page table. In z/Architecture O R, a translation hierarchy is provided, including a region first table, a region second table, a region third table, a segment table, and an optional page table. The performance of address translation is typically improved by utilizing a Translation Lookaside Buffer (TLB) that includes entries that map virtual addresses to associated physical memory locations. When a DAT translates a virtual address using a translation table, an entry is created. Subsequent use of the virtual address may then utilize the entry of the fast TLB, rather than the slow sequential translation table access. TLB content may be managed by a plurality of replacement algorithms including LRU (least recently used).

Where the processors are processors of a multi-processor system, each processor has the responsibility of maintaining shared resources, such as I/O, caches, TLBs, and memory, which are interlocked to achieve coherency. Typically, "snooping" techniques will be used to maintain cache coherency. In a snooping environment, each cache line may be marked as being in one of a shared state, an exclusive state, a changed state, an invalid state, etc., to facilitate sharing.

The I/O unit 5054 (fig. 14) provides the processor with means for attaching to peripheral devices including, for example, tapes, disks, printers, displays, and networks. The I/O cells are typically presented to the computer program by a software driver. In a mainframe computer such as System z O R from IBM O R, channel adapters and open System adapters are the I/O units of the mainframe computer that provide communication between the operating System and peripheral devices.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, an environment may include an emulator (e.g., software or other emulation mechanisms), in which a particular architecture (including, for example, instruction execution, architectural functions such as address translation, and architectural registers) or a subset thereof is emulated (e.g., in a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though the computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, a particular instruction or operation being emulated is decoded, and the appropriate emulation function is established to implement the single instruction or operation.

In an emulation environment, a host computer includes, for example, memory to store instructions and data; an instruction fetch unit to fetch instructions from memory and, optionally, to provide local buffering of fetched instructions; an instruction decode unit to receive the fetched instruction and determine a type of instruction that has been fetched; and an instruction execution unit to execute the instruction. Execution may include loading data from memory to a register; storing data from the register back to the memory; or perform some type of arithmetic or logical operation as determined by the decode unit. In one example, each unit is implemented in software. For example, the operations performed by the units are implemented as one or more subroutines in emulator software.

More specifically, in a mainframe computer, programmers (typically today's "C" programmers) typically use architected machine instructions through compiler applications. These instructions stored in the storage medium may be executed natively in the z/Architecture o rbm o R server, or in a machine executing other architectures. They may be emulated in existing and future IBM O R mainframe computer servers as well as IBM O R other machines (e.g., Power Systems servers and System x O R servers). They may be executed in machines running Linux on various machines using hardware manufactured by IBM o R, Intel o R, AMDTM, etc. In addition to executing on this hardware under z/Architecture o R, Linux may also be used for machines that use emulation provided by TurboHercules, Hercules, UMX, or FSI (Fundamental Software, Inc), where execution is generally in emulation mode. In emulation mode, emulation software is executed by the native processor to emulate the architecture of the emulated processor.

The native processor typically executes emulation software, which includes firmware or a native operating system, to execute an emulation program of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulated program counter to keep track of instruction boundaries. The emulation software can fetch one or more emulated machine instructions at a time and convert the one or more emulated machine instructions into a corresponding set of native machine instructions for execution by the native processor. These translated instructions may be cached so that faster translations may be accomplished. The emulation software will maintain the architectural rules of the emulated processor architecture to ensure that the operating system and applications written for the emulated processor operate correctly. Furthermore, the emulation software will provide resources determined by the emulated processor architecture, including but not limited to control registers, general purpose registers, floating point registers, dynamic address translation functions including, for example, segment and page tables, interrupt mechanisms, context translation mechanisms, time of day (TOD) clocks, and architectural interfaces to the I/O subsystem, such that operating systems or applications designed to run on the emulated processor may run on the native processor with the emulation software.

The particular instruction being emulated is decoded and a subroutine is called to perform the function of that single instruction. The emulation software functions that emulate the functions of an emulated processor are implemented, for example, in a "C" subroutine or driver, or by other methods that provide drivers for specific hardware, as will be understood by those skilled in the art after understanding the description of the preferred embodiments. Including, but not limited to, U.S. patent No. 5,551,013 entitled "Multiprocessor for Hardware Emulation" to beaussoleil et al; and U.S. patent certificate number 6,009,261 entitled "Preprocessing of Stored Target Instructions for simulating an incorporated instruction on a Target Processor" to Scalazi et al; and U.S. patent document No. 5,574,873 entitled "Decoding Guest Instructions to direct Access orientations angles of the Guest Instructions" to Davidian et al; and U.S. patent certificate No. 6,308,255 entitled "symmetric Multiprocessing Bus and chip Used for multiprocessor support Non-Native Code to Run in a System" to Gorishek et al; and U.S. patent document No. 6,463,582 entitled "Dynamic Optimizing Object code translator for Architecture implementation and Dynamic Optimizing Object code Translation Method" by Lethin et al; and U.S. patent certificate No. 5,790,825 entitled "Method for simulating Guest instruments" by Eric Traut for Host computer through Dynamic reconfiguration of Host instruments "; as well as numerous other patents, show various known ways to implement emulation of instruction formats architected for different machines for a target machine available to those skilled in the art.

In fig. 16, an example of an emulated host computer system 5092 is provided that emulates a host computer system 5000' of a host architecture. In the emulated host computer system 5092, the host processor (CPU) 5091 is an emulated host processor (or virtual host processor) and includes an emulated processor 5093 having a different native instruction set architecture than the processor 5091 of the host computer 5000'. The emulation host computer system 5092 has a memory 5094 accessible by an emulation processor 5093. In the exemplary embodiment, memory 5094 is partitioned into a host computer memory 5096 portion and an emulation routines 5097 portion. Host computer memory 5096 is available to programs emulating host computer 5092, according to the host computer architecture. The emulation processor 5093 executes native instructions of an architected instruction set of a different architecture than the emulated processor 5091 (i.e., native instructions from the emulated program processor 5097), and may access host instructions for execution from programs in the host computer memory 5096 by using one or more instructions obtained from a sequence and access/decode routine that may decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. Other tools defined for the host computer system 5000' architecture may be emulated by the architecture tool routines, including such tools as general purpose registers, control registers, dynamic address translation and I/O subsystem support and processor caches. The emulation routine may also take advantage of functions available in the emulation processor 5093, such as dynamic translation of general purpose registers and virtual addresses, to improve the performance of the emulation routine. Specialized hardware and offload engines may also be provided to assist the processor 5093 in emulating the functionality of the host computer 5000'.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and/or components.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

The claims (modification according to treaty clause 19)

1. A method for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the method comprising:

obtaining, by an input/output "I/O" subsystem, a request block comprising a command code indicating a deconfigure storage class memory command and a storage class memory "SCM" increment request list comprising one or more entries, each entry configured to include a total size field indicating a number of increments of storage class memory to be deconfigure and a starting SCM address indicating a starting location of a deconfigure storage class memory increment;

based on the command code, initiating a deconfiguration process that changes a configuration of storage class memory by deleting one or more increments of storage class memory, the process configured to remove from the SCM address space the requested number of storage class memory increments specified in the total size field, wherein the initiating includes performing one or more validity checks;

in response to the one or more validity checks being successful, continuing the deconfiguration process of the storage class memory, wherein the one or more validity checks include determining that an increment of storage class memory to be deconfigured is in a configured state; and

Storing a response code in a response field of a response block, the response code indicating whether the deconfiguration process was initiated, the response block including a length code indicating a length of the response block.

2. The method of claim 1, wherein the one or more validity checks further comprise:

checking a length field of the request block;

a check of whether the deconfigure storage class memory command is available to be executed;

a verification that the request block has a valid format;

the I/O subsystem is capable of performing a check of the deconfigure storage class memory command, and wherein the deconfigure process continues to execute in response to the one or more validity checks being successful.

3. The method of claim 1, wherein the initiating further comprises: in response to the one or more validity checks being successful, initiating an asynchronous process to perform the deconfiguration of the storage class memory, wherein contents of the deconfigured storage class memory are initialized to zero and placed in a standby state.

4. The method of claim 3, wherein the method further comprises indicating completion of the asynchronous process in a notification response block.

5. The method of claim 4, wherein the notification response block includes a response code indicating a result of attempting to execute the deconfigure storage class memory command.

6. The method of claim 5, wherein the notification response block is obtained via execution of a store event information command to obtain event information.

7. The method of claim 4, wherein the request block is further configured to include an asynchronous completion correlator to be returned in the notification response block, the asynchronous completion correlator to be used to resume processing of the deconfigure storage class memory command.

8. The method of claim 1, wherein the deconfiguration process comprises:

moving the increment of memory from a configuration state to a retention state;

zeroing the contents of the increment of memory; and

placing the increment of memory in a standby state.

9. A computer system for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the computer system comprising:

a memory; and

a processor in communication with the memory, wherein the computer system is configured to perform a method comprising:

Obtaining, by an input/output "I/O" subsystem, a request block comprising a command code indicating a deconfigure storage class memory command and a storage class memory "SCM" increment request list comprising one or more entries, each entry configured to include a total size field indicating a number of increments of storage class memory to be deconfigure and a starting SCM address indicating a starting location of a deconfigure storage class memory increment;

based on the command code, initiating a deconfiguration process that changes a configuration of storage class memory by deleting one or more increments of storage class memory, the process configured to remove from the SCM address space the requested number of storage class memory increments specified in the total size field, wherein the initiating includes performing one or more validity checks;

in response to the one or more validity checks being successful, continuing the deconfiguration process of the storage class memory, wherein the one or more validity checks include determining that an increment of storage class memory to be deconfigured is in a configured state; and

storing a response code in a response field of a response block, the response code indicating whether the deconfiguration process was initiated, the response block including a length code indicating a length of the response block.

10. The computer system of claim 9, wherein the one or more validity checks further comprise:

checking a length field of the request block;

a check of whether the deconfigure storage class memory command is available to be executed;

a verification that the request block has a valid format;

the I/O subsystem is capable of performing a check of the deconfigure storage class memory command, and wherein the deconfigure process continues to execute in response to the one or more validity checks being successful.

11. The computer system of claim 9, wherein the initiating further comprises: in response to the one or more validity checks being successful, initiating an asynchronous process to perform the deconfiguration of the storage class memory, wherein contents of the deconfigured storage class memory are initialized to zero and placed in a standby state.

12. The computer system of claim 11, wherein the method further comprises indicating completion of the asynchronous process in a notification response block.

13. The computer system of claim 12, wherein the notification response block includes a response code indicating a result of the attempt to execute the deconfigure storage class memory command.

14. The computer system of claim 13, wherein the notification response block is obtained via execution of a store event information command to obtain event information.

15. The computer system of claim 12, wherein the request block is further configured to include an asynchronous completion correlator to be returned in the notification response block, the asynchronous completion correlator to be used to resume processing of the deconfigure storage class memory command.

16. The computer system of claim 9, wherein the deconfiguration process comprises:

moving the increment of memory from a configuration state to a retention state;

zeroing the contents of the increment of memory; and

placing the increment of memory in a standby state.

17. A computer program product for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the computer program product comprising:

a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing the method according to any one of claims 1 to 8.

Claims (17)

1. A method for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the method comprising:

obtaining, by an input/output (I/O) subsystem, a request block comprising a command code indicating a deconfigure storage class memory command and a Storage Class Memory (SCM) increment request list comprising one or more entries, each entry configured to include a total size field indicating a number of increments of storage class memory to be deconfigure and a starting SCM address indicating a starting location of a deconfigure storage class memory increment;

based on the command code, initiating a deconfiguration process for deconfiguring the storage class memory, the process configured to deallocate the requested number of storage class memory increments specified in a total size value, wherein the initiating includes performing one or more validity checks;

in response to the one or more validity checks being successful, continuing the deconfiguration process of the storage class memory, wherein the one or more validity checks include determining that an increment of storage class memory to be deconfigured is in a configured state; and

Storing a response code in a response field of a response block, the response code indicating whether the deconfiguration process was initiated, the response block including a length code indicating a length of the response block.

2. The method of claim 1, wherein the one or more validity checks further comprise:

checking a length field of the request block;

a check of whether the deconfigure storage class memory command is available to be executed;

a verification that the request block has a valid format;

the I/O subsystem is capable of performing a check of the deconfigure storage class memory command, and wherein the deconfigure process continues to execute in response to the one or more validity checks being successful.

3. The method of claim 1, wherein the initiating further comprises: in response to the one or more validity checks being successful, initiating an asynchronous process to perform the deconfiguration of the storage class memory, wherein contents of the deconfigured storage class memory are initialized to zero and placed in a standby state.

4. The method of claim 3, wherein the method further comprises indicating completion of the asynchronous process in a notification response block.

5. The method of claim 4, wherein the notification response block includes a response code indicating a result of attempting to execute the deconfigure storage class memory command.

6. The method of claim 5, wherein the notification response block is obtained via execution of a store event information command to obtain event information.

7. The method of claim 4, wherein the request block is further configured to include an asynchronous completion correlator to be returned in the notification response block, the asynchronous completion correlator to be used to resume processing of the deconfigure storage class memory command.

8. The method of claim 1, wherein the deconfiguration process comprises:

moving the increment of memory from a configuration state to a retention state;

zeroing the contents of the increment of memory; and

placing the increment of memory in a standby state.

9. A computer system for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the computer system comprising:

a memory; and

a processor in communication with the memory, wherein the computer system is configured to perform a method comprising:

Obtaining, by an input/output (I/O) subsystem, a request block comprising a command code indicating a deconfigure storage class memory command and a Storage Class Memory (SCM) increment request list comprising one or more entries, each entry configured to include a total size field indicating a number of increments of storage class memory to be deconfigure and a starting SCM address indicating a starting location of a deconfigure storage class memory increment;

based on the command code, initiating a deconfiguration process for deconfiguring the storage class memory, the process configured to deallocate the requested number of storage class memory increments specified in a total size value, wherein the initiating includes performing one or more validity checks;

in response to the one or more validity checks being successful, continuing the deconfiguration process of the storage class memory, wherein the one or more validity checks include determining that an increment of storage class memory to be deconfigured is in a configured state; and

storing a response code in a response field of a response block, the response code indicating whether the deconfiguration process was initiated, the response block including a length code indicating a length of the response block.

10. The computer system of claim 9, wherein the one or more validity checks further comprise:

checking a length field of the request block;

a check of whether the deconfigure storage class memory command is available to be executed;

a verification that the request block has a valid format;

the I/O subsystem is capable of performing a check of the deconfigure storage class memory command, and wherein the deconfigure process continues to execute in response to the one or more validity checks being successful.

11. The computer system of claim 9, wherein the initiating further comprises: in response to the one or more validity checks being successful, initiating an asynchronous process to perform the deconfiguration of the storage class memory, wherein contents of the deconfigured storage class memory are initialized to zero and placed in a standby state.

12. The computer system of claim 11, wherein the method further comprises indicating completion of the asynchronous process in a notification response block.

13. The computer system of claim 12, wherein the notification response block includes a response code indicating a result of the attempt to execute the deconfigure storage class memory command.

14. The computer system of claim 13, wherein the notification response block is obtained via execution of a store event information command to obtain event information.

15. The computer system of claim 12, wherein the request block is further configured to include an asynchronous completion correlator to be returned in the notification response block, the asynchronous completion correlator to be used to resume processing of the deconfigure storage class memory command.

16. The computer system of claim 9, wherein the deconfiguration process comprises:

moving the increment of memory from a configuration state to a retention state;

zeroing the contents of the increment of memory; and

placing the increment of memory in a standby state.

17. A computer program product for executing a deconfigure storage class memory command in a computing environment comprising main storage and storage class memory, the computer program product comprising:

a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing the method according to any one of claims 1 to 8.