Using Unisphere for VMAX to Manage Symmetrix CKD … · Symmetrix configuration . ... Using Unisphere for VMAX to Manage Symmetrix CKD Devices in a z/OS ... Remote SYMAPI installation

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

2 Using 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

Documents

Using Unisphere for VMAX to Manage Symmetrix CKD … · Symmetrix configuration . ... Using Unisphere for VMAX to Manage Symmetrix CKD Devices in a z/OS ... Remote SYMAPI installation