One of the primary functions of any computing system is to process the input data. Much of the data that is processed exists external to the processor's storage. That is, it might be all on tape, or it might be out on the DASD volume, or it could be entered from a terminal. The Helen data requires the services of both software and hardware, which is the channel subsystem, and the devices attached to it. Understanding the roles of software and hardware in handling I/O request is necessary for determining how to configure the hardware, how to tune it, and how to analyze I/O-related problems. In this unit, you'll learn about the purpose of HCD, the components of the channel subsystem, and how I/O operations perform. Also, you'll learn how a system can dynamically add or delete devices while it's running. Covered also in this unit is the purpose of load address, the load parm and so much more. The hardware configuration facility, or what we call HCD, is part of z/OS and is used to define the I/O configuration to both the hardware and to the software. HCD provides dialogues on to TSO. They'll let you interactively define configuration information, and if you make a mistake, in many cases, HCD will notify you of that mistake. We'll learn more about this later in this unit. When you build IODF, the output of HCD is a file called IODF, input/output definition file. You specify which DASD devices IODF will live on in the load parm. What is HCD? HCD basically defines what software and what hardware your system will use. It will define the software devices that your system will use at IPL time and these will become UCBs. It defines all the hardware and all the paths from the system, through the channel, and a switch if you use one, that connect to the control unit. The switch is defined to the devices. From the control unit, it defines all the hardware and it'll pass from the system through the channel. It defines a switch if it's used to connect to the control unit. Then the switch is defined too. From the control unit, it defines all the devices on the control unit, which in POR time, will become UCWs, which is also known as sub-channels. HCD also builds the input/ output configuration program, or what we call IOCP, and is used to generate I/O configuration data set based on user-defined inputs. In the past, this was something that the system programmer had to spend hours building. Now HCD does it in a matter of minutes. The I/O configuration data set or IOCDS contains the control blocks that will be built by IOCP. These will be the subchannels that the channel subsystem will use at the end of the POR. The hardware and software definitions will then be mapped together to an IPO. If a match to the hardware is not found, the device is unusable. Making sure this step is correct is vital to accessing all the devices that are attached to your system. Before any processing can be done, a program and its data must reside in a processor's central storage. During a POR process, the boundaries of central storage are set up and during the LP activation, DASD storage is split among the L bars depending on the values defined in the HMC image profile. The input-output operations results in the transfer of information between central storage and I/O devices. Usually, something called a SAP. A SAP is simply a system assist processor, which on our IBM systems are used to channel I/O. A SAP is simply CP that is dedicated to do I/O work. Data is normally stored separately from the program on an external storage device, such as DASD or tape. All the hardware components such as the channel subsystem, control unit, and channel pairs are necessary to connect the external storage device to the processor. The channel subsystem processes I/O request, queues I/O, selects paths, and presents interrupts. It includes a collection of channel paths, the collection of control units, and I/O devices which it can use. The channel path is a data path to transfer control and user data between central storage and the control unit. It's the connection between a processor and a control unit along which signals and data can be sent to perform I/O requests. The control unit interprets commands which initiates actions on the device. The control unit will respond to the channel path signals, then interpret channel command words. Finally, controls device operations. The I/O device performs the actual I/O and data transfer and control. The device does the work, then analyzes the results, and transfers the data back to the control unit on a request. Let's now talk about terminology. Here we see the PCIe I/O drawer, the I/O drawer, and the I/O cage. A cage or drawer is an infrastructure that houses I/O cards and other I/O-related components. The PCIe is the most recent enhancement. Next, we have I/O subsystem. All z system servers have one I/O subsystem which uses one IOCDS and one single HSA. HSA stands for hardware systems area. We'll talk more about the HSA later. With z systems, we have something new, that is the logical channel subsystem, or what we call LCSs. The z system servers can use up to six LCSs depending on the z model. Before we had LCSs, the most channels that a system could have was 256. That'd be addresses 00 to fox fox. But now assigning LCSs, we can now have 256 channels per LCSs, now allowing systems to grow way beyond that 256 limitation. A physical CHPID, or what we call a PCHID, is the physical location that is mapped to a channel path, or CHPID. A PCHID is unique to the server and a CHPID is unique to the LCSs. CHPIDs will always have addresses 00 to fox fox. PCHIDs, however, do not use this number convention. Finally, the function identifier, the FID, is a new IOCP statement used to identify the specific hardware feature on a PCIe I/O drawer. Function is not related to a channel subsystem. Let's now try to put the pieces together. On this visual, we can see CPs, SAPs, cache, I/O adapters, all going through HCAs. HCA is the host channel adapters. They all work together to process instruction and I/O requests. The core process or CPs process instructions. The system assist processors, as I've mentioned before, work with the channel subsystem and does all the I/O processing through the I/O adapters. The HCA or the host channel adapters connect the CP drawers to the I/O drawers. The Z system architect, in conjunction with the operating system, provides hardware registers and formatted areas of storage. During the POR process, an area in upper central storage is reserved for the hardware. This area is called HSA or hardware systems area. It stores information that the channel subsystem needs to process requests. Those requests are used by the subchannels that I mentioned earlier. The area in central storage that is reserved for devices is called SQA, the system queue area and ESQA, extended system queue area. It is always a low area central storage. There are also program status registers, or what we call PSWs. One register for each CP. It contains information that's required for the execution of a currently active program. The z system works by using interrupts. Status, interrupt, instruction sequences of the new CP can be changed by loading a new PSW, or it can do a PSW swap when an interrupt occurs. In order to get to any device, a star subchannel commands issued to a device. Remember, at POR, those subchannels were created. At IPL time, those UCBs were created by the software. Now we have mapping for those devices to command any data sent to a CP to perform some operation, read or write. But that data is out on our device, so for a CP to handle the request and wait for I/O return, that data would be a waste of time for the CP. You'll probably be very disappointed in the performance of your processor. Instead, the system uses a SAP, system assist processor to do all the I/O work for it. There are a lot of control blocks that the channel subsystem uses to perform this I/O operation. We'll discuss more about how a channel operation works later in this chapter. That's it for now. In the next session, we'll take a closer look at HCD.
