BS2000/OSD Scope Chapter 6 System Software Issue February 2013 Use External Pages 17 Introduction Future development of BS2000/OSD will focus on expanding its typical mainframe strengths while also leveraging current and future technological capabilities. This will ensure that BS2000/OSD will remain the system of choice for high-performance OLTP and data center operation in the future too, as well as for use as a server in all types of networks. Maximum availability is achieved with the HIPLEX concept. Virtualization decouples applications and associated data from dedicated hardware resources. The VM2000 virtual machine system permits flexible, load-oriented partitioning of a server’s resources into multiple concurrently running systems, all independent of one another and able to run under different versions of the operating system. Contents Introduction 1 6.1 Overview 2 6.2 BS2000/OSD operating system 2 6.2.1 Hardware support 2 6.2.2 Scalability 4 6.2.3 Availability 5 6.2.4 Security 6 6.2.5 Storage Integration 8 6.2.6 Manageability and Ease of Use 9 6.2.7 Openness and Capacity to Integrate 10 6.3 HIPLEX: Highly Integrated System Complex 12 6.3.1 High availability with HIPLEX 12 6.3.2 HIPLEX MSCF and HIPLEX AF 13 6.4 VM2000 Virtual Machine System 14 6.4.1 Usage scenarios 14 6.4.2 VM2000 version overview 15 6.4.3 VM2000 concept for SQ servers 16 6.4.4 Functional enhancements in the new VM2000 version 17
Transcript
BS2000/OSD Scope Chapter 6 System Software
Issue February 2013
Use External
Pages 17
Introduction Future development of BS2000/OSD will focus on expanding its typical mainframe strengths while also leveraging current and future technological capabilities. This will ensure that BS2000/OSD will remain the system of choice for high-performance OLTP and data center operation in the future too, as well as for use as a server in all types of networks.
Maximum availability is achieved with the HIPLEX concept.
Virtualization decouples applications and associated data from dedicated hardware resources. The VM2000 virtual machine system permits flexible, load-oriented partitioning of a server’s resources into multiple concurrently running systems, all independent of one another and able to run under different versions of the operating system.
Contents
Introduction 1
6.1 Overview 2 6.2 BS2000/OSD operating system 2
6.2.1 Hardware support 2 6.2.2 Scalability 4 6.2.3 Availability 5 6.2.4 Security 6 6.2.5 Storage Integration 8 6.2.6 Manageability and Ease of Use 9 6.2.7 Openness and Capacity to Integrate 10
6.3 HIPLEX: Highly Integrated System Complex 12 6.3.1 High availability with HIPLEX 12 6.3.2 HIPLEX MSCF and HIPLEX AF 13
6.4 VM2000 Virtual Machine System 14 6.4.1 Usage scenarios 14 6.4.2 VM2000 version overview 15 6.4.3 VM2000 concept for SQ servers 16 6.4.4 Functional enhancements in the new VM2000 version 17
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 2 / 17
6.1 Overview
Today’s IT systems are required to deliver a maximum of security, reliability, scalability and performance. At the same time they are expected to be open in order to provide high levels of flexibility and allow the easy integration of all business processes. The tried-and-trusted mainframe features – unrivaled fault tolerance, outstanding security concepts, exceptional scalability and excellent manageability – are more important than ever. They are the basis for the low TCO (Total Cost of Ownership) for which the BS2000/OSD system is renowned. With its comprehensive set of services and functions, BS2000/OSD provides the best possible support for existing and new IT infrastructures. BS2000/OSD has been the subject of continuous innovation for more than two decades and has been constantly updated to take account of constantly changing market requirements. For example, BS2000/OSD is a mainframe operating system that runs on servers based on standard processors. And with its open interfaces it offers future-proof integration into modern application architectures. A strategic development priority is to combine proven BS2000/OSD and open standards-based technology while preserving compatibility. This includes common, open standard interfaces and sharable, open middleware (openUTM, WebTransactions, Oracle). The extensive scalability of the BS2000/OSD platform, reaching into the very highest performance bands, ensures that BS2000/OSD customers can respond flexibly to increasing demands on overall system performance. The architecture is optimized to deliver maximum performance, so several tens of thousands of clients can be served simultaneously, efficiently and at high levels of availability. Maximum availability is achieved with the HIPLEX concept, in which multiple BS2000/OSD servers implement a failover cluster so that if a server crashes or is temporarily unavailable due to a scheduled downtime, applications are exported to another server either automatically or on command. The VM2000 virtual machine system opens up a further dimension in scalability and availability for BS2000/OSD customers. VM2000 permits flexible, load-oriented partitioning of a server into multiple concurrently running systems, all independent of one another and able to run under different versions of the operating system. These systems can be assigned to IT subprocesses (production, development, testing, etc.) as well as to separate business subprocesses. They can even be used for outsourcing with customer/system assignment. Needless to say, the high availability concept with failover also covers the individual VM2000 guest systems. The full compatibility of programs in object code provides long-term protection for software investments. This compatibility is guaranteed by BS2000/OSD and, of course, also extends to the different server lines supported by BS2000/OSD. Investment protection, excellent scalability and high availability mean the proverbial “growth without change” for BS2000/OSD users.
6.2 BS2000/OSD operating system
6.2.1 Hardware support
BS2000/OSD provides binary-compatible support based on the /390 standard for the latest BS2000/OSD business servers and peripheral components. The main memory capacity of the BS2000/OSD business servers is scalable into the terabyte range. The multiprocessor capability of BS2000/OSD can also efficiently support two-digit processor numbers. This performance capability is constantly being expanded. Server support: New S175 and S210 S servers BS2000/OSD-BC V9.0 will support the newest S175 and S210 S series servers. Thus, in the top-end performance range,
BS2000/OSD-BC V9.0 will support BS2000/OSD servers based on /390 architecture rated at up to 5000 RPF capacity (see chapter 7). The S175 and S210 servers are also released for operation with BS2000/OSD-BC V7.0 and V8.0.
Fibre Channel connectivity on S Series BS2000/OSD Business Servers
On the S servers, Fibre Channel connectivity was introduced at the end of 2002, starting with the S120/S140/S170 models running BS2000/OSD-BC V5.0B. It has since become available for all current S server models and will also be standard on the actual S175 and S210 servers. All available online and near line peripheral devices for BS2000/OSD S series servers provide Fibre Channel connectivity. BS2000/OSD S server networking connectivity via Fibre Channel is realized with HNC IV or HNC V.. High transfer rates and extremely short response times are a hallmark of Fibre Channel connection technology. It enables servers to integrate into an enterprise storage area network (SAN) and therefore also supports server integration into storage consolidation environments on the basis of the most advanced connection standards. Performance scores of up to 95 MB/s were recorded on S systems with Fiber Channel interface. The marked improvement in performance also considerably simplifies the I/O configuration, since one FC channel replaces four ESCON channels on average. A particular advantage of the SAN integration is that the storage systems can also be shared by multiple heterogeneous servers via a homogeneous Fibre Channel network. Only a single, shared SAN infrastructure is required. Customers still using the CKD disk format need to migrate their data resources to the FBA format, if they want to enjoy the advantages of Fibre Channel. In order to avoid the necessary interruption in operation for this, DRV as of V3.1 provides a
functional enhancement that automatically performs the conversion online and in the background.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 3 / 17
Server support: SQ and SX series business servers
The current generation of SQ series BS2000/OSD servers covers the BS2000/OSD entry and midrange performance class. The SQ servers are based on high-end Intel servers and their software structure is based on the successful SX servers with SPARC64 processors. In order for BS2000/OSD and its applications to run Intel and SPARC64 processors, the X2000 hardware abstraction layer acts a carrier system. Three code variants, one for business servers featuring /390 processors, one for those based on SPARC64 standard processors and one for business servers featuring Intel processors, are generated from a common BS2000/OSD-BC source. Full protection for customer investments is assured through object compatibility for all existing applications and middleware products in /390 object code. BS2000/OSD-BC is released for the business servers of the SQ and SX series as part of the OSD Extended Configuration package OSD/XC. Based on BS2000/OSD-BC V8.0 the package version OSD/XC V4.1 is being supplied. As of OSD-BC V9.0 the package OSD/XC V9.0 is released. This package is only available for SQ servers. SX servers use furthermore the package OSD/XC V4.1.
The OSD/XC package includes the following software products:
Functional area Product name Version in OSD/XC V4.1
Version in OSD/XC V9.0
Operating system BS2000/OSD-BC V8.0 V9.0
Open networking openNet Server V3.4 V3.5
TIAM V13.2 V13.2
Data/program management CRTE V2.8 V2.9
EDT V17.0 V17.0
LMS V3.4 V3.4
PERCON V2.9 V2.9
SCA V17.0 V18.0
SORT V7.9 V7.9
Data backup and restore ARCHIVE V9.0 V9.0
HSMS V9.0 V9.0B
Printing / batch job processing JV V15.0 V15.1
RSO V3.6 V3.6
OSD/XC V9.0 also supports the newest SQ server generation. By means of the corresponding carrier system version X2000 it delivers a major boost in multiprocessor performance and consequently offers significantly expanded system scalability (see chapter 7).
Figure 1: Overview of storage architecture with Fibre Channel (FC)
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 4 / 17
Outlook
BS2000/OSD-BC V9.0 contains among other things memory management optimization and is as a result also prepared for the support of coming server generations. The support of new peripherals is expanded through BS2000/OSD-BC V9.0 and also continued after the release through modifications and regression tests.
6.2.2 Scalability The scalability of the BS2000/OSD system platform up to the highest performance levels ensures that operators can react in a flexible way to the increasing requirements made of server performance. Server performance, network bandwidth and data storage can be configured in such a way that more than 10.000 end users can be efficiently managed almost simultaneously. The range of server performance comprises a factor of more than 400, measured in RPF (relative performance factor) - from the SQ210 with 12 RPFs to the S210 with 5.000 RPFs. Increasingly large peripheral configurations save the constantly growing quantities of data. In further development the design of the operating system is such that increasing performance requirements can be met without any problems. In the new version BS2000/OSD-BC V9.0, following measures to increase the performance of BS2000 operation were realized:
High-performance support of SQ servers up to MP grade 16 As with S servers, it was the objective of all the performance measures for SQ servers released for BS2000/OSD-BC V9.0 to achieve an equally good MP factor for the MP grades 8 to 16. The main approach to increasing MP performance for SQ was to implement x86-Page Table optimization. Furthermore, reference recording on SQ servers was only performed "on demand" in OSD V9.0. Due to the measures an improvement in performance of between 5 and 10% was achieved for mono and between 10 and 20% for multi processors.
Increase in the number of parallel RSC I/Os per device from 4 to 6
The RSC interface (RSC=Remote System Call) between BS2000 and X2000 is used for disk I/Os on SQ servers. As standard 4 I/Os are simultaneously output on one device at present. This value is increased in BS2000/OSD-BC V9.0 to 6 in order to increase I/O parallelization.
Formal support of up to 32 processors (as a preparatory action for later high-performance SQ servers) Up to OSD V8.0 the BS2000 can support a maximum of 16 CPUs. As of OSD V9.0 the formal support of up to 32 processors is possible on SQ machines. No specific SQ model is planned with >16 CPUs with OSD V9; the extension is intended as a preparatory action for later high-performance SQ servers.
Extended PAV PAV (Parallel Access Volume) can be used for several I/Os to take place simultaneously on one logical volume. PAV can be used to reduce the response times for disks with great loads and to increase the maximum I/O rates to one volume. Extended PAV is offered for devices on the FC channel. With Extended PAV, the previous restriction that an alias device has to be defined in the same logical controller as the basic device is lifted. A further logical controller (even several if required) with 256 alias devices can be configured to an existing logical controller. Extended PAV creates higher flexibility in case of (unforeseen) bottlenecks and is particularly suited for configurations, in which PAV was not planned from the outset, in which no or only a few free addresses for alias devices are available.
Parallelization of the paging I/Os with PAV When high data quantities are created in the main memory in a short period of time, the paging mechanism must displace the contents of the main memory with the same speed or an even higher speed as the new data is created. To also ensure this with constantly increasing server performance, parallelization of paging I/Os is effected in BS2000/OSD-BC V9.0. It is possible to perform up to 4 I/Os per device in parallel with the new implementation.
Improved PTHREADS performance The performance for fork() in PTHREADS applications is improved by means of "copy-on-write semantics" for the CL6 memory pool of the PTHREADS. Customers with SHC-OSD configurations, ORACLE EMAGENT and SM2 users benefit from the planned improvements.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 5 / 17
6.2.3 Availability
The IT processes supporting e-business require all IT resources involved to be permanently available. Management of mission-critical processes is now totally IT-based in many sectors. At the same time the importance of high availability is increasing constantly. That is why availability has always been a development priority for BS2000/OSD, and will remain so. Today, a high level of availability has already been achieved for the operating system and the system support components: Functions for avoiding / reducing planned shutdowns (self-configuring properties of BS2000/OSD):
Online maintenance / replacement of hardware components: service/console processor, peripherals, ESCON channels, firmware and fans can be replaced during online operation.
Dynamic changes to the hardware configuration: The BS2000/OSD business servers with /390 architecture allow the I/O configuration to be modified on the hardware side during online operation, i.e. without a new IPL. BS2000/OSD also supports this function on the software side, by allowing new entries for released I/O components (channels, System Connection Directors (SCDs), device controllers and devices) to be added dynamically, as well as entries to be modified or deleted.
Dynamic changes to operating system settings: I/O paths, date/time, user entries, job management entries, network (BCAM) entries, FT partner definitions, pubset assignments, catalog size, paging files and POSIX systems parameters can be modified during online operation.
Dynamic changes to the software configuration: IMON/DSSM enables new product/subsystem versions to be installed during online operation.
Data backup via Concurrent Copy: Performing backups with the HSMS Concurrent Copy function enables the interruption to the application to be limited to the generation of the consistency point. HSMS backup with Concurrent Copy supports ETERNUS DX EquivalentCopy, Symmetrix TimeFinder and CLARiiON CX SnapView: Data are read from the split-off volumes during the backup run.
Reorganisation of open files and online extension of volumes in conjunction with SPACEOPT as of V3.0. Functions for avoiding / reducing unplanned system interrupt (self-healing properties of BS2000/OSD):
Failure of hardware components: Problems with hardware components are detected automatically and defective processors, memory areas, channels and IOPs are generally (when redundantly configured) taken offline without disrupting operation. Faulty peripherals can be replaced during online operation, and defective I/O paths can be redefined. Should a printer crash, spool jobs can be redirected to standby printers via DPRINT.
Protection against errors in the application program: Application programs are insulated from one another and from the middleware (UDS/SQL, SESAM/SQL Server, Oracle): If errors occur in the application program, only the affected transaction is aborted, not the entire application.
Shorter system restart: Processing of batch, openFT and spool job queues resumes automatically on restart. Larger spool jobs can be resumed at checkpoints. Automated restart: openUTM, databases, DSSM etc. continually store status information in job variables, allowing evaluation
via automated procedures. All current S server models including the new S175 and S210 servers feature a standby general processor, called a “hot-
spare CPU”. If a general processor fails, the hot-spare CPU is activated during online operation and operation continues with the original, model-specific performance. This also applies to monoprocessor systems if the only CPU of the system fails.
For HIPLEX configurations with Global Storage, BS2000/OSD-BC offers reconfiguration functions to ensure interrupt-free resumption of service by the GS units even after power failures or other disaster scenarios.
Journaling file system in POSIX as of A37. Faster failure detection in clusters with HIPLEX MSCF V4.0 and HIPLEX AF V3.2. The further increase in system availability is of paramount importance for the further development of BS2000/OSD. In BS2000/OSD V9.0 further measures to increase the BS2000 system availability are provided. Online SNAP file setup
To date the snapshot process could only be activated and deactivated during system startup via the parameter file. If an error occurs in the ongoing session, the snapshot process may have been stopped. A restart was only possible with a complete system restart. It has until now not been possible to change the size of the $TSOS.SNAPFILE, either (data container for the snapshot process). In BS2000/OSD-BC V9.0 the snapshot process can be stopped, restarted and re-initialized at will in the ongoing session. At the same time, changed general conditions also become effective, e.g. a change in size of the $TSOS.SNAPFILE. New commands ACTIVATE-SNAPSHOT and DEACTIVATE-SNAPSHOT are provided for the purpose of switching on/off the SNAP dump function.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 6 / 17
Online update of the change dates for summer and winter time
The change dates between summer and winter times were up to now defined for a maximum of three years in advance in the SYSPAR file that is only read and evaluated by the startup, because the responsible governmental authority also only defines the change dates for such a period of time in advance. To modify the change dates it was necessary to restart the system - and thus interrupt operations - after at least three years. From now on new/modified change dates can be made known to the operating system by command. It is no longer necessary to restart the system for this purpose. The function is provided as a new subsystem "CHDATES" with the commands ADD-, /MODIFY-, /REMOVE-, /SHOW-CHANGE-DATES, thus making interruptions to operations / STARTUP no longer necessary (7 * 24-hr operation). In the event of any legislative changes regarding summer and winter time it is possible to react quickly. Online backup of the home pubset with FDDRL V18.0
Compared with the logical backup with ARCHIVE/HSMS, the physical backup of home pubset with FDDRL has the advantage that the IPL capability, the pubset attributes, the entire software configuration and the user attributes are backed up and recovered during restore. A pubset restored with FDDRL can be put back into operation immediately. In contrast, a HOME pubset backed up with HSMS/ARCHIVE must first be set up again and configured. As far as a fast and reliable restore of the home pubset is concerned, backup using FDDRL is essential and therefore strongly recommended. Since the software configuration is fairly consistent and is not changed every day, it is sufficient to perform an FDDRL backup at greater intervals, e.g. monthly. However, to backup the home pubset with FDDRL it has until now been necessary to end the system run. Then the home pubset could be backed up offline using another system. The home pubset backup can now take place in FDDRL V18.0 during ongoing operations.
6.2.4 Security Reliable data protection is a key requirement for the use of systems in commercial data processing. Mission-critical data must be effectively protected against intentional and above all against negligent modification or destruction. Suitable data protection is available both within the BS2000/OSD system platform and also in the associated middleware. BS2000/OSD already features powerful self-protecting functions.
BS2000/OSD in combination with the product SECOS (Security Control System) conforms to the Class F2/Q3 certification criteria of the BSI (German Federal Bureau for Security in Information Systems).
Figure 2 Basic security within the operating system; extended security with SECOS
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 7 / 17
SECOS offers the following functions:
Extended access control through improved user identification and authentication: In the BS2000/OSD environment this
ensures that only authorized users can work with the system and that access is barred to unauthorized users. In BS2000/OSD, the password mechanism is used for authentication at the point of access to the system. SECOS provides protection measures for LOGON passwords that effectively prevent systematic hacking attempts in everyday operation. With shared user IDs, the “personal LOGON” serves for identification.
Access control for objects (incl. files): SECOS provides extended protection mechanisms to control file sharability and access rights in a number of different ways. The access control list permits access rights to be defined down to the level of individual users; specifiable access types include read, write and execute. Access rights for multiple objects can be similarly specified by means of a GUARD. This has the advantage that it is easy to assign the same access rights to multiple objects. Default settings for protection attributes enable objects to be effectively protected right from the time they are created.
Support for user groups: This enables the large number of users present on the system to be more clearly structured. It is also possible to simulate organizational units or projects that are represented by certain individuals with user IDs, including with the appropriate allocation of resources in the system.
Mechanisms for extended rights administration / decentralization of system administration: These enable different administration tasks of the TSOS privileged user ID to be delegated to a number of other user IDs. The co-ownership function helps to decentralize tasks. It permits administration rights, such as creating and deleting objects belonging to an arbitrary user ID, to be assigned to a different user ID (than the system administration ID). The special TSOS co-ownership function enables the right of a user under the TSOS ID to access files or job variables of any user ID to be selectively restricted to individual files or JVs.
Audit trail/logging of security-related events: “Security Audit Trail” (SAT) as part of the SECOS product supports the selective logging of security-relevant events in specially protected files. By analyzing these files, suitably authorized users obtain a complete overview detailing which user accessed a specific object, at what time, and how. Alternatively, the SAT outputs can also be in XML format for subsequent processing.
Single Sign On with Kerberos BS2000 users are given the option through Kerberos authentication to perform user logons (LOGON) in the sense of a single sign-on without having to specify a password. A Kerberos client has been implemented in BS2000/OSD and will use the Windows Primary Domain Controller (PDC) that (usually) exists in the BS2000 environment as the server (Key Distribution Center). Benefits for the customer are: o No additional hardware/software costs as a result of using the Windows PDC as an authentication server. o Kerberos protocols offer high cryptographic security. Support for the Kerberos authentication function has been implemented on the client side in the MT9750 terminal emulation
(starting with V6.0) as well as in other emulations from software partners. The Kerberos authentication functionality is also available for TU applications. Users of this function are the OMNIS-MENU product: V3.4 or higher in combination with OMNIS V8.4 and openUTM V5.3 and higher.
Security audits including BS2000/OSD business servers
An increasing number of customers want their data center to undergo a “security audit”. For this, an organization draws up its own security guidelines and has these and compliance with them evaluated by an internal or external auditor. The incentive to carry out a security audit generally comes from outside the organization, with the terms of reference being set based on statutory provisions such as the Corporate Governance and Transparency Act (KonTraG) in Germany or the Sarbanes-Oxley Act in the USA. As with quality management, the security guidelines can be based on ISO standards, in particular on ISO/IEC 27001 titled "Information technology - Security techniques - Information security management systems - Requirements". In Germany specifically, the Federal Bureau for Security in Information Technology (BSI) has produced comprehensive implementation rules in the form of the IT Basic Protection Handbook and offers a separate certification process for this. Given their security functions, BS2000/OSD business servers can be successfully included in security audits. The BS2000/OSD-BC operating system contains extensive security mechanisms by default. SECOS enables extended, finely granular control of the security mechanisms; in the ISO27001 context, SECOS has the following key functions Audit trail, Personal login also under system administrator IDs, Protecting the integrity of system files (also implemented via SAT logging). For SX and SQ servers, an X2000 security concept is available in addition; it is deployed as a standard on SQ servers, and on SX servers a query to verify whether it is deployed was included as part of the installation checklist. To support our customers in security audits, we can provide know-how and manpower on a project basis.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 8 / 17
Functional enhancements in SECOS V5.3 (Current version)
The subsystem GUARDS implements an access protection mechanism for objects of varied type. The protection criteria are managed centrally in the system and the protection definitions, related to a specific object, are compiled in a so-called guard. Each guard container has a fixed area for access conditions. This area was increased so that further usage scenarios are possible for guards, e.g. use for log-in access via personnel ID (only 90 entries can be currently managed).
Kerberos keys which are entered in the Key Distribution Center via, for example ktpass, had to be manually entered into the BS2000. This often resulted in incorrect settings. In SECOS V5.3 the ktpass file can be evaluated directly which considerably reduces the danger of incorrect operation.
Outlook User requirements are largely implemented in the follow-up version SECOS V5.4. The following function extensions have
already been decided and are currently being implemented: Default of the ADDRESS-SPACE-LIMIT for user IDs can be set to greater than 16 MB:
As standard new user IDs are currently created with an ADDRESS-SPACE-LIMIT of 16 MB. This available address area corresponds to an ID that no longer meets requirements. Thus, the class-2 system parameter SYSGJASL is introduced in the commands ADD-USER and ADD-USER-GROUP for the value ADDRESS-SPACE-LIMIT=*STD.
Increase in the maximum number of SATUT input files: In the event of daily change to the SATLOG a monthly evaluation should then also be possible if the system was restarted a number of times so that several files exist for these days. This is achieved by significantly increasing the maximum number of SATUT input files of at present 31.
LOGON choice between NET dialog and DIALOG The choice whether LOGON is to be via the settings of the NET dialog (station type 9763) or via DIALOG (station type <> 9763) has until now only been implemented for the station type of the MT9750 emulation.
In a further follow-up version of SECOS the support of additional symmetric algorithms is planned for Kerberos authentication.
6.2.5 Storage Integration System Managed Storage is the term used to denote the extended concept for data management by the operating system instead of by the user (self-optimizing data management). It makes a major contribution to the availability and automation of system operation. Key aspects are the transparency of the storage hierarchy for the end user and the simplification of data management activities for the system administrator. Optimum storage of the data within the pubset is handled automatically by the system. System Managed Storage supports operation of an Information Lifecycle Management (ILM) system aimed at providing the right information at the right time and at the right place at minimum cost. ILM is a storage management concept that actively controls and administers information objects over their entire lifecycle. An optimization process embedded in a control system determines the most suitable place to store the information. The backup, replication, export, relocation and archiving functions required for ILM are available in BS2000/OSD. They are realized within the HSMS product (Hierarchical Storage Management System). The focus of the new storage integration functionality in BS2000/OSD-BC V9.0 is the integration of NET storage (NAS) and the support of the ETERNUS DX storage systems on the basis of SHC-OSD: BS2000/OSD integration for NET-Storage (NAS)
Different storage media - various versions of disks and tapes - have been used in the BS2000. In BS2000/OSD V9.0 storage media that offer their services via NFS can also be used by the BS2000. The new functionality gives following new possibilities:
Archiving of performance-uncritical BS2000 files on favorably priced NAS storage systems with somewhat less performance than on the SAN disks (e.g. for backup and filing of logging-files and test data).
Direct access to common used data at the original by co-operating inhomogeneous applications (imaginable: applications deposit status information in files; further processing of PDF- and HTML-files, which were stored on NET-storage by BS2000).
The applications, which use the files on this type of storage media (generally referred to as NET storage), process them just as well as on a classic local pubset. The affected commands are extended accordingly. The new functionality is fully compatible for the applications. SHOW-NET-STORAGE is used to enable the user to obtain information about existing NFS servers. Information can also be output about existing NET volumes. Data on the NET storage also belongs to the backup scope of a pubset in OSD V9.0. Thus, in backups with the previous standard settings in ARCHIVE and HSMS the data is always also backed up on the NET storage. The ARCHIVE user interface is not extended. With regard to files on local pubsets and files on remote NET storage the backup amount can be selected directly via extended HSMS interfaces.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 9 / 17
Access from the BS2000 system to the NET storage must be permitted by means of an appropriate configuration. The BS2000 system administrator receives new commands (MOUNT-NET-STORAGE/UMOUNT-NET-STORAGE, CREATE-NET-STORAGE-VOLUME/DELETE-NET-STORAGE-VOLUME) for administration of the NET storage, which is used by the BS2000 as BS2000 storage. Architecture A separate Linux system acts as a gateway for the NET-Client (gateway between BS2000 and NFS storage). HNC (HNC IV and HNC V) is used as the gateway platform for S servers and X2000 is used directly for SQ servers (the X2000 version developed for SQ200-successor). Like every BS2000 file, a file on a NET storage has a catalog entry on a pubset. The information to the file system is stored in this catalog entry. Supported NET Servers The new NAS connection of ETERNUS CS High End V5 will be the first supported NET server hardware. The release for a NAS system from NetApp is available on special release request. BS2000/OSD integration for the ETERNUS DX clone and snap functions based on SHC-OSD
The storage systems Fujitsu ETERNUS DX410/DX440, DX410 S2/DX440 S2 and DX8400/DX8700 are released for operation with Fujitsu BS2000/OSD business servers of the S and the SQ series with BS2000/OSD V7.0 and V8.0. The release of the models ETERNUS DX 8000 S2 is planned in a supplement to SHC-OSD V9.0 for the 1st quarter of 2012. The storage host component SHC-OSD and products/components based on it have until now offered a powerful and comprehensive functionality for controlling the replication functions of the EMC Storage systems Symmetrix and CLARiiON CX from the BS2000/OSD. With the release of Fujitsu BS2000/OSD SHC-OSD V9.0 in mid-September 2011 information functions and event monitoring were also offered for ETERNUS DX and the ETERNUS DX replication functions Equivalent Copy and Remote Equivalent Copy were supported on BS2000 servers. EC is the local mirroring at volume level comparable to TimeFinder/Clone with Symmetrix. REC is the remote mirroring comparable to SRDF/S with Symmetrix. The clone and snap function of ETERNUS DX differs in some points from the clone/snap implementation of the EMC-Storage systems so that SHC-OSD cannot offer the underlying components snapsets, CCOPY and PVSREN any compatible interfaces. These components are adapted accordingly in the OSD versions concerned, thus offering the BS2000 customer an alternative to the EMC Symmetrix systems. Outlook
Further measures for the improvement of storage integration are already being prepared. Thus, the support of local mirroring with snaps and of asynchronous remote mirroring for ETERNUS DX systems is planned for the follow-up version of SHC-OSD (V10.0), to be released probably in the 2nd half-year of 2012. The support of virtual provisioning is planned for a further follow-up version.
6.2.6 Manageability and Ease of Use Low-priced administration, efficient resource usage and 24h operation are only possible if all the essential operational procedures can be automated. BS2000/OSD is a highly automatable system platform. Additional automation functions are added with every version. However, improvements to the dialog interface also make the operation of the BS2000/OSD simpler and more effective. Among others the following extensions were realized in BS2000/OSD V9.0: MAIL-FILE extensions
In BS2000/OSD V8.0 mail functions are implemented which enable system components and user programs to simply generate e-mails from system processes. Thus a text file can, as an alternative to the printout, be sent as an e-mail attachment file to the e-mail address of the user ID. The BS2000 file to be sent has until now had to be an SAM or ISAM file. In BS2000/OSD V9.0 library elements of print-editable element types (without the need for previous file extraction) and PDF files can also be sent (The command CONVERT-FILE-TO-PDF can be used to convert BS2000 text files (cataloged SAM or ISAM files) into "PDF files" (especially designated SAM-U files)). Adaptation of the SHOW and MODIFY commands of the pubset administration
New (additional) SHOW commands are offered for pubset administration in such a way that a MODIFY commando can also be found for a SHOW command by means of the function prefix alone, and vice versa. Example: Currently, the MODIFY commands MODIFY-PUBSET-CACHE-ATTRIBUTES, MODIFY-PUBSET-SPACE-DEFAULTS and MODIFY-SPACE-SATURATION-LEVELS belong to the SHOW-PUBSET-PARAMETERS. In future the commands SHOW-PUBSET-CACHE-ATTRIBUTES, SHOW-PUBSET-SPACE-DEFAULTS, SHOW-SPACE-SATURATION-LEVELS will also be available. New EDIT commands
EDIT commands, for which the current operand values are displayed, are offered for a range of frequently used MODIFY commands (analog to the already existing EDIT-FILE commands). This allows the operand value to be showed and changed in a single work step. The EDIT commands are implemented via SDF-P S-procedures and supplied as compiled SDF-P S-procedures so that they cannot be modified by the customer. Advantage: They do not require the chargeable product SDF-P for implementation with the customer. In BS2000/OSD V9.0 these are amongst others commands from the area of MODIFY-JOB, MODIFY-JV, MODIFY-PUBSET and MODIFY-USER.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 10 / 17
More informative messages
In some commands additional information, such as the reference to the object (e.g. which file), is missing after a negative return code. Error diagnostics are as a result made more difficult for customers. In BS2000/OSD V9.0 appropriate measures are planned amongst others for the commands of pubset management. Selectable system reaction when CPU time limits are exceeded
Tasks and programs which exceed their predefined CPU time limit should be scheduled as close to the deadline as possible. When a CPU time limit is reached
no time surcharges are granted,
batch and dialog tasks are handled identically and
no answerable console messages are output.
This behavior is also offered via the class-2 option DIATTL. Function extensions for BS2000 commands
The RUN command for the operator is extended by the option of starting RUN procedures from library elements.
The new command SHOW-TEST-OPTIONS is used to display set and additional test options via the MODIFY-TEST-OPTIONS command.
Unconditional waiting for command WAIT-EVENT
The command WAIT-EVENT is extended to include
unconditional waiting for a certain period
unconditional waiting up to a specific time
without triggering spin off.
6.2.7 Openness and Capacity to Integrate
The openness strategy pursued by Fujitsu over many years is being systematically continued. This was documented, for example, by the Unix95 certification (SPEC1170) obtained for BS2000/OSD in 1997. Fujitsu has independently ported basic services such as Network File System (NFS) and Simple Network Management Protocol (SNMP) to the XPG4 interfaces. What’s more, the overall BS2000/OSD system has been expanded into a full internet server/OSD. All the protocols, interfaces and services necessary for internet operation are provided by operating system, communication manager and add-on products (see Chapter 3). The POSIX interfaces in BS2000/OSD serve as the technical basis for these developments. POSIX
BS2000/OSD-BC supports standardized interfaces according to POSIX/XPG4.2. The POSIX shell is available as part of the operating system. As the technical basis for the openness strategy of BS2000/OSD, POSIX is being developed further in line with user requirements. The POSIX version A41 was developed in conjunction with BS2000/OSD-BC V8.0. A priority here was the BS2000 file system bs2fs with the ability to access BS2000 files transparently from within the POSIX environment and so make use of the extensive facilities of the POSIX tool environment (grep, make) e.g. for program development for BS2000. Access of BS2000 files by remote clients is planned for the consequent POSIX version POSIX A43 for BS2000/OSD-BC V9.0; this will take place in two stages: First, the BS2000 file system is mounted at the desired point in the ufs file system by means of an (extended) mount
command. When a file is accessed (e.g. open()), the copy operation for the file is initiated. On completion of the processing, the file is copied back to BS2000. During this operation POSIX ensures the consistency of the versions.
Once the BS2000 file system has been mounted, these files can also be accessed by a remote computer (in the same way as locally in POSIX). This means that BS2000/POSIX is then the server and the remote computer is the client on which the directory into which the BS2000 files have been mounted is mounted via NFS.
Further important functions in POSIX A43:
Separate job classes for POSIX tasks, which are defined according to the default job classes for DIALOG and BATCH. The resources for "POSIX tasks" can then be controlled via special job classes. The shell command fork() allocates the POSIX default job class to the task to be created.
Backup of bs2fs files after an error with close(): A "bs2fs_lost+found" is implemented, in which files are kept after the error with close() and from which they can be backed up to BS2000.
Acceleration of the POSIX shutdown. The benefit here is the acceleration of maintenance and test work that requires a POSIX restart
Introduction of "logrotate" ("syslogd"): Rotation of POSIX log files during ongoing operation (see CONSLOG)
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 11 / 17
Apache
The latest version of Apache, the world’s most popular web server, is also available for BS2000/OSD in addition to Windows, Linux and Solaris, and is included in the operating system basic configuration BS2000/OSD-BC. The migration to the Apache http server 2.2.8 of the Apache Software Foundation took place with the release of APACHE (BS2000/OSD) V2.2, with support for PHP V5.2, PERL V5.8, TOMCAT V5.5 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. Java
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 as of V7.0 includes the version JENV (BS2000/OSD) V6.0. Version V6.0 of the Environment for Java is a rebasing on Java2 SDK Standard Edition 6.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 6.0” Java applets and Java applications can also be developed. The programs generated with JENV V6.0 can then be run on any platforms having an SDK™ V6.0-compatible runtime environment. The further development plans to port Java SE 7 JDK to BS2000/OSD. WebTransactions for OSD
The product WebTransactions for OSD implements the integration of any BS2000/OSD applications into the internet or an intranet/extranet. WebTransactions for OSD operates in combination with the Apache web server on the BS2000/OSD system platform. WebTransactions V7.5 for OSD applications, a variant which runs on BS2000/OSD under POSIX, is being shipped with an unlimited number of user licenses as part of the BS2000/OSD-BC package. The basic configuration of the operating system thus provides the basic conditions for the use of web technology for e-business activities. WebTransactions for OSD V7.5 comprises enhanced Unicode support compared with V7.1. Unicode in BS2000/OSD
Certain EU directives and their transposition into national legislation oblige our customers to adapt their IT applications to take account of guidelines for a correct writing of names, foreign addresses, and so on. When processing data, the BS2000/OSD system uses a 7-bit EBCDIC character set (named EDF03IRV) as standard, making 95 different characters available. Additionally, BS2000/OSD supports 8-bit character sets that enable the customer to work with up to 189 characters. The aim of Unicode is to define a globally unique coding for all characters occurring worldwide. The BS2000 implementation achieves this for the Western European area. With Unicode support in BS2000/OSD, the EBCDIC character sets available in BS2000/OSD systems are being 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 code points in addition to the existing EBCDIC variants. Users are provided with the programming and runtime environment that they need in order to extend their existing applications with Unicode data fields. 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), OMNIS/OMNIS-
MENU, WebTransactions A suitable software configuration is provided under BS2000/OSD-BC versions as of V6.0 in order to support the Unicode functionality in BS2000/OSD. Preview Unicode-EDT (command "edtu") in POSIX A43
The currently available shell command "edt" uses the V16.6 function of the EDT subprogram. The V17 version of the EDT subprogram offers new features
Unicode and ISO character sets, new output formats
Very important in POSIX: long lines (32768 bytes)
A new command "edtu", which uses the V17 function of the EDT subprogram, is integrated in the shell with POSIX A43.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 12 / 17
6.3 HIPLEX: Highly Integrated System Complex
6.3.1 High availability with HIPLEX
On the internet, the demand for 24-hour IT availability is growing dramatically as a result of global business transactions. The operators of IT infrastructures need to find ways to keep IT applications continuously available. Increasing the availability of IT subsystems, e.g. servers, while useful, is decidedly not sufficient to assure the permanent availability of applications. High application availability can only be achieved through the use of redundancies for the carriers of these applications. High system availability is basically achieved by two techniques: fault tolerance and failover. Fault tolerance
As much redundancy and fault detection logic as necessary is built into an existing system to ensure that faults are almost always discovered immediately and failover to redundant components can be initiated without delay. This leads to very high availability without application disruption, but has one drawback: In normal operation, the redundant components running in parallel deliver no productive output and are therefore very costly. Failover
A second, basically identical system is connected to an existing system. The two systems monitor each other, and each acts as the backup system for the other. Both systems are productive in normal operation. In the event of a fault, business-critical applications on the failing system are exported together with their resources to the live system (less important services on the standby system may have to be terminated). This operation is called “failover”. Failover is a very cost-effective solution because it is not based on unused redundancies. Another advantage is that it offers increased scalability into the bargain. This explains why almost all manufacturers today have adopted the failover concept on their mainframe, Unix and NT-based platforms. In the mainframe environment, failover capability is provided by clusters. Clusters enable server applications to achieve high availability with relatively little overhead and at reasonable cost. HIPLEX (Highly Integrated System Complex)
HIPLEX is the Fujitsu clustering concept, designed to support an availability cluster comprising multiple BS2000/OSD business servers. A HIPLEX consists of a number of BS2000/OSD systems networked together via a connection system. This HIPLEX structure offers better self-healing characteristics by providing higher scalability and redundancy than a conventional monoprocessor or multiprocessor system (with common linking of the processors via the main memory). In the context of the HIPLEX concept, scalability and redundancy are used to increase performance and availability and are made available to the BS2000/OSD users. At the same time cluster automation and administration functions are implemented. The very high and constantly improving availability of BS2000/OSD cluster systems is due to the steadily improving hardware availability and configurability of
BS2000/OSD servers, the new availability features in the BS2000/OSD operating system
and the possibility of exporting applications and their resources in the
HIPLEX. Downtimes due to repair and restart of the failing server can be eliminated for HIPLEX applications by fully automatic export of applications in the event of a fault. The result is a level of application availability which is considerably higher than that achievable with just one server. The central products in the HIPLEX are HIPLEX MSCF (Multi System Control Facility) HIPLEX AF (Availability Facility)
Figure 3 HIPLEX concept
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 13 / 17
6.3.2 HIPLEX MSCF and HIPLEX AF HIPLEX MSCF
HIPLEX MSCF establishes basic structures for the job, load balancing and availability cluster and also for distributed applications for a maximum of 164 BS2000/OSD business servers. HIPLEX MSCF expands the server- or system-local basic functions catalog access, file access, starting of ENTER jobs on the HIPLEX MSCF cluster. HIPLEX AF
HIPLEX AF monitors applications in the multi-server cluster and, in the event of a server crash, automatically switches the applications together with their resources to an intact server. In addition, applications with HIPLEX AF can be selectively moved onto another server. In a disaster situation, i.e. local failure of server and storage systems, HIPLEX AF supports a fully automatic failover to a remote data center. HIPLEX MSCF and HIPLEX AF play the following roles in the different types of cluster:
Load balancing cluster: The load balancing cluster uses the extensive scalability potential of the system by allowing easy integration of further BS2000 servers into the cluster and by distributing applications over multiple BS2000 servers. HIPLEX MSCF and HIPLEX AF implement static task distribution and the planned application export in the load balancing cluster. Availability cluster: The availability cluster ensures very high application availability by exporting applications to other business servers within the cluster. HIPLEX MSCF and HIPLEX AF in the availability cluster are capable of detecting failures and switching over affected applications selectively to a standby system. Failure detection in the cluster with HIPLEX-MSCF as of V4.0 and HIPLEX AF as of V3.2
It is important to detect the failure of a partner computer as quickly as possible in order to shorten the restart time of afflicted applications. In addition to the use of the MSCF-specific mechanisms for failure detection, the corresponding HIPLEX-AF mechanisms can be used via interfaces. In version V3.2, HIPLEX-AF implemented a live monitor, which recognizes a system failure and reports it to HIPLEX-MSCF. HIPLEX MSCF can also instruct the live monitor to check the status of a system and to terminate it if no clear active status is detected. The total time for failure detection is the MSCF failure detection time plus the wait time until fail-reconfiguration (during which an SETS of the computer detected as failed may be performed as a precaution). Reliability of failure detection: Incorrect failure detection can be avoided using the MSCF query CHECK-SYSTEM or STOP-SYSTEM-CONDITIONAL; after this, the fail reconfiguration can be performed without a precautionary SETS and without wait time. Support for Autoswap starting with HIPLEX AF V3.2
Autoswap is a HIPLEX AF function which permits automatic switchover to the mirror Symmetrix in the event of a planned outage of an SRDF-mirrored Symmetrix. This enables activities such as maintenance work on a Symmetrix to be performed offline without application disruption. In the case of an unplanned outage of a Symmetrix system, Autoswap also supports automatic failover of the failed work Symmetrix system to an SRDF-mirrored standby Symmetrix system in addition to the automatic failover of the work system to a standby system by HIPLEX AF. This enables the failover process to be initiated more quickly and reduces the system downtime. After a brief delay the applications resume running on the same server using the consistent data of the mirrored Symmetrix system, without the need for an interruption to operation or a restart.
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 14 / 17
6.4 VM2000 Virtual Machine System
A virtual infrastructure leads to reduced IT costs as a result of increased efficiency, flexibility and response capability. It enables IT resources to be assigned quickly in response to changing business requirements, new services to be provided, and utilization of the servers to be significantly increased.
VM2000 supports the simultaneous operation of different, totally segregated system environments on one server. Depending on
the server type, up to fifteen BS2000/OSD systems (guest systems) can run on one server under VM2000. An advantage of using VM2000 as compared with the use of multiple servers is the possibility of consolidation with the aim of providing more efficient use of hardware resources, human resources and infrastructure.
6.4.1 Usage scenarios Parallel operation of production, development and testing
VM2000 allows a development system running untried, unstable applications to operate alongside the production system. When multiple systems are operated on a single installation, system errors in one system have no impact on the other simultaneously active systems. Differentiated systems, e.g. for service providers
If a service data center requires different system environments for its customers, VM2000 allows the option of installing a single, high-performance server. This enables savings to be achieved in terms of floor space and in the administrative area. With VM2000, the same benefits can also be enjoyed by customers who require different production environments for their own purposes, e.g. when applications have not yet been updated in line with current versions of BS2000/OSD or the system support software. The VM2000 “CPU utilization” function enables a service data center to allocate precisely the agreed (maximum) CPU performance to its customer systems.
Figure 4 Operation of several guest systems with VM2000
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 15 / 17
Balancing of load peaks, use for backup concepts
VM2000 usage scenarios can be optimized even further with the VM2000 function “dynamic enlargement and reduction of the main memory domain”. Without active VMs having to be terminated, this feature allows VM load peaks to be balanced even more efficiently, temporary VMs to be set up, and backup VMs to be held in reserve with minimal consumption of resources. Version migrations
With VM2000, the individual production applications can be migrated to the new system environment in stages (to the extent that this is possible with mutually independent data resources). In this process, the execution of the individual application complexes is tested in a second guest system until freedom from errors is established. They are then deployed in the production system. Migration with VM2000 thus proceeds without time pressure. Arrangements that were previously necessary, such as lights-out testing and weekend working, can be forgotten with VM2000. During the test activities, operating personnel can get to know the new version at their leisure. Using VM2000 therefore also helps minimize subsequent operator errors in the production system.
(1): guest systems as of OSD V5.0 (also with VM2000 V8.0)
(2): guest systems as of OSD V7.0
(3): monitor system OSD/XC as of V2.x only
(4): monitor and guest systems OSD/XC as of V3.0 only
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 16 / 17
6.4.3 VM2000 concept for SQ servers
VM2000 provides in same manner as on S servers that several parallel BS2000/OSD systems can run on one SQ server. VM concept for SQ servers
VM2000 enables multiple BS2000/OSD systems to run in parallel also on an SQ server. VM2000 was made available with a XEN-based architecture on SQ servers, while retaining the VM2000 user interfaces. In this case the XEN Hypervisor handles the operation and virtualization of the hardware. On the S and SX servers, VM2000 essentially consists of the components VM2000 Monitor and VM2000 Hypervisor. The VM2000 Monitor component implements the user interface of VM2000, provides the internal accounting, logging and eventing functions, manages the VM administrators, and implements the $VMCONS functionality (i.e. network access for the VM administration and the virtual console). On the SQ servers, the VM2000 Monitor continues to be available with a compatible command interface. The functions of the VM2000 Hypervisor are handled by the XEN Hypervisor and a VM2000 agent component in the privileged domain Dom0.
On SQ servers, the VM2000 command functions for operating VMs and managing the host are mapped to XEN administration functions. The VM2000 Agent daemon running in Dom0 implements the mapping of the VM2000 Hypervisor functionality, with BS2000 guest systems also occurring as job submitters alongside the VM2000 Monitor. VM2000 functions in the guest systems
Currently, each BS2000 guest system has communication interfaces to the VM2000 Hypervisor in order to obtain information about VM2000 operation and initiate VM2000-specific actions in the guest system (e.g. implicit device assignment). On SQ servers, too, the BS2000 guest systems can continue using VM2000 functionality by calling XEN interfaces instead of the current Hypervisor Calls. In VM2000 operation, each BS2000 domain has its own HAL and CISC firmware. Running BS2000, Linux and Windows guest systems on SQ servers
As well as the parallel operation of multiple BS2000 guest systems supported by VM2000, it is also possible to run Linux and Windows as additional guest systems based on the Xen architecture. The administration interface of the SQ servers, the SQ Manager, was extended and now also enables the administration of Linux and Windows guest systems. However, the administration of the BS2000 guest systems is as before via the VM2000 commands. The VM2000 administrator also receives information about existing resources in Linux and Windows guest systems (CPU, main memory). The GUI of the SQ Manager also indicates BS2000 guest systems and enables for BS2000 guest systems the functions “Start guest system“, “End guest system“ and “Abort guest system “.
Figure 5 VM concept for SQ servers
Summary | Issue: February 2013 | BS2000/OSD Scope – Chapter 6 System Software Use: External Page 17 / 17
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. 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
6.4.4 Functional enhancements in the new VM2000 version VM2000 V10.0
VM2000 V10.0 provides a joint version serving business servers of both the S and the SX series. The SX servers become through VM2000 V10.0 no longer supports. VM2000 V10.0 supports BS2000/OSD-BC V9.0 as monitor and as guest system. The main new functions in VM2000 V10.0 are: Joint VM2000 version for S and SQ servers
After version V9.0 (S/SX) and V9.5 (SQ only) VM2000 V10.0 is a joint version, which again supports all the current HSI lines (S/SQ). SX servers are officially no longer supported. Full support of ETERNUS disk systems
Eternus DX disk systems (DX400/8000) are supported to the same extent as EMC Symmetrix disk systems by VM2000 (PAV, Snap & Clones). Backup of the VM2000 configuration and automatic recovery for server start (S and SQ servers)
The backup of an existing VM2000 configuration is intended to enable the VM2000 administrator to recover the VM2000 configuration after the restart of the overall VM2000 system, i.e. ending all guest systems and restarting the monitor system, without having to write a suitable procedure file with VM2000 commands or adapt an existing procedure file. It should also be possible to use the backup to recover the VM2000 configuration on a backup server, on which - apart from the monitor system - no further BS2000 guest systems run. The VM2000 administrator can create a backup using the command SAVE-VM-CONFIGURATION. The VM2000 administrator can trigger the recovery of a VM2000 configuration through the installation of a backup with the command RESTORE-VM-CONFIGURATION. CPU pools for BS2000-VMs also with the SQ server (incl. adaptation of the virtual multiprocessor capacity) The restriction that in addition to the static CPU pools no further dynamic CPU pools can be configured on SQ servers is lifted. In order to administer the CPU pools the commands CREATE-, DELETE- and SHOW-VM-CPU-POOL as well as ASSIGN-VM-TO-CPU-POOL and SWITCH-VM-CPU are available to the VM2000 administrator. In the last two commands the current multiprocessor capacity of the affected VM(s) is - as on S servers - checked and automatically modified. Support of 32 virtual CPUs per VM (SQ server)
The maximum multiprocessor capacity of a VM on an SQ server is increased from 16 to 32. VM2000 support of high availability & LiveMigration configurations (SQ servers)
The high availability & LiveMigration functionality for SQ server units is mainly implemented through MARS, X2000 and HA-Addon software. Nevertheless, deliverables are also required in VM2000, which make it possible to use VM2000 in such a HA cluster (e.g. a global view of all VMs in a cluster due to the required global uniqueness of VM names and necessary VM2000-specific tests). Future prospects
VM2000 will in future also be adapted to new customer requirements. Furthermore, deliverables for system requirements are implemented.
