h5898 Using SMC CKD in Zos Enterprise WP

Using Symmetrix Management Console
to Manage EMC Symmetrix CKD Devices

in a z/OS Enterprise Environment
Applied Technology

Abstract
This white paper provides an introduction to Symmetrix
Management Console (SMC) capabilities for

administering z/OS mainframe-attached devices. Along with viewing array properties and performing common
configuration tasks, SMC allows the mapping and unmapping of Count Key Data devices to front-end EA/EF
directors and the assignment/removal of PAV (Alias) addresses to and from base addresses. Delivering z/OS-
specific configuration management makes SMC a powerful tool for Symmetrix users in a mainframe
environment.

November 2008

Copyright 2008 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
All other trademarks used herein are the property of their respective owners.
Part Number h5898

Using Symmetrix Management Console to Manage EMC Symmetrix CKD Devices
Applied Technology 2

Table of Contents
Executive summary ............................................................................................ 4
Introduction......................................................................................................... 5
Audience ...................................................................................................................................... 5
Overview.............................................................................................................. 6
Symmetrix configuration .............................................................................................................. 6
SMC and Solutions Enabler......................................................................................................... 7
SMC for CKD devices ......................................................................................... 8
Array properties ........................................................................................................................... 8
Free space................................................................................................................................... 9
Configuration session management .......................................................................................... 10
ConfigSession tab .................................................................................................................. 10
Symmetrix audit log................................................................................................................ 11
Symmetrix audit log records................................................................................................... 11
SMC Command History.......................................................................................................... 12
Device creation .......................................................................................................................... 13
Non-meta CKD 3380 or 3390 devices ................................................................................... 13
Meta (RAID 10) CKD devices................................................................................................. 14
Device duplication .................................................................................................................. 15
SSID management ................................................................................................................. 16
Mapping CKD devices ............................................................................................................... 17
Device mapping 5671............................................................................................................. 19
Mapping devices................................................................................................................. 19
Unmapping devices ............................................................................................................ 20
Assigning aliases................................................................................................................ 21
Unassigning aliases............................................................................................................ 22
Copy Mapping..................................................................................................................... 23
Device online/offline considerations ................................................................................... 24
Device mapping 5771 and later.............................................................................................. 25
Mapping devices................................................................................................................. 25
Unmapping devices ............................................................................................................ 25
Assigning aliases................................................................................................................ 26
Unassigning aliases............................................................................................................ 28
Device online/offline considerations ................................................................................... 29
Conclusion ........................................................................................................ 30
References ........................................................................................................ 30
Appendix ........................................................................................................... 31
Z series hardware complex........................................................................................................ 31
Example of HCD configuration parameters ............................................................................... 32
PAVs .......................................................................................................................................... 33
Planning addresses for static PAV......................................................................................... 34
Planning addresses for Dynamic PAV................................................................................... 36

Executive summary
As EMC storage management tools have evolved to meet the complex and wide-ranging needs of many
different enterprises, the capabilities of these tools have increased. One outcome of the advancements in
storage management functionality is a large and varied set of options available in each tool, making EMC
storage management products comprehensive in support of different environments as in the mainframe data
center.
EMC received feedback from an extensive customer base that there is in fact a place in the storage
management arena for product(s) with reduced choices as an alternative to the option of comprehensive. In
response, EMC mapped out a strategy to build a suite of Symmetrix management products enabling
customers with varying levels of capital and degrees of sophistication to access the Symmetrix Value
Proposition. Tenants of that strategy include building products that are simple to operate yet intelligent
enough to maximize the user experience regardless of their level of sophistication. Additionally the
portfolio is modular, allowing the product suite to continue to add value and maximize customer return on
investment by offering additional capabilities to the base platform as the customer environment grows in
scale and complexity. In fulfillment of that strategy EMC introduced the Symmetrix
Management
Console (SMC), which employs a simple and intuitive web-based user interface to administer the most
common daily storage management functions for the Symmetrix array. The intention is that SMC can be
used quickly and efficiently by operators of all experience levels.
Members of the mainframe community typically participate in a structured change control process to
manage their storage environment with certainty and stability. When using the SMC mainframe storage
administrators can avoid consultation with EMC personnel on array change control activities and perform
the actions themselves, removing one level of complexity in the change control process. It is anticipated
that changes can be enacted in a more timely fashion and communication errors avoided when SMC is used
by authorized customer administrators to directly perform array modifications.
SMC puts control of the following 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
Replication and quality of service monitoring
SMC is designed to deliver Symmetrix array management that is responsive to user controls and modest on
server resource requirements. As a consequence of this design mandate, one SMC instance is
recommended for controlling a maximum of 64K devices. Some mainframe sites may require several SMC
instances to provide management coverage for the entire storage pool. Each SMC instance, however,
shares a server with other applications and each instance remains quick, light, and independent.
SMC is intended to make array management faster and easier. Using dialog boxes structured into task
wizards SMC accelerates setup, configuration, and routine tasks. By providing simplified replication
management and monitoring, SMC delivers ease of use that translates into efficient operation. Finally,
managing for the future, SMC will make new functionality available in the same simple intuitive manner,
greatly lessening the learning curve necessary to implement any new technology and functionality.
With SMC the mainframe user community now has an additional choice in Symmetrix array management.
This choice is a tool that is easy to deploy, simplifies complex tasks through structured templates and
wizards, delivers responsive user interaction, and readily integrates the tasks and changes of tomorrow.

Introduction
This white paper provides an introduction to SMC functionality that allows administration of Count Key
Data (CKD) devices in a Symmetrix array attached to a z/OS mainframe. SMC in conjunction with EMC

Solutions Enabler and Symmetrix Enginuity

can perform numerous Symmetrix configuration and control
tasks. The operations discussed in this paper include:

Creation of standard and Meta (RAID 10) CKD devices
Mapping a range of CKD devices to a front-end director
Unmapping CKD devices from a front-end director
Copying a Control Unit image of device mappings from one director to another director
Assigning alias addresses for devices that need to function as Parallel Access Volumes (PAV)
Removing alias addresses
Details regarding SMC functions outside of this white paper can be found in the SMC online help file.
Common operations also performed with SMC but not discussed within this CKD-specific paper include:
EMC TimeFinder
control actions
EMC SRDF
control actions
Quality-of-service control actions
Monitor replication activity
Monitor quality-of-service activity
SMC is a web-based application designed to be responsive to user controls and modest on server resource
requirements. SMC is recommended to support up to six Symmetrix arrays or an upper limit of 64K
Symmetrix logical volumes. SMC is tested to discover 32K volumes in under two minutes. All SMC
functions are memory resident and operations are performed at Solutions Enabler speeds. The memory
usage on an SMC server averages 384 MB but can grow to a maximum of 684 MB. The CPU footprint of
the SMC service is approximately 20 percent of a dual 2.2 GHz Xeon processor. In a large mainframe
environment several SMC instances may be required to provide management coverage for the entire
storage pool.
Security considerations are an integral component of today's operating environment and SMC can provide
local user security authentication or participate in active directory validation over the network. Six user
security roles are available ranging from a full access Administrator to no access at all. As with all
functions within SMC, the administration of user security is simple and intuitive. The web-based SMC
client can use Internet Explorer or Firefox. A Java RTE 1.5 or later applet is downloaded to that client.
Client-server communication can be secured through HTTPS (128-bit SSL) security or standard HTTP can
be used. There is no requirement for software to be installed on the client desktop, no dynamic ports are
used, and the SMC client can participate through most virtual private networks and firewalls.
Audience
This white paper is intended for any reader interested in understanding the SMC's potential for simplified
management of Symmetrix array configuration tasks. This paper will be of particular interest to storage
administrators, system administrators, or any technology professional concerned with managing CKD
devices on a Symmetrix storage platform. This paper assumes the reader is familiar with storage array
configuration requirements in a mainframe environment.

Overview
SMC delivers a web-based graphical user interface that is an alternative to the Solutions Enabler SYMCLI.
SYMCLI commands are built on top of SYMAPI library functions that use system calls to generate low-
level control commands to Symmetrix storage arrays. Rather than using SYMCLI commands that require
correct syntax structures, SMC allows point-and-click selection of objects and action sequences. User
selected objects and actions (the equivalent of CLI commands) are passed to the SYMAPI, allowing 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 SMC server. These topics will be explored in the following
sections as a prerequisite to the later examination of SMC mainframe management activities.
Symmetrix configuration
When a Symmetrix array is connected to a z/OS mainframe either ESCON (EA) or FICON (EF) directors
will be 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 managed commands from the Channel Subsystem to
a particular disk drive. Although early Control Units had less than 256 drives assigned to them, this
number of 256 represents today's maximum devices that can be defined within a Control Unit. As storage
arrays advanced to contain more than 256 disks/devices, arrays presented Logical Control Units (LCUs) to
the Channel Subsystem, outgrowing the physical limits of previous hardware. Each Control Unit and
indeed each LCU had its own unique Storage Subsystem Identifier (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 a maximum of 256 devices within them.
Although the Symmetrix storage array with EFs can emulate up to 64 (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 would be in a different SPLIT and each SPLIT would
appear 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 are achievable using SMC.
Looking within the LCU 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 have 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-27, and 3390-54. SMC has these definitions built into wizards to
make device creation as simple as possible. Older track geometry such as 3380 is also available. 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
was more pressing in the past. When PAV is present only one type of geometry can exist in each CU
image.
The process to build and load a configuration change via SMC 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 via the SymmWin application.
Configuration change parameters are collected via SMC's point-and-click interface and sent to the
SYMAPI server. The SYMAPI server generates System Calls (Syscalls) to pass the configuration
parameters to the Symmetrix where SymmWin builds a new bin file combining the current configuration
with the SMC 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.

SMC and Solutions Enabler
SMC is installed on a Windows, UNIX, or Linux server where it runs as a service or a process. An SMC
user (client) communicates with the SMC service via a web browser such as Internet Explorer or Firefox.
The SMC service/process allows the client user to select array objects and action options with a point-and-
click interface. The SMC service/process then passes the collected parameters to the Solutions Enabler
SYMAPI, which accomplishes the low level completion of the array management task.
SMC can be installed with SYMAPI running on the same server as SMC. This is a local installation. SMC
can be installed with SYMAPI running on a different server to SMC. This is a remote installation. For
SMC management of CKD devices in a z/OS environment there is a benefit to installing SMC with
Solutions Enabler running remotely on the z/OS host. This remote installation is shown in Figure 1.

Figure 1. SMC with remote SYMAPI installation
In the SMC remote installation shown, SYMAPI has access to z/OS information about online Symmetrix
devices. This z/OS information includes VOLSER and device number details obtained from the operating
system. In Figure 2 the example SMC properties panel includes the z/OS Info (1) tab. Notice that
VOLSER, device number, and even mount status are shown. If VOLSER is required for management of
Symmetrix devices then SMC must be installed with Solutions Enabler running under z/OS.

Figure 2. Remote SYMAPI installation can obtain VOLSER and device number

SMC examples used within this paper are based on the following minimum versions of software: SMC
version 6.0.2, EMC Solutions Enabler version 6.5, and Enginuity version 5671. SMC online help provides
additional details on the full range of SMC Symmetrix resource management functionality.
It is advisable to invoke the appropriate z/OS DISPLAY, DEVSERV, VARY device and PATHING related
system commands to validate SMC Symmetrix configuration changes. Refer to the IBM z/OS reference
documentation z/OS System Commands for detailed system command syntax.

SMC for CKD 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 Properties view from an SMC
instance. The hierarchy of objects is displayed in the left panel, and the properties information for that
object is available in the right panel. For CKD devices the CU images are immediately visible in the object
tree under the Symmetrix unit, allowing easy interrogation of CU devices and properties. In this example
the highest level action/command menu is also shown. Notice that "z/OS Configuration" is a distinct item
in the list of available action/command options.
In addition to the CU object, information on other Symmetrix array features such as Pools, Replication, and
Dynamic Cache Partitions is also available one level under the Symmetrix object. Replication, Quality of
Service, and Device Pool Management actions are easily accessible choices in the master action/command
menu. As you would expect with a point-and-click interface, further properties information is available by
selecting additional fields such as Devices (192). This tab will open a list of all 192 base devices in the CU
and data on an individual device from that list can be obtained by selecting one device and so on. Figure 2
on page 7 shows some of the information categories available for devices. Properties of various objects
will be shown in other examples throughout this document.

Figure 3. SMC array properties and action menu


Free space
Understanding free space on a Symmetrix unit is another important item for array management. In SMC's
object tree, properties for the Disks object show information about used and available space. An easy-to-
read graphic is also displayed, giving a very obvious used to free capacity comparison, as shown in Figure
4. 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.
To convert the reported Gigabytes free to CKD 3390 Gigabytes, use the ratio 1 GB = .865 3390 GB.
To convert the reported Gigabytes free to CKD 3380 Gigabytes, use the ratio 1 GB = .725 3380 GB.
Free space information will be 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 space on appropriate drives for the desired
protection strategy. Unbalanced utilization of drives may leave some protection partners (RAID groups,
mirror groups) with uneven free space and the inability to complete a device creation. For example, having
free space on seven out of eight RAID partners will not result in a successful device creation.
The Disks properties displayed in Figure 4 show the Used and Free capacity. These fields sum to the
Actual Capacity if a little rounding discrepancy is forgiven. The Capacity field shows another value that is
slightly less than the Actual Capacity. The difference is the drives for Sparing, Symmetrix Power volumes,
Symmetrix File System volumes, and other overheads used to administer the storage array.
After creating or removing devices an SMC Refresh View should be activated to update the free space
display. To reduce overhead SMC does not continually poll Symmetrix arrays. User management of
refresh operations is required after performing action tasks. The Refresh View focuses on updating fields
only within the current view and in this way performs the refresh operation with reduced overhead and
minimal interrogation of the storage array.

Figure 4. SMC properties: Free space

Configuration session management
ConfigSession tab
Quickly obtaining properties about items selected from the object tree will showcase SMC's ease and
efficiency. Right-clicking or using CONROL on the master menu will display the list of control actions
available for the selected object. Parameters necessary for completion of a control action are requested in
templates and dialog boxes that lead the user through processes without the requirement for extensive
experience or prior knowledge. Once parameters have been entered a control action is often completed by
using the "Add to Config Session List". The configuration session tab in SMC allows preview or execution
of configuration change tasks, the removal of tasks from management queues, and access to logs showing
activity progress. Configuration change tasks affect the whole array and any object within the hierarchy of
an array will present the same view of the configuration sessions. Managing configuration sessions is an
important part of SMC functionality and many of the examples shown in the following sections will be
completed by releasing the task through the ConfigSession interface. It is important to be familiar and
comfortable with manipulating this interface to configuration session management.
Whenever a control action template is completed the task is queued in the ConfigSession list. Figure 5
shows a configuration list for Symmetrix unit 000190102000 where configuration changes are queued.
There are four tabs for viewing:
My Active Tasks
My Inactive Tasks
All Active Tasks
All Inactive Tasks
Although all tasks can be viewed, even the most privileged user cannot control another's tasks. Visibility of
other user tasks merely provides an understanding of what changes are queued or are taking place. Upon
selection of a manageable task the following actions can be initiated:
Deactivate moves the task to the inactive list
Preview All sends all task parameters to SymmWin in the appropriate array and confirms
that a legal configuration or series of legal configurations can be created.
Commit All sends all task parameters to SymmWin in the appropriate array and
loads all legal configurations created.
Abort attempts to stop a commit that is currently in progress. Many scripts have a point of
no return after which an abort is not possible.

Figure 5. Configuration list management
Figure 5 also includes some lines from the log of the last attempted activity. In this case the log shows that
the configuration lock was not acquired. Logs can be viewed from other locations in SMC but it is useful
to monitor configuration change progress from this activation interface.
The examples throughout the rest of this paper detail templates and dialog boxes that simplify the
accomplishment of various changes. All these examples will ultimately require that the actual
configuration change be placed in a task queue and managed via this ConfigSession interface.

Symmetrix audit log
The audit log contains information about all operations performed on the chosen Symmetrix array. Select
the array object identified by serial number then right-click or use CONTROL on the master menu to open
the control option list. From the control list select Symmetrix Admin and then View Symmetrix Audit log
to launch the SymAudit filter dialog box.
The filter dialog box displayed in Figure 6 shows the assists available for the retrieval of audit log entries
concerning Symmetrix 000190102000. The highlighted record (1217) is the oldest entry. Many filter
options are available to make record location simple.

Figure 6. SymAudit filtering

Symmetrix audit log records
Figure 7 on page 12 details an example SymAudit record, in this case record 104. The Action Code was
"Commit" and the text field indicates the upgrade was a mapping operation of devices 002B 002F to
director 14C-0 and the addressing was copied to director 14D-1. All actions are recorded in this tamper-
proof log providing a detailed audit trail for management review.


SMC Command History
In addition to providing audit records, a log of SMC user functions and results is available. The display in
Figure 8 shows an extract from the Command History log for an SMC instance that is connected to
Symmetrix 000190102000. Command History is an item directly available from the main menu. An array
object should be selected when Command History is opened. If an object within an array is selected there
will be no available view. Even though an array object is selected the History log is for the SMC instance.
All user actions and results are reported, not just items applicable to the selected array.



Device creation
Non-meta CKD 3380 or 3390 devices
Figure 9 illustrates the SMC selection choices necessary to create new devices. Select the array object
identified by serial number then right-click or use CONTROL on the master menu to open the control
option list. From the control list select Device Configuration to launch the device options list and lastly use
Create Device to open the device creation dialog box. In this example a CKD-3390 100 cylinder volume is
to be created. The new volume will be created as a 2-Way Mirror with 81 MB 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). The
example uses SSID 7777 as a temporary SSID for the unmapped newly created 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. Please refer to the section on SSID management for more information on why a
temporary SSID is used between device creation and device mapping.
Menu choices that cannot be selected are colored gray (not black). In the current example the master object
is the array; many device level tasks are not pertinent to the whole array and are gray for not available. To
make these device control options active, you must select a specific device from the object tree. Within the
device creation dialog box, some fields are not available. In our example, remote device parameter entry is
blocked. This is the result of specifying a 2-Way Mirror device configuration. If RDF1+Mir or any other
RDF device type was specified, the volume to be created would have editable remote parameters. SMC
intelligently makes fields active only for options that apply to the objects and tasks specified by selection.
Notice that the device creation dialog box has selectable tabs for other templates to create THIN, DATA, or
SAVE devices. This example shows the Regular device creation template but four templates are available
in the dialog box to create all the various device types.

Figure 9. CKD-3390 device creation

Meta (RAID 10) CKD devices
Figure 10 shows the SMC selection choices necessary to create new CKD meta (RAID 10) devices. Select
the array object identified by serial number then right-click or use CONTROL on the master menu to open
the control option list. From the control list select z/OS Configuration to launch the list of z/OS specific
tasks. Lastly use Create CKD Meta to open the CKD meta device creation dialog box. Figure 10 shows a
new meta volume created as a 2-Way Mirror with 81 MB capacity from space on any available disk. SSID
7777 is used as a temporary SSID for the unmapped newly created meta device. When the device mapping
option is used to map the newly created meta device to the appropriate EF/EA directors the final SSID will
be specified. Please refer to the section on SSID management on page 16 for more information on why a
temporary SSID is used between device creation and device mapping.
All CKD meta devices are made up of four meta members, have mirrored protection, and use a one
cylinder stripe. Each member is a separate Symmetrix volume but all four meta members make one logical
volume when presented to the z/OS host. Typical z/OS volumes have odd cylinder counts such as 3339
and 10017; the meta creation algorithm only allows mirrored protection and standardizes which of the four
meta members has an odd cylinder count. This precise control of device construction is restricted to the
z/OS meta device and so the creation template has been placed under the z/OS Configuration option and
not the Device Configuration option.
Menu choices that cannot be selected are colored gray (not black). In our example, Auto and Data Meta
fields are not user definable and are gray for not available. Notice that the meta device creation dialog box
has no selectable tabs for other device creation templates such as THIN, DATA, or SAVE devices. The
meta CKD device template is specifically for this one type of device creation. If an RDF meta CKD
volume is desired an additional step is required where the particular meta devices are selected and the
Device Configuration option is used to activate the Change Device to RDF Configuration dialog box.

Figure 10. CKD-3390 meta device creation

Device duplication
Both examples of device creation shown previously use a template to prompt for correct parameter input.
But once those parameters have been supplied is it necessary to supply them again in 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 11 outlines the
duplication option.
Select the CU object available under the appropriate array, identified by serial number. Using the
properties view of the CU Image, select the device you wish to duplicate. Right-click or use CONTROL
on the master menu to open the control option list. From the control list select Device Configuration to
launch the device options list and lastly use Duplicate Device to open the duplication dialog box. There are
only two inputs required when using the device duplication process. The number of new devices is an
essential parameter that must still be supplied. The other necessary input is the temporary SSID that will be
used until the new devices are assigned to the EF/EA directors. The Override option shown in the figure
can be used to change any parameter in the template but must be used every time to specify the temporary
SSID. The section SSID management on page 16 has more information on why a temporary SSID is
used between device creation and device mapping.
Because SMC intelligently activates options applicable to selected objects and tasks, the Device duplication
template will not be available for SRDF devices. These devices require specification of remote parameters.
The template does not accommodate entry of remote parameters and the Duplicate Device option will be
gray and unavailable if SRDF devices are used as the model device.

Figure 11. CKD-3390 device duplication

SSID management
MVS has rules for SSIDs that are enforced in the Symmetrix configuration program (SymmWin.) By
enforcing the operating system rules SymmWin prevents illegal configurations from being loaded onto the
Symmetrix unit. One such MVS rule policed by SymmWin is that all devices that have the same SSID
must be assigned to the same set of channels (EA/EF director set). The following example in Figure 12
shown from the SymmWin configuration program breaks the MVS rule. Notice that Symmetrix devices
50-54 have SSID 140 but are not assigned to SPLIT 0 (a set of EA/EF director ports) that also has SSID
140. The SymmWin program finds the configuration in error and will prevent this from loading on the
Symmetrix.

Figure 12. SymmWin SSID management 1
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). All three discussions of
device creation outlined above include this mandated use of a temporary SSID at device creation until the
new devices are assigned to the EA/EF directors.
The other essential SSID rule specifies there must be only one SSID within a CU image (of 256 devices).
Figure 13 shows an example breaking this rule where CU image 00 addresses 00-07 have two SSIDs, 140
and 141. The SymmWin error message is shown in Figure 13, which demonstrates that 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.

Figure 13. SymmWin SSID management 2

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 Control Definition (HCD) should be configured to reflect the Symmetrix
devices and the associated Input Output Definition File 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 is in place and a Vary
Online command marks the device as being 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 14 a group
of devices becomes part of a CU image when mapped to front-end EA or EF ports. Unit Control Blocks
(UCBs) manage device addresses within the z/OS operating system. The Logical Partition (LPAR) is a
subset of processing resources within a complex that forms the environment containing the running
operating system.

Figure 14. 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, and each CU image has a
unique SSID. The Symmetrix can have many CU images; the total of which is model and Enginuity code
level dependent. Several other considerations for mapping CKD devices are discussed in the following
paragraphs.
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 doesn't 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. During pre-checks for an upgrade from 5670 to 5671 the discipline of common addressing across
both ports will be reported and the new addressing enacted at 5670 prior to upgrading to 5671.
Commencing with Enginuity 5771 an enhanced SPLIT configuration management structure was
incorporated into the Symmetrix configuration program. The new SPLIT structure in Enginuity 5771 code
reduced the time required to correlate and manage SPLIT path groups. SMC detects the running Enginuity
version for each array and intelligently enables the appropriate command templates. Examples of both
command templates will be shown in the following pages.
A Symmetrix SPLIT can contain multiple LCUs. The CU images are bound to selected EA/EF director
ports defining the SPLIT. Currently 16 SPLITS can be configured in a Symmetrix unit running Enginuity
5771 or later.


Figure 15 presents the SPLIT information page from SymmWin. In this example directors EF-6c and EF-
6d are configured for SPLIT 0, EF-4a and EF-4b are SPLIT 1, and finally EF-4c and EF-4d are configured
for SPLIT 2. This is an example of poor redundancy. Paths for each SPLIT should be balanced across
different directors so a hardware replacement does not affect more than one path in a SPLIT. In this case
the path distribution is a result of the directors being added one at a time over a long period. An EMC
Customer Service engineer can reconfigure the paths within these SPLITS and create a better redundancy
distribution across the directors. In our example, during the reconfiguration one of the available paths will
be interrupted and moved but one path will continue to run in each SPLIT. SPLIT reconfiguration can also
be performed when EA/EF director boards are added or removed.

Figure 15. SPLIT management in SymmWin
It is possible to map duplicate CU image numbers to different SPLITs. Duplicate LCU 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 Hosts LPAR to interpret the duplicate CU image
number as an LCU 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.
Figure 16 shows SMC's object tree for a Symmetrix array with serial number 2000. Within the object
hierarchy the CU Images object is expanded to show duplicate CU numbers. There are three instances of
CU 18 and CU 19. The presence of three instances of the same CU image indicates that three SPLIT are
active, in fact the three SPLITs shown in Figure 15. 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 16. Duplicate CU image numbers indicating SPLITs

Device mapping 5671
Because Enginuity 5671 does not include the SPLIT management screen, mapping for EA/EF directors
requires manual control of the grouped ports. The ability to copy director mapping from one port to
another port was necessary and the Copy Mapping function is found in Enginuity 5671. As previously
discussed, 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 doesn't have multiple ports.) However there is a further complication to
this restriction. Although both ports must have the same addresses they should not map to the same LPAR.
The A(0) and B(1) ports share one logical processor (multiplexed). Excessive Control Unit Busy and
Control Unit End conditions and contention could exist during z/OS Channel Path rotation selection if ports
in this mode are configured to the same LPAR. This consideration adds a layer of complexity by
specifying that the similarly addressed A(0) and B(1) ports be attached to different LPARs.
Another item worth noting is that the first base address assigned to a CU image must be a multiple of
0x010. When planning to add base addresses using SMC 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
Previous examples started with the CU Image object and the selection was refined within the hierarchy of
that object. When performing a mapping operation the device(s) exist but are not yet in a CU. Selection of
the correct object to initiate mapping therefore starts with Devices. Select the Devices object available
under the appropriate array, identified by serial number. 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. If SMC is used to identify the list of devices for mapping, the unmapped devices for each
protection type are grouped in the Unmapped object (Figure 17). If there are unmapped devices within a
protection type the Unmapped object can be selected and the list of available unmapped devices will be
presented. Right-click or CONTROL on the master menu will open the action control list, then select z/OS
Configuration > Map Devices to open the mapping dialog box. The mapping dialog box requires the
following entries as detailed in Figure 17:
The device range to be mapped.
The base address including the identifying CU number, for example, CU 18 base address 00 = 1800.
The starting alias address if aliases are to be used. See the section Assigning aliases on page 21.
The correct SSID for this CU. (The SSID number will be unique within the complex.)
All of the ports that currently are grouped and have the same addressing.


Figure 17. Mapping devices

Unmapping 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, the aliases are also removed.
Removing aliases in 5671 can be done ad hoc because the aliases are fixed in the configuration. In later
codes only the alias range is specified and holes in the alias range caused by device removal are prevented.
(The whole range is removed and added back in a contiguous block.) Managing aliases in SymmWin is
different from the actual alias association in MVS. The aliases may have been moved to any base by MVS
components even though the configuration file carries the original assignment. The original allocation in
the bin file is managed by SMC to achieve the unmap result. The section Unassigning aliases on page 22
has more information.
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 MVS restriction be observed. If base address 00 remains in
place, satisfying the MVS rule, then all other address modifications are legitimate. Ensure that
volumes/datasets are deallocated to z/OS resources prior to any unmapping activities. When unmapping
z/OS devices, associated paths should be varied offline to the devices.
Warning: When all devices are unmapped from an ESCON or FICON director, that director will go into a "DD"
state. SymmWin 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 unmap operation 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, identified by serial number. Using the properties view of the CU Image, select the device(s)
to unmap. Right-click or use CONTROL on the master menu to open the control option list. Select z/OS
Configuration > Unmap Devices to open the unmap dialog box. The unmap dialog box requires the
The device range to be unmapped.
The SSID that will be used while the devices are unmapped. See the section on SSID management
on page 16.
All of the ports that currently are grouped and have the same addressing. The unmapped devices must
be unmapped from all the grouped ports simultaneously.


Figure 18. Unmapping devices

Assigning aliases
SMC provides for the assignment of alias addresses to base devices in the event that improved I/O device
performance is required (refer to the IBM WLM DASD characterization benchmarking analysis). Figure 19
shows the SMC procedure to assign alias addresses. In this example the starting alias address is LCU x'0A'
and the device number within the LCU is x'E0'. The alias addresses starting at this number will be applied
consecutively to base device range 023 - 028. This procedure will consume six additional channel
addresses in CU Imagex'0A'. The alias assignment is propagated to all directors mapped to the device
range. The SMC CU Image 0A Properties display shows the successful addition of six alias addresses.

Figure 19. Assigning alias addresses (5671)
In Enginuity 5671 the initial alias allocation is a specific alias assigned to a specific base device. (MVS
components may then move the alias addresses to other bases.) Figure 20 shows a very unusual individual
allocation of alias addresses to various base devices. This type of initial allocation is possible because of
the individual assignment process. In later Enginuity code where only a range of alias values is given in
the configuration, alias operations must be on the range in its entirety.

Figure 20. Ad hoc alias addressing in SymmWin (5671)

Unassigning aliases
SMC provides for the removal of alias channel addresses from base devices in the event that additional
channel addresses are required for allocation to Symmetrix devices (return base addresses to the CU).
Figure 21 shows the SMC procedure to remove all the currently configured alias addresses, starting with
address CU number x'0A' and alias address x'E0', for device range 023 - 028. This procedure will free up
six channel addresses in CU Image 0A.
The SMC CU Image number 0A Properties display shows the successful removal of six alias addresses.
The starting alias to be removed applies to the first device in the range. As the alias removal is processed,
the alias value is incremented. Any gaps in the base addresses of the device range generate gaps in the
range of alias addresses.

Figure 21. Removal of aliases (5671)
In Enginuity 5671 the initial alias allocation is a specific alias assigned to a specific base device. (MVS
components may then move the alias addresses to other bases.) Figure 22 shows an allocation that ranges
from one to three aliases against a base. When SMC configuration changes are validated, the new
configuration is built upon the old assignments. Removal of aliases leaving gaps in the alias range is
possible because of the individual assignment process. In later Enginuity code where a range of alias
values is given in the configuration alias operations must be on the range in its entirety.

Figure 22. Alias addressing in SymmWin (5671)

Copy Mapping
As discussed in the Mapping CKD devices section, Enginuity 5771 and later use the SymmWin
discipline of structured SPLITs. The SPLITs mechanism ensures selected devices are mapped across all
grouped EA/EF director ports. For 5671, SymmWin expects and SMC provides individual selection
criteria for mapping EA/EF director ports. To make port changes for the entire port easier and to maintain
address consistency, the Copy Mapping command is available in 5671. Figure 23 shows how to open the
SMC template to run the procedure for copying front-end mapping of CKD devices from one port to
another port.
The mapping dialog box can be initiated from either the Device Range object or CU Image object. This
example shows devices 023 028 (addressed on the EA as 0A70-0A75), CU image 0A, SSID 7A00
mapped on existing grouped directors including EA 14A-0. The Copy process is from one director
identified in the available pool of EA (ESCON) and EF (FICON) directors, to additional directors
identified in the selected director's box. In the example EF 4A-0 and EF 4B-0 are the selected copy to
directors. These parameters are added to the Configuration Session list, which will create a new
configuration on a preview or create a new configuration and run an upgrade script if commit is initiated.
The changing directors will be put in an offline state and all the addresses changed to match the source
example. Devices addressed on the changing ports should have other paths available to support I/O during
and after the change.

Figure 23. Copy CU Image mapping to another director port (5671)

Device online/offline considerations
The CKD assignment change rules and device online/offline considerations will be summarized here. The
information is from Knowledgebase 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 is
still base address 00 but 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 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. Obviously we cannot have
serial numbers overlapping. 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. Example are 0100, 0A10, 0E20.
EMC restrictions for CKD assignment change
Map/Unmap operations will be blocked for configurations that do not follow the rules listed above.
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
MVS restrictions for CKD assignment change
The following restrictions are MVS 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 also be removed, however, do not
leave a configuration that breaks rule 5 as noted above.
Before an alias can be removed in a DPAV environment, either with or without removing the base, the
entire CU image the alias is in 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 startup 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 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 removing bases and aliases, do not create a configuration that breaks rule 5 above.
The HCD must match Symmetrix changes!


Device mapping 5771 and later
Because Enginuity 5771 and later do include the SPLIT management screen (see Mapping CKD
devices), 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 will receive the same
mapping. 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. (An EF
doesn't 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 one logical processor (multiplexed). Excessive Control Unit
Busy and Control Unit End conditions and contention could exist during z/OS Channel Path rotation
selection if ports in this mode are configured to the same LPAR. The possibility of contention is alleviated
when addresses for the A(0) and B(1) ports are attached to different LPARs.
Once again, the first base address assigned to a CU image must be a multiple of 0x010. When planning to
add base addresses using SMC 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
Mapping in 5771 is the same as in 5671, although it will be shown later that unmapping aliases is different.
When performing a mapping operation the device(s) exist but are not yet in a CU. Selection of the correct
object to initiate mapping therefore starts with Devices. Select the Devices object available under the
appropriate array, identified by serial number. 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.
If SMC is used to identify the list of devices for mapping, the unmapped devices for each protection type
are grouped in the Unmapped object, as shown in Figure 17. If there are unmapped devices within a
protection type the Unmapped object can be selected and the list of available unmapped devices will be
presented. Right-click or CONTROL on the master menu will open the action control list where selection
of z/OS Configuration is possible. Choose Map Devices to open the mapping dialog box. The mapping
dialog box requires the following entries as previously detailed in Figure 17:
The device range to be mapped.
The base address including the identifying CU number, for example, CU 18 base address 00 = 1800.
The starting alias address if aliases are to be used. See the section Assigning aliases on page 26.
The correct SSID for this CU. (The SSID number will be unique within the complex.)
One of the ports that currently is grouped in the SPLIT and has the same addressing.
See the section Mapping CKD devices for an explanation of the SPLIT concept.

Unmapping 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. In Enginuity 5771 and later aliases are specified as a range, and holes in the alias range
caused by device removal are 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 MVS restriction be observed. If base address 00 remains in
place, satisfying the MVS rule, then all other address modifications are legitimate. When unmapping z/OS
devices, associated paths should be varied offline to the devices. Ensure volumes/datasets are deallocated
to z/OS resources prior to any unmapping activities.
Warning: When all devices are unmapped from an ESCON or FICON director, that director will go into a "DD"
state. SymmWin 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 unmap operation 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, identified by serial number. Using the properties view of the CU Image, select the device(s)
to unmap. Right-click or use CONTROL on the master menu to open the control option list. Select z/OS
Configuration > Unmap Devices to open the unmap dialog box. The unmap dialog box requires the
The device range to be unmapped.
The SSID that will be used while the devices are unmapped. See the section SSID management.
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.
See the section Mapping CKD devices for an explanation of the SPLIT concept.

Assigning aliases
SMC provides for the assignment of alias addresses to base devices in the event that improved I/O device
performance is required (see the IBM WLM DASD characterization benchmarking analysis). Figure 24
shows the SMC dialog choices to assign alias addresses in Enginuity 5771 and later. At 5771 and later
aliases are added with two statements. Both statements should be used together. The first component is the
RANGE of aliases and the second component is a COUNT of aliases to be assigned to the bases.
Warning: Both of the input values are hexadecimal. A count value of 10 is decimal 16.
As seen in Figure 24 after using right-click or CONTROL on the master menu to open the control option
list and selecting z/OS Configuration the Assign Alias Range template is completed and the Assign Alias
Count template is completed and both of those configuration entries are executed together from the
ConfigSession page.


Figure 24. Alias assignment Enginuity 5771 and later

The Assign Alias Range statement and the Assign Alias Address statement together define what aliases are
assigned to base addresses. Figure 25 shows both completed templates queued in the ConfigSession list.
When those tasks are completed a valid bin file will have been constructed. In the following example the
alias range is C0-FF (64 devices) and the alias count for device 1CA9-1CB0 is 8. (Remember the count (8)
is a hexadecimal number.) An extract from the bin file shows how this is assigned to the base addresses.
The second example captured in Figure 25 shows a count of 10 (decimal 16) for the same range of 64
aliases. Notice that those aliases are assigned to 64/16= 4 bases. The total range of aliases divided by the
count must fit exactly on the specified bases! In a Dynamic PAV environment both results are effectively
the same. The initial allocation of 8 or 16 aliases on a base is changed by MVS as the workload demands.
The default bin file setting allows 31 (decimal) aliases to be assigned to a base.

Figure 25. Completed templates

Unassigning aliases
SMC provides for the removal of alias channel addresses from base devices in the event that additional
channel addresses are required for allocation to Symmetrix devices. (Return base addresses to the CU.)
Figure 26 shows the SMC dialog choices to unassign alias addresses in Enginuity 5771 and later. At
Enginuity 5771 and later aliases are removed with two statements. Both statements should be used
together. The first component is the RANGE of aliases and the second component is a COUNT of aliases
to be unassigned from the bases.
Warning: Both of the input values are hexadecimal. A count value of 10 is decimal 16.
As seen in Figure 26, after using right-click or CONTROL on the master menu to open the control option
list and selecting z/OS Configuration, the Remove Alias Range template is completed and the Remove
Alias Count template is completed and both of those configuration entries are executed together from the
ConfigSession page. The real location of the alias addresses is not known and the removal of the aliases is
based on the static configuration in the bin file. To remove the aliases the command parameters must
match the existing bin file. It is not allowed to have holes in the range of aliases. Given these
considerations the most efficient way to approach alias removal is to remove the whole alias range and all
the counts. If further management is desired a new range and count can be added back based on the fact
that the previous remove cleared ALL the records and the slate is clean.


Figure 26. To remove alias assignment with Enginuity 5771 and later, use Remove Alias
Range and Remove Alias Count together

Device online/offline considerations
The CKD assignment change rules and device online/offline considerations will be summarized here. The
information is from Knowledgebase 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 is
still base address 00 but 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 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. Obviously we cannot have serial
numbers overlapping. 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. Examples are 0100, 0A10, 0E20.
EMC restrictions for CKD assignment change
Map/unmap operations will be blocked for configurations that do not follow the rules listed above.
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
MVS restrictions for CKD assignment change
The following restrictions are MVS 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 also be removed; however, do not
leave a configuration that breaks rule 5 as noted above.
Before an alias can be removed in a DPAV environment, either with or without removing the base, the
entire CU image the alias is in 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 startup 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 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 removing bases and aliases, do not create a configuration that breaks rule 5 above.
The HCD must match Symmetrix changes!


Conclusion
(SMC is an operating system agnostic storage management tool that delivers easy and intuitive Symmetrix
array management. Intelligence is built into SMC to guide the user toward 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 will reduce complexity and improve time frames for activities administered under change
control systems. SMC provides ease and simplicity for current functionality and SMC 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 Symmetrix Management Console Version 6.0 Installation Guide
EMC Solutions Enabler Version 6.4 Installation Guide
Symmetrix Management Console online help
IBM z/OS V1R8 MVS System Commands SA22-7627-15

Refer to EMC Powerlink for the latest SMC, Solutions Enabler, and Symmetrix documentation and release
notes.


Appendix
Z series hardware complex
Although SMC 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 z/OS connectivity example shown below 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 27, Symmetrix devices in CU image 1A are defined on 4 x FICON directors (EFs). The CU
image is identified by the first two digits of the channel address. The FICON directors are connected via 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 or z10
complex. The four Symmetrix EF directors form a single Logical Path Group to CU image 1A.

Figure 27. 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 SMC users are conversant with the hardware and software configurations of the z/OS
environment before implementing Symmetrix resource changes. SMC 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. SMC 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 HCD. The extract shown in Figure 28 is from a typical HCD configuration. The
CNTLUNIT and IODEVICE statements provide indicators of resources that SMC has the ability to
influence. Key points of interest for SMC users are 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 28. Example HCD definition


PAVs
PAV technology allows a single z/OS host to simultaneously process multiple I/O operations to the same
logical volume. Prior to PAV capability, UCB 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 29 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).

Figure 29. 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 control
unit. An alias device is also represented by a UCB in the host, uses a real channel address, but while
defined in the control unit, consumes no real disk space and has no Symmetrix logical volume number.
The Symmetrix Dynamic PAV feature allows the Workload Manager (WLM) component of z/OS to
dynamically reassign/remove alias devices (donor) to/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 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 is a control unit 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 SMC may necessitate the use of applicable z/OS system commands (and/or
IODF) 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. WLM 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 backward down the
range). The remaining device addresses in the range 040 to 07F can be used as base devices with no
aliases.

Table 1. 64 base devices, two aliases for each
Base Alias #1 Alias #2
000 080 0C0
001 081 0C1
002 082 0C2
003 083 0C3

03F 0BF 0FF
040
041

07F

If you intend to assign alias addresses to base devices 040 to 04F some time in the future, careful planning
is required. Observing the rule that base addresses begin at 00 ascending and alias addresses begin at FF
descending will prevent difficulty with conflicting base and alias ranges. The final result is shown in Table
2.

Table 2. Adding two aliases to base devices 040 and 04F
Base Alias #1 Alias #2
040 060 070
041 061 071
042 062 072
043 063 073

04F 06F 07F


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.

Table 3. Adding three aliases for each base device 040 to 04F
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

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. (Sixty-
four base addresses and 192 alias addresses use 256 addresses in an even distribution.)

Table 4. Adding three aliases for each of the 64 base devices

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

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 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, Workload Manager will dynamically move base/alias relationships
as indicated by workload.
Table 5. Adding one alias for each Dynamic PAV device

Base Alias
000 080
001 081
002 082

03F 0BF
040 0C0
041 0C1

07E 07E
07F 0FF


h5898 Using SMC CKD in Zos Enterprise WP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

h5898 Using SMC CKD in Zos Enterprise WP

Uploaded by

Copyright:

Available Formats

Using Symmetrix Management Console

to Manage EMC Symmetrix CKD Devices

Management Console (SMC) capabilities for

You might also like