|Company / developer||Stanford University|
|Written in||360/370 Assembler|
|Initial release||1967, 1968|
|Supported platforms||IBM S/360, S/370, and successors|
|History of IBM mainframe operating systems|
ORVYL and WYLBUR are the names associated with the Stanford Timesharing System. Initially developed in 1967-68 for the IBM S/360-67 mainframe computer, it was one of the first time-sharing systems to be made available for IBM computers.
The names ORVYL and WYLBUR are often used interchangeably, but:
WYLBUR is not a full standalone operating system in the mold of Dartmouth Time Sharing System (DTSS) or Unix. Instead it runs on top of the ORVYL time-sharing system or an IBM batch operating system (OS/360, SVS, MVS). It takes the form of an editor with a Remote Job Entry system and thus has much the same relationship to ORVYL or the IBM operating systems as Emacs does to Unix. For these reasons WYLBUR is often thought of as a text editor rather than a time-sharing system. However whereas Unix does not need Emacs to provide time-sharing services, IBM's operating systems originally needed WYLBUR. Later innovations such as IBM's Time Sharing Option (TSO) made WYLBUR less relevant for IBM users and gradually replaced it.
ORVYL and WYLBUR were used at the Stanford Linear Accelerator Center (SLAC), the European Organization for Nuclear Research (CERN), the U.S. National Institutes of Health (NIH), and many other sites. Retired from most sites in the late 1990s owing to concerns about Y2K issues, they remained in use at NIH until December 2009. ORVYL and WYLBUR are still available as open source from Stanford. There are also proprietary versions such as SuperWYlbur.
ORVYL and WYLBUR were much admired as shown by this excerpt from a 2004 article titled "Computing at CERN: the mainframe era":
ORVYL and WYLBUR first became available in 1967-68, before TSS/360, TSO, or any other official time-sharing solution from IBM. This was roughly the same time that third-party time-sharing systems such as MTS became available and the under the radar development effort of CP-67 at IBM's own Cambridge Scientific Center took place. WYLBUR had the additional advantage that it could be used in conjunction with IBM's mainstream operating system, OS/360.
WYLBUR is a single-address-space system, unlike TSO. This conserved memory in the days when memory was precious. So even when TSO was available, organizations seeking to minimize memory use would often keep some or even a majority of their users on WYLBUR rather than letting them use the TSO interactive environment.
WYLBUR provided compressed Partitioned Data Sets (PDSs, aka libraries) to save disk space. In MVS source code was typically stored as a sequence of card images (80 character lines). If a line contained only one or just a few characters, 80 characters were still used to store that line. Even when data, e.g., source code, were stored as variable blocked (VB), space could be wasted on strings of embedded blanks. WYLBUR implements stream-oriented storage of text in PDSs, so that a one character line might only take 16 characters (line length, offset, chunk length, character) rather than 80 to store. An external program run via JCL was used to convert files to and from the WYLBUR compressed PDS format.
Although TSO allowed a user to do more than a locked-down WYLBUR system did, it was possible to write WYLBUR Exec scripts that executed batch jobs to perform functions that ordinarily would have required a TSO account, filling a batch job skeleton out with parameters, submitting the batch job, retrieving the output and displaying it on the screen.
WYLBUR had some security advantages over TSO, and some disadvantages. Advantages included:
Disadvantages related to security included:
||This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (August 2010)|
Mashpedia enables any individual or company to promote their own Youtube-hosted videos or Youtube Channels, offering a simple and effective plan to get them in front of our engaged audience.
Want to learn more? Please contact us at: firstname.lastname@example.org