BS2000/OSD V7.0 Issue Pagessp.ts.fujitsu.com/dmsp/Publications/public/wp_bs2000-osd... ·...

Issue April 2009

BS2000/OSD V7.0

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

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 SX160 10 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 V2.2 14 Java V5.0 14 WebTransactions for OSD V7.1 14

Enhancements in SW products 15 AVAS V8.0 15 FDDRL V16.0 15 HSMS/ARCHIVE V8.0B 15 MAREN V11.0 16

Parameter changes effective immediately 16 Changing the exits during online operation 16 MAREN executable without TSOS 16 Volume groups 16

ROBAR V6.0 17 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 V6.0 17 SHC-OSD V6.1 17 VM2000 V9.0 18

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 VM2000 18 Enhanced performance monitoring with SHOW-VM-STATUS 19

SW product overview 19


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 4.300 RPF capacity. Pilot release of these servers was effective in May, 2007. 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, 2007.

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 http://docs.ts.fujitsu.com/dl.aspx?id=2efe2fff-f6b6-4652-b5ac-b35efd454610 In CentricStor, the connection of LTO-3 devices is possible as of version 3.1 from November 2005.

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.

http://docs.ts.fujitsu.com/dl.aspx?id=2efe2fff-f6b6-4652-b5ac-b35efd454610


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.3.2007, 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).

Volume A

Original Volume View

Point-in-time Mirror

Track C

Track B

Track A

Save Area

Production view of volume

Point-in-time Snap

BCV / Clone

TimeFinder/Snaps and TimeFinder/Clones

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: EMC2

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.


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


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” http://docs.ts.fujitsu.com/dl.aspx?id=3040f608-c945-430b-b3df-4e85818779a9

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.

SYMMX / DMX / FibreCat

SPACEPRO

SX/S Server (VM2000)

VMx VMy

BS2000 Pubsets

SX/S Server (native)

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.

http://docs.ts.fujitsu.com/dl.aspx?id=3040f608-c945-430b-b3df-4e85818779a9


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 “low-cost 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.


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.

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: http://docs.ts.fujitsu.com/dl.aspx?id=a087709d-69de-4e17-bf08-9a79b1572ca5 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.

Host1 CHPI D

A8

AC

Host2 CHPI D

88

8C

Host3 CHPI D

68

6c

FC Switch1

P0

P1

P2

P3

P8

P4

P5

P6

P7

FC 2 -Switch

P0

P1

P2

P3

P8

P4

P5

P6

P7

FabricDisk Subsystem

1

CTL

D101/<wwp

D102/<wwp

D103/<wwp

D104/<wwp

Disk Subsystem 2

CTL

D201/<wwp

D202/<wwp

D203/<wwp

D204/<wwp

Disk Subsystem 2

CTL

D301/<wwp

D302/<wwp

D303/<wwp

D304/<wwp

http://docs.ts.fujitsu.com/dl.aspx?id=a087709d-69de-4e17-bf08-9a79b1572ca5


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, low-priority 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)

BS2000 server

ICP ICP ICP

log. LW

CSdevice selectionold:

device selection new:

VM1 VMnThe 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. 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


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.


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 http://www.unicode.org/. 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 http://docs.ts.fujitsu.com/dl.aspx?id=8f91a59b-7f96-4947-a14a-66519ac904bd

http://www.unicode.org/

http://docs.ts.fujitsu.com/dl.aspx?id=8f91a59b-7f96-4947-a14a-66519ac904bd


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.


Unicode in the BS2000/OSD system environment

Windows

MT9750

screenbuffer

NEABX810 protocol

BCAM

e.g. UNIX-basedsystem

openFT

other system

VTSU

UTM

DB systemSESAM / Oracle

workingmemory

FHS

UTM applicationEDT

XHCS

openFT

UTF-16EBCDIC

UTF-16EBCDIC

UTF-16EBCDIC

UTF-8

UTF-8 UTF-E

UTF-8

UTF-16EBCDIC

UTF-E

UTF-16

UTF-E

UTF-E

UTF-E

UTF-16EBCDIC

UTF-8

UTF-8 UTF-E UTF-E

UTF-E

UTF-16EBCDIC

UTF-16EBCDIC

Data processing:

For sorting, XHCS provides SORT (V7.9) with the necessary sorting tables. PERCON V2.9 was extended as appropriate for normalizing diacritical characters and for converting files.

EDT V17.0 is able to process files in the Unicode code sets in BS2000. Input/output:

The introduction of an EBCDIC variant of UTF-8 (UTF-E) enables terminal input and output via the MT9750 V7.0 terminal emulation and VTSU-B V13.2 for the extended characters that are to be supported. (VTSU-B V13.2 is included in openNet Server V3.2.)

FHS V8.3 is able to output formats as Unicode-encoded messages (UTF-E) and convert input strings containing Unicode fields into EBCDIC or UTF16 on a field-specific basis prior to transfer into the corresponding buffers of the application.

RSO V3.5 supports UTM-8-capable network printers (currently Printronix P7000 with IBM ProPrinter or EPSON-FX emulation). Here, print files with coding in UTF-8, UTF-16 and UTF-E (dependent on data record type) are accepted (in addition to EBCDIC/ASCII).

In the local spool system, Unicode data in the UTF-16 format can be printed out on Océ high-performance printers in I(PDS) mode (using suitable fonts and Océ SPS driver software).

openFT V10.0 for BS2000 supports the transfer of DMS and Posix files using the Unicode variants UTF-16 (big-endian) and UTF-8.

All data containers remain the same size. In other words, as a UTF-16 character occupies two bytes of storage space, a maximum of 16,000 characters can be stored in a SAM record, for example, and not 32,000 characters. A similar rule applies to database fields of the NCHAR and NVCHAR types. See White Paper “Unicode in BS2000/OSD” for further details http://docs.ts.fujitsu.com/dl.aspx?id=99f163e6-0dd5-4b5e-93d3-81dd6c47d18a

POSIX A39 POSIX as the technical basis of the BS2000/OSD openness strategy is being developed further in accordance with user requirements. The release of the new POSIX A39 version is planned in conjunction with BS2000/OSD-BC V7.0. Functional enhancements are: Dynamic setting of system parameters The POSIX system parameters are defined in the kernel header sys/config.h. They are transferred into the structures of the kernel when POSIX is started up and so are available to POSIX during execution. This is followed by evaluation of the POSIX parameter file (SYSSSI file), which can contain the new current values of the system parameters. In POSIX A39, the current values of selected system parameters can additionally be modified using a privileged command usp. These parameters are:

HDSTNI (maximum number of server tasks for I/Os) HDPTNI (maximum number of mounted (local) file systems) NPROC (maximum number of user processes in POSIX) MAXUP (maximum number of user processes) HEAPSZ (maximum value for break() systemcall) NOTTY (maximum number of ttys) NOSTTY (maximum number of sttys)

http://docs.ts.fujitsu.com/dl.aspx?id=99f163e6-0dd5-4b5e-93d3-81dd6c47d18a


MAXTIMERC (maximum wait time for rc termination (in seconds)) FORCEDTERM (invocation of forced termination)

The modified value can optionally also be entered in the SYSSSI file and so be used automatically at the next startup. Dynamic posdbl cache change The posdbl POSIX command allows the superuser to setup a global program cache of scalable size in order to store executable core images of POSIX programs. These core images are stored either implicitly calling a POSIX tool out of the Shell library or explicitly with the posdbl command. This shortens the load time of these programs. In order to load a stored program, the global program cache is available for all users. The size of the posdbl cache can be changed in POSIX A39 without the POSIX shutdown that was necessary before. Enhancements of the POSIX installation program in batch mode (START-POSIX-INSTALL)

An installation error protocol is written into the /var/sadm/pkg/insterr logging file. Via the new ERROR-HANDLING SDF operand the delivery of a command return code (MAINCODE, SUBCODE1, SUBCODE2) and the Spin-Off mechanism activation within the procedure are supported.

Increase of the maximum amount of local file systems Before POSIX A39, the maximum amount of local file systems was 200. It was increased to 300. However, the corresponding default value in the SYSSSI file remains 200. Measures to ensure better portability of the Java VM

Support for mmap after /dev/zero. This essentially serves to increase performance and reduce the porting overhead for JAVA versions.

Support for shared libraries for JAVA: Dynamically load and initialize the runtime system for JAVA (as for C++ or COBOL) and take account of special characteristics when loading JAVA shared objects.

Improvements/fixes for the POSIX commands lp and lpstat, which are used for printing in the latest JAVA version. Use of the secure shell Restrictions on the use of the secure shell were lifted. The secure shell is available with the product interNet Services starting with V3.0B (openssh). Before POSIX A39, the ssh client program could be used only within a remote-login session (i.e. logged in in POSIX by means of rlogin, ssh, or slogin command). In $DIALOG or TELNET sessions, it could be used only if stdin, stdout and stderr have been redirected to a file or POSIX pipe. This redirection will no longer be necessary with POSIX A39.

Apache V2.2 In the current release version, Apache, the world’s most popular web server, is also available for BS2000/OSD, as well as for Windows, Linux, Solaris, and is included in the operating system basic configuration BS2000/OSD-BC. BS2000/OSD-BC V7.0 will include the new version APACHE (BS2000/OSD) V2.2*. This is based on the official release version 2.2 of the Apache Group web server. With Apache V2.2, the migration to the Apache HTTP Server 2 of the Apache Software Foundation is complete, with support for PHP V4, PERL V5.8, TOMCAT instead of JSERV/JSP. APACHE (BS2000/OSD) V2.2 includes support for the SSL (Secure Socket Layer) protocol for secure transfer of documents and data over the internet; the existing add-on product interNet Security ("Apache+SSL") is omitted. * APACHE V2.2 is planned to be released in May 2008. Deliveries before this date will contain APACHE V1.3.

Java V5.0 With BS2000/OSD Environment for Java (short name JENV), Java is provided as part of BS2000/OSD-BC. BS2000/OSD Environment for Java (JENV) enables any Java programs, written on any platforms, to be run on BS2000 systems. BS2000/OSD-BC V7.0 will provide the new JENV (BS2000/OSD) V5.0. This version fulfils the relevant specifications:

„The Java Language Specification, Third Edition“ „The Java Virtual Machine Specification, Second Edition“ the version-specific API specification „Java 2 Platform Standard Edition API Specification 5.0“

The conformity to these specifications was approved by Sun Microsystems, Inc. by the grant of the „Java Compatible“-Logo for the BS2000/OSD Environment for Java ™ V5.0 (on 10/08/2005). Java Development Kit V5.0 is supplied as an optimized variant for the particular hardware, together with the BS2000/OSD basic configuration. The JDK gives programmers a basic tool for developing Java applications. It comprises the HotSpot compiler, the Java interpreter, the Debugger, Java class libraries and various other tools In addition, JENV (BS2000/OSD) V5.0 includes the JRIO package. This package is a collection of Java classes for native access to record- and/or block-structure files and for record- or block-oriented input/output with respect to such files. JENV V5.0 supports the files of the BS2000 data management system.

WebTransactions for OSD V7.1 The product WebTransactions for OSD implements the integration of any BS2000/OSD applications into the internet or an intranet/extranet. WebTransactions for OSD runs on the BS2000/OSD system platform and works together with the APACHE web server. With BS2000/OSD-BC V7.0, the WebTransactions V7.1 variant will be executable for OSD applications on BS2000/OSD under POSIX, shipped with an unlimited number of user licenses. This creates the basis for using web technology for e-business activities already in the operating system basic configuration. WebTransactions for OSD V7.1 comprises the following enhancements compared to V7.0:

Web integration of Unicode-enabled applications Support for the Unicode-enabled 9750 terminal protocol


Enhancements in SW products From this point forward, we present the functional enhancements implemented in new versions for a number of major software products which were released within the BS2000/OSD V7.0 timeframe, but which are also available for BS2000/OSD V6.0 (and in part for V5.0).

AVAS V8.0 The following main functional enhancements are planned for the future version, AVAS V8.0:

The SYSOUT file of an AVAS job in a BS2000 system can be displayed during its active phase. File transfer requests that are currently serviced within jobs can in AVAS V8.0 be handled via AVAS structure elements. This further increases the transparency of the runtime logic.

The integration of subnets in hypernets is improved: The start time of subnets can be linked to the execution of the hypernet, so that the start time for both can be changed to an earlier one in a single step. The hypernet’s USER-PAR-FILE can be inherited by the subnets.

Significant functional enhancements for servers within the framework of the new AVAS-SV V8.0 version are:

Additional log files can be transferred in server jobs and threshold values for the scope of the transfer can be predefined. Starting with AVAS V7.0, a server administrator can check via a server monitoring interface which jobs (initiated from another system) have been started in the local system. In AVAS V8.0, the server monitoring interface will provide more detailed information (JCL, Joblog) as well as the option to halt job distribution. The aim is greater transparency on the decentralized system.

AVAS V8.0 was released for BS2000/OSD V5.0 or higher.

FDDRL V16.0 With FDDRL V16.0, physical disk backup supports the technical advancements made in the development of MTC technology, both the large capacity and the increased throughput of LTO devices. The Several-Disk Tapeset function enables multiple disks of a pubset to be dumped to a tape/tapeset. This guarantees optimum use of the capacity of large MT cartridges. The simultaneous saving of multiple (two) disks to one tape (multiplexing) compensates for the current performance differences between slow disk and fast tape. The Reload-Pubset function ensures consistent pubset restore. The RELOAD-PUBSET statement affords the same user-friendly convenience as its counterpart DUMP-PUBSET during backup. The pubset configuration and disk characteristics are determined and displayed by accessing saved meta information. This greatly simplifies the task of providing target disks and enables the restore run to be automated to a large extent. The backup volumes for the restore are identified automatically through access to the MAREN volume catalog or, alternatively, on the basis of the FDDRL meta data. FDDRL V16.0 was released for BS2000/OSD V6.0 and V7.0.

HSMS/ARCHIVE V8.0B In connection with BS2000/OSD-BC V7.0, HSMS V8.0B supports the Symmetrix DMX TimeFinder Snap and Clone functions:

The files/JVs saved in snapsets can be copied into backup archives using HSMS. Clones (like BCVs today) can be used as input for tape backup.

See chapter ‘Improved storage integration / storage virtualization / Storage on Demand’, section ‘Support for the new Symmetrix DMX functions TimeFinder Snap and Clone’ for details. 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 order to use PAV resp. RSC in ARCHIVE, buffer management and reading / writing into files (at Save/Restore) was changed at central points: Here are set several asynchroneous I/Os that under PAV are executed in parallel and are executed in sequence without PAV (I/O parallelisation within RSC is standard on SX servers). In addition, asynchroneous I/O were also implemented for copying from Disk-Save-File to Tape-Save-File. Parallel disk access has a positive impact on writing on disk (Restore) and therefore on the data rate when reading from tape. In addition, it causes shorter run times for Save and Restore.


MAREN V11.0 Parameter changes effective immediately MAREN parameters can be modified for all BS2000 systems in the MAREN network by an administrator (primarily the all-domain administrator). Currently, the changes do not take effect immediately in all components and on all systems: In the executing MARENADM, in MARENCP and in the MAREN subsystem on the same BS2000 system, they take effect instantly; otherwise, they are effective only when the components MARENCP, MARENUCP, MAREN and MARENADM are reloaded on all the systems affected. In MAREN V11.0, the immediate effectiveness of parameter changes is achieved by the following measures:

In MAREN and MARENADM, the parameter record (HOSTREC) is read consistently for each statement. On MARENUCP, the HOSTREC is passed as well by the subsystem at each call. If other information is to be transferred, additional identifiers are inserted in the annex to the HOSTREC and evaluated after the HOSTREC has been read.

In cross-system MAREN operation, an exchange of messages is being introduced for the MAREN administration. The MAREN administrator specifies that the relevant statements are also to be effective for other systems as well as the home system. During processing of the statement, a message is sent by MARENADM or within the MARENADM task in the subsystem to the system specified by the administrator and where necessary there is a wait for a response. The message is evaluated on the specified computers and appropriate activities are initiated. MSCF is used as the communication mechanism.

Swapping of the logging file is also instantly effective in MAREN V11.0.

Changing the exits during online operation In MAREN V11.0 it is possible to switch the MAREN exits during online operation. The analogous function for the MARENLM file was already present in MAREN V10.0. Each time a job is executed, a check is made in MARENCP, MARENUCP, OFFLINE to determine whether an assigned exit library has been modified since the last check. For this purpose, CHANGE-DATE and CHANGE-TIME are determined using FSTAT and compared for equality with the previously noted values. If a change is found, all the loaded exits are unloaded using UNBIND and reloaded using BIND. This means that production operation no longer has to be interrupted; it also makes it considerably easier to modify and/or make corrections to exits.

MAREN executable without TSOS Up to MAREN V10.0, MARENUCP and //INITIALIZE-VOLUMES must always be run under TSOS. This is undesirable because MAREN and TAPE administrators are not necessarily also system administrators. In MAREN V11.0, MARENCP, MARENUCP and //INIT-VOL can run under any user ID with TAPE-ADMINISTRATION privilege. The product SECOS is a requirement in order to enable the TAPE-ADMINISTRATION privilege to be assigned to any user ID. In installations without SECOS it is possible in MAREN V11.0 to use the SYSMAREN user ID as an alternative for running MARENUCP and //INIT-VOL. In anticipation of this function, the SYSMAREN user ID was already set up as a new system user ID with the TAPE-ADMINISTRATION privilege in OSD V6.0B. Note: The MARENADM statement //CHECK-TSOSCAT and the //ADD-RESERVED-VOLUME parameter VOLUME=*BY-TSOSCAT continue to run exclusively under TSOS in the future also, since it must be possible to access all TSOSCAT entries. For reasons of compatibility the existing method is also still possible: If the SYSMAREN operator role does not exist and the program runs under TSOS, the previous procedure is followed.

Volume groups Since the release of MAREN V9.0B, tapes created as logically related by HSMS / ARCHIVE have been marked as related in MAREN. They can be handled collectively in MARENADM / MAREN statements. In BS2000, other tapesets are also created, however. These are produced, for example, by applications in conjunction with DMS (multifile/multivolume tapes) or also by backup runs with FDDRL. Previously, MAREN knew the tapes in these tapesets only as individual tapes. In V11.0, MAREN was extended to allow logically related tapes to be processed as a group. The volume group has been introduced for that purpose. Tapes can be assigned the name of a volume group as an additional attribute. The name of the group is freely selectable. Which tapes belong to a volume group can be defined according to arbitrary criteria. The //MODIFY-VOLUME-ATTRIBUTES statement was extended accordingly for this purpose. Scratch tapes can be assigned to a volume group even as they are being written to. This is done using the extended /ADD-MAREN-FILE-ENTRY command. The tapes in a volume group can be processed via MAREN using the existing selection mechanisms. The MARENADM and MAREN statements were extended accordingly. MAREN V11.0 was released for BS2000/OSD V5.0 or higher.


ROBAR V6.0 Faster and safer order-processing in ROBAR-SV The communication between ROBAR-CL and ROBAR-SV has been optimized with the aim of reducing the net-bandwidth required. Messages which have to be transmitted to ROBAR-SV are now filtered by HSMS-CL before transmission so that both net-load and usage-levels of the ROBAR-SV-order-file are reduced, which is especially useful in peak-load- and failure-situations. So ROBAR-SV’s order-processing gets faster and more stable.

Multi-location control of ROBAR-operations improves ease-of-use Four new menu-windows ease both operation and control of ROBAR-SV. Apart from the administrator-window, which enables administration-procedures like START/STOP and the manual input of library-commands, there are now five so-called operator-menu-windows which can be used to control ROBAR-operation. So the customer is able to run ROBAR without being fixed to one location.

Improved User Interface with respect to failure messages and alerts The presentation of messages has been improved within all parts of ROBAR. Semantic checks are done with the ROBAR-configuration-file to ensure cross-section plausibility. Additionally there is a new message appearing in the menu-windows in case of link-perturbations or link-losses between ROBAR-SV and the associated ROBAR-Clients.

Support of the ADIC-library i500 – an attractive midrange offer The control of the Scalar i500 is integral part of ROBAR-V6.0. The library is attached to both ROBAR-SV and a BS2000-system via a Storage Area Network (SAN). The independent operation of single partitions is supported as well: In this case several independent instances of ROBAR-SV control the partitions (locations) of the Scalar i500.

Linux- and Primergy-platform for ROBAR-SV – new freedom of choice As of ROBAR V6.0B at the End of 2007 you can run ROBAR-SV on Fujitsu’s Intel/AMD-based Primergy Servers. The operating system is Linux (SuSE SLES 9). This means that ROBAR-SV exploits a new, modern, powerful and future-proof platform. ROBAR-SV on Linux/Primergy supports the same archival systems as ROBAR-SV on PRIMEPOWER/SOLARIS. ROBAR V6.0 was released for BS2000/OSD-BC V5.0 or higher.

SHC-OSD V6.0 A priority topic of SHC-OSD V6.0 was the integration of Snap and Clone. For details, see the chapter titled “Improved storage integration / storage virtualization / Storage on Demand”, section “Support for the new Symmetrix DMX functions Snap and Clone”. Program interfaces enabling integration into backup procedures using HSMS/CCOPY for OSD V7.0 and for using Snap from within DMS functions are offered here in addition to command interfaces. SHC-OSD V6.0 also makes provision for supporting SRDF/A extensions provided with Enginuity 5671 and SYMAPI V6.0. SRDF/A is an asynchronous mirroring function of the Symmetrix DMX family disk subsystems, that offers cross-disk data consistency as the main difference compared to the hitherto asynchroneous mirroring mode. In detail:

Consistent transition from SRDF/A to synchronous SRDF As of Enginuity 5671, a consistent change from asynchroneous to synchroneous for the target site’s data is possible.

Consistent TimeFinder split (for BCV, Clone, Snap) on the SRDF target. (SRDF/A Consistency Protection) The Consistency Protection can be enabled or disabled for devices not working in SRDF/A mode. It determines the behavior of the Symmetrix in the case that data in SRDF/A mode can no more be copied from the source to the target. If the Consistency Protection is enabled in this case, all devices are set to „not ready on the link“, to keep the target data consistent.

SHC-OSD V6.0 was released for BS2000/OSD-BC V5.0 or higher.

SHC-OSD V6.1 SHC-OSD V6.1 (released in September 2007) contains the following features: Hardware adaptations

SYMAPI V6.4 running in PTHREAD mode RAID6 support (in Enginuity version 5772) Support of Enginuity version 5772

Functional enhancements Support of EMC product SYMACL (Symmetrix Access Control) Support of TimeFinder/Snap extensions for 127 Snaps (as of Enginuity 5772 update planned in Q3/07) Extension of TimeFinder/Clone features Performance improvements by flexible settings for event monitoring


SHC-OSD V6.1 was released for BS2000/OSD-BC V5.0 or higher.

VM2000 V9.0 VM2000 V9.0 is the VM2000 version for BS2000/OSD V7.0 including support for BS2000/OSD V7.0 as monitor system. VM2000 V9.0 supports

On S servers: OSD V6 and OSD V7 as monitor system, OSD V5 – OSD V7 as guest systems, On SX servers: OSD V6- or OSD V7-based OSD/XC packages as monitor system, OSD V5- to OSD V7-based OSD/XC packages as guest system.

X2000 as of V3.0 is a requirement for VM2000 V9.0 on SX servers. Note: VM2000 V8.0 can already support BS2000/OSD V7.0 as monitor system and as guest system. The main new functions in VM2000 V9.0 are:

VM assignment of pubsets Assigning the devices of a pubset to a VM is greatly simplified. Pubset reconfigurations (e.g. expansion) are automatically taken into account. Command procedures for setting up VMs are shorter and more clearly structured, and no longer need to be adapted, in particular when the new SPACEPRO provisioning tool in OSD V7 is used. Explicit assignment or specification of the option of implicit assignment of a pubset is accomplished by specification of the pubres device or the catid. In a pubset reconfiguration, the VM assignment and the attributes of the implicit assignability for the affected devices are updated automatically.

Finer privilege levels for implicit device assignment The implicit assignment of devices to a VM (during ATTACH for the device in the guest system) requires the VM to be issued with the appropriate privilege and the device to be released for the function. VM2000 V9.0 enables

devices to be subdivided into so-called ASSIGNMENT sets for implicit assignment corresponding VM privileges to be conferred.

This function opens up a variety of usage scenarios: An exclusive set of devices/pubsets for implicit assignment can now be specified for a VM or a VM group. VM assignment for pubsets which are used by the SPACEPRO tool is implicit. A pool pubset of this kind can therefore only be released for a selected set of VMs.

Support for Snapsets For the first time BS2000/OSD-BC V7.0 supports snap techniques for disks in the context of so-called snapsets and snap sessions. VM2000 V9.0 displays snap units in its SHOW commands and provides an automatic assignment option for these: Given the appropriate privilege, a VM can assign itself snap units for the snapsets without any preparation being necessary for these devices in VM2000.

Enhanced support for large configurations Larger main memory for VMs With VM2000 V9.0, a main memory larger than 32 GB can be assigned to a VM. This also applies to VM1, which was previously limited to 2 GB. In future the main memory of VM1 can be expanded and reduced dynamically. HIPLEX-MSCF-coordinated Move of a VM A VM is stopped while it is being moved in main memory. The operation implies a critically long downtime for VMs several gigabytes in size that are partners in a HIPLEX-MSCF cluster. VM2000 V9.0 notifies the HIPLEX-MSCF partners of this in advance in order to forestall an automatic reconfiguration due to partner failure. Enhanced support for very small VMs VM2000 V9.0 supports the operation of VMs with a performance allocation (CPU-QUOTA and MAX-CPU-UTILIZATION) in the per mil range of server performance. This allows VMs with single-digit RPF performance to be implemented even on very large S servers. VM scheduling for small VMs is also improved: shorter timeslices guarantee a sufficiently frequent, albeit more strictly limited, CPU allocation for these. Option to combine VM groups and CPU pools VM groups enable service level management for customers with multiple VMs. Subdividing a server into CPU-POOLs improves VM2000 performance for servers with a higher MP level. VM2000 V9.0 permits VM groups not only to be set up in precisely one designated CPU pool, but also to be combined without restriction.

Shutdown for individual VMs and coordinated shutdown for the entire VM2000 The VM2000 administrator has the option to initiate a shutdown for individual VMs. Besides the SHUTDOWN command execution, a “Shutdown” RUN file can be activated. A coordinated VM2000 shutdown between guest systems and monitor


system is also supported as a further function. As a first step, a shutdown is initiated automatically in all OSD V7 guest systems. Following termination of all the guest systems, a shutdown is initiated in VM1. This then also terminates VM2000.

Enhanced performance monitoring with SHOW-VM-STATUS The VM2000 SHOW-VM-STATUS command provides CPU utilization data and internal performance characteristics in a periodic output. In future the command will also offer a one-time, synchronous output of the measured data of the immediately preceding past. Unlike the periodic output, this function is not limited to one workstation.

SW product overview The following table lists all SW products for which a new version will be released to support BS2000/OSD V7.0, along with a summary of the new functions in each case.

Product Version New function with OSD V7.0

ARCHIVE V8.0B Parallel disk access via asychronous I/Os and PAV (performance)

COSMOS V16.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

CRTE V2.7 COBOL2000 V1.4 runtime system support

DAB V9.1 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

FDDRL V16.0 Backup of multiple disks to one tapeset Multiplexing: simultaneous backup of 2 disks to 1 tapeset RELOAD PUBSET: Automated pubset recovery

FDDRL-OS V16.0 Technically linked to FDDRL V16.0

HIPLEX-MSCF V5.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

HSMS V8.0B Integration of snapsets into the backup procedures (prepared in V8.0A) Backup from TimeFinder clones Parallel disk access via asychronous I/Os and PAV (performance)

LMS V3.3B Library element restore from snapsets

MAREN V11.0 Parameter changes effective immediately Changing exits during online operation MAREN executable without TSOS Volume groups

openNet Server V3.2 VLAN support in BCAM Unicode support (XHCS V2.0, VTSU-B V13.2)

openSM2 V7.0 Support for SPACEPRO (online provisioning), alignment with BS2000/OSD-BC V7.0 (technically linked product)

PCS V2.8 Support for IO priorities in combination with IORM

PERCON V2.9 Support for Unicode: normalization and code conversion of files

RFA V16.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)


Product Version New function with OSD V7.0

RSO V3.5 Secure printing with IPP V1.1 Customized header and trailer pages Support for Unicode printers (dependent on HW)

SCA V16.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

SHC-OSD V6.0 Support for TimeFinder/Snap and TimeFinder/Clone Rounding-off of SRDF-A

SORT V7.9 Unicode support.

SPACEOPT V4.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

TASKDATE V16.0 Alignment with BS2000/OSD-BC V7.0 (technically linked product)

VM2000 V9.0 OSD V7 enhancements for IORM, snapset support Device assignment for pubsets Full support for large configurations

Published by department: Partner login partners.ts.fujitsu.com

All rights reserved, including intellectual property rights. Technical data subject to modifications and delivery subject to availability. Any liability that the data and illustrations are complete, actual or correct is excluded.

Margret Germann Phone: ++49 (0)89 3222 2623 Fax: ++49 (0)89 3222 329 2623 [email protected]

Designations may be trademarks and/or copyrights of the respective manufacturer, the use of which by third parties for their own purposes may infringe the rights of such owner. For further information see ts.fujitsu.com/terms_of_use.html

ts.fujitsu.com

Copyright © Fujitsu Technology Solutions GmbH 2009

Date post:	13-Feb-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

BS2000/OSD V7.0 Issue Pagessp.ts.fujitsu.com/dmsp/Publications/public/wp_bs2000-osd... ·...

Documents