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 a JES, the correct names were MVS/SP-JES2 Version 1 or Version 2 and MVS/SP-JES3 Version 1 or 2.
Shmuel's note. MVS/SP JES2 replaced not only the free JES2 but also the NJE program product.
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 product, 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 two 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 code, control blocks and data above 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 storage 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 customers' investment in applications. 370-XA introduced a bi-modal addressing capability, which allowed most applications written for OS/360, OS/VS1, OS/VS2 or MVS/370 (24-bit addressing structure) to run with 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 by the operating system, freeing up processor resources.
T.Falissard's note. It was the more visible feature of MVS/XA. I/O were dramatically boosted.
When the IBM ES/3090 processor complex was introduced in 1985, it contained new hardware features: vector facility, expanded storage and four-way multiprocessing. These new features were supported by MVS/SP V2, which used 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.
Shmuel's note. The 3084 provided 4-way MP ("dual dyadic") processors before the 3090.
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 added similar capability. JES2 followed suit with a dual spool 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.
T.Falissard's note. This infamous OCO policy has been cursed by cranky hackers and programmers (like me). Interestingly enough, IBM is now saying that < quote > "(in contrast with Unix) we can see immediately that OS/390 has a natural advantage in the security stakes. It is a bit more expensive than some of the other systems, it just as cheerful, but it requires specialized hardware. Its main benefit is that it has been distributed as Object Code Only for a number of years now, making it very difficult for the casual user to find holes with. (You never thought that OCO would one day be of benefit to you, did you?)." < endquote > from "Stay Cool on OS/390: Installing Firewall Technology" (Redbook SG24-2046-00). Personally, when I consider the number of MVS sites that have hidden holes (like "magic" authorization SVCs that enable anybody to bypass the security), I am less optimistic than IBM...
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, new release levels, or new products. The CBPDO was also customized with 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.