|Marketing target||Academic computing and the teaching of computer science|
|Platforms||S/360, S/370, and 4300-series mainframes|
|History of IBM mainframe operating systems|
MUSIC/SP (Multi-User System for Interactive Computing/System Product; originally "McGill University System for Interactive Computing") was developed at McGill University in the 1970s from an early IBM time-sharing system called RAX (Remote Access Computing System). The system ran on IBM S/360, S/370, and 4300-series mainframe hardware, and offered novel features (for the time) such as file access control and data compression. It was designed to allow academics and students to create and run their programs interactively on terminals, in an era when most mainframe computing was still being done from punched cards. Over the years, development continued and the system evolved to embrace email, the Internet and eventually the World Wide Web. At its peak in the late 1980s, there were over 250 universities, colleges and high school districts that used the system in North and South America, Europe and Asia.
The MUSIC/SP file system was unique in a number of respects. There was a single system-wide file index. The owner's userid and the file name were hashed to locate the file in this index, so any file on the system could be located with a single I/O operation. However, this presented a flat file system to the user. It lacked the directory structure commonly offered by DOS, Microsoft Windows and Unix systems. In 1990 a "tree-structured" directory view of the file system was overlaid on this, bringing the system more in line with the file systems that were then available. By default the information stored in the files was compressed. This offered considerable saving in disk space. The file system had a fairly sophisticated access control scheme allowing the owner to control who could read, write, append to and execute the file. It also had the concept of a "public" file which was visible to all users and a "private" file which was only visible to the owner. In version 2.3, even private files were listed in the common library, with the result that no two users could have files under the same name; by 4.0, this limitation was removed.
The initial versions of the system provided no support for virtual memory and address translation. Only one active user could reside in core memory at any time. Swapping (to disk) was used to time-share between different users, and a variable-length timeslice was used. Virtual memory support was introduced in 1985. This allowed multiple users to be in core memory at the same time, removed many of the restrictions in the size of the programs that could be run and provided a significant performance improvement. System performance was also improved by pre-loading commonly used modules into virtual memory at startup time where they could be available to all users simultaneously.
The system was designed to support academic computing and the teaching of computer science, so a rich suite of programming languages was available. The system nucleus was written in IBM/370 assembler but most of the native applications were written in FORTRAN. The system supported the Waterloo WATFIV and WATBOL compilers and also provided compilers for Pascal, C, PL/I, BASIC, APL, ALGOL, RPG, and GPSS. The system was missing a command scripting language until REXX was ported from CMS in 1984. Later, in 1986, a complete user interface was written entirely in REXX.
E-mail was one of the major applications on MUSIC/SP. The e-mail interface initially provided access to local e-mail. As the networks developed, this was expanded to provide access to BITNET and Internet based e-mail. MUSIC/SP did not have direct access to the Internet until 1990, when the University of Wisconsin Wiscnet TCP/IP code was ported to the system, allowing the system to provide access to all Internet services.
A major feature of the system was its ability to run programs that were designed to run on IBM's mainstream operating system (MVS). This was accomplished using an MVS emulator that intercepted system calls at the Supervisor Call instruction (SVC) level. Most third-party applications ran in this mode. Rather than write their own version of an application, the MUSIC/SP developers would usually start from the MVS version and rebuild it to run in MVS emulation mode. Since the MVS emulation was a very limited subset of the real thing, the applications generally ran more efficiently on MUSIC/SP.
One major advantage the system had in educational environments was that through the use of special lines called "control cards" at the top of a file, source files for any supported language could be automatically directed to the appropriate compiler (Fortran being the default), compiled, linked, and executed, (with compilation, linkage, and execution options also specified in control cards) simply by entering the filename on a command line.
A wide variety of terminals were supported as of 1980, including both EBCDIC-based units using IBM-proprietary protocols, and asynchronous ASCII-based units. Since terminals were connected through various types of front-end processors (as per common IBM timesharing practice both then and now), and could therefore function without CPU attention for a considerable amount of time, MUSIC used variable-length time slices, which could, on compute-bound processing, reach a maximum of several seconds per time slice; conversely, if a user filled the output buffer or reached a conversational read, the timeslice would end immediately.
Edited: 2021-06-18 18:37:22