6947ch06.fm

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

–If the set CPUID command has been issued, bits 0-7 are set to ‘FF’ by z/VM and bits

8-31 are set to the value entered in the set CPUID command. Bits 32-63 are the same as they would have been without running as a z/VM guest.

Table 6-5shows the possible output returned to the issuing program for an operating system running as a guest under z/VM.

Table 6-5 STIDP output for z990, VM guest

 

Version

CPU identification number

Machine

 

 

code

 

 

type number

 

 

 

 

 

 

 

Bit position

0-7

8-15

16-31

32-48

48-63

 

 

 

 

 

 

Without

x’FF’

LPAR ID

4-digit number derived from

x’2084’

x’8000’

set CPUID

 

 

the CPC serial number

 

 

command

 

 

 

 

 

 

 

 

 

 

 

With

x’FF’

6-digit number as entered by the

x’2084’

x’8000’

set CPUID

 

command SET CPUID = nnnnnn

 

 

command

 

 

 

 

 

 

 

 

 

 

 

￿STSI, Store System Information instruction

The STSI instruction returns the processor software model as a 16-byte character field. It also returns the same processor type that is returned by the STIDP instruction and the full serial number information.

The STSI instruction always returns the latest processor software model information, including information about the new processor model after a concurrent model upgrade has occurred. This is key to the functioning of CUoD, On/Off CoD, CIU and CBU.

Channel to Channel links

After a concurrent upgrade, the channel CPC Node-Descriptor (NED) information is not updated until after a processor POR.

Additional planning may be required in a multisystem environment with CTCs linking different processors. NED information, which includes serial number, machine type, and model, is exchanged between systems on the CTC link. As a way to prevent cabling errors, CTCs will go into a “boxed” state if the NED information changes without having taken the proper actions. Boxed CTCs may impact XCF, VTAM®, IMS™, and other software products.

Dealing with boxed CTCs in a multisystem environment is not new; it occurs during the POR after traditional disruptive upgrades. However, in the case of a concurrent upgrade, the node-descriptor information (model number) will not change until the next POR, which may be months after the actual upgrade. At that time, the customer needs to be prepared to deal with the boxed CTCs. It is important to consider and prepare for the case where, during an unplanned POR of the upgraded process, the CTCs become boxed.

The boxing of CTCs can be avoided if, during the concurrent upgrade, the CTC links between systems are deallocated and then varied off-line. However, when alternate communication links are not available this may be disruptive to applications.

The alternative is to be prepared for the boxed CTCs to occur during the next POR of the upgraded system. In most cases, using the UNCOND option of the VARY ONLINE command will un-box the CTCs in a nondisruptive manner.

The implications of boxed CTCs, particularly on ISV products, should be investigated during the planning process prior to a concurrent upgrade.

152IBM eServer zSeries 990 Technical Guide

Page 165 Page 167
Page 166
Image 166
IBM 990 manual Channel to Channel links
Page 165 Page 167

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