Using Symmetrix Management Console to Manage EMC Symmetrix ... · PDF fileUsing Symmetrix Management Console to Manage EMC Symmetrix CKD Devices in a z/OS Enterprise Environment Applied

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 in a z/OS Enterprise Environment 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. Using Symmetrix Management Console to Manage EMC Symmetrix CKD Devices in a z/OS Enterprise Environment Applied Technology 6

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 Using Symmetrix Management Console to Manage EMC Symmetrix CKD Devices in a z/OS Enterprise Environment Applied Technology 9

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.


Figure 7. SymAudit filtering 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.

Figure 8. SymAudit filtering


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 Host’s 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.

in a z/OS Enterprise Environment Applied Technology 19

Figure 17. Mapping devices Using Symmetrix Management Console to Manage EMC Symmetrix CKD 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 following entries as detailed in Figure 18: • 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) Using Symmetrix Management Console to Manage EMC Symmetrix CKD Devices in a z/OS Enterprise Environment Applied Technology 23

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 following entries as detailed in Figure 18: • 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


Documents

Using Symmetrix Management Console to Manage EMC Symmetrix ... · PDF fileUsing Symmetrix Management Console to Manage EMC Symmetrix CKD Devices in a z/OS Enterprise Environment Applied