IBM z13s Technical Manual page 129

The function that is assigned to a PU is set by the Licensed Internal Code (LIC). The LIC is
loaded when the system is initialized (at power-on reset (POR)) and the PUs are
characterized
.
Only characterized PUs have a designated function. Non-characterized PUs are considered
spares. Order at least one CP, IFL, or ICF on a z13s server.
This design brings outstanding flexibility to z13s servers because any PU can assume any
available characterization. The design also plays an essential role in system availability
because PU characterization can be done dynamically, with no system outage.
For more information about software level support of functions and features, see Chapter 7,
"Software support" on page 229.
Concurrent upgrades
Except on fully configured models, concurrent upgrades can be done by the LIC, which
assigns a PU function to a previously non-characterized PU. Within the CPC drawer
boundary or boundary of multiple CPC drawers, no hardware changes are required. The
upgrade can be done concurrently through the following facilities:
Customer Initiated Upgrade (CIU) for permanent upgrades
On/Off capacity on demand (On/Off CoD) for temporary upgrades
Capacity BackUp (CBU) for temporary upgrades
Capacity for Planned Event (CPE) for temporary upgrades
If the PU SCMs in the installed CPC drawer node have no available remaining PUs, an
upgrade results in a model upgrade (upgrade Model N10 to N20, same drawer). If the
upgrade is for more than 2048 GB of memory or additional I/O features, then installation of an
extra CPC drawer is necessary. However, there is a limit of two CPC drawers. CPC drawer
installation is disruptive, and takes more time than a simple LIC upgrade.
For more information about Capacity on Demand, see Chapter 8, "System upgrades" on
page 311.
PU sparing
In the rare event of a PU failure, the failed PU's characterization can dynamically and
transparently be reassigned to a spare PU if the physical configuration allows for it. The z13s
Model N20 has two spare PUs. PUs that are not characterized on a CPC configuration can
also be used as spare PUs. For more information about PU sparing, see 3.5.10, "Sparing
rules" on page 111.
PU pools
PUs that are defined as CPs, IFLs, ICFs, and zIIPs are grouped in their own pools, from
where they can be managed separately. This configuration significantly simplifies capacity
planning and management for LPARs. The separation also affects weight management
because CP and zIIP weights can be managed separately. For more information, see "PU
weighting" on page 102.
All assigned PUs are grouped in the PU pool. These PUs are dispatched to online logical
PUs.
As an example, consider a z13s server with 6 CPs, two IFLs, five zIIPs, and one ICF. This
system has a PU pool of 14 PUs, called the p
A CP pool of 6 CPs
An ICF pool of one ICF
ool width
. Subdivision defines these pools:
Chapter 3. Central processor complex system design
101