MVS... a long history : '79 : MVS/370.

A history of IBM's most powerful and reliable operating system.

H o m e

'79 : MVS/370.

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 and ACF/TCAM. These were followed by MVS/SP, TSO/E 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.

T.Falissard's note. This phenomenon, "unbundling", had significant consequences upon the industry. "An independent software industry was created almost overnight as a response to unbundling. If an independent vendor could supply software that was cheaper than IBM's and perhaps had more powerful features than IBM's software, then there was a real chance to sell non-IBM software to IBM customers (...). The IBM-compatible computer market got a big boost. Many companies, called PCM (for plug compatible mainframers) now copy IBM hardware. (Harvey M. Deitel, An Introduction to Operating Systems).

A note from Alan Hinds (Sat, 15 Dec 1990, in the IBM Mainframe Discussion List). When IBM first released System 360, a great deal of software was bundled free with the mainframe purchase. Independant software developers and competitive mainframe vendors (CDC most notably) won an anti-trust suit to force IBM to unbundle software from hardware and to separately price software items. I believe IBM is the only vendor forced by the courts to unbundle. Similarly, IBM is the only vendor required by the courts to publish its hardware interface specs and provide spare parts to anyone who wishes to buy them. The suits were filed to limit IBM's power in the marketplace, but I believe the long run effect has been to to increase the attractiveness of IBM (or compatible) equipment. If you own IBM (or compatible) equipment, you can buy low-priced compatible peripherals and maintenance from many competitive sources, and you have the widest variety of software offerings available in the business.

Shmuel on unbundling. (Mon, 03 Apr 2000). Well before ACF/TCAM and ACF/VTAM, IBM was charging for such compilers as Assembler (H), PL/I Checkout and PL/I "Optimizing" compiler.

Shmuel's note. TSO/E was a replacement for two other program products, TSO Command Package and TSO Session Manager.

Shmuel's note. There are a couple of other products missing in the history of the transition from MVS to MVS/SP. Take DF/EF (please!) and DF/DS. Note that the original DFP was only for MVS/XA; the version for MVS/SP V1 came in somewhat later, and until then DF/DS was the vehicle for device support in MVS/SP V1.

T.Falissard's reply to Shmuel's note. I never worked with DF/EF (Data Facility Extended Function, it preceded DFP). I found in the IBM Mainframe Discussion List (Wed, 11 Aug 1999) Shmuel's post on the subject : "My recollection is that DF/DS and DF/EF were announced concurrently. DF/DS was required for new DASD. DF/EF is the only product that I remember being 'recalled': IBM said, in effective, 'If you haven't installed it, don't. If you've installed it, do a RESTORE. If you've already done an ACCEPT or switched to ICF catalogs, contact the support center.' I missed out on all of the fun, and was perfectly happy to forgo the experience; finding out third hand was already hair raising." I had a similar ugly experience in the beginning 90' with PDSEs which suffered many bugs during YEARS !

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 16MB virtual address space for use by the operating system, with 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 hall. In fact, some combinations occupied as much as 13-14MB. Since it was common storage, 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 thought virtual storage would last a long time.

T.Falissard's note. It was our problem during the 80' with MVS/SP. I remember that it was impossible to get a REGION=4000K for our IMS/DC version 120 (it often crashed because of that). IMS v120 was nice if you enjoyed seeing tapes in rotation : 4 units were required (log file + alternate "forward" log file + their backups in case the tape broke).

With the introduction of MVS/SP 1.3, a new feature, cross-memory, was added to the System/370 architecture. Cross-memory introduced a dual address space architecture, which provided for direct access to programs and data in separate address spaces under the control of a 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 a 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.

T.Falissard's note. I remember our manager's silly question : how can we use all the memory (64MB) of our computer (3081) with address-spaces of only 16MB ? There must be some waste...

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.



Back to home page