Using Unisphere for VMAX to Manage CKD Devices in zOS

White Paper
USING UNISPHERE FOR VMAX TO MANAGE
SYMMETRIX CKD DEVICES IN A z/OS
ENVIRONMENT
Abstract
This white paper provides an introduction to the capabilities of
Unisphere for VMAX for administering z/OS Mainframe-attached
devices. Delivering z/OS-specific configuration management
makes Unisphere a powerful tool for Symmetrix VMAX users in
the z/OS Mainframe environment.
June 2013

2Using Unisphere for VMAX to Manage Symmetrix CKD Devices in a z/OS Environment
Copyright © 2013 EMC Corporation. All Rights Reserved.
EMC believes the information in this publication is accurate as
of its publication date. The information is subject to change
without notice.
The information in this publication is provided “as is.” EMC
Corporation makes no representations or warranties of any kind
with respect to the information in this publication, and
specifically disclaims implied warranties of merchantability or
fitness for a particular purpose.
Use, copying, and distribution of any EMC software described in
this publication requires an applicable software license.
For the most up-to-date listing of EMC product names, see EMC
Corporation Trademarks on EMC.com.
Part Number h11631

Table of Contents
Executive summary...................................................................................4
Audience....................................................................................................................4
Overview................................................................................................5
Symmetrix configuration ..............................................................................................5
Unisphere for VMAX and Solutions Enabler....................................................................6
Unisphere for Count Key Data devices ...........................................................7
Array properties...........................................................................................................7
Free space ..................................................................................................................8
Device creation: CKD 3390 devices ...............................................................................9
Device duplication................................................................................................. 10
SSID management................................................................................................. 11
Mapping CKD devices ................................................................................................ 12
Device mapping.................................................................................................... 14
Mapping devices................................................................................................... 14
Unmapping CKD devices ............................................................................................ 15
Assigning aliases....................................................................................................... 16
Unassigning aliases................................................................................................... 17
Device online/offline considerations........................................................................... 18
CKD assignment change: EMC restrictions ................................................................... 18
CKD assignment change: z/OS restrictions .................................................................. 19
Conclusion................................................................................................................ 19
References...........................................................................................19
Appendix.............................................................................................21
Z series hardware complex......................................................................................... 21
Example of HCD configuration parameters ................................................................... 22
Parallel Access Volumes............................................................................................. 22
Planning addresses for static PAV........................................................................... 24
Planning addresses for dynamic PAV....................................................................... 26

Executive summary
As EMC®
storage-management tools have evolved to meet the intricate and wide-
ranging needs of many different enterprises, the capabilities of these tools have
increased, alongside their complexity. One outcome of the advancement in storage-
management functionality is a large and varied set of options available in each tool,
making EMC storage-management products very powerful but daunting to
inexperienced users.
In response to customer concerns for ease of use, EMC introduced Unisphere®
for
VMAX®
, which employs a simple and intuitive Web-based user interface to administer
the most common daily storage-management functions for a Symmetrix®
array. The
benefit is that Unisphere can be used quickly and efficiently by operators of all
experience levels.
When using Unisphere, Mainframe storage administrators can avoid consultation
with EMC personnel on array change-control activities and perform the actions
themselves, thus removing one level of complexity in the change-control process.
This allows for changes to be enacted in a more timely fashion, and it also avoids
communication errors when Unisphere is used by authorized customer administrators
who directly perform array modifications.
Unisphere puts control of the following Symmetrix array activities into the hands of
the Mainframe storage administrator:
• Device creation and removal
• Device base and alias addressing
• Local and remote replication
• Quality of service
Unisphere is intended to make array management faster and easier. Using dialog
boxes structured into configuration wizards, Unisphere accelerates setup,
configuration, and routine tasks. By providing simplified replication management and
monitoring, Unisphere delivers ease of use that translates into efficient operation.
Finally, managing for the future, Unisphere will make new functionality available in
the same simple intuitive manner, greatly lessening the learning curve necessary to
implement any new technology. With Unisphere, the Mainframe user community now
has a new choice in Symmetrix array management.
Audience
This white paper is intended for any reader interested in understanding the potential
of Unisphere for simplified management of Symmetrix array-configuration tasks for
the mainframe. It will be of particular interest to storage administrators, system
programmers, or any technology professional concerned with managing Count Key
Data devices on a Symmetrix storage platform. This paper assumes that the reader is
familiar with storage array-configuration requirements in a mainframe environment.

Overview
Unisphere delivers a Web-based graphical user interface that allows point-and-click
selection of objects and action sequences. User-selected objects and actions are
passed to the SYMAPI, enabling array management with the ease and intuitive
approach of point-and-click.
A z/OS Mainframe-attached Symmetrix must obey configuration characteristics
defined by the host operating system. Running Solutions Enabler on the z/OS host
provides some additional information not available to Solutions Enabler running on
the Unisphere server. These topics are explored in the following sections as a
prerequisite to the later examination of Unisphere mainframe-management activities.
Symmetrix configuration
When a Symmetrix array is connected to a mainframe, either ESCON (EA) or FICON (EF)
directors are present in the array. Based on the evolution of mainframe hardware
components, several key configuration structures are associated with the devices
addressed on the EA or EF directors.
In original mainframe implementations, a Control Unit (CU) managed commands from
the Channel Subsystem to a particular disk drive. Although early CUs had less than
256 drives assigned to them, this number of 256 represents today's maximum
devices that can be defined within a CU. As storage arrays advanced to contain more
than 256 volumes/devices, arrays presented Logical Control Units (LCUs) to the
Channel Subsystem, outgrowing the physical limits of previous hardware. Each CU,
and indeed each LCU, had its own unique Subsystem ID (SSID), and the legacy of
these structures remains in place today. Addressing on EA and EF directors is divided
into (Logical) Control Unit images that each have their own unique SSID and contain a
maximum of 256 devices.
Although the Symmetrix Storage array with EFs can emulate up to 255 (Logical)
Control Units per director port, another logical abstraction became necessary in some
customer environments. The new requirement was for the Symmetrix array to logically
represent several arrays. Within the EMC configuration program (SymmWin), each
logical array is referred to as a split. With splits defined, the Symmetrix array could
contain the same LCU addresses several times (duplicates), but the SSIDs for each
LCU would be unique. Each instance of the duplicate LCU address scheme is in a
different split, and each split appears as a separate array by slightly modifying the
original array serial number. Currently, manipulation of split definitions is only
available to EMC Customer Service Representatives, but LCU addressing and SSID
definition is achievable using Unisphere.
Within the LCU context, there are operating system restrictions surrounding the
devices. Disk hardware evolution is responsible for requirements built into the
Symmetrix configuration program. Disk-drive track formatting and disk-drive size has
been standardized by the mainframe disk products of the past. Although variation in
size is possible, normal configuration practices are to use the standard drive sizes
such as 3390-1, 3390-3, 3390-9, 3390-2,7 and 3390-54. Unisphere has these

definitions built into Configuration Wizards to make device creation as simple as
possible. When Parallel Access Volumes (PAVs) are present, only one type of
geometry can exist in each CU image. Also, 3380 track geometry is available with
Symmetrix arrays. EMC can mix 3380 disk geometry with 3390 geometry on a physical
drive. Further, when the (PAV) feature is not present, 3380 and 3390 devices can
exist in the same CU, although the need for this type of configuration has almost been
eliminated.
The process to build and load a configuration change by means of Unisphere parallels
the process used by EMC service staff. Symmetrix configurations are held in a binary
data structure commonly called the bin file. This configuration file is managed from
the Symmetrix Service Processor (SP) by way of the SymmWin application.
Configuration change parameters are collected by means of the point-and-click
interface of Unisphere and sent to the SYMAPI server. The SYMAPI server generates
System Calls (Syscalls) to pass the configuration parameters to the Symmetrix array
where SymmWin builds a new bin file, combining the current configuration with the
Unisphere configuration change parameters. Validity checks are performed against
the new bin file, and if the intended configuration upgrade is legal, a script is initiated
to load the new configuration.
Unisphere for VMAX and Solutions Enabler
Unisphere is installed on a Windows, UNIX, or Linux Server where it runs as a service
or a process. A Unisphere user (client) communicates with the Unisphere Service by
means of a web browser, such as Internet Explorer, Chrome, or Firefox. The Unisphere
service/process allows the client to select array objects and action options with a
point-and-click interface. The Unisphere service/process then passes the collected
parameters to the Solutions Enabler SYMAPI, which accomplishes the low-level
completion of the array-management task.

Figure 1. Unisphere for VMAX with remote SYMAPI installation
Unisphere can be installed with the SYMAPI running on the same server as Solutions
Enabler (SE). This is a local installation. Unisphere can also be installed with the
SYMAPI running on a different server as Solutions Enabler. This is a remote
installation. For Unisphere management of Count Key Data (CKD) devices in a z/OS
environment, there is a benefit to installing Unisphere with Solutions Enabler running
remotely on the z/OS host. This remote installation is shown in Figure 1. In this
diagram, the SYMAPI has access to z/OS information about online Symmetrix
devices. This z/OS information includes VOLSER and device-number details obtained
from the z/OS operating system. In Figure 2, the Unisphere display of CKD Regular
Volumes shows the Unit Control Block (UCB) address and VOLSER information. If the
VOLSER and the UCB address are required for management of Symmetrix devices,
then Unisphere must be installed with Solutions Enabler running under z/OS.
Figure 2. Remote SYMAPI installation can obtain VOLSER and device number
Unisphere examples used within this document are based on the following minimum
versions of software: Unisphere for VMAX V1.5.1, EMC Solutions Enabler V7.5, and
Enginuity™ version 5876 Q2 2013 SR.
Unisphere online help provides additional details on the full range of Unisphere
Symmetrix resource-management functionality.
It is advisable to invoke the appropriate z/OS DISPLAY, DEVSERV, VARY device and
PATHING related system commands to validate Unisphere Symmetrix configuration
changes. Refer to the appropriate IBM z/OS reference documentation, z/OS System
Commands, for detailed system-command syntax.
Unisphere for Count Key Data devices
Array properties
Symmetrix array management begins by understanding the elements available for
control and the action items that can be performed with these elements. Figure 3
captures the CU Images view from a Unisphere instance. For CKD devices, the CU
images are immediately visible in the object tree under the Symmetrix unit. This
allows for easy interrogation of CU devices and properties. On the right-most side,
Common Tasks are displayed. They are capable of opening additional Configuration
Wizards.
As expected with a point-and-click interface, further properties information is
available by selecting additional fields. Select SSID 0x01, and the next display will

show Properties for that SSID. Once that display is visible, select Volumes–240 for a
list (abbreviated in this example) of volumes assigned to that CU Image.
Figure 3. Unisphere array properties
Free space
Understanding free space on a Symmetrix system is an important aspect of array
management. In System Dashboard, a feature of Unisphere, physical and virtual
capacity, both free and used, are reported. An easy-to-read graphic is displayed,
giving a very obvious used-to-free capacity comparison (see Figure 4 on the following
page). Although fixed-block architecture and CKD architecture can exist on the same
physical drive, the free-capacity report presents information in one format only, and
that is in terms of drive native blocking, 512 bytes per block. Emulation of the CKD
format consumes slightly more space than native blocking on the disk.
Free-space information is relevant when creating additional devices and also may be
useful when confirming performance configurations where drives are deliberately left
underutilized. Be aware that as maximum disk capacity is approached, the total free
space may become more difficult to fill. Although free space can be reported, device-
creation requests may not find sufficient contiguous space on appropriate drives for

the desired protection strategy. Unbalanced utilization of drives may leave some
protection partners (RAID groups or mirror groups) with uneven free space and the
inability to complete a device-creation request.
Figure 4. Unisphere: Free space
Device creation: CKD 3390 devices
Figure 5 shows the Storage Volumes dashboard. From here, select Create Volumes
under the Common Tasks heading to open the Configuration Wizard.
Figure 5. Unisphere : Free Space
Figure 6 illustrates the Unisphere selection choices necessary to create new devices.
The array object has already been selected and identified by serial number on the
Unisphere home page.
From this point, navigate to the Storage display, and select Volumes. Then select
Create Volumes under Common Tasks. This opens the Create Volumes Configuration
Wizard. In this example, a CKD-3390 10017 cylinder volume is requested. The new

volume will be created as a 2-Way Mirror with 7.93 GB capacity from space on any
available disk.
The Select SSID tab, when activated, indicates the current number of SSIDs in use,
mapped and unmapped devices, device numbers currently present, and maximum
devices allowed (256). This example uses SSID 0001 as a temporary SSID for the
newly created, but currently unmapped, device.
When the device mapping option is used to map the newly created device to the
appropriate EF/EA directors, the final SSID will be specified. Refer to the “SSID
management” section on page 11 for more information on why a temporary SSID is
used between device creation and device mapping. Also, note that the device-
creation dialog box has selectable tabs to create other volume types, Virtual, Private
or Template. This example shows the Regular device creation template, but all four
templates are available in the dialog box to create the various device types.
The dialog box presents options to either create the volume immediately or Add to Job
List so it can be created at a later time or date.
Figure 6. CKD-3390 device creation
Device duplication
The example of device creation uses a Configuration Wizard to prompt for correct
parameter input. But once those parameters have been supplied, it is necessary to
supply them again for future creation tasks. If there are volume standards, an existing
device can be a model for the duplication of that type of volume. By using the
principle of duplication, the creation process is simplified even more. Figure 7
outlines the duplication option.
Select Storage> Volumes to open the Volume Dashboard. In the Volume Type panel,
select the type of volume, and then select View to open the Volumes lists. Select the

volume, and select > (>> which translates to More) to open the Duplicate Volume
dialog box.
The number of new devices is an essential parameter that must still be supplied.
Another necessary input is the temporary SSID that will be used until the new devices
are assigned to EF/EA directors. There is an Override option that can be used to
modify any parameter in the template, however, it must be used every time to specify
the temporary SSID. Refer to the “SSID management” section for more information on
why a temporary SSID is used between device creation and device mapping.
Because Unisphere intelligently activates options applicable to selected objects and
tasks, the Device duplication template will not be available for SRDF® devices. These
devices require the specification of remote parameters. The template does not
accommodate entries for remote parameters. If SRDF devices are used as the model
device, the Duplicate Device option will be unavailable.
Figure 7. CKD-3390 device duplication
SSID management
z/OS has rules for subsystem IDs (SSIDs) that are enforced by Unisphere when
creating a Symmetrix configuration for CKD devices. By enforcing the operating
system rules, Unisphere prevents illegal configurations being loaded onto the
Symmetrix system. One such z/OS rule policed by Unisphere is that all devices with
the same SSID must be assigned to the same set of channels (EA/EF director set).
Because device-creation and device-mapping operations are performed in two
separate configuration load operations, there is always a period of time when devices

exist but are not mapped. Consequently, a temporary SSID must be chosen at device
creation and remain in place until the mapping task is completed for operations that
are not exactly a CU image (256 or a multiple of 256 devices). Each of the three
preceding discussions of device creation includes this mandated use of a temporary
SSID at device creation until the new devices are assigned to EA/EF directors.
The other essential SSID rule specifies that there must be only one SSID within a CU
image (of 256 devices.) Care must be taken when selecting the final SSID. There is
only one correct value if addresses already exist to define a CU image, and that is the
existing SSID for that CU.
Mapping CKD devices
To access a device from a mainframe host, the device must be mapped to one or
more front-end EA or EF director ports. The Hardware Configuration Definition (HCD)
should be configured to reflect the Symmetrix devices, and the associated Input
Output Definition File (IODF) must be loaded and active.
Front-end port mapping is the Symmetrix mechanism for exporting the logical view of
devices to the z/OS system. Devices are usually offline to z/OS until a Volume Table
of Contents (VTOC) is in place and a Vary Online command marks the device as ready.
Completion of these steps allows the mainframe host to recognize devices as ready
for read and write operations. Unmapped devices have been created but have either
never been mapped or were mapped and later explicitly unmapped. As shown in
Figure 8, a group of devices becomes part of a CU image when mapped to front-end
EA or EF ports. UCBs manage device addresses within the z/OS operating system. The
LPAR (Logical Partition) is a subset of processing resources within a complex that
forms the environment containing the running operating system.
Figure 8. CU images and mapped devices
A z/OS mainframe can access multiple CU images. A CU image contains up to 256
device addresses (numbered 0x000 through 0x0FF). A device can be in only one CU
image. Each CU image has a unique Subsystem ID (SSID). By contrast, the Symmetrix
system can have many CU images, the total of which is dependent on model and
Enginuity code level.

When PAVs are enabled, the base and alias addresses for a device must be the same
across all ports of an EA processor. (An EF does not have multiple ports.) Although it
is common for EA port A(0) and port B(1) to be mapped exactly the same, some older
configurations addressed port A(0) to one range of devices and port B(1) to a different
range of devices. Once PAV is enabled, these mixed configurations are no longer
valid.
Commencing with Enginuity 5771, an enhanced split configuration management
structure was incorporated into the Symmetrix configuration program. The new split
structure reduced the time required to correlate and manage split path groups.
Unisphere detects the running Enginuity version for each array and intelligently
enables the appropriate command templates. Examples of both command templates
are shown in the following pages.
A Symmetrix split can contain multiple LCU images. The CU images are bound to
selected EA/EF director ports defining the split. Currently, 16 splits can be configured
in a Symmetrix system running Enginuity 5771 and higher.
It is possible to map duplicate CU image numbers to different splits. Duplicate
(Logical) Control Unit images are assigned to different Symmetrix devices and have
different SSIDs. The array serial number presented by each split is slightly modified to
allow the associated host’s LPAR to interpret the duplicate CU image number as a
(Logical) Control Unit within a unique array. In this manner, IOCP conformity can be
maintained when replacing a number of existing smaller Symmetrix units and
collapsing the existing configurations into the single larger Symmetrix system.
Figure 9 shows the Unisphere CU Image display for the Symmetrix array, serial
number 4575. The list of CU Images shows duplicate CU numbers. In this case, there
are two instances of CU 00. The presence of two instances of the same CU image
indicates that two splits are active. Notice however that even though the CU numbers
are duplicated, the SSID is unique. Whether the CU image is online or offline all SSIDs
within a complex must be unique.
Figure 9. Duplicate CU image numbers indicating splits

Device mapping
Because Enginuity includes the split management screen (see “Mapping CKD
devices” on page 12), mapping for EA/EF directors in a group is accomplished
automatically by the SymmWin application. Choosing one EA/EF port in a group
means all ports in that group receive the same mapping. However, the previously
discussed situation for port addressing when PAVs are enabled is still in effect. The
base and alias addresses for a device must be the same across all ports of an EA
processor. (Again, an EF does not have multiple ports.) Although both ports must
have the same addresses, they should not map to the same LPAR. The A(0) and B(1)
ports share the one logical processor (multiplexed). If ports in this mode are
configured to the same LPAR, excessive CU Busy and CU End conditions and
contention could exist during z/OS Channel Path rotation selection. The possibility of
contention is alleviated when addresses for the A(0) and B(1) ports are attached to
different LPARs.
Remember, the first base address assigned to a CU image must be a multiple of
0x010. When planning to add base addresses using Unisphere functionality, it is
important that this MVS restriction be observed. If base address 00 is in place,
satisfying the MVS rule, then all other address modifications are legitimate.
Mapping devices
When performing a mapping operation, the devices exist but are not yet in a CU.
Select Storage> Volumes to open the Volume Dashboard under the appropriate array,
which is identified by serial number. In the Volume Type panel, select CKD. Under
General Volumes, select Regular,Virtual,Meta or Private. Next, select the Volume
type (in this example, Private/2-Way Mir). Select View to open the Volumes lists. If the
list of correct devices for mapping is known, any device can be selected and the
mapping template started and completed using the known device numbers. Choose
the volumes, and click z/OS Map to open the z/OS Map dialog box.
The z/OS Map Volume dialog box requires the following entries, as detailed in Figure
10:
• The device range to be mapped.
• The base address, including the identifying CU number.
• The starting alias address, if aliases are to be used. (For information on aliases,
see “Assigning Aliases” on page 16.)
• The correct SSID for this CU. (The SSID number will be unique within the Complex.
It corresponds to one of the ports that currently is grouped in the split and has the
same addressing.)

Figure 10. Mapping devices
Unmapping CKD devices
A range of CKD devices with base addresses can be unmapped from the associated
EA or EF ports. If the devices being unmapped have alias addresses allocated in the
configuration, all the aliases in the CU image are also removed. Aliases are specified
as a range, and holes in the alias range caused by device removal is prevented. When
aliases are removed, the whole range is removed and added back in a contiguous
block.
Once alias considerations have been resolved, the unmapping process can be
completed. An item worthy of note is that the first base address assigned to a CU
image must be a multiple of 0x010. When planning to remove base addresses, it is
important that this z/OS restriction be observed. If base address 00 remains in place,
satisfying the z/OS rule, then all other address modifications are legitimate. When
unmapping z/OS devices, associated paths should be varied offline to the devices.
Ensure that volumes/datasets are deallocated to z/OS resources prior to any
unmapping activities.
Note: When all devices are unmapped from an ESCON or FICON director, that director
will go into a DD state. Symmetrix configuration scripts know when to expect this
state, and steps are in place to accommodate the presence of DD directors, but the
script is lengthened when bringing DD directors back to full functionality.

When performing an unmapping operation, select Hosts> CU Images to open the CU
Images view. (In this example, specific volumes are chosen to be unmapped.) The CU
Image object contains the existing mapped devices, therefore, the CU Image is the
appropriate starting control object. Select the correct CU object available under the
correct array, which is identified by serial number. Select the CU Image and the SSID
that contain the volumes that are to be unmapped. Select the volumes, and click
z/OS Unmap. This opens a Configuration Wizard dialog box.
The z/OS Unmap Volumes dialog box requires the following entries, as detailed in
Figure 11:
• The device range to be unmapped.
• The SSID that will be used while the devices are unmapped. (See “SSID
management” on page 11.)
• One of the ports that currently is grouped in the split and has the same
addressing. The unmapped devices will be unmapped from all the grouped ports
simultaneously by the split management in SymmWin.
Figure 11. Unmapping devices
See “Mapping CKD devices” on page 12 for an explanation of the split concept.
Assigning aliases
In the event that improved I/O device performance is required, Unisphere provides for
the assignment of alias ranges to base devices. (Refer to IBM WLM DASD
characterization benchmarking analysis). On a Symmetrix array running Enginuity

56XX or earlier, you have to assign PAV alias addresses. However, with Enginuity
5771 and higher, you can now assign a range of PAV aliases to mapped CKD volumes.
Select Hosts> CU Images to open the CU Images view. Figure 12 shows the Unisphere
dialog-box choices to assign an alias range. Select CU Image 0x00, and click > (More)
to open the Assign Alias Range dialog box. Enter the values for the starting and
ending alias addresses, and execute the dialog box.
Figure 12. Assigning alias range
Unassigning aliases
Unisphere provides for the removal of alias ranges from base devices in the event
that additional channel addresses are required for allocation to Symmetrix devices
(returning base addresses to the CU). Figure 13 shows the Unisphere dialog-box
choices to unassign alias range F0 through FF on CU number 00.

Figure 13. Remove alias range
Device online/offline considerations
The CKD assignment-change rules and device online/offline considerations are
summarized here. The information is from Primus Solution EMC77918.
1. A device must only be in one CU.
All addresses for a given device must be the same on all ports to which that
device is mapped. In the past, it was possible to address a device as 00 on some
ports and 100 on other ports. This was still base address 00, however, it reflected
a different CU image on different ports. Such addressing is no longer legal.
2. Empty ports are not allowed.
If a configuration change involves temporarily removing all devices from a
director, then the task will be treated as removal and re-addition of the director.
The director will drop DD and be reloaded with a single director IML.
3. Devices shared with FBA can have aliases (InfoMover and FDR/SOS).
4. Two different splits in a Symmetix unit cannot intersect.
A split uses a serial-number modifier to generate a slightly different serial number
to the host. Each split in a Symmetrix array presents a unique CU serial number to
the mainframe host, and there are a maximum of 16 splits allowed in a Symmetrix
frame. Obviously, you cannot have overlapping serial numbers. Illegal bins with
serial-number modifier errors cannot be created with the CKD assignment
capability.
5. The first address on any port must be a multiple of hex 10. For example: 0A10,
0E20, and 2F30.
CKD assignment change: EMC restrictions
• Map/Unmap operations will be blocked for configurations that do not follow the
preceding rules.
• If a configuration is split on a port level (this is only possible if there is no PAV in
the box), then it cannot be unsplit on the EA interface with the interface online. If
the A and B port addressing is different, and if that situation needs to be resolved
to introduce PAV devices, both ports will need to be taken offline for the
configuration change.

CKD assignment change: z/OS restrictions
The following restrictions are z/OS limits, and not EMC limitations.
• Before an alias can be removed in a static PAV environment, the base associated
with that alias must be varied offline from the host. If the base is offline, the base
can be removed as well, however, do not leave a configuration that conflicts with
rule 5 on page 18.
• Before an alias can be removed in a DPAV environment, either with or without
removing the base, the entire CU image that the alias is associated with must be
offline. This is necessary because there is no way to predict the current base/alias
locations of any alias under DPAV. Remember, the bin is just the start-up position.
A display may show a base with the same number of aliases as there were at
startup, but they may be aliases that have moved from other bases during the
course of the DPAV changes. There is no way to reconcile the DPAV moves with the
static bin file being loaded. So the whole CU image must start again after the
configuration change. This means the CU image must be offline for the change,
and when it comes back online, the DPAV process can start again from the
beginning with the new information. If you are removing bases and aliases, do not
create a configuration that conflicts with rule 5 on page 18.
• The Hardware Control Definition (HCD) must match Symmetrix changes.
Conclusion
Unisphere for VMAX is a storage-management tool that delivers easy and intuitive
Symmetrix array management. Intelligence is built into Unisphere to guide the user
towards selecting the appropriate object within the array hierarchy before initiating a
command sequence. Array properties can be viewed, and array configuration changes
can be initiated and managed. Users of all experience levels will find this tool helpful
as templates and dialog boxes streamline parameter entry and make tasks easy and
efficient. Mainframe-specific configuration tasks are available under the z/OS
Configuration menu item. These Mainframe items are intended to allow storage
administrators to perform CKD-specific configuration changes on Symmetrix arrays.
Enabling authorized storage administrators to directly perform array modifications
reduces complexity and improves time frames for activities administered under
change control systems. Unisphere provides ease and simplicity for current
functionality, and Unisphere will deliver the same intuitive constructs for any future
functionality, lessening the learning curve when implementing new technology.
References
The following manuals and references provide information related to concepts
discussed in this paper:
• EMC Unisphere for VMAX Release Notes
• EMC Unisphere for VMAX Online Help

• EMC Unisphere for VMAX Product Guide
• EMC Unisphere for VMAX Installation Guide
• EMC Solutions Enabler Symmetrix Array Controls CLI Product Guide
• EMC Solutions Enabler Symmetrix Array Management CLI Product Guide
• EMC Solutions Enabler Symmetrix CLI Command Reference
• IBM z/OS V1R13 MVS System Commands
Refer to support.emc.com for the latest Unisphere and Symmetrix release
documentation and product release notes.

Appendix
Z series hardware complex
Although Unisphere only reports on and manages Symmetrix arrays, it is important to
understand the position of an array within the hardware hierarchy of z/OS. The
following z/OS connectivity example is a typical high-availability configuration. There
are many hardware elements and logical layers involved in delivering an I/O
operation from the Mainframe host to the Symmetrix array.
In Figure 14, Symmetrix devices in CU image 1A are defined on 4 x FICON directors
(EF's). The CU image is identifiable by way of the channel address of the base devices
being 1Axx. The FICON directors are connected by means of 2 x FICON switches into 8
x CHPIDs. There are several logical layers shown in the diagram that exist between the
CHIPIDs and the UCBs mapped to Logical Channel Subsystem (LCSS) 0/1 of the z9,
z10, z114, or z196 complex. The four Symmetrix EF directors form a single Logical
Path Group to CU image 1A.
Figure 14. Z series hardware complex

LCSS Logical Channel SubSystem
LPAR Logical Partition
MIF Multiple Image Facility
MSS Multiple Subchannel Set
CHPID Channel Path ID
PCHID Physical Channel ID
Example of HCD configuration parameters
It is important that Unisphere users are conversant with the hardware and software
configurations of the z/OS environment before implementing Symmetrix resource
changes. Unisphere initiated configuration changes are validated by SymmWin to
ensure conformance with internal Symmetrix data structures. These Symmetrix
checks extend to some but not all of the online requirements of the z/OS operating
system. Unisphere users are encouraged to participate in the appropriate change
control processes to assure adherence to site resource planning.
Symmetrix configuration definitions for CU image numbering and device addressing
for both base and aliases must match the Hardware Control Definition (HCD).
The extract shown in Figure 15 is from a typical HCD configuration. The CNTLUNIT and
IODEVICE statements provide indicators of resources that Unisphere has the ability to
influence. Key points of interest for Unisphere users are the UNITADD, CUADD
number, PATH and LINK, IODEVICE base devices, and associated alias-addressing
range statements.
CHPID PATH=(CSS(1),98),SHARED,
PARTITION=((0),(V11A,V118,V119)),SWITCH=7E,PCHID=1E1,
TYPE=FC
CHPID PATH=(CSS(1),99),SHARED,
PARTITION=((0),(V11A,V118,V119)),SWITCH=7E,PCHID=1F1,
CNTLUNIT CUNUMBR=13DA,PATH=((CSS(1),98,99)), *
UNITADD=((00,256)),LINK=((CSS(1),7E21,7E22)),CUADD=1A,
UNIT=2105
IODEVICE ADDRESS=(1A00,224),CUNUMBR=(13DA),STADET=Y,UNIT=3390B
IODEVICE ADDRESS=(1AE0,032),CUNUMBR=(13DA),STADET=Y,SCHSET=1,
UNIT=3390A
Figure 5. Example HCD definition
Parallel Access Volumes
Parallel Access Volume (PAV) technology allows a single z/OS host to simultaneously
process multiple I/O operations to the same logical volume. Prior to PAV capability,
Unit Control Blocks (UCBs) and z/OS queues kept track of I/O requests that were
processed serially. With PAV-enabled devices, instead of one UCB per logical device,
a z/OS host can use a base UCB, and several alias UCBs, to access the same logical
device, as long as I/O is not writing to the same device extent.
Figure 16 shows a representation of multiple UCBs for the same PAV-enabled logical
device through the assignment of a base channel address (000) and two-channel
alias addresses (080 and 0C0).

Figure16. Multiple addresses for a PAV-enabled device
A base device is a real device represented by a Symmetrix logical volume, as well as
by a UCB in the host. A base device uses a real channel address and consumes real
space on the back-end disks of the CU. An alias device is also represented by a UCB
in the host, uses a real channel address, but while defined in the CU, consumes no
real disk space and has no Symmetrix logical volume number.
Symmetrix Dynamic PAV feature allows the Workload Manager (WLM) component of
z/OS to dynamically reassign/remove alias devices (donor) to or from different base
devices (receivers) depending on the performance needs of the workload at a
particular time. The I/O Supervisor uses these WLM-allocated alternative UCBs to
perform multiple I/O operations to the same device.
With dynamic PAV, the total set of aliases for a CU image is treated as a pool. The
WLM component of z/OS works with the Symmetrix system to allocate aliases to
devices based on performance-selection criteria. Devices reaching performance limits
are allocated aliases automatically according to the current workload scheduling
demands. This allocation provides the best PAV device performance, without putting
the allocation burden upon the human administrator.
Multiple Allegiance (MA) is a CU capability that allows the parallel processing of non-
conflicting I/Os from multiple z/OS hosts (as opposed to PAV, which is parallel I/O
from the same host). Multiple Allegiance I/O executes concurrently with PAV I/O. The
Symmetrix array treats them equally and guarantees data integrity by serializing write
I/Os where extent conflicts exist.
PAV discovery is an event that occurs during the z/OS device Vary online process;
detecting the availability or unavailability of an alias association with the base
device. Dynamically removing and assigning alias devices under Unisphere may
necessitate the use of applicable z/OS system commands (or IODF or both) to ensure
synchronization of the host and Symmetrix configurations for base/alias
relationships.

When setting up base/alias addressing assignments within a 256-device addressing
range, base addresses must be in the low end of the range and alias addresses in a
range above the base addresses. Typically, base addresses begin at 00 and ascend,
and alias addresses begin at FF and descend.
Planning addresses for static PAV
When setting static PAV, a fixed relationship between a base device and its alias is
created. Workload Manager cannot reassign a static alias to a different base device.
Table 1 shows the most common layout when two alias addresses are statically
assigned to 64 base devices within a CU. The base addresses for these devices are
000 to 03F. The number of aliases required is 128. The high-end alias device range is
0C0 to 0FF and 080 to 0BF, (working from FF backwards down the range.) The
remaining device addresses in the range 040 to 07F can be used as base devices with
no aliases.
Base Alias #1 Alias #2
000 080 0C0
001 081 0C1
002 082 0C2
003 083 0C3
“ “ “
“ “ “
03F 0BF 0FF
040
041
“
“
07F
Table 1. 64 base devices with two aliases for each
If you intend to assign alias addresses to base devices 040 to 04F sometime in the
future, careful planning is required. Observing the rule that base addresses begin at
00 ascending and alias addresses begin at FF descending, prevents difficulty with
conflicting base and alias ranges. The final result is shown in Table 2.
Base Alias #1 Alias #2
040 060 070
041 061 071
042 062 072
043 063 073
“ “ “
“ “ “
04F 06F 07F
Table 2. Adding two aliases to base devices 040 to 04F

Adding three aliases each for base devices 040 to 04F would complete the 256
address capacity of the CU. Additional addressing would need to use another CU
image. Table 3 shows how adding three aliases to base devices 040 to 04F completes
the CU. This CU now has two static aliases on devices 00-34 and three static aliases
on devices 40-4F. The base range is 00-7F, and the alias range is 80-FF. The base and
alias ranges cannot cross each other, and this layout has achieved that goal.
Base Alias #1 Alias #2 Alias #3
040 050 060 070
041 051 061 071
042 052 062 072
043 053 063 073
“ “ “ “
“ “ “ “
04F 05F 06F 07F
Table 3. Adding three aliases for each base device 040 to 04F
Assigning three alias addresses for each of the 64 base devices within the 256-device
addressing range of a CU is a natural division and would complete the addressing
within the CU, as Table 4 illustrates. (64 base addresses and 192 alias addresses,
uses 256 addresses in an even distribution.)
Base Alias #1 Alias #2 Alias #3
000 040 080 0C0
001 041 081 0C1
002 042 082 0C2
003 043 083 0C3
“ “ “ “
“ “ “ “
“ “ “ “
“ “ “ “
“ “ “ “
“ “ “ “
“ “ “ “
“ “ “ “
03F 07F 0BF 0FF
Table 4. Adding three aliases for each 64 base devices
Note: Once an addressing configuration is set up for a Symmetrix array, any change
made to the mix of addresses requires management work on the host (IOCDS), which
could be highly disruptive. All involved devices, perhaps an entire CU image, may
have to be taken offline during some address reassignments.

Planning addresses for dynamic PAV
Setting dynamic PAV operation allows the Workload Manager (WLM) component of
z/OS to dynamically reassign alias devices to different base devices depending on
the performance needs of the workload at a particular time. Although WLM manages
the alias devices dynamically and changes base/alias assignments on the fly, the
initial allocation of alias addresses to base devices needs to be established. The
operating system can revert back to this initial allocation if dynamic management
encounters an error. Even in a dynamic environment, the Symmetrix array must
present an initial base/alias allocation to the host.
Table 5 is an example of assigning 128 alias addresses to 128 base devices in a CU.
Once the Symmetrix array is brought online to the z/OS host, WLM will dynamically
move base/alias relationships as indicated by the workload.
Base Alias
000 080
001 081
002 082
“ “
“ “
03F 0BF
040 0C0
041 0C1
“ “
“ “
07E 07E
07F 0FF
Table 5. Adding one alias for each dynamic PAV device

Using Unisphere for VMAX to Manage CKD Devices in zOS

More Related Content

Viewers also liked (15)

Similar to Using Unisphere for VMAX to Manage CKD Devices in zOS (20)

Using Unisphere for VMAX to Manage CKD Devices in zOS