|WikiProject Computing||(Rated Start-class)|
|To-do list for MVS:|
- 1 Non-POV claims
- 2 Post-MVS features
- 3 31-bit addressing
- 4 Benefit of running MVS now z/OS
- 5 Need to restructure IBM operating system articles?
- 6 Rewrite of Job Control Language in progress
- 7 Name standardization
- 8 Merger proposal
- 9 Modern definition of MVS?
- 10 History and names
- 11 Merge MVS articles
- 12 DSS was not a hypervisor
- 13 References to MVS/370
- 14 Reverted of good faith edits by Rfc1394
> Japanese mainframe manufacturers Fujitsu and Hitachi both repeatedly and illegally obtained IBM's MVS source code and internal documentation in one of the 20th century's most famous cases of industrial espionage.
I found some references to this from old ComputerWeek articles from 1980s, but even those don't read quite like the above, sounds like a much more complex case.... the above sounds like something out of IBM lawyers. — Preceding unsigned comment added by 2601:18F:600:E20:99A6:13B5:83E8:B008 (talk) 01:45, 4 September 2016 (UTC)
- Presumably this would be covered by the reorganization discussed below. Guy Harris 18:27, 19 October 2007 (UTC)
- First and foremost, keep in mind that OS/VS Rel.2 (a.k.a. VS2 or MVS), MVS (MVS Rel.3), MVS/SP, MVS/XA, OS/390 and the early z/OS are nothing but enhanced, expanded releases of the original OS/360 PCP stock. The name changes are confusing though they were necessary for marketing and legal reasons. While the early OS/360 versions (MFT an MVT) were "bundeled", all subsequent releases were leased / licensed software. As the operating systems evolved, so did the terms and conditions of the licenses. Case in point well worth noting: If it was written respecting the rules, any program which once worked and ran under OS/360 MFT/MVT could have and often did run on all subsequent operating system releases and will still run on the latest z/OS release. AndreasCA (talk) 17:37, 26 October 2008 (UTC)
MVS is still the name of today's z/OS products' core services. Therefore, it would be better to structure along the lines of major enhancements (see: "z/OS V1R10.0 MVS ..." ).
- I think AndreasCA's comment "OS/VS Rel.2 (a.k.a. MVS) ... and the early z/OS are nothing but enhanced, expanded releases of the original OS/360 PCP stock" is an exaggeration. I was an IBM employee when MVS was introduced and was told by some of IBM's best technical people that MVS was a complete re-write in a different language (PL/S instead of Assembler). It's true that "If it was written respecting the rules, any program which once worked and ran under OS/360 MFT/MVT could have and often did run on all subsequent operating system releases and will still run on the latest z/OS release," because IBM took backwards compatibility very seriously, if only to avoid having to write all its software products simultaneously. However MVS had completely different memory management and security from SVS, which was just MVT with virtual memory bolted on. Functional structure of IBM virtual storage operating systems Part II: OS/VS2-2 concepts and philosophies by A. L. Scherr makes these and other differences clear. In short, these systems retained very similar externals but had very different internals. -- Philcha (talk) 18:28, 26 October 2008 (UTC)
- Philcha understood correctly that IBM partially (re-)wrote / replaced substantial parts of the old OS/360 code by new functions written mostly in PL/S, namely those parts which had to be changed to go from vertical mapping of regions to the horizontal one. Also, a lot of new functions and features were added (VSAM, VTAM) which replaced similar ones from the OS/360 era, eg. BTAM/QTAM, QISAM and many releases later TCAM, CVOL catalog management and others. The "completely different memory management" talk refers to is a fine example of a lot of IBM Marketing hype. The old MVT memory management was partially eliminated. The rest was ported to MVS with little more than "minor" changes as the new MVS memory management of virtual storage, the same 'ol GETMAIN, FREEMAIN, subpools, FQEs (though better protected). Of course, a completely new real-storage management was added, including a completely redesigned swapping and paging. The next big partial rewrite occured when IBM reworked MVS/SP to support 31-bit addressing. At no point in the evolution did IBM rewrite OS/360 MFT/MVT. Although many original components are still around I can't imagine anyone except IEFBR14 still being in its original state. AndreasCA (talk) 19:33, 26 October 2008 (UTC)
- Also, :Philcha wrote "MVS had completely different memory management and security from SVS, which was just MVT with virtual memory bolted on." may be misleading since SVS was really an MFT extension with 16 vertically mapped partitions, mapped in virtual storage, but included JES1 or JES2, TSO, VSAM and VTAM. Though the last two I could be wrong because I used TCAM for TSO and had no ISAM on that 370/158 VS1 system (1974-1975). No new or better security features were introduced with either VS1 or VS2. RACF wasn't available or usable until MVS Rel.2.3 (or thereabouts, say 1979). MVS Rel.2 used the exact same security components (Assembler programs, SYS1.UADS, etc.) as MFT and/or MVT did, all Assembler modules, all ported from MFT and/or MVT. AndreasCA (talk) 20:41, 26 October 2008 (UTC)
- "GETMAIN, FREEMAIN, subpools, FQEs" remained the same for backwards compatibility, and because they seemed to do what was needed at the time. However internally MVS' memory managemnt was totally different, because it was more efficient (no more fragmentation) and inherently more secure - in 1976 IBM announced that it would treat corruption of one MVS address space by another without the help of a rogue SVC as a priority 1 bug, something they had not felt confident of doing with MVS' predecessors. -- Philcha (talk) 21:33, 26 October 2008 (UTC). Unfortunately Philcha quotes from IBM Marketing literature and is getting confused, Security and RAS, though related, are two different topics. MVS Rel.2 fragmented virtual storage no more and no less than MVT fragmented real storage. However MVS generally makes better use of real storage than MVT does. AndreasCA (talk) 17:45, 27 October 2008 (UTC)
From OS/360 PCP to z/OS, MVS has been continually expanded, enhanced and adapted. And it shows. There are many "questionable" features and quirks that have their justification and origin in a long forgotten world of System/360 with its SIO and CCWs and the OS/360 designed to hog not much more than the 56KiB of real core storage. AndreasCA (talk) 20:41, 26 October 2008 (UTC). Coming back to "questionable" features and quirks, here are some of them:
- many files have 80-byte long records and the last 8 or 9 are reserved
- MVS assists but it is still the users (plus add-on software) who manage disk space (ref: x37 abends).
- the dataset catalog isn't a directory but there is exactly one directory called VTOC per disk
- DOS/360 and OS/360 and their offspring, all use CKD disk formats
- AndreasCA (talk) 17:45, 27 October 2008 (UTC)
OS/360 right up to MVS/SP only supported 24-bit addressing. As the underlying hardware progressed it supported 31-bit (XA and ESA) and now (as z/OS) 64-bit addressing were added.
Should this say "it supported 32-bit (XA and ESA)"? No, because the 32nd bit, the top/left-most bit is used to distinguish between 31-bit and 24-bit addressing modes, as well as being used as a special "end-of-list" marker known as the VL-bit. Both adressing modes can be intermixed in the same program, as documented in the respective "Princple of Operations" manual. Special instructions were introduced to let any program switch from one addressing mode to another AndreasCA (talk) 18:31, 26 October 2008 (UTC)
- There was an early attempt at 32-bit addressing in the System/360 Model 67, and the weird bugs deriving from unsigned addresses in a milieu where sign bits hadn't previously participated were legendary horror. When Extended Addressing (XA) came it did in 31-bit form to avoid repeating those problems. When System/390 extended the addressing to 64 bits, a lot of us said "surely you mean 63 bits - no sign, right?". The response from IBM was that they had spent so much time and effort dealing with public relations etc. fallout from the 31-vs.-32 bit decision that there was only one acceptable answer to the 63-vs.-64 bit question. RossPatterson 03:48, 12 April 2006 (UTC)
- Interesting. How did 64-bit systems handle variable-length argument lists in subroutine calls (see below re CALL macro)?Philcha 05:37, 19 October 2007 (UTC)
The high order bit running in XA mode (31-bit addressing) was typically used to indicate the last element in a series of link listed addresses, i.e. there were not any more tokens in the chain.
- That's right. More specifically, from DOS/360 and OS/360 onwards subroutine calls passed the addresses of their arguments (like references in C); the last of a variable-length set of arguments had the high bit set to 1 (by the CALL macro in Assembler; by compilers for high-level languages). Philcha 05:37, 19 October 2007 (UTC) In all cases of 24-bit adressing modes the hardware always did and still does ignore all 8 high-order bits. Only the lower 24 bits of an address are used to access memory.AndreasCA (talk) 18:31, 26 October 2008 (UTC)
I dont' see any reference to MFT an ancestor of MVT.--Les 14:25, 12 December 2006 (UTC) Correct, though technically a revised PCP was released as MFT. Going back to 1968 I never knew of anyone having ever used OS/360 PCP. MVT was as much a revised MFT as MFT was a down-scaled "lighter" MVT. To use MVT one needed at least a 512KiB machine (typically 360/65s) whereas most MFT shops had 360/40's or 360/50's with 256KiB. AndreasCA (talk) 18:31, 26 October 2008 (UTC)
Benefit of running MVS now z/OS
MVS will run the processor at 100% utilization while still performing real work. Try that on UNIX or Windows based systems.
- More precisely, MVS requires hardly any tuning to run the processor at 100% utilization while still performing real work. In the early 1970s the large UK clearing banks ran their overnight systems at 100% just to get all the work done, but that required careful system design and heavy tuning of MVT. Philcha 06:19, 19 October 2007 (UTC)
Need to restructure IBM operating system articles?
Long discussion on the topic, with a plan of new structure, has been moved to Talk:History of IBM mainframe operating systems. Please continue there.
--Kubanczyk 12:46, 24 October 2007 (UTC)
Rewrite of Job Control Language in progress
As part of the proposed restructure of articles on IBM mainframe operating systems (above), I've rewritten Job Control Language to: cover IBM's DOS/360 and its descendants as well as OS/360 and its descendants; focus more on the facilities and flavour of the 2 JCLs rather than on details of some statement types and some of their options. Please comment in Talk: Job Control Language. I'd be particulary grateful for more info on DOS/360 and its descendants, especially after 1980 - I only used DOS JCL a handful of times, and only in the late 1970s.
The rewrite does not currently take account of Truthanado's point in Talk: Job Control Language about use of "JCL" by computer suppliers other than IBM, which may entail further restructuring of articles about JCLs.Philcha 23:47, 20 October 2007 (UTC)
Some time ago there was a push to standardize the names of articles related to exclusive IBM products (OS/2 → IBM OS/2). I've moved a few of the more obvious ones... would the move here be appropriate? /Blaxthos 17:04, 28 October 2007 (UTC)
- How this ummmm "standardization" effort relates to official Wikipedia guideline WP:COMMONNAME? The two seems to be in conflict, aren't they? May I ask about the reasons for this renaming push? --Kubanczyk 17:38, 28 October 2007 (UTC)
- Please do not rename until merger proposal decided (see below). If the pages are merged, renaming will be unnecessary. Philcha (talk) 21:10, 25 November 2007 (UTC)
To reduce duplication of content re features inherited from MVS's predecessors and to fit into the framework provided by History of IBM mainframe operating systems. —Preceding unsigned comment added by Philcha (talk • contribs) 21:07, 25 November 2007 (UTC)
Modern definition of MVS?
I'm a person who sometimes uses z/OS but I did not cut my teeth on IBM mainframes. I encounter the term MVS often, so I came here hoping to see a definition, but I don't see what I'm looking for. I'm not looking for "Multiple Virtual Storage" which may be the term's origin but clearly has little relevance to it's current meaning. And I'm not looking for "MVS was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers," (note the past tense), or "MVS is no longer supported by IBM." This may be one meaning of the term, but it is not the way the term is currently used (in my experience). IBM still uses the term widely, see http://www.ibm.com/systems/z/os/zos/bkserv/r9pdf/#mvs, and IBM's usage doesn't fit the definitions presented in this article. If MVS is just an old name for z/OS, then why does IBM still use the term so often, in current publications?
I'm afraid this sounds like a rant. I don't mean it to be, I'm just suggesting that this article should start with the information that most non-mainframe people are going to be looking for -- a straightforward definition of the current meaning of the term. Historical information can come after that. I would suggest a definition to you, if only I knew what it would be. MVS currently seems to be used as a generic term for the non-POSIX portion of z/OS, as far as I can tell, but as a non-expert on the subject I'm not really sure (which is why I turned to Wikipedia). I have not been able to find the answer on the IBM website either. Doctorpepper (talk) 19:27, 19 April 2008 (UTC)
- Interesting question. I just googled for "MVS" and found (among a load of irrelevant stuff, nothing to do with IBM OSs):
- FolDoc on OS/390 - appears to suggest that OS-390 = MVS + Unix. If true, that would support your "MVS currently seems to be used as a generic term for the non-POSIX portion of z/OS".
- a UK contracts site that is try into recruit for "MVS" contracts - so the term is still in use and widely recognised, despite the fact thatIBM introduced the OS/390 "brand" in 1995.
- I'll ask around. Philcha (talk) 20:11, 19 April 2008 (UTC)
- I'm afraid that in this field history is important, so if readers don't want to read about the history, they may have serious problems with figuring out anything. In the same way, to provide an example from the PC field, most people say "DOS commands" instead of "Windows Command Prompt commands" (whatever...). Just try to explain this to somebody that does not want to know a bit of DOS/Windows history. --Kubanczyk (talk) 21:16, 19 April 2008 (UTC)
- I *think* that in a modern context, MVS refers to the supervisor portion of z/OS. I'd say that MVS is to z/OS what linux is to gnu/linux. Ivan Scott Warren (talk) 11:45, 16 March 2009 (UTC)
- For those of us who worked on MVS, the acronym became a metonym. Metonymy is a figure of speech in which a thing or concept is not called by its own name, but by the name of something intimately associated with that thing or concept. For instance, "Hollywood" is used as a metonym (an instance of metonymy) for American cinema, because of the fame and cultural identity of Hollywood, a district of Los Angeles, California as the historical center of movie studios and movie stars. Another example is "Westminster," which is used as a metonym for the Parliament of the United Kingdom, because it is located there.
- In the early part of my career (beginning in 1967) I was a DOS/MVT/MVS systems programmer. When I got out of day to day SP work and became a manager, MVS was etched in my mind as THE operating system. As MVS evolved into z/OS the name just stuck for me and all my fellow old-timers. So forget your quest to figure out the current definition, ain't gonna happen...188.8.131.52 (talk) 22:58, 14 November 2011 (UTC)Bill Anderson <me>
- Well, z/OS V1R11.0 Information Roadmap z/OS V1R10.0-V1R11.0 speaks of "documents for MVS™ (Base Control Program)", and of "MVS and other z/OS elements", suggesting that what IBM calls "MVS" these days is a component of z/OS. Networking on z/OS speaks of "MVS application[s]" and "z/OS UNIX application[s]", suggesting that "MVS" might be the component of z/OS that supports the "classic" part of z/OS rather than the "support UNIX APIs" part, i.e. the component that isn't descended from the stuff added in MVS/ESA OpenEdition, or, to put it another way, not the "Unix System Services" part. Guy Harris (talk) 01:32, 15 November 2011 (UTC)
History and names
First, the genealogy of z/OS is a bit longer than the article states. There were also several add-on program products that were eventully meged into the base. Off the top of my head:
- OS/VS2 Release 2 through 3.8
- MVS/System Extensions
- Release 1 based on 3.7 and SU7
- Release 2 (SE2) based on 3.8 and SU64
- MVS/SP Version 1
- MVS/SP Version 2 (MVS/eXtended Architecture)
- MVS/SP Version 3 (MVS/ESA)
- MVS/SP Version 4 (MVS/ESA)
- Release 3 introduced OPEN EDITION (Unix)
- MVS/ESA Version 5
- OS/390 Version 1
- OS/390 Version 2
Unix came in with MVS/SP 4.3, under the name MVS OPEN EDITION.
Several older add-on packages were swallowed up by TSO/E and DFP; the latter was eventually renamed to DFSMS and incorporated several other add-on products.
Officially Unix System Services does not have an acronym; USS refers to Unformatted System Services, a part of VTAM, and by extension to equivalent services in the TN3270 server. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:11, 7 July 2010 (UTC)
- I've edited the article to address some of the above. In the process I noticed a claim that MVS was the most common mainframe operating system. I've always understood the DOS/VSE, VSE/AF, VSE/SP. VSE/ESA and z/VSE were each, in their day, more popular. If anybody has any documentation one way or the other, please add a citation. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:44, 8 July 2010 (UTC)
Merge MVS articles
- approve, however
DSS was not a hypervisor
DSS was not qa hypervisor, it was an interactive debugging facility for the operating system. It was much more primitive than the similar TSSS in TSS/360.
Also, IBM killed DSS twice. After the announcement that Selectable Unit 7 would remove support for DSS, the user organization Share passed an Imperative requirement to reinstate DSS, and IBM caved in. Rumor had it thaqt the massive code change required to allow DSS to coexist with SU 7 was actually a single line. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:46, 20 July 2011 (UTC)
References to MVS/370
There are several problems with the references to MVS/370 in this article
- MVS/370 refers to all of OS/VS2 (MVS), MVS/SE and MVS/SP Version 1
- MVS/370 has not been supported for decades, so the reference to being supported should be removed.
- The earliest MVS/370 was OS/VS2 R2; the latest was MVS/SP V1.3 (1.3.7?)
Reverted of good faith edits by Rfc1394
My edit summary for my revert of two edits by Rfc1394 was truncated. In its entirety: "The comparison of PDSs to ZIP files is marginal, ZIP files are not really meant to be updated, whereas PDSs are, and the above/below the line distinction is an RMODE distinction whereas the description describes AMODE differences.". And to further expand on the AMODE/RMODE thing, the residence mode (RMODE) of an application controls whether it runs below (RMODE(24)) or (potentially) above the line (RMODE(ANY)), whereas the addressing mode defines if the program uses 24 bit (AMODE(24)), 31 bit (AMODE(31)), or in either (AMODE(ANY)), based on the caller. While a program running AMODE(24) must be RMODE(24), programs running with 31 bit addressing may (and commonly do) run below the line, so that the can be easily called from 24 bit programs. There are additional complications (newer versions of the OS support 64 bit addressing and programs that have bits loaded into separate areas), but they're not really relevant here. Rwessel (talk) 05:43, 4 August 2014 (UTC)
- In addition, AMODE and RMODE are attributes of individual load modules or program objects, not of entire applications. Further, an RMODE(24) AMODE(24) module can still allocate storage above the line, using the appropriate parameters of the GETMAIN or STORAGE macro, and an AMDE(31) RMODE(ANY) module can still allocate storage below the line. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:42, 4 August 2014 (UTC)