FDDRL, HSMS, MAREN, ROBAR, SHC-OSD

Transcription

1 BS2000/OSD V7.0 Issue April 2009 Pages 20 Efficiency, Innovation, Openness and Continuity are the main BS2000/OSD development goals. In BS2000/OSD V7.0 emphasis is placed on the following aspects: Data growth, Data and Backup Management according ILM (Information Lifecycle Management) Data replica and their integration into the BS2000 Storage Management Software SAN integration and autonomous, dynamic I/O resource control Self-regulating functions for simpler and more effective BS2000 operation Unicode: additional character sets for the European language area. Major functional enhancements in BS2000/OSD-BC V7.0 relate to: New hardware / hardware support: Server support: New S165 and S200 S series Business Servers, new SX100-D and SX160 SX series Business Servers Peripheral support: LTO-3 tape drives, Scalar i500 library system with LTO-3 tape drives in connection with ROBAR V6.0 Improved storage integration / storage virtualization / Storage on Demand New Symmetrix DMX functions Snap and Clone: support in SHC-OSD, PVSREN, save/restore to/from snapsets Online provisioning for pubsets Improved SAN integration and I/O resource control SAN check function I/O priority control for tasks Dynamic I/O load balancing for disks Optimized load balancing in CentricStor operation I/O Limitation of VM2000 Guest systems Openness Enhanced character set and character code support: CCS Defaulting, Unicode Support New versions: POSIX A39, Apache V2.2, Java V5.0, WebTransactions for OSD V7.1 General release of BS2000/OSD-BC V7.0: March 2007 New versions of SW products were also released within the BS2000/OSD-BC V7.0 timeframe. The main functional enhancements for certain selected products (AVAS, FDDRL, HSMS, MAREN, ROBAR, SHC-OSD and VM2000) are also presented here. Description Issue: July 2007

2 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 2 / 20 Contents Hardware support 3 Support for BS2000/OSD S series and SX series Business Servers 3 Server support: S165 and S200 S Servers 3 Server support: SX100-D and SX160 SX Servers 3 Peripheral support: LTO-3 drives 3 Scalar i500 Library System with LTO-3 drives in conjunction with ROBAR V6.0 3 Improved storage integration / storage virtualization / Storage on Demand 4 Support for the new Symmetrix DMX functions TimeFinder Snap and Clone 4 Hardware functionality and deployment scenarios 4 Support for Snap and Clone in SHC-OSD as of V6.0 5 Save/restore to/from Snapsets 5 Support for Clone (and Snap) in PVSREN 5 Support for Snap and Clone in HSMS/ARCHIVE V8.0B 5 Online provisioning for pubsets: SPACEPRO 6 Consistent mirroring of SF and SM pubsets 7 Enhancements for System Managed Storage 7 Shifting files on the online processing level 7 PVSREN program enhancements 7 Improved SAN Support and I/O Resource Control 8 SAN check function 8 Autonomous Dynamic I/O Resources Control (IORM) 8 I/O priority control for tasks (IORM function: I/O priority handling for tasks) 9 Dynamic I/O load balancing for disks on FC channel (IORM function: Dynamic Parallel Access Volume) 9 Optimized load balancing in CentricStor operation (IORM function: Dynamic Device Allocation) 9 I/O Limitation of VM2000 Guest systems (IORM function I/O Limit for Virtual Machines) 9 Compression switching for LTO tapes (IORM function: Tape Compression) 9 Availability 10 MONJV for running job 10 Parallelization of the Tape Monitor task 10 Larger reconfigurable memory under VM2000 for SX New subsystem ASE (Auxiliary SERSLOG Extension) for systems diagnosis 10 Openness 11 Extended support for character sets and character codes 11 CCS defaulting 11 Unicode support in BS2000/OSD 12 POSIX A39 13 Apache V Java V WebTransactions for OSD V Enhancements in SW products 15 AVAS V FDDRL V HSMS/ARCHIVE V8.0B 15 MAREN V Parameter changes effective immediately 16 Changing the exits during online operation 16 MAREN executable without TSOS 16 Volume groups 16 ROBAR V Faster and safer order-processing in ROBAR-SV 17 Multi-location control of ROBAR-operations improves ease-of-use 17 Improved User Interface with respect to failure messages and alerts 17 Support of the ADIC-library i500 an attractive midrange offer 17 Linux- and Primergy-platform for ROBAR-SV new freedom of choice 17 SHC-OSD V SHC-OSD V VM2000 V VM assignment of pubsets 18 Finer privilege levels for implicit device assignment 18 Support for Snapsets 18 Enhanced support for large configurations 18 Shutdown for individual VMs and coordinated shutdown for the entire VM Enhanced performance monitoring with SHOW-VM-STATUS 19 SW product overview 19

3 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 3 / 20 Hardware support Support for BS2000/OSD S series and SX series Business Servers BS2000/OSD-BC V7.0 supports all current BS2000/OSD S series and SX series Business Servers. BS2000/OSD-BC V7.0 was released for the SX servers as part of the OSD Extended Configuration Package OSD/XC version 3.0. As a carrier system, the Solaris 8-based X2000 version 3.0 will be continued to support the SX servers. Server support: S165 and S200 S Servers BS2000/OSD-BC V7.0 supports the new S165 and S200 S series servers. Thus in the upper performance range, BS2000/OSD- BC V7.0 supports BS2000/OSD servers based on /390 architecture with more than RPF capacity. Pilot release of these servers was effective in May, The S165 and S200 servers were also released for operation with BS2000/OSD-BC V5.0 and V6.0. Server support: SX100-D and SX160 SX Servers BS2000/OSD-BC V7.0 supports the new SX100-D and SX160 SX series servers. The X2000 carrier system was rebased on Solaris 10 for supporting the SX100-D and SX160 servers (X2000 V4.0). Thereby the SX160 offers an important increase of multiprocessor performance compared with SX150 and thus an enhanced system scalability. Pilot release of these servers was effective in July, Peripheral support: LTO-3 drives With BS2000/OSD-BC V7.0, the device type LTO-3 is supported in addition to the LTO device types LTO-1 and LTO-2 supported hitherto. Also coming on-stream with the LTO-3 device are new 512-track magnetic tape cartridges with a capacity of 400 GB uncompressed (new volume type TAPE-U3). LTO-3 devices are intended to operate with SX and S servers in conjunction with an ADIC Scalar 10K, i2000 or i500 (see below) library system. In addition, LTO-3 drives can be operated on SX servers within an FC-connected FibreCAT TX24 library system. If the high-performance LTO-3 devices are to be connected directly to BS2000 hosts (directly means without CentricStor), a well-balanced configuration is supposed, i.e. also fast disk peripherals are required, the disks must be connected via Fibre Channel. In order to support the high LTO-3 data rates in an adequate way (the maximum data rate is 80 MB/sec (uncompressed)), new versions of the BS2000 backup products were released, that attain corresponding data rates by parallelizing disk access. In V8.0B, HSMS and ARCHIVE parallelize disk access by using the PAV feature (Parallel Access Volume) on S servers resp. the I/O parallelisation within the RSC feature on SX servers. In V16.0, FDDRL supports I/O parallelisation and, in addition, the simultaneous backups from two disks on a single tape (Multiplexing). The release was effective for OSD V6.0 and OSD V7.0 (For details see the respective product chapters). If no optimum disk configuration is available, the LTO-3 devices standard compression function can be switched off with the new I/O resource manager IORM, in order to decrease the minimum data rate hat is required for the LTO-3 tapes streaming function (see IORM TCOM tape compression function on page 10 for details). See White Paper Efficient Peripheral Operation with BS2000/OSD for more details In CentricStor, the connection of LTO-3 devices is possible as of version 3.1 from November Scalar i500 Library System with LTO-3 drives in conjunction with ROBAR V6.0 The intelligent Scalar i500 is a midrange library with industry leading scalability, performance and reliability. Based on the iplatform architecture, progressive backup functions were integrated directly into the library, in order to enhance the data security in general, to facilitate the management, to reduce the needed external servers and software and to minimize the time and cost spending over the total backup system lifecycle. Capacity-on-Demand scalability enables the customer to expand the Scalar i500 capacity by steps of 46 slots from 36 to 404 tape slots. LTO-3 drives are integrated into the scalar i500 systems. Control of the new Scalar i500 library was implemented in the new ROBAR V6.0 version.

4 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 4 / 20 Improved storage integration / storage virtualization / Storage on Demand Support for the new Symmetrix DMX functions TimeFinder Snap and Clone Hardware functionality and deployment scenarios For Symmetrix DMX storage systems, EMC provides the new local replication mechanisms Timefinder/Snap and Timefinder/Clone in addition to the SRDF and Timefinder/Mirror replication methods (previously and hereinafter referred to as BCV). Timefinder/Snap produces a virtual copy of a logical volume at any snap(shot) time as follows: Timefinder/Snap saves the content of the volume by writing a copy of the original block into a special Symmetrix space, the so-called Save Pool, when a block of the original volume is modified for the first time (copy-on-first-write technique). For snap-based recovery, the blocks are copied back from the Save Pool to the original volume. The Save Pool is present as a single default pool as standard. In Symmetrix DMX starting with Enginuity 5671, further Save Pools can be set up in addition to the default pool. This enables the Save Pool to be partitioned and individual snap sessions to be segregated from one another. Considerably less disk space is required for snaps than for BCVs. With multiple consecutive snaps for a volume, only the originals of the blocks modified with respect to the next more recent status will be saved in each case. A maximum of 15 consecutive snaps can be created for a volume. As of Enginuity 5772 update scheduled for Q , the maximum value is being augmented to 127. Unlike with BCV, no preamble run for taking a copy is necessary with snap. The primary deployment scenario for Timefinder/Snap is fast and efficient disk backup and restore. It is also possible to use Timefinder/Snap as input for tape backup and as a free disk copy (only for read access). TimeFinder/Snaps and TimeFinder/Clones Original Volume View Volume A Track A Production view of volume BCV / Clone Track B Track C Point-in-time Mirror Save Area Point-in-time Snap EMC TimeFinder/Mirror (BCV) or TimeFinder/Clone TimeFinder/Snap Full-volume copies Pointer-based copies Requires 100% source capacity Requires ~30% source capacity Applications access volumes independently Applications share access to volumes Source: EMC 2 TimeFinder/Clone is a flexible and powerful method for creating copies of entire Symmetrix DMX volumes. From the user viewpoint, a clone unit is an instantly available copy of a volume. With Clone, unlike with BCV, no preliminary run is necessary to create a copy, since the copy-on-access technique is used for clones: TimeFinder/Clone in each case copies the tracks to the clone unit which are accessed for writing on a unit of the clone pair or for reading on the clone unit. Two operating modes are possible: Clone can generally (only) operate in copy-on-access mode (copy as snapshot) or The storage subsystem copies the entire original unit to the clone unit in the background. In both cases TimeFinder/Clone requires 100% additional disk space. In contrast to BCV pairs (original unit + BCV unit), clone pairs do not consist of predefined unit types which, like the BCV units, have to be configured and maintained independently. After the clone pair relationship has been dissolved, the two units of the (former) pair can be used freely. In particular, new clone pairs can also be formed. Positioning of Clone vs. BCV TimeFinder/Clone provides everything a customer needs to create data replicas for parallel processing. Clones are used (like BCVs today) as input for tape backup and as a free disk copy. In some cases Clone offers even more than BCV. The main advantage of clones is their flexibility: no specially preconfigured BCVs are necessary. A clone can become an original for a further clone session, whereas a BCV always remains a mirror.

5 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 5 / 20 TimeFinder/Mirror (BCV) continues to be a good solution for environments in which very high performance and availability can only be ensured with true mirror volumes. Support for Snap and Clone in SHC-OSD as of V6.0 Snaps and clones are integrated in SHC-OSD with the release of SHC-OSD version 6.0. Specifically, the following functions are offered: Implementation of session actions (Start, Stop, Activate, Restore, Restart-Clone) Information function for the Snap/Clone sessions Integration functions for HSMS, such as special renaming, selection of the Snap list, processing of VSN lists, etc. Integration with the SRDF family (e.g. snap of SRDF target) Support for CKD and FBA disks Monitoring of the use of the Save Pool of the Symmetrix system, output of warning messages to the console when certain fill levels are reached or modified. Save/restore to/from Snapsets BS2000/OSD-BC V7.0 supports snapshot-oriented backup/restore scenarios in DMX configurations. The virtual pubset copy that can be used for restore consists of the simultaneously generated snap units for all volumes of the pubset. The snap unit is a virtual device that contains the pointers to the original data. For unchanged data, the pointers address the original volume. For changed data, the pointers address the Save Pool. Snap units need to be configured both in the disk subsystem and in the S servers IORSF resp. the SX servers X2000 device configuration. A pubset copy from snap units of this type is referred to below as a snapset. Snapsets are not full-blown pubsets, but pubset mirrors which can be accessed in read mode only and moreover only in order to restore individual files or complete pubsets. Snapsets are implemented as special pubsets and addressed using a pseudo notation based on the original notation. DMS access by normal user applications is not possible (i.e. no normal IMPORT). A maximum of 15 snapsets can be administered for one pubset with the currently released Enginuity version. In BS2000/OSD- BC V7.0, 26 snaps are provided as an advance feature for the future 5772 and higher Enginuity versions. Snapsets are created and deleted by the administrator using the new CREATE-SNAPSET and DELETE-SNAPSET commands; the administrator can restore an entire pubset from the last snapset with RESTORE-PUBSET-FROM-SNAPSET. These functions are implemented internally by means of the SHC-OSD V6.0 functions for TimeFinder/Snap control (resp. SHC-OSD V6.1 for Enginuity 5772). New DMS functions enable the end user to restore individual files and job variables from the available snapsets. SHOW commands (SHOW-SNAPSET, LIST-FILES-FROM-SNAPSET, LIST-JVS-FROM-SNAPSET) and action commands (RESTORE-FILES-FROM-SNAPSET, RESTORE-JVS-FROM-SNAPSET) are provided for this purpose. In addition, LMS supports in its supplement version V3.3B the restoration of library elements from snapsets. When operating shared pubsets the snapsets can be used from all systems. In a disaster recovery scenario with SRDF mirroring, snapsets can be operated also in the target storage subsystem. Synchronization of volumes with Restore Pubset Volume-based reconstruction of pubsets is achieved by copying back the most recent snapset to the volumes of the pubset and subsequently renaming the special VSNs as standard VSNs by means of the new RESTORE-PUBSET-FROM-SNAPSET command. The process also takes account of the fact that the number of volumes in the original pubset may be larger than the number of volumes in the snapset, since, of course, volumes can be added to a pubset. Restore pubset is not possible if the pubset was deconfigured after the snapset creation. Support for Snapsets in VM2000 V9.0 VM2000 V9.0 supports snap units (of snapsets) as follows: VM2000 identifies snap units and displays their characteristics. The new VM privilege AUTO-SNAP-ASSIGN permits the implicit VM assignment (ASSIGN-BY-GUEST) of a snap unit for a snapset by a VM without the VM2000 administrator having previously assigned the corresponding ASSIGN-BY-GUEST attribute by command to such a device. I.e. with the appropriate privilege, a VM can assign snap units for the snapset automatically without preparing measures in VM2000. Support for Clone (and Snap) in PVSREN Using the Symmetrix TimeFinder function Clone it is possible to split off copies of a pubset (split). If the split-off pubsets are to be processed in parallel to the originals, the pubset has to be renamed before. With the PVSREN program in BS2000/OSD-BC V7.0, both SF and SM pubsets can be used as source pubsets. In addition, the creation of free pubsets based on snaps is also supported in PVSREN. Snap-based free pubsets are (only) useful for short-term use with predominantly read access. Only clone copies are suitable for creating pubsets that are intended to lead an independent existence. Support for Snap and Clone in HSMS/ARCHIVE V8.0B Conventional tape backup of snapsets is supported with HSMS V8.0B. The files/jvs saved in snapsets can be copied into backup archives using HSMS. Snapsets and conventional archives are separate backup resources (differentiation by the user). Clones (like BCVs today) are used as input for tape backup. Clone support in HSMS is based on the same HSMS call interface as for HSMS backup of BCVs. To express the neutral usage of disk copies as BCVs or Clones some changes had been made within the command //BACKUP-FILES. The parameter BY- ADDITIONAL-MIRROR-UNIT is replaced by BY-ADDITIONAL-UNIT and the operand RESUME-MIRRORING by DISCARD-COPY. The former parameters are still supported by compatibility reasons. In other words, the system administrator initializes the clone session with /START-CLONE-SESSION (similar to initializing the BCV mirror with /START-MULTI-MIRRORING). HSMS is called with the same user interface for clones and BCVs, the distinction amongst BVC and Clones is made in the BS2000/OSD-BC V7.0 CCOPY subsystem. If a clone is present, the clone

6 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 6 / 20 pairs are then activated by HSMS internally via a privileged program interface of SHC-OSD (similar to the splitting of the BCV pairs using this interface). This mode of use requires an Enginuity version 5671 or later. For more details see White Paper Use of Symmetrix TimeFinder Replication Functions with BS2000/OSD Online provisioning for pubsets: SPACEPRO SPACEPRO (SPACE PROvisioning) is a PROP-XT application in BS2000/OSD-BC V7.0 which monitors pubsets for saturation and where necessary extends them in a controlled manner with volumes from a free pool. A sufficiently large, unoccupied public space is essential for proper operation of BS2000. Currently, this space has to be made available anticipatory by the system administration. With SPACEPRO in BS2000/OSD-BC V7.0, the number of disks in a BS2000 pubset can be adjusted automatically. Automation helps avoid potential operator errors and supports (temporarily) unattended operation. If a defined threshold is reached or exceeded (imminent pubspace bottleneck), disks are added automatically. The free disks are held in reserve here in one or several pubsets consisting of free, but already BS2000-formatted disks. To provide better use of resources, this pool of free disks is available to a number of BS2000 and/or VM2000 systems. SX/S Server (native) SX/S Server (VM2000) VMx VMy BS2000 Pubsets SPACEPRO SYMMX / DMX / FibreCat The pool pubsets are setup by the BS2000 administrator and consist of disks whose physical characteristics match the characteristics of the disks of the pubset to be extended. The relevant physical characteristics are e.g. CKD, FBA) or the Disk Box. When the pubset has to be extended, the physical characteristics are determined dynamically, and the logical attributes can be adapted accordingly (e.g. by VOLIN). The product SHC-OSD is used to check the physical characteristics of disks in a Symmetrix box. When pubsets are extended using SRDF or BCV mirroring, a homogeneity check can be performed in BS2000/OSD-BC V7.0 (see below under Consistent mirroring of SF and SM pubsets). On SX servers SPACEPRO supports the storage systems EMC Symmetrix and FibreCAT. However the FibreCAT mirroring functions Snapview and Mirrorview cannot be controlled by BS2000. Technical implementation: The space-saturation console messages issued by BS2000 are recorded by a PROP-XT application, which initiates automatic pubset extension via SDF-P procedures if a definable threshold is exceeded. Alternatively, the INSPECTOR in opensm2 can also monitor the saturation of a pubset and launch SDF-P procedures. The following improvements have been implemented in opensm2 V7.0 for the rule-driven execution of procedures: Passing of editable parameters to the called procedure (e.g. name(s) of the pool pubset(s) (CAT-ID) or the volume (VSN) or the device (MN)), Invocation of a number of procedures on different systems (e.g. monitor and guest), synchronized and controlled via their results. For online provisioning under VM2000, implicit device assignment is extended by the guest system operating function ( ASSIGN-BY-GUEST ) in VM2000 V9.0: The devices of a disk pool can then also be assigned from within a guest system for itself automatically, in a controlled manner and as appropriate for a pubset that is to be extended, and this assignment is preserved even after a VM2000 restart. Cross-BS2000 synchronization is achieved by IMPORT/EXPORT of the respective pool pubset: After attachment (using /ATTACH *PUBSET(cat-id)) and exclusive importation of the pool pubset, SPACEPRO determines which volumes are available and selects one, which is removed from the pool pubset (/MODIFY-PUBSET-PROCESSING). After this, the pool pubset is exported again and detached (using /DETACH *PUBSET(cat-id)). In the process the reduced list of volumes is noted in the SVL of the PUBRES. The removed volume remains ATTACHED; it is reformatted and renamed (VOLIN) and integrated into the pubset to be extended using /MODIFY-PUBSET-PROCESSING. A 2nd system wanting to serve itself from the same pubset afterward finds a reduced pubset following /ATTACH and /IMPORT and selects one of the remaining volumes. The exclusive import function prevents two systems making use of the same pool pubset simultaneously.

7 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 7 / 20 A manually callable function is provided for reducing pubsets (returning free disks). Here the SPACEOPT function CLEAR- VOLUME serves to free a volume. As this operation requires considerable I/O resources, it should be performed selectively at times of low load. SPACEOPT writes a protocol of all pubset expansions into a history file. In order to test a SPACEPRO configuration, threshold exceeding can be simulated. SPACEPRO operation requires functions of the PROP-XT and JV products. Consistent mirroring of SF and SM pubsets The mirror mechanisms available for Symmetrix storage subsystems BCVs, SRDF, snaps and clones cater for various deployment scenarios such as pubset backup and creation of free pubset copies. The particular mirroring technique must be provided here for all the volumes of a pubset, i.e. the same types of mirror must be maintained for all volumes of the pubset, and all the mirrors must be in the same operating state. Up to OSD V6.0, for BCV and SRDF mirroring, the operator must ensure this by administrative action. With snapsets, the snap units are assigned to the volumes of the source pubset automatically (by SHC-OSD or NDM) at the time the mirrors are required as a backup archive (snapset) or for creating free pubsets. The question of homogeneity therefore does not arise for this mirror type. In BS2000/OSD-BC V7.0, the target configuration can be checked when commissioning or reconfiguring an SF or SM pubset to ensure that the relevant BCV and SRDF mirroring is performed consistently for the entire pubset. This check takes place (as an option) at the time of commissioning a pubset as part of the import processing, at the time a pubset is extended by individual volumes or by one or more volume sets by means of the /MODIFY-PUBSET- PROCESSING command and with the /CHECK-PUBSET-MIRRORS command at every time (so the pubset mirrors can be monitored continuously). Messages of the DMS commands are issued and help to identify the affected volumes, so error states can be removed and missing mirrors can be setup. Enhancements for System Managed Storage System Managed Storage (SMS) in BS2000/OSD enables the storage administrator to define within a public volume set (pubset) a hierarchical storage system consisting of the online processing level and migration levels on disks and tapes. Shifting files on the online processing level In the FibreCAT storage systems attached to SX servers, ATA disks (large, cheap, slower containers) are supported in addition to fast FC disks. The benefit lies in the reduction of expensive online storage, without forfeiting SLAs for data access. With the DMX-3, EMC offers tiered storage in a box in the form of disks running at different spin speeds, in particular also lowcost FC disks (LC-FC) for the DMX-3 systems. BS2000 supports ATA and LC-FC disks as normal disks. ATA disks can already be integrated into SMS/HSMS today, for example by way of special service classes at the online processing level or in the form of use at the migration level by HSMS. With BS2000/OSD-BC V7.0, a MOVE-FILE function is offered in order to support the exporting of files into low-performance volume sets at online processing level (SM pubset). PVSREN program enhancements PVSREN can be used to create free pubsets from pubset mirrors. With PVSREN, SF as well as SM pubsets can be replicated. In addition to the adjustments made in the TSOSCAT or the file-related catalogs of an SM pubset, PVSREN currently performs further modifications as an option: Renaming of the default catalog ID in the user catalog of the HOME-PVS. This is relevant if the newly created pubset is to replace the source pubset or if the replicated pubset is to be used on a different system. Renaming of the default catalog ID in the user catalog of the replicated pubset. Modification of the IMON software configuration inventory. This is relevant, as above, if the replicated pubset is to replace the source pubset or if the replicated pubset is to be used on a different system. In BS2000/OSD-BC V7.0, PVSREN was enhanced as follows: PVSREN automates the adjustment of the storage classes. The storage classes for the newly created pubset can optionally be reset or taken over. In the latter case the volume lists stored in the SYSCAT.VSETLST catalog are aligned with the catalog IDs of the new SM pubset.

8 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 8 / 20 Improved SAN Support and I/O Resource Control SAN check function The complexity of the cabling and generation of the components has increased due to the introduction of Fibre Channel/SAN in the BS2000 environment. With SAN connection technology, only a limited view of the actual peripherals is possible using the existing control and monitoring functions. Consequently it is difficult to trace the causes of errors during online operation or when devices are attached. Host1 Host2 Host3 CHPI D A8 AC CHPI D 88 8C CHPI D 68 6c Fabric FC Switch1 P0 P4 P1 P5 P2 P6 P3 P7 P8 P8 P0 P4 P1 P5 P2 FC-SwitchP6 2 P3 P7 Disk Subsystem 1 D101/<wwp D102/<wwp D103/<wwp D104/<wwp CTL Disk Subsystem 2 D201/<wwp D202/<wwp D203/<wwp D204/<wwp CTL Disk Subsystem 2 D301/<wwp D302/<wwp D303/<wwp D304/<wwp CTL The SAN check function (utility SANCHECK) is designed to support the detection of generation errors and the location of error states in the SAN. The following functions are provided: SHOW-SAN-PATH This command allows to search and to show the path via the SAN switches for a predefined selection of the hardware configurations source and target units. Dependent of the given operands, the paths are checked for all the systems generated connections, or all generated connections to a given hardware unit, or only a connection between two given units. SHOW-SAN-CONFIGURATION This command shows information for the required SAN components. The SAN configuration data is determined using POSIX-based SNMP interfaces. The getmany SNMP functions used by SAN CHECK are provided within the SNMP-LIGHT BS2000/OSD-BC component as well as within the SBA-BS2 product (SNMP- Basic-Agent BS2000). SANCHECK supports Brocade and Mcdata switches. After each modification of the configuration definition and after changes in cabling or zoning settings, SANCHECK should be used for a comparison of the configuration definition and the actual cabling and zoning settings. By doing this configuration problems can be detected and eliminated in time. The SANCHECK description is part of the BS2000/OSD-BC V7.0 utility manual. In addition, a description paper Fibre Channel Error Detection for S Series BS2000/OSD Business Servers is available. With some examples of configuration problems this document helps in detecting and eliminating the reason of such problems. The description paper is available in the internet under the following link: The SAN check function was implemented as a decoupled subsystem and was released for BS2000/OSD-BC V5.0C or higher. Autonomous Dynamic I/O Resources Control (IORM) In order to further enhance the BS2000/OSD I/O characteristics, the IORM subsystem was developed in BS2000/OSD-BC V7.0. IORM comprises the following functions to control I/O resources in an autonomous dynamic manner (devices, controllers, channels, paths): IOPT - I/O Priority Handling for Tasks DPAV - Dynamic Parallel Access Volume DDAL - Dynamic Device Allocation IOLVM - I/O Limit for Virtual Machines TCOM Tape Compression IORM connects itself at the BS2000 I/O system at startup and collects I/O data about it. With these data, the I/O resource load can be determined. IORM checks periodically, if the I/O operation must be intervened. The IORM functions IOPT, DPAV and IOLVM deal with disk devices, the DDAL and TCOM functions deal with tape devices. If in VM2000 operation IORM operates on the monitor system and on all guest systems, the IORM subsystems exchange I/O data and control information via a VM-internal interface. This requires at least VM2000 V8.0.

9 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 9 / 20 The IORM subsystem supports S and SX servers as well as type S and type FC channels. In the End of 2006, IORM was released with correction package also for BS2000/OSD-BC V5.0C and V6.0B. Under these versions appropriate subsets of the new functions are available. I/O priority control for tasks (IORM function: I/O priority handling for tasks) Up to OSD V6.0, a low-priority, yet I/O-intensive application on a device can adversely affect higher-priority applications running on the same device. Three I/O priorities low, medium and high were therefore introduced in BS2000/OSD V7.0. These can be assigned to the task categories using /MODIFY-TASK-CATEGORY. For all tasks in such a category, the task I/O priority is determined by the predefined I/O priority of the category. Under PCS, this enables a further dynamic allocation to be set in the I/O priorities via the follow-on categories mechanism (automatic category switching). If tasks with low or medium I/O priority hold back higher-priority tasks with medium or high I/O priority, only a limited utilization level will be allowed for each I/O priority. Depending on the load being handled by the devices, controllers and channels, lowpriority I/O jobs will be forced to slow down by time penalties. The /SHOW-SYSTEM-STATUS INFORMATION=*CATEGORY command information output was extended by the I/O priority specification. Dynamic I/O load balancing for disks on FC channel (IORM function: Dynamic Parallel Access Volume) As an alternative to simple disk access (standard), parallel disk access is supported on S servers as of BS2000/OSD-BC V5.0 (PAV = Parallel Access Volume). With Parallel Access Volume (PAV), several device addresses (alias devices) are assigned to a logical device (base device). This enables to direct several I/O requests to the same volume in parallel. Cache-hits are served simultaneously in the disk storage system (EMC), while a cache-miss is operated by physical I/O in parallel. With PAV the response times for heavily used disks can be reduced and the maximum I/O rates on a volume can be increased. PAV on the FC channel is a pure software solution that can be put into operation without interventions at the Symmetrix controller. To implement the PAV functionality, BS2000 takes advantage of the ability of a device to accept an I/O request at the FC channel while an I/O is still active. Static PAV requires predictive planning of the future utilization of device capacity, so proactive measures must be taken in the BS2000 system (generation of alias devices). In advance via generation one or several alias devices must be assigned to the devices where heavy load is assumed. Dynamic PAV in BS2000/OSD-BC V7.0 will autonomously assign alias devices to those volumes that will benefit most. I/O bottlenecks due to accesses to the same disk by multiple jobs will be alleviated by automatic attachment of alias paths. Dynamic PAV is offered for S servers and disks on type FC channels. On SX servers as an analogous function an I/O parallelization for emulated disks is realized via RSC as of BS2000/OSD-BC V6.0B. Optimized load balancing in CentricStor operation (IORM function: Dynamic Device Allocation) The use of virtual tape devices in CentricStor can be set in BS2000/OSD-BC V7.0: As an alternative to using devices as defined at generation (as previously), the system can ensure uniform utilization of all available ICPs (Integrated Channel Processors). The device management will note the number of devices reserved for each ICP and take this counter into consideration during device selection. The device management, however, does only know the device reservations within a system. If several guest systems on a server request for devices at the same time, load distribution can be unbalanced even while device management is optimized. The Dynamic Device Allocation IORM function extends the optimized local device selection to all systems of a server operating VM2000. This requires IORM to be run in the monitor system and in all guest systems. A VM2000-global internal communication ensures IORM to be informed about the ICPs overall reservation by all servers systems. In case of a device reservation request, IORM provides the device management the counter for reserved devices in all guest systems for each controller. VM1 VMn BS2000 server ICP ICP ICP CS log. LW device selectionold: device selection new: I/O Limitation of VM2000 Guest systems (IORM function I/O Limit for Virtual Machines) Currently, a low-priority, yet I/O-intensive guest system can adversely affect higher-priority guest systems. Conflicts can arise when these guest systems process I/Os on the same (logical) device or on different (logical) devices that however reside on the same physical device, or are connected via the same paths, or can be reached via the same ports or are connected on the same channels. IORM can detect these conflict situations and can proactively intervene into the I/O processing. Compression switching for LTO tapes (IORM function: Tape Compression) For an optimum data backup on LTO tapes, a minimum data rate is required for continuous streaming of the tapes. For LTO-3 tapes on LTO-3 devices this minimum is 40 MB/sec uncompressed resp. 80 MB/sec compressed. In the range between approx. 40 MB/sec and approx. 80 MB/sec the minimum data rate is reached if the device compression function is switched off. The compression function being switched off, the tape capacity is lower as well (ca. 400GB instead of 800 GB for LTO-3). As a default, compression is always switched on in BS2000/OSD-BC V7.0 (also without IORM operation). TCOM allows to switch off compression completely. As an alternative, TCOM offers the possibility to switch the compression dynamically

10 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 10 / 20 according to the data rate. Compression is switched off if the data rate without compression is sufficient for streaming but not the data rate with compression. Availability The aim is to avoid/reduce scheduled shutdowns (improvement of the self-configuring characteristics of BS2000/OSD), and to avoid/reduce unscheduled system interrupts (improvement of the self-healing characteristics of BS2000/OSD). BS2000/OSD- BC V7.0 includes further developments aimed at increasing availability: MONJV for running job In order to monitor applications by means of MONJVs, hitherto a MONJV must be assigned to the task at application start.. In BS2000/OSD-BC V7.0 the system administrator (TSOS) can assign a monitoring MONJV afterwards to a running job with the MODIFY-JOB-OPTIONS command. This allows to activate the application monitoring after a configuration update or after handling errors without a shutdown of the application. Parallelization of the Tape Monitor task The Tape Monitor is a performance-critical instance for scheduling mount operations and for monitoring the online security of magnetic tape cartridges (MTCs). If this task is blocked, no more mount/demount operations can take place. In the past, blockades caused by delayed I/O jobs were frequently observed at irregular intervals. In BS2000/OSD-BC V7.0, the I/O activities are moved into other runtime units, thereby bypassing the blockades: For the most important and frequent I/O operations (CHECK-TAPE-MOUNT, transition from not_ready_to_ready), instead of the I/O a suitable recover function is invoked which runs under a different task. The IOs for supplying the information display on the device (LOAD DISPLAY) are also exported into a subtask. Larger reconfigurable memory under VM2000 for SX160 Under VM2000 there is the option to add or remove main memory to the BS2000 system while it is running, up to a main memory minimum which must be preserved for BS2000 from the beginning to the end of the system run. In HIPLEX-AF scenarios there is, for example, a standby system (under VM2000) which comes into service if the production system fails. As a standby system, it should occupy as little real memory space as possible, i.e. main memory and main memory minimum should be as small as possible and the real main memory made available to other VM guest systems. If the remaining VM2000 guest systems are to be retained when the tasks of the production system are taken over by the standby system, then it also makes sense for these systems to have a very small main memory minimum. The reconfigurable part of the main memory used was made substantially larger in BS2000/OSD-BC V7.0 for SX160 servers by moving large consumers of the real main memory, such as Big Pages for JIT compiled code and DAT tables (Page-Tables for Big Pages etc.) into the main memory above the main memory minimum. This provides more freedom for cross-system resource optimization without this requiring the system to be terminated. The Big Pages for JIT compiled code demand at high load periods hitherto represented the lower limit of the main memory minimum, which was about 40% of the main memory size at high load periods. This limit was lifted in BS2000/OSD-BC V7.0: New Big Pages can be generated during main memory enlargement (previously only when the main memory minimum was increased). Big Pages occupied by local JIT compiled code can be dissolved e.g. in the event of main memory saturation and main memory reduction. The system therefore adapts automatically to the main memory size when Big Pages are provided. This applies for SX160 servers, because the required CISC FW extensions were implemented in X2000 V4.0. New subsystem ASE (Auxiliary SERSLOG Extension) for systems diagnosis The new subsystem ASE enables automatic reactions on critical system conditions that reflect in SERSLOG entries: Protocol in buffer, message on console, teleservice alert Thresholds can be defined for the events to be monitored. The protocol can be restricted to selected SERSLOG events. The benefit is an easy, interrupt-free generation of diagnosis material.

11 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 11 / 20 Openness The openness strategy pursued for years is systematically continued with BS2000/OSD-BC V7.0. Extended support for character sets and character codes Purpose of Unicode support in BS2000/OSD Unicode is an international standard in which the long-term objective is to specify a digital code for every character or text element of all known scripts and alphabets. The aim of Unicode is to define a globally unique coding for all characters occurring worldwide. For more details on Unicode, visit the Unicode homepage at Traditional computer character systems comprise a character set of either 128 (7-bit) characters or 256 (8-bit) characters. Until now, the BS2000/OSD system too has only supported 7-bit and 8-bit character sets. These character encodings permit only a few languages to be represented simultaneously in the same text. Following new EU directives and their transposition into national law, this will no longer be sufficient in the medium term (international postal directive on the notation for addresses, BundOnline 2005, German Federal Ministry of the Interior directive on data exchange between authorities). With Unicode support in BS2000/OSD, the EBCDIC character sets available in BS2000/OSD systems will be extended by additional characters that will be required in the European language area in the future. This will be achieved through the use of selected Unicode codepoints in addition to the existing EBCDIC variants. Current situation in BS2000/OSD When processing data, BS2000/OSD uses a 7-Bit EBCDIC character set as standard. The BS2000-defined international 7-bit EBCDIC table, which is used as the system standard character set, is called EDF03IRV. This makes 95 different characters available (160 characters excluding 65control characters). The notation of 7-Bit is caused by the fact that the printable characters correspond to those of ASCII 7-Bit. Using XHCS, BS2000/OSD supports a series of 8-bit ISO codes and the associated EBCDI codes. Extended Host Code Support (XHCS) The concept known as "Coded Character Sets" (CCS) is used to support different character sets and character codes. A CCS defines a character set and the encoding of these characters in the file. The XHCS subsystem is the central information source relating to the coded characters sets (CCS) that are available in BS2000/OSD. It means that the different programs do not have to store information on characters sets permanently: they receive this information from XHCS. XHCS identifies the data codes regardless of where they originate from, e.g. from a terminal input, a program output or another system. The character set name (CCS name) is used to identify the transferred data codes. XHCS makes the coded character sets available in the form of tables. Up to Version 1.5, XHCS supported the 8-bit ISO codes ISO8859-1/2/3/4/5/7/9/15 and the various associated EBCDIC codes. The use of a specific 8-bit EBCDIC code can be set for the entire BS2000/OSD system via the Class-2 option HOSTCODE = CCS-name, or for individual user IDs and pubsets by entering a CCS name in the user ID. The 8-bit code assigned to a user ID is used for the terminal inputs/outputs of the TIAM, UTM and DCAM applications that run under this user ID. This can be controlled globally via the VTSU-B parameter file or for specific user IDs via /MODIFY-TERMINAL-OPTIONS. The CCS-name file attribute can be assigned to describe the binary encryption within a file. All BS2000 pograms suppose to work with data in an EBCDIC code with the so-called EBCDIC kernel to be invariant. Therefore the ISO 8859-x variants should not be used as a system s or user s code. CCS defaulting During the conversion from a 7-bit to an 8-bit character set and also later it is necessary to distinguish converted data from unconverted data. A new system behavior was therefore introduced in BS2000/OSD-BC V7.0 so that the default value for the CCS name of a file can be influenced as follows: When a new file is created, the CCS name of the user entry of the receiving PVS will be used in contrast to previously as the CCS name of the file if this is not EDF03IRV. If it is EDF03IRV, the file will as previously be given the CCS name *NONE. The LMS behavior for new elements is changed in an analogous way: They get the CCS name of the library, if no value is set for the CCS name. In other words, there is no change for customers working with the system standard character set. For customers working with an 8-bit character set, this ruling means that the use of a code at file level is clearly specified. (Previously, the CCS name *NONE was always assigned by the BS2000 data management system. This meant that when a conversion took place, all programs had to be modified so as to supply the file attribute explicitly.) The basic rule is, however, that an explicit specification of a CCS name always takes precedence. When a file is copied, backed up or restored, the CCS-name file attribute is always transferred as well. The modified CCS default behavior was also released by way of a correction in KP 2/2006 for BS2000/OSD-BC V6.0. For converting from 7-bit to 8-bit character set see also White Paper

12 White Paper Issue: April 2009 BS2000/OSD V7.0 Page 12 / 20 Unicode support in BS2000/OSD Unicode usage scenario With the introduction of Unicode support in BS2000/OSD, the code sets available in BS2000/OSD systems are extended by additional characters. Users are provided with the programming and runtime environment that they need in order to extend their existing applications with Unicode data fields. It is assumed here that the number of fields needing to be converted to Unicode or to be additionally inserted is small. These will mainly be name and address fields. The customer only has to modify those applications/application parts that use the extended functionality. Unicode support in BS2000/OSD is implemented on the basis of the existing products. Unicode-based characters are permitted only for the texts that are to be processed/administered, i.e. for the field and container contents, but not for the field and container names. The product-specific rules for commands and object names remain uneffected. Introduction of unicode use in the customer system In addition to upgrading the BS2000/OSD system basis and the system-level tools as well as the programming environment to the required product versions, the customer has to fulfil further preparations, mainly: Data and files are to be moved in a well-defined state. The CCS names (Coded Character Sets) used in the BS2000 system are a focal point in data processing. It is to be ensured that the content and the declaration of the data via CCS name are consistent. The affected applications are to be modified for extra Unicode data fields. Storage of Unicode Characters of the most important industry standard character sets, such as the ISO standards, have a 1:1 correspondence in Unicode (this means that the same result is obtained in a conversion from the industry standard to Unicode and back). Unicode is stored and transferred in different formats. UTF (Unicode Transformation Format) describes methods for mapping a Unicode character to a sequence of bytes. Each character of the Unicode string is represented here by one or more "code units". UTF-8 is the most widely used encoding scheme for Unicode characters and the most space-saving method of mapping Unicode characters for all scripts based on the Latin alphabet. Code units are 8 bits; each Unicode character needs 1, 2, 3 or 4 bytes. Alongside UTF-8, UTF-16 is also very important, e.g. for character encoding in Java. Code units are 16 bits; each Unicode character needs either 2 or 4 bytes. UTF-16 is largely identical to the 2-byte Unicode representation UCS-2. UTF-EBCDIC is a Unicode extension based on the proprietary EBCDIC format used on IBM mainframes. Code units are 8 bits; each Unicode character needs 1, 2, 3, 4 or 5 bytes. UTF-E was newly introduced in BS2000/OSD; UTF-E in BS2000 is similar to IBM s UTF-EBCDIC format. XHCS V2.0 Extensions in the XHCS subsystem (XHCS V2.0 as part of opennet Server V3.2) form the basis for Unicode support in BS2000/OSD. XHCS V2.0 supports the encoding variants UTF-8, UTF-16 (2-byte, BS2000) and UTF-E (variable, BS2000). XHCS V2.0 includes conversion tables for the supported 8-bit ISO codes (ISO8859-1/2/3/4/5/7/9/15) to Unicode and their reverse mapping. In addition to the characters contained in these ISO codes, XHCS supports some 70 characters of the Unicode character set (the special characters used in the alerting signals of public authorities). Unicode in the BS2000/OSD application environment Unicode support for the programming and runtime environment extends to the following functional areas: Programming: COBOL2000, ESQL-COBOL, IFG/FHS (Unicode data fields), AID Data storage: SESAM/SQL, UDS/SQL, ORACLE (Unicode data fields) Data processing: EDT, SORT, PERCON Input/output: terminal support (VTSU, MT9750, FHS), printer support (RSO, Spool), file transfer (openft) A suitable software configuration is provided under BS2000/OSD-BC versions V6.0 and V7.0 in order to support the Unicode functionality in BS2000: Overview: Unicode-specific enhancements in BS2000/OSD system software products Programming: COBOL2000 V1.4 implemented the data type NATIONAL in its different variants and supports the procedural use of this data in compiler and runtime system (CRTE V2.7 for BS2000/OSD-BC V7.0). ESQL-COBOL V3.0 permits the COBOL data type NATIONAL in its Declare Sections and allows its use as a host variable in SQL statements. IFG V8.3 and FHS V8.3 support an identifier for Unicode for individual fields of a format. AID V3.2 provides an LL support of the UTF-16 data type, which is also supported as a new COBOL data type. In addition, given suitable support by COBOL, AID also provides the UTF-16 data type in the LSD. This also enables symbolic debugging of this data type. Data storage: In the SESAM/SQL V5.0 and Oracle 10g DB systems, the introduction of the NCHAR and NVARCHAR data types also allow Unicode characters to be stored and processed using SQL resources. In UDS/SQL V2.5 National data (UNICODE) are supported. Data fields and data groups with PIC N are allowed in the DDL.