h5898 Using Smc Ckd in Zos Enterprise Wp

8/13/2019 h5898 Using Smc Ckd in Zos Enterprise Wp

1/36

Using Symmetrix Management Console

to Manage EMC Symmetrix CKD Devicesin a z/OS Enterprise Environment

Applied Technology

Abstract

This white paper provides an introduction to Symmetrix

Management Console (SMC) capabilities foradministering z/OS mainframe-attached devices. Along with viewing array properties and performing commonconfiguration 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 toand from base addresses. Delivering z/OS-

specific configuration management makes SMC a powerful tool for Symmetrix users in a mainframe

environment.

November 2008


2/36

Copyright 2008 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information issubject 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 applicablesoftware 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 EnvironmentApplied Technology 2


3/36

Table of Contents

Executive summary ............................................................................................4

Introduction.........................................................................................................5

Audience ...................................................................................................................................... 5

Overview..............................................................................................................6Symmetrix configuration .............................................................................................................. 6

SMC and Solutions Enabler......................................................................................................... 7

SMC for CKD devices .........................................................................................8

Array properties ........................................................................................................................... 8

Free space ................................................................................................................................... 9

Configuration session management .......................................................................................... 10

ConfigSession tab .................................................................................................................. 10Symmetrix audit log................................................................................................................ 11Symmetrix audit log records................................................................................................... 11SMC Command History.......................................................................................................... 12

Device creation .......................................................................................................................... 13Non-meta CKD 3380 or 3390 devices ................................................................................... 13Meta (RAID 10) CKD devices................................................................................................. 14Device duplication .................................................................................................................. 15SSID management ................................................................................................................. 16

Mapping CKD devices ............................................................................................................... 17

Device mapping 5671............................................................................................................. 19Mapping devices................................................................................................................. 19Unmapping devices ............................................................................................................ 20

Assigning aliases................................................................................................................ 21Unassigning aliases............................................................................................................ 22Copy Mapping..................................................................................................................... 23Device online/offline considerations ................................................................................... 24

Device mapping 5771 and later.............................................................................................. 25Mapping devices................................................................................................................. 25Unmapping devices ............................................................................................................ 25

Assigning aliases................................................................................................................ 26Unassigning aliases............................................................................................................ 28Device 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......................................................................................... 34Planning addresses for Dynamic PAV ................................................................................... 36




4/36

Executive summaryAs 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 datacenter.

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. Inresponse, 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 oninvestment 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 SymmetrixManagement

Console (SMC), which employs a simple and intuitive web-based user interface to administer the mostcommon 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 tomanage 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 anticipatedthat 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 isrecommended 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 andwizards, delivers responsive user interaction, and readily integrates the tasks and changes of tomorrow.




5/36

IntroductionThis white paper provides an introduction to SMC functionality that allows administration of Count KeyData (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 TimeFindercontrol actions

EMC SRDFcontrol 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 64KSymmetrix 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 ofthe 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 allfunctions 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 canbe 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 simplifiedmanagement of Symmetrix array configuration tasks. This paper will be of particular interest to storage

administrators, system administrators, or any technology professional concerned with managing CKDdevices on a Symmetrix storage platform. This paper assumes the reader is familiar with storage array

configuration requirements in a mainframe environment.




6/36

OverviewSMC 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. Userselected 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 followingsections as a prerequisite to the later examination of SMC mainframe management activities.

Symmetrix conf igurat ion

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 toa particular disk drive. Although early Control Units had less than 256 drives assigned to them, thisnumber 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 thesestructures 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 requirementwas 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 wouldappear as a separate array by slightly modifying the original array serial number. Currently, manipulationof 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 hardwareevolution 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 canmix 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 configurationparameters 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.




7/36

SMC and Solut io ns Enab ler

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




8/36

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 referencedocumentationz/OS System Commands for detailed system command syntax.

SMC for CKD devices

Array p roper t ies

Symmetrix array management begins by understanding the elements available for control and the actionitems that can be performed with these elements. Figure 3captures the Properties view from an SMC

instance. The hierarchy of objects is displayed in the left panel, and the properties information for thatobject 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 ofService, 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 CUand data on an individual device from that list can be obtained by selecting one device and so on. Figure 2

on page 7shows 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




9/36

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 Figure4. 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 thedisk.

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 freespace 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 4show the Used and Free capacity. These fields sum to theActual 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 fieldsonly 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




10/36

Conf igurat ion s ession 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 extensiveexperience 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 executionof 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 andcomfortable 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 confirmsthat a legal configuration or series of legal configurations can be created.

Commit All sends all task parameters to SymmWin in the appropriate array andloads all legal configurations created.

Abort attempts to stop a commit that is currently in progress. Many scripts have a point ofno return after which an abort is not possible.

Figure 5. Configuration list management

Figure 5also 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 usefulto 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.




11/36

Symmetrix audit log

The audit log contains information about all operations performed on the chosen Symmetrix array. Selectthe 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 logto launch the SymAudit filter dialog box.

The filter dialog box displayed in Figure 6shows the assists available for the retrieval of audit log entriesconcerning 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 7on page 12details 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.




12/36


SMC Command History

In addition to providing audit records, a log of SMC user functions and results is available. The display inFigure 8shows an extract from the Command History log for an SMC instance that is connected toSymmetrix 000190102000. Command History is an item directly available from the main menu. An arrayobject 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.





13/36

Device creat ion

Non-meta CKD 3380 or 3390 devices

Figure 9illustrates 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 isto 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, mappedand 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 thedevice 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. SMCintelligently 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 availablein the dialog box to create all the various device types.

Figure 9. CKD-3390 device creation




14/36

Meta (RAID 10) CKD devices

Figure 10shows 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 10shows 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 mappingoption 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 16for more information on why atemporary 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 3339and 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 boxhas noselectable 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 theDevice Configuration option is used to activate the Change Device to RDF Configuration dialog box.

Figure 10. CKD-3390 meta device creation




15/36

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 11outlines 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 tolaunch 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 temporarySSID. The section SSID management on page 16has 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 duplicationtemplate 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 begray and unavailable if SRDF devices are used as the model device.

Figure 11. CKD-3390 device duplication




16/36

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 notassigned to SPLIT 0 (a set of EA/EF director ports) that also has SSID140. 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

operationsthere is always a period of time when devices exist but are not mapped. Consequently atemporary 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 13shows an example breaking this rule where CU image 00 addresses 00-07 have two SSIDs, 140and 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 CUimage and that is the existing SSID for that CU.

Figure 13. SymmWin SSID management 2




17/36

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 VaryOnline 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 14a 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 runningoperating 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 aunique 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 codereduced 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.




18/36

Figure 15presents 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 EMCCustomer 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 alsobe 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. DuplicateLCU images are assigned

to different Symmetrix devices and have different SSIDs. The array serial number presented by eachSPLIT is slightly modified to allow the associated Hosts LPAR to interpret the duplicate CU image

number as an LCU within a unique array. In this manner IOCP conformity can be maintained whenreplacing a number of existing smaller Symmetrix units and collapsing the existing configurations into the

single larger Symmetrix.

Figure 16shows 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 ofCU 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




19/36

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 allports 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 notmap 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 portsin 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 MVSrestriction 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 notyet in a CU. Selection of

the correct object to initiate mapping therefore starts with Devices. Select the Devices object availableunder 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 aprotection 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 thefollowing 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.) Allof the ports that currently are grouped and have the same addressing.


Figure 17. Mapping devices



20/36

Unmapping devices

A range of CKD devices with base addresses can be unmapped from the associated EA or EF ports. If thedevices 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 MVScomponents 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 inplace, 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 thecorrect array, identified by serial number. Using the properties view of the CU Image, select the device(s)

to unmap. Right-click or use CONTROLon the master menu to open the control option list. Select z/OSConfiguration > 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 managementon page 16.

All of the ports that currently are grouped and have the same addressing. The unmapped devices mustbe unmapped from all the grouped ports simultaneously.


Figure 18. Unmapping devices



21/36

Assigning aliases

SMC provides for the assignment of alias addresses to base devices in the event that improved I/O deviceperformance 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 appliedconsecutively 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 devicerange. 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 individualallocation 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)




22/36

Unassigning aliases

SMC provides for the removal of alias channel addresses from base devices in the event that additionalchannel 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 upsix 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. (MVScomponents may then move the alias addresses to other bases.) Figure 22shows an allocation that rangesfrom 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 aliasvalues is given in the configuration alias operations must be on the range in its entirety.

Figure 22. Alias addressing in SymmWin(5671)




23/36

Copy Mapping

As discussed in the Mapping CKD devices section, Enginuity 5771 and later use the SymmWindiscipline 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 maintainaddress consistency, the Copy Mapping command is available in 5671. Figure 23shows how to open the

SMC template to run the procedure for copying front-end mapping of CKD devices from one port toanother 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 directoridentified 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 todirectors. 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)




24/36

Device online/offline considerations

The CKD assignment change rules and device online/offline considerations will be summarized here. Theinformation is from Knowledgebase solution EMC77918.

1. A device must only be in one CU.All addresses for a given device must be thesameon all portsto which that device is mapped. Inthe 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 reloadedwith a single director IML.

3. Devices shared with FBA CAN have aliases (InfoMover and FDR/SOS).

4. Two different SPLITs in a Symmetix unit cannotintersect. A SPLIT uses a serial numbermodifier 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 withthe 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 itcannot 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 offlinefor 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 mustbe varied offlinefrom 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, theentire CU imagethe 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 thesame 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 offlinefor the change and when it comes back online the DPAV processcan 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!




25/36

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 notmap to thesame 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 rotationselection 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 baseaddress 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 notyet 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, anydevice 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 bepresented. 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 rangecaused 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 inplace, 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 DDdirectors 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




26/36

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 deviceperformance 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 theRANGE 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 24after using right-click or CONTROL on the master menu to open the control optionlist 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



27/36

The Assign Alias Range statement and the Assign Alias Address statement together define what aliases are

assigned to base addresses. Figure 25shows 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 25shows 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 bothresults are effectivelythe 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




28/36

Unassigning aliases

SMC provides for the removal of alias channel addresses from base devices in the event that additionalchannel addresses are required for allocation to Symmetrix devices. (Return base addresses to the CU.)

Figure 26shows 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 usedtogether. 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 isbased 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 AliasRange and Remove Alias Count together



29/36

Device online/offline considerations

The CKD assignment change rules and device online/offline considerations will be summarized here. Theinformation is from Knowledgebase solution EMC77918.

1. A device must only be in one CU.All addresses for a given device must be thesameon all portsto which that device is mapped. Inthe 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 reloadedwith a single director IML.

3. Devices shared with FBA CAN have aliases (InfoMover and FDR/SOS).

4. Two different SPLITs in a Symmetix unit cannotintersect. Asplituses a serial number modifierto 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 theCKD 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 itcannot 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 offlinefor 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 mustbe varied offlinefrom 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, theentire CU imagethe 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 thesame 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. Thismeans the CU image must be offlinefor 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!




30/36

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 toolhelpful 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 configurationchanges 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.

ReferencesThe 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.




31/36

Appendix

Z ser ies hardware com plex

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 typicalhigh 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 2x 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 PartitionMIF Multiple Image Facility

MSS Multiple Subchannel Set

CHPID Channel Path ID

PCHID Physical Channel ID




32/36

Examp le of HCD con f igurat ion 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 Symmetrixchecks 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 28is from a typical HCD configuration. The

CNTLUNIT and IODEVICE statements provide indicators of resources that SMC has the ability toinfluence. 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

IODEVICEADDRESS=(1A00,224),CUNUMBR=(13DA),STADET=Y,UNIT=3390B

IODEVICEADDRESS=(1AE0,032),CUNUMBR=(13DA),STADET=Y,SCHSET=1,

UNIT=3390A

Figure 28. Example HCD definition




33/36

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 29shows 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 ofz/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 theavailability 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.




34/36

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 noaliases.

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 072043 063 073

04F 06F 07F




35/36

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 3shows 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 aCU is a natural division and would complete the addressing within the CU as Table 4illustrates. (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 addressesrequires 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.




36/36

Planning addresses for Dynamic PAV

Setting Dynamic PAV operation allows the WLM component of z/OS to dynamically reassign alias devicesto 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 environmentthe Symmetrix array must present an initial base/alias allocation to the host.

Table 5is 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 081002 082

03F 0BF

040 0C0

041 0C1

07E 07E

07F 0FF

h5898 Using Smc Ckd in Zos Enterprise Wp

Documents

Transcript of h5898 Using Smc Ckd in Zos Enterprise Wp