6947ch06.fm

Draft Document for Review April 7, 2004 6:15 pm

Option 1: Java dispatching by priority (honor_priority=yes)

Option 1 is the default option and specifies that standard CPs execute both Java and non-Java work in priority order when zAAPs are not configured. When zAAPs are configured they only execute Java work in priority order while the CPs execute normal tasks and JVM tasks in priority order. This option is oriented towards servicing work with the highest priority first, regardless of the type of work.

Option 2: Java discretionary crossover (crossover=yes)

Standard CPs execute Java work in priority order only if no non-Java (standard) work is available to be dispatched. This way Java work may execute on a CP as if it has a lower priority than the non-Java work. This option is oriented towards environments where not enough zAAP capacity is available and the Java work has no need for priority over non-Java work. When executed on a zAAP, Java work is handled in priority order.

Option 3: No Java crossover (crossover=no)

This option is set to prevent Java work to be executed on a CP. If for example Sub Capacity Workload License Charging is applicable, Java work that is executed on a CP will increase CP utilization and consequently may increase the software charges for non-Java work. Also, is ample zAAP capacity is available this option assures that all Java work is done on a zAAP. Only if the last available zAAP would fail, crossover to a standard CP is enforced.

6.2.3 HCD support

HCD support for both Compatibility support, and Exploitation support allows the definition of the z990 processor and I/O configuration from an existing system. If the z990 processor is part of a S/390 microprocessor cluster, the HCD support also allows the IOCDS to be written directly from an existing system. The new HCD elements apply to z/VM and z/OS.

HCD uses a concept: the validated work IODF. This is a new status for an IODF data set. It contains a complete set of validated processor, LCSS, partition, channel, control unit, and I/O device definitions. A validated work IODF would not normally contain the physical channel identifiers (PCHIDs) for channels.

Closely allied with this function, support is added to allow HCD to work with the z990 CHPID Mapping Tool (CMT) to assign PCHIDs. This support allows an IOCP source statement data set to be created from a validated work IODF; it also allows the data from the CHPID Mapping Tool to be merged with the validated work IODF to complete the PCHID assignments.

Compatibility support for HCD allows an installation to do the following:

￿Define a z990 environment with multiple Logical Channel Subsystems

￿Make dynamic hardware changes to LCSS 0 only. Devices cannot be added, modified or deleted if they are also defined to another LCSS. This requires a Power-on Reset.

Exploitation Support for HCD has full dynamic change support for all LCSSs.

6.2.4 Automation changes

Several commands and messages have been adapted to accommodate the two-digit LPAR identifier.

6.2.5 SMF support

CPU and PR/SM activity data is recorded by RMF in the SMF type 70 subtype 1 records. Prior to the z990, these records were always shorter than 32 KB. With the increased number

140IBM eServer zSeries 990 Technical Guide

Page 153 Page 155
Page 154
Image 154
IBM 990 manual HCD support, Automation changes, SMF support
Page 153 Page 155

990 specifications

The IBM 990 series, often referred to in the context of IBM's pioneering efforts in the realm of mainframe computing, represents a unique chapter in the history of information technology. Introduced in the late 1960s, the IBM 990 series was designed as a powerful tool for enterprise-level data processing and scientific calculations, showcasing the company's commitment to advancing computing capabilities.

One of the main features of the IBM 990 was its architecture, which was built to support a wide range of applications, from business processing to complex scientific computations. The system employed a 32-bit word length, which was advanced for its time, allowing for more flexible and efficient data handling. CPUs in the IBM 990 series supported multiple instructions per cycle, which contributed significantly to the overall efficiency and processing power of the machines.

The technology behind the IBM 990 was also notable for its use of solid-state technology. This provided a shift away from vacuum tube systems that were prevalent in earlier computing systems, enhancing the reliability and longevity of the hardware. The IBM 990 series utilized core memory, which was faster and more reliable than the magnetic drum memory systems that had been standard up to that point.

Another defining characteristic of the IBM 990 was its extensibility. Organizations could configure the machine to suit their specific needs by adding memory, storage, and peripheral devices as required. This modular approach facilitated the growth of systems alongside the technological and operational demands of the business environments they served.

In terms of software, the IBM 990 series was compatible with a variety of operating systems and programming environments, including FORTRAN and COBOL, enabling users to access a broader array of applications. This versatility was a significant advantage, making the IBM 990 an appealing choice for educational institutions, research facilities, and enterprises alike.

Moreover, the IBM 990 was engineered to support multiprocessing, which allowed multiple processes to run simultaneously, further increasing its effectiveness in tackling complex computing tasks.

In summary, the IBM 990 series represents a significant advancement in computing technology during the late 20th century. With a robust architecture, versatile configuration options, and a focus on solid-state technology, the IBM 990 facilitated substantial improvements in data processing capabilities, making it a cornerstone for many businesses and academic institutions of its time. Its impact can still be seen today in the continued evolution of mainframe computing.
Top Page Image Contents