Flexible, nondisruptive upgrade capabilities and self-healing characteristics in IBM eServer systems are currently being addressed. The IBM eServer z900 and preceding S/390 ® servers have been delivering leading-edge self-configuring, self-optimizing, self-protecting, self-managing, and self-healing capabilities that provide a solid foundation for those efforts. Current processors, memory, and input/output (I/O) cards are produced with dense physical packaging at high volumes without requiring fine configuration granularity. The granularity is provided under the control of Licensed Internal Code (LIC), which enables hardware entities to fulfill specific requirements based on encrypted product data. Disabled hardware entities are "dormant" and are reserved for capacity upgrades or self-healing. Concurrent capacity upgrade functions enable dormant hardware entities to reflect the new configuration. In case of hardware failure, healthy dormant hardware can be enabled, without disruption, to replace failing hardware. This paper describes the high level of concurrent configuration-change flexibility provided in the IBM eServer z900 and the asset protection approach on which it is based.

No abstract

When the PL8 64-bit GNU compiler collection front end was introduced with the IBM z990 system, it laid the foundation to move toward an open-standard development environment for the i390 layer of IBM System ze host firmware. However, when the z990 system was developed, the proprietary project development library system and the table of contents object file format for i390 code were still being used. With the IBM System z9e, we have moved to a fully open-standard development environment. This paper describes the steps we took to get there, to improve code performance, development efficiency, and regression testing, and to develop base functionality for important System z9 features such as enhanced driver maintenance. We also discuss plans to further enhance the development environment for future systems.

The communication interface between support element applications and applications running on the zSeries system processors is an essential part of the zSeries system design. For example, the interface is used to load firmware during startup, it is used for service actions such as configuring or deconfiguring I/O channels, and for many other functions. It must be fast, reliable, and failsafe. A special hardware interface in the clock chip is used to connect the service infrastructure (support element and cage controller) to the central electronic complex (CEC). Four firmware parties are involved in the communication: support element, cage controller, and two firmware layers running on the processors in the CEC: millicode and i390 code. Starting with the z900, the interface between the support element and cage controller was implemented using the NetMessage protocol, whereas the interface between the cage controller and processors still used the legacy service-word communication protocol from previous IBM S/390 models. This meant that the cage controller had to translate the NetMessage protocol from the support element side to the legacy service-word protocol toward the CEC side. In the z990, the communication interface between the support element and the CEC was generally replaced by the NetMessage protocol. The following paper describes the new design and structure of the support element to CEC communication.

No abstract