MVS ... A long and rich heritage..

A history of IBM¹s most powerful and reliable operating system (pictures of 360 and 370 reference cards ) ........ MVS: Then and now Today, MVS is IBM¹s most powerful and reliable computer operating system. Over the years, MVS has been refined and honed, incorporating customer requirements, remaining attuned to new hardware and software developments, and expanding its capabilities to keep pace with changing directions in technology. The MVS of today is not the MVS of old. In fact, much of MVS has been rewritten, using state-of-the-art techniques which reflect new concepts and functions to ensure high levels of quality and availability. MVS/ESA(tm) has a long and rich heritage. Its roots lie in OS/360, an IBM operating system developed in the 1960s. Whether you are a newcomer to MVS, or have been in data processing for 40 years, we hope you enjoy retrospective. (Picture of AUTOCHART CODING SHEET) OS/360 In April 1964, IBM announced OS/360, an operating system developed to support the new generation and architecture OS System/360(tm) hardware capable of both commercial and scientific applications. Prior to System/360, these applications ran on separate lines of hardware. OS/360 included three control programs options, delivered in stages beginning in March 1966. The first stage was the simplest - a sequential scheduler called the primary control program (PCP). PCP, performed only one task at a time, and ran in 32KB of memory. That¹s right! Kilobytes, not megabytes. With PCP, a processor could spend considerable time waiting for I/O. OS/360 was the first operating system to require direct access devices. Multiprogramming introduced the technique of assigning control of the processor to another task while the first task was waiting for I/O. This technique utilized resources more effectively. Next came MFT (multiprogramming with a fixed number of tasks). Initially MFT supported four tasks at one time. Later it was upgraded to support fifteen tasks. A third option, MVT (multiprogramming with a variable number of tasks) followed . Theoretically, MVT allowed any number of tasks to be performed concurrently. Because of the added function, more real storage was required: 64KB for MFT and 128KB for MVT. System installation was accomplished through sysgen, a time consuming, difficult and tedious process performed in two stages: building the system and defining the I/O configuration. Early user requirements identified the need to simplify this process. Prior to OS/360, even the most dedicated programmers found I/O programming to be a painful process - repetitive, inconsistent, and error prone. OS/360 supplied data and telecommunications access methods that simplified the task. Job control language (JCL) also was introduced at this time. Upon initial release the access methods included BSAM, QSAM, BDAM, BPAM. In addition, OS/360 contained system utilities, an assembler, and some compilers. Applications were soon developed that required faster access to data. Consequently, ISAM and QTAM were added. :Later, improvements were made to linking new functions and operational enhancements were added. A checkpoint/restart facility was developed to allow application to restart at points other than the beginning. However due to the limited size of the processor storage, many applications couldn¹t be stored in one piece. An overlay supervisor was developed to help control and load the application in parts. In 1968, a multi-processing capability was designed for the System/360 (S/360) Model 65. This new function was supported by MVT, and allowed a user to have dual Model 65s, which could share central storage under control of a single operating system. Having two processors working on the same job significantly improved application availability. As more and more organizations began developing compilers, users wanted the flexibility to pick and choose among these, including IBM compilers. To respond to this need, in 1969 IBM changed its definition of the operating system to distinguish our compilers from system code. Compilers were classified as program products, offered separate license agreements. OS/360 was originally developed as a batch operating system. However, users soon asked for interactive capability. In 1971, IBM released the time-sharing option (TSO), which became an integral part of the operating system. TSO used TCAM, a new communications access method that was developed and released at the same time. Release 21.8, the last in the OS/360 line was made available in 1974. (Picture of a OS/360 green card) MVS/370 ?79.... Times and marketing conditions changed rapidly in the late 1970s. By 1979, the concept of pricing system code separately from the hardware was established. Some of the first separately priced products were ACF/VTAM(tm) and DFP/370. JES2 and JES3 were considered integral to the base control program (BCP) and therefore were packaged with the BCP as part of MVS/SP. It was definition time again. In the new separately priced structure, the combination of MVS/SP and DFP/370 now made up the operating system called MVS/370. When OS/VS2 MVS was developed, some virtual storage was designed to be common storage, shared by all address spaces, while some was declared private storage, for use by applications. Our direction was to reserve one-half of a 126MB virtual address space for use by the operating system and the other half to be used by customer applications. At this time, common virtual storage was used primarily by the operating system. However, IMS, VTAM and other products were seeing the benefits of occupying common virtual storage. Not surprisingly, it didn¹t take long before the operating system with its subsystems exceeded its half. that left only 2-3MB for applications. It wasn¹t long before applications learned the value of virtual storage, eliminating overlays and simplifying design. Suddenly after only three years, there was no more room! And we though virtual storage would last a long time. With the introduction of MVS/SP 1.3 a new feature, cross memory was introduced a dual address space architecture, which provided for direct access to programs and data in separate address space under the control of the new cross-memory authorization mechanism. Cross-memory allowed subsystems and server-like functions to manage data and control blocks efficiently in private storage. Moving code from common virtual storage to private virtual storage provided some virtual storage constraint relief (VSCR).. For applications, as well as additional isolation and protection for subsystem control blocks and data. IMS, VTAM, JES3 and MVS components were among the first to use cross-memory. Although virtual storage was limited to 16MB because of 24-bit address, processor architecture allowed a 26-bit (64MB) address for real storage, supported in MVS/SP 1.3. MVS/370 performance was improved by utilizing the additional real storage as paging space. The MVS 3.8 operating system was required as an installation base for MVS/370. MVS 3.8 contained specific functions, such as BTAM and GAM, which had not yet been provided as separately priced products. MVS/370 was withdrawn from marketing in December 1991. Service was discontinued in December 1992, approximately 13 years from original availability. (Picture of a System/370 Reference Summary card ) The next major evolutionary step took place in 1981, with the introduction of the IBM 3081 processor complex with 370-XA extended architecture. 370-XA defined a dynamic channel capability, plus 31-bit addressing for both real and virtual storage. To support the new functions, the MVS/SP product had to be reworked. The result was named MVS/SP Version 2. The original MVS/SP product was then renamed MVS/SP Version 1. Technically, since both products also contained JES, the correct names were MVS/SP-JES2 Version 1 or Version 2 and MVS/SP-JES3 Version 1 or 2. MVS 3.8 contained five distinct data-management functions, which were updated and repackaged into a new product, MVS/XA DFP Version 1. MVS/SP Version 2 and MVS/XA DFP Version 1 were co-requisite products. Together they made up the MVS/XA operating system, first made available in March of 1983. Other licensed products, such as ACF/VTAM and ACF/TCAM were updated to work with the new architecture. BTAM was also revised and a new licensed, BTAM/SP was created. Although MVS/370 provided some VSCR with cross memory, it wasn¹t enough. A continual effort was required to maintain a balance between operating system usage and application usage. MVS/XA with its 31-bit addressing structure, gave access to 2 gigabytes (2GB) of virtual storage per address space - 128 times more than MVS/370. What a relief! New operating system code and other licensed programs moved control block and data above the 16MB virtual, which up to that time was the highest virtual storage address. As might be expected, the first question was ³How long will 2GB of virtual last?² Although the architecture allowed for 2GB of real storage, implementation in software didn¹t occur until storage of that size was also supported by the processors. Throughout this process, compatibility was maintained to protect our customer investment in applications. 370-XA introduced a bi-modal addressing capability, which allowed most applications for OS/360, OS/VS1, or OS/VS2 or MVS/370 (24 bit address structure) to run with the MVS/XA (31-bit addressing structure). To aid the customer with migration to the IBM family of 308x processors, OS/VS2, MVS 3.8 and MVS 370 all ran on the new hardware, but without the ability to utilize the new architecture.. Dynamic channel architecture allowed access to I/O devices over any of eight channels. Initial hardware implementation was four channels. Specific DASD devices were able to reconnect to and pass data back on a different channel from the one on which the request was received. Significant improvements in channel utilization were achieved. Requests were queued and managed by the channel rather than the operating system, freeing up processor resources. When the IBM ES/3090(tm) processor complex was introduced in 1985, it contained new hardware features: vector facility, expanded storage primarily to improve paging performance by reducing I/O that occurs when writing pages to DASD. Along the way, MVS/XA DFP continued to add function, including ISMF, a catalog address space, and VSCR, and was reversioned into MVS/XA DFP Version 2. Because of the demand for high availability, MVS/XA. Along with IMS/VS, ACF/VTAM and ACF/NCP, introduced XRF, a capability that allowed high-speed switching of applications and terminals to an alternate system. CICS/MVS(tm) added similar capabilities. JES2 followed suit with a dual spooling capability. As a result of changing views on intellectual property and enforcement of software copyrights and patents, MVS began distributing code as object code-only (OCO). User exits, better documentation and improved responsiveness to both requirements and requests for service helped to smooth the transition from source code to object code. As a wider selection of products became available for MVS, the pre integrated IPO became less useful. It was a common package with a product set that was limited to basic user needs. This meant that all optional products had to be installed separately. In 1984, IBM introduced a custom built IPO, which allowed users to specify products from a menu. A set of distribution libraries, with integrated service, was then built to order. CBIPOs were developed for new customers as well as those who wanted to replace existing systems. In 1986, CBPDO was introduced for those users who wanted to enhance their existing systems with added service for all products for which the user was licensed. As with CBIPO, new products were selected from a product menu. MVS/XA was withdrawn from marketing on December 31, 1992. *****MVS/ESA In February 1988, IBM announced ESA/370(tm), which provided new capabilities for the IBM ES/3090 processors, including access registers, linkage stacks and PR/SM(tm). The volume of data to be processed had risen dramatically over the proceeding decade . Access registers made it easier to separate application code from data, resulting in improvements in data volume handling capabilities and data isolation. ESA/370 provided a new virtual storage space for data only, called a data space. Unlike a cross memory address space, no application code can execute in a data space. Linkage stacks simplify calls/program returns between address spaces, as well as program calls/program returns within a single address space. Linkage stacks also offer associated recovery routines that reduce the need for ESTAEs. Today¹s DB2(tm) uses Linkage stacks facilities. Once again, MVS/SP V2 and MVS DFP V2 were reworked into the next level of the MVS operating system, MVS/ESA. MVS/ESA product levels were MVS/SP Version 3 and MVS/DFP Version 3 also contained significant productivity enhancement called system-managed storage. System managed storage allows the operating system to place and control data on external devices, based on data characteristics and usage. System-managed storage significantly improves DASD utilization, and reduces the work that people, particularly the storage administrator, must do. MVS/DFP 3.2 provided PDSEs, a new 4K physical blocksize structure for partitioned data sets. PDSEs eliminate periodic compresses and the need for careful space pre-planning. MVS/DFP V3 offered a network file server, supporting Sun(tm) Microsystem¹s remote procedure call (RPC) through TCP/IP. The network file server represented a first functional step toward making MVS/ESA operate in an open-system environment. MVS/DFP V3 also introduced a new access method, OAM, in support of optical disk technology. Data spaces addressed a long-standing customer requirement-the ability to access and process data more quickly. Data spaces allow large amounts of data to reside in processor storage, essentially trading storage for I/O access time. Data in a data space is byte addressable, and can be manipulated directly by a program in an address space. Two new services, LLA and VLF, allow the operating system and subsystems to easily utilize data spaces for program libraries, CLISTs and data objects. MVS/SP V3 also provided a special high-speed form of data space called a Hiperspace(tm). Hiperspace data always resides in expanded storage, and must be moved to the address space for manipulation. However, it does not use the paging mechanism. Movement in 4KB or multiples of 4KB blocks bypasses the high-speed buffer. Since data in the high-speed buffer is not disturbed, the buffer hit ratio is improved. VSAM LSR and DFSORT utilize Hiperspaces to improve performance. Another storage technique, Hiperbatch(tm), allows interim VSAM or QSAM sequential data to be kept in a Hiperspace for improved batch processing. Assembler and FORTRAN were subsequently updated to enable user applications to directly access data in data spaces. Callable services are provided so user applications can utilize Hiperspaces. MVS/ESA SP 3.1.3 with RACF(tm) 1.8 received a B1 security rating from the U.S. Department of Defense. B1 provides the appropriate environment for applications that must have mandatory label security protection. The first release of MVS/ESA was delivered in August 1988. To provide for an orderly migration from MVS/XA to MVS/ESA, two provisions were made. MVS/XA DFP 2.4 was updated to run with MVS/SP V3 until such time as MVS/DFP V3 could be installed. No Hiperspace support was available with MVS/XA DFP2.4. For users needing system-managed before migrating to MVS/ESA, MVS/DFP V3 was upgraded to run on MVS/XA with starter-level, system managed storage function. OS/VS3 MVS 3.8 remained an installation prerequisite for new users of MVS. The continuation of MVS/ESA In September 1990, IBM announced ESA/390(tm) and the ES/9000 family of processors. Prime new concepts were Sysplex and ESCON(tm). Again, the base control program was enhanced to support the new architecture, resulting in MVS/ESA SP Version 4. A new component, XCF was added, which allowed authorized applications on one system to communicate via CTC with the other specified authorized applications on another MVS/ESA SP Version 4 system. If an application or system begins to fail, the companion application on the other system can be called into service. XCF presented the opportunity for higher levels of availability. OPC(tm)/ESA, CICS/ESA(tm) XRF and JES2 V4 have been modified to utilize XCF services for takeover and recovery. XCF can also be used with PR/SM ARF to automatically reconfigure processor storage when takeover occurs. Another new component, APPC/MVS, provided a new level of application portability and interoperability with other SAA(tm) systems. APPC applications can now operate in client server fashion and may be ported from one operating system to another when written to the CPI-C interface. Dynamic I/O reconfiguration was realized through ESCON architecture, the ESCON Manager licensed product, and MVS/ESA SP4 V4 HCD. Specified channel-attached devices can be attached and configurations changed without bringing the system down, reducing PORs and IPLs. Support was also provided in NCP to dynamically add preconfigured lines with HCD. A common and consistent front end was also developed for HCD and ESCON Manager, using the ScreenView feature. ScreenView is part of MVS/ESA SP4.3. Once again, productivity for the systems programmer was improved. PR/SM EMIF, an extension announced for ESA/390 in June 1992, is also supported by MVS/ESA SP 4.3 PR/SM EMIF allows sharing of ESCON channels among logical hardware partitions, which should increase configuration flexibility and provide cost savings through reduction in the number of channels required for PR/SM. DFSMS/MVS(tm), announced in MAY 1992, integrates and expands the storage and program management functions previously available in MVS/DFP V3, DFHSM and DFDSS. A new feature, Removable Media Manager, was also added. DFSMSrmm(tm) allows tapes, both automated and manual libraries, to have full automated management support by DFSMS. DFSMS/MVS has since added a concurrent copy function that provides potential for improved data availability during the backup process. DFDSM/MVS is capable to act as a file backup and archive server for LAN file servers and workstations. It also allows applications access to local or distributed record data of DDM systems. Remaining OS/VS2 MVS 3.8 components were repackaged into existing licensed products and the requirement to have MVS 3.8 as an installation base was removed with MVS/ESA SP 4.2.2. In 1992, IBM further simplified the installation process through a group of offerings called CustomPacs(tm). One of these, the SystemPac(tm), is a system replacement option that goes beyond CBIPO in building and customizing. Two others, ProductPac(tm) and ServicePac(tm), are system upgrade options, tailored to a particular system rather than to an establishment. They are simpler to install and require less SMP/E knowledge than CBPDO. Throughout the existence of MVS, heavy emphasis has been made on reliability. With MVS/ESA SP V4, we increased our efforts to ensure quality and reliability.. Both existing code and newly developed code were examined for defects, and corrections included in the product. However, quality means more than code-defect removal. Installation procedures, IPL actions, publications and other forms of documentation were also reviewed and updated. MVS/ESA SP 4.3 OpenEdition(tm) services provide an expanded role for MVS¹s participation in an open-systems environment. POSIX and OSF(r)/DCE are currently being developed to run MVS/ESA SP 4.3. Netview(r) and DFDSM are key products upon which MVS system management and network management will be built. MVS/ESA will continue to play a leadership role in out customers¹ enterprises within the open-system environment. It will act as the enterprise-wide data server and database manager; it will provide data protection and integrity; it will be the enterprise-wide network manager, providing upload/down-load, backup and recovery services; it will be the base for high-volume, high-response transaction processing; an application server; a technical computing platform; a high-volume cryptographic platform; a data compression platform and a quality server. Needless to say, MVS remains a superior batch processing system. The addition of VIO to expanded storage, Hiperbatch, Batch LSR and data striping have contributed significantly to this capability. Future directions point to MVS support of a parallel processing environment, providing significant improvements in data sharing and workload balancing. With MVS/ESA, a high degree of scaleability has been achieved, moving from a uniprocessor environment through eight-way multiprocessing and Sysplex; from kilobytes of real storage to gigabytes of central and expanded storage. Additional processors are supported with efficient utilization ratios. MVS/ESA supports the full range of architectural features. Architecture defined-protection mechanisms range from low-address protection for MVS to subsystem storage protection for CICS. MVS defines virtual storage that reaches into terrabytes. It has added sort instructions, DB2 sort-assist facility, a vector facility, a cryptographic feature and compression, data streaming channels, dynamic channel subsystems. ESCON channels, CTCs, a Sysplex Timer(tm) and more. MVS/ESA has evolved into a highly sophisticated and reliable operating system - one which provides tremendous customer value and is continually responsive to customer needs. MVS/ESA has the quality integrity and function, along with the responsiveness and the performance realization, required to run today¹s businesses. No other operating system matches it. Application investments made in os/360, OS/VS2, MVS/370, MVS/XA and earlier levels of MVS/ESA continue to work with today¹s MVS/ESA. MVS will continue to enhance its offerings with the characteristics that have always been its strengths-and can help companies like yours meet the challenge of the 90¹s. (end) Glossary ACF/TCAM Advanced Communication Function/TCAM ACF/VTAM Advanced Communication Function/VTAM APPC/MVS Advanced Program-to-Program Communication/MVS ASP Attached Support Processor CICS/MVS Customer Information Control System CPI-C Common Programming Interface For Communications BCP Base Control Program BDAM Basic Direct Access Method BPAM Basic Partitioned Access Method BSAM Basic Sequential Access Method BTAM Basic Telecommunications Access Method BTAM/SP BTAM/System Product CBIPO Custom Built Installation Offering CBPDO Custom Built Product Delivery Offering CTC Channel-to-Channel DASD Direct Access Storage Device DFDSM Data Facility Distributed System Management DFP/MVS Data Facility Product/MVS DFSMS Data Facility Storage Management Subsystem DFSMS/MVS Data Facility Storage Management Subsystem/MVS ESCON Enterprise System Connections ESTAE Extended-specify Task Abnormal Exit GAM Graphic Access Method GB Gigabyte - 1,000,000,000 bytes HASP Houston Automatic Spooling Program HCD Hardware Configuration Definition I/O Input/Output IMS/VS Information Management System/Virtual Storage IPL Initial Program Load IPO Integrated Program Offering ISAM Indexed Sequential Access Method ISMF Interactive Storage Management LLA Library Lookaside LSR Local Shared Resources MB Megabytes - 1,000,000 bytes MVS Multiple Virtual Storage MVS/ESA MVS/Enterprise System Architecture MVS/SP MVS/System Product MVS/XA MVS/Extended Architecture OAM Object Access Method OCO Object Code Only OS/VS Operating System/Virtual Storage PDSE Partitioned Data Set Extended POR Power-on-Reset PR/SM Processor Resource/Storage Manager PR/SM ARF PR/SM Automatic Recovery Facility PR/SM EMIF PR/SM ESCON Multiple Image Facility QSAM Queued Sequential Access Method QTAM Queued Telecommunications Access Method SAA Systems Applications Architecture SNA Systems Network Architecture TCAM Telecommunications Access Method TCP/IP Transmission Control Protocol/Internet Protocol TSO/E Time Sharing Option/Extended VIO Virtual Input Output VLF Virtual Lookaside Facility VSAM Virtual Sequential Access Method VSCR Virtual Storage Constraint Relief VTAM Virtual Telecommunications Access Method XCF Cross-system Coupling Facility XRF Extended Recovery Facility