Editing ICL VME (section)

==Architecture==
VME is structured as a set of layers, each layer having access to resources at different levels of abstraction. Virtual resources provided by one layer are constructed from the virtual resources offered by the layer below. Access to the resources of each layer is controlled through a set of Access Levels: in order for a process to use a resource at a particular access level, it must have an access key offering access to that level. The concept is similar to the "rings of protection" in [[Multics]]. The architecture allows 16 access levels, of which the outer 6 are reserved for user-level code.

Orthogonally to the access levels, the operating system makes resources available to applications in the form of a Virtual Machine (VM). A VM can run multiple processes. In practice, a VM in VME is closer to the concept of a process in other operating systems, while a VME process (or application-created sub-process) is more like a thread in other systems. However, processes running within a VM cannot run concurrently and thus resemble [[Thread (computing)#User threads|user threads]] found in other systems.<ref name="holt1995">{{cite book | url=https://www.fujitsu.com/uk/Images/the-architecture-of-open-vme.pdf | title=The Architecture of OpenVME | publisher=International Computers Limited | last1=Holt | first1=Nic | date=1995 | access-date=21 June 2024 | archive-date=8 November 2016 | archive-url=https://web.archive.org/web/20161108131142/https://www.fujitsu.com/uk/Images/the-architecture-of-open-vme.pdf | url-status=bot: unknown }}</ref>{{rp|pages=32|quote=A VM may have multiple processes each of which has its own stack. No more than one process may be active in a VM at a given instant. New processes are created by the system when it is necessary for execution to commence on a new stack. They may also be created by user software, in which case they are termed sub-processes. Sub-processes provide a facility similar to threads in other systems.}} A dedicated instruction is involved in the transfer of control between processes sharing the same VM.<ref name="icl199305_coates"/>{{rp|pages=483|quote=Processes within a VM are not scheduled by the operating system. Control is passed to another process when the application executes a process-switching call instruction. At most one process per VM can be executing at a time, even on multiprocessor systems.}}

The allocation of resources to a virtual machine uses a stack model: when the stack is popped, all resources allocated at that stack level are released. Calls from an application to the operating system are therefore made by a call that retains the same process stack, but with a change in protection level; the resulting efficiency of system calls is one of the features that makes the architecture competitive.

Communication between Virtual Machines is achieved by means of Events (named communication channels) and shared memory areas. The hardware architecture also provides [[semaphore (programming)|semaphore]] instructions INCT (increment-and-test) and TDEC (test-and-decrement).

Files and other persistent objects are recorded in a repository called the Catalogue. The file naming hierarchy is independent of the location of a file on a particular tape or disk volume. In days where there was more need for offline storage, this made it easy to keep track of files regardless of their location, and to move files between locations without renaming them. As well as files, the Catalogue keeps track of users and user groups, volumes, devices, network connections, and many other resources. Metadata for files can be held in an object called a File Description. The Catalogue was probably the first example of what would later be called an [[Entity–relationship model|entity-relationship]] database.

[[Interrupt]]s are handled by creating a new stack frame on the stack for the relevant process, handling the interrupt using this new environment, and then popping the stack to return to the interrupted process.

Run-time exceptions, referred to as ''contingencies'', are captured by the Object Program Error Handler (OPEH), which can produce a report (equivalent to a [[stack trace]]), either interactively or written to a journal.

===OMF===<!-- "Object Module Format" redirects to this section -->
{{SeeAlso|Intel Object Module Format}}
Compiled object code is maintained in a format called OMF (Object Module Format), which is both the compiler output and the format used by the loader.  Various compilers are available, as well as utilities, notably the Collector, which links the code in several OMF modules into a single module, for more efficient loading at run-time, and the Module Amender, which allows patching of the instructions in an OMF module to fix bugs, using assembly language syntax.

===SCL===
The command language for VME is known as SCL (System Control Language).

This is much more recognizably a typed [[high-level programming language]] than the job control or shell languages found in most other operating systems: it can be likened to scripting languages such as [[JavaScript]], though its surface syntax is derived from [[Algol 68]].

SCL is designed to allow both line-at-a-time interactive use from a console or from a [[shell script|command file]], and creation of executable scripts or programs (when the language is compiled into object module format in the same way as any other VME programming language). The declaration of a procedure within SCL also acts as the definition of a simple form or template allowing the procedure to be invoked from an interactive terminal, with fields validated according to the data types of the underlying procedure parameters or using the default procedure parameter values.

The built-in command vocabulary uses a consistent naming convention with an imperative verb followed by a noun: for example DELETE_FILE or DISPLAY_LIBRARY_DETAILS. The command can be written in full, or in an abbreviated form that combines standard abbreviations for the verb and noun: for example XF (X for DELETE, F for FILE) or DLBD (D for DISPLAY, LB for LIBRARY, D for DETAILS).

SCL is block-structured, with begin/end blocks serving the dual and complementary roles of defining the lexical scope of variable declarations, and defining the points at which resources acquired from the operating system should be released. Variables in the language (which are accessible from applications in the form of [[environment variable]]s) can have a number of simple types such as strings, superstrings (sequences of strings), booleans, and integers, and are also used to contain references to system resources such as files and network connections.

It is possible to "disassemble" an SCL program from OMF back into SCL source code using the READ_SCL (or RSCL) command. However the output is not always perfect, and will often include errors that would stop re-compilation without user intervention.

A simple code example can be seen on the [[99 bottles of beer]] website.<ref>[http://99-bottles-of-beer.net/language-scl-848.html SCL code example on the 99 bottles of beer website]</ref>

A more realistic example, where SCL is used to compile a program written in [[S3 (programming language)|S3]], is shown below. This example is taken from the [[Columbia University]] Archive of implementations of [[Kermit (protocol)|Kermit]].<ref>{{cite web
|url=http://www.columbia.edu/kermit/archive
|publisher=Columbia University's Kermit Project
|title=Kermit Software Source Code Archive
|date=22 Aug 2011
|access-date=1 March 2013
}}</ref>

<pre>
BEGIN
   WHENEVER
      RESULT GT 0 +_
      THEN        +_
         SEND_RESULT_MESSAGE (RES = RESULT,
                              ACT = "QUIT()")
   FI
 
   INT KMT_SRC, KMT_OMF, KMT_REL
 
   ASSIGN_LIBRARY (NAM = KERMIT.SOURCE,
                   LNA = KMT_SRC)
   ASSIGN_LIBRARY (NAM = KERMIT.OMF,
                   LNA = KMT_OMF)
   ASSIGN_LIBRARY (NAM = KERMIT.REL,
                   LNA = KMT_REL)
 
   BEGIN
      DELETE_FILE (NAM = *KMT_OMF.KMT_DATA_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_DH_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_EH_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_FH_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_HELP_MTM(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_MAIN_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_PH_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_PP_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_SP_MODULE(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_SP_MTM(101))
      DELETE_FILE (NAM = *KMT_OMF.KMT_UI_MODULE(101))
 
      DELETE_FILE (NAM = *KMT_REL.KERMIT(101))
      DELETE_FILE (NAM = *KMT_REL.KERMIT_MODULE(101))
   END
 
   S3_COMPILE_DEFAULTS (LIS = OBJECT & XREF,
                        DIS = ERRORLINES)
 
   S3_COMPILE (INP = *KMT_SRC.KMT_DATA_MODULE(101),
               OMF = *KMT_OMF.KMT_DATA_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_DH_MODULE(101),
               OMF = *KMT_OMF.KMT_DH_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_EH_MODULE(101),
               OMF = *KMT_OMF.KMT_EH_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_FH_MODULE(101),
               OMF = *KMT_OMF.KMT_FH_MODULE(101))
 
   NEW_MESSAGE_TEXT_MODULE (CON = *KMT_SRC.KMT_HELP_MTM(101),
                            OMF = *KMT_OMF.KMT_HELP_MTM(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_MAIN_MODULE(101),
               OMF = *KMT_OMF.KMT_MAIN_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_PH_MODULE(101),
               OMF = *KMT_OMF.KMT_PH_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_PP_MODULE(101),
               OMF = *KMT_OMF.KMT_PP_MODULE(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_SP_MODULE(101),
               OMF = *KMT_OMF.KMT_SP_MODULE(101))
 
   NEW_MESSAGE_TEXT_MODULE (CON = *KMT_SRC.KMT_SP_MTM(101),
                            OMF = *KMT_OMF.KMT_SP_MTM(101))
 
   S3_COMPILE (INP = *KMT_SRC.KMT_UI_MODULE(101),
               OMF = *KMT_OMF.KMT_UI_MODULE(101))
 
   COLLECT ()
----
      INPUT(*KMT_OMF.KMT_DATA_MODULE(101)      &
            *KMT_OMF.KMT_DH_MODULE(101)        &
            *KMT_OMF.KMT_EH_MODULE(101)        &
            *KMT_OMF.KMT_FH_MODULE(101)        &
            *KMT_OMF.KMT_HELP_MTM(101)         &
            *KMT_OMF.KMT_MAIN_MODULE(101)      &
            *KMT_OMF.KMT_PH_MODULE(101)        &
            *KMT_OMF.KMT_PP_MODULE(101)        &
            *KMT_OMF.KMT_SP_MODULE(101)        &
            *KMT_OMF.KMT_SP_MTM(101)           &
            *KMT_OMF.KMT_UI_MODULE(101))
      NEWMODULE(*KMT_REL.KERMIT_MODULE(101))
      SUPPRESS
      RETAIN(KERMIT_THE_FROG)
      LISTMODULE
      PERFORM
++++
 
COMPILE_SCL (INP = *KMT_SRC.KERMIT(101),
             OUT = *KMT_REL.KERMIT(101),
             COD = NOTIFWARNINGS,
             OPT = FIL)
 
END
</pre>

Commands illustrated in this fragment include WHENEVER (declares error handling policy), ASSIGN_LIBRARY (binds a local name for a file directory), DELETE_FILE (Makes a permanent file temporary, and it is then deleted at the END of the block), S3_COMPILE (compiles a program written in S3: this command breaks the usual verb-noun convention), NEW_MESSAGE_TEXT_MODULE (creates a module containing parameterized error messages suitable for localization) and COMPILE_SCL, which compiles an SCL program into object code.

The COLLECT command combines different object code modules into a single module, and is driven by its own local command file which is incorporated inline in the SCL between the delimiters "----" and "++++". The sub-commands INPUT and NEWMODULE identify the names of the input and output modules; SUPPRESS and RETAIN determine the external visibility of named procedures within the collected module; and LISTMODULE requests a report describing the output module.

Note that "." is used to separate the parts of a hierarchic file name. A leading asterisk denotes a local name for a library, bound using the ASSIGN_LIBRARY command. The number in parentheses after a file name is a generation number. The operating system associates a generation number with every file, and requests for a file get the latest generation unless specified otherwise. Creating a new file will by default create the next generation and leave the previous generation intact; this program however is deliberately choosing to create generation 101, to identify a public release.

===Enhanced security variants===
As a result of [[International Computers Limited|ICL's]] heavy involvement with delivery of computer services to the UK Public Sector, in particular those with special security requirements such as [[OPCON CCIS]], it was an early entrant into the market for [[Information Security|Secure Systems]].

VME formed a core of ICL's activities in the Secure Systems arena.  It had the advantage that as the last large-scale operating system ever designed, and one built from scratch, its underlying architecture encompassed many of the primitives needed to develop a Secure System, in particular the hardware assisted Access Control Registers (ACR) to limit to privileges that could be taken by any process (including Users).

This led to the UK Government's Central Computing and Telecommunications Agency ([[Central Computer and Telecommunications Agency|CCTA]]) funding ''Project Spaceman'' in the mid 1980s for ICL Defence Technology Centre (DTC) to develop an enhanced security variant of VME.<ref name="aldrich2022">{{ cite journal | url=https://www.tandfonline.com/doi/full/10.1080/02684527.2022.2139342 | title=Project Spaceman: Early British Computer Security and Automatic Data Processing | journal=Intelligence and National Security | last1=Aldrich | first1=Richard J. | last2=Work | first2=J. D. | date=2022 | access-date=25 June 2024 | pages=525–537 | volume=38 | issue=4 | doi=10.1080/02684527.2022.2139342 }}</ref> ICL launched this as a pair of complementary products, with the commercial release being called High Security Option (HSO), and the public sector release, including Government Furnished Encryption (GFE) technologies, being called Government Security Option (GSO).

HSO and GSO were formally tested under the [[Government Communications Headquarters|CESG]] UK (Security) Evaluation Scheme, one of the predecessors to [[ITSEC]] and [[Common Criteria]], and in doing so became the first mainstream operating system to be formally Certified.

===Unix and open systems interoperability===

ICL had originally announced a hosted Unix facility for VME in 1985, with availability and support for strategic applications to arrive within eighteen months.<ref name="computerworld19851014_icl">{{ cite magazine | url=https://archive.org/details/sim_computerworld_1985-10-14_19_41/page/n31/mode/2up | title=ICL banks on open systems strategy | magazine=Computerworld | date=14 October 1985 | access-date=3 June 2024 | pages=30–31 }}</ref> This facility, supporting [[UNIX System V#SVR1|SVR1]], was reportedly in "field trials" and was to be upgraded to [[UNIX System V#SVR2|SVR2]] prior to a general release in the summer of 1987.<ref name="unigramx19860927_icl">{{ cite news | url=https://archive.org/details/unigram_x_1986_0034_0058/page/26/mode/1up | title=Unix under VME Now out on Field Trials | work=Unigram/X | date=27 September 1986 | access-date=22 July 2024 | pages=4 }}</ref> Limited availability was then announced to existing VME customers, with others being guided towards ICL's Clan range of Unix departmental systems.<ref name="unigramx19870627_icl">{{ cite news | url=https://archive.org/details/UnigramX1987109-159/page/n150/mode/1up | title=ICL Sets Unix under VME for September | work=Unigram/X | date=27 June 1987 | access-date=22 July 2024 | pages=1 }}</ref>

In October 1987, ICL made the SV221 release of VME available with support for running SVR2 as a VME Unix System guest.<ref name="unigramx19871003_icl">{{ cite news | url=https://archive.org/details/UnigramX1987109-159/page/n229/mode/1up | title=ICL Guests Unix under New VME Release, Adds Cut-Down 39/80 Mainframe Models | work=Unigram/X | date=3 October 1987 | access-date=22 July 2024 | pages=2 }}</ref> This implementation, described as an "unmarketed" product also known as VNS, informed the design of VME/X, a largely new implementation that was itself released in 1991 and recognised as XPG3 compliant, with XPG4 base 1 compliance following in 1992.<ref name="icl199305_coates"/>{{rp|pages=489–490}} ICL's OpenVME promotional material noted that VME had been the first non-Unix operating system to gain XPG3 compliance, and the first operating system of any kind to gain XPG4 base compliance.<ref name="iclopenvme1994">{{ cite book | url=http://www.1000bit.it/ad/bro/icl/icl-openvme-thewayforward.pdf | title=OpenVME the way forward | publisher=International Computers Limited | date=1994 | access-date=6 December 2024 | pages=2 }}</ref>

In 1995, ICL added support for the [[Internet protocol suite]] in the form of its UNIX Interworking Option for OpenVME, featuring implementations of TCP/IP, UDP/IP and support for the [[File Transfer Protocol]], [[Telnet]] and [[Network File System]] (NFS) protocols. The NFS functionality included a server that enabled portions of the OpenVME filestore to be served to NFS clients, and the Telnet functionality allowed users on an OpenVME system to access Unix hosts, also supporting the provision of a login facility on OpenVME for remote users using the protocol. Alongside the [[Berkeley sockets]] programming interface, already widely used by Unix applications, the product also offered the [[X/Open Transport Interface]] for protocol independence and to support the [[OSI protocols]] customarily used by VME software.<ref name="icltcp1995">{{ cite book | url=http://www.1000bit.it/ad/bro/icl/tcpovme.pdf | title=OpenVME UNIX Interworking Option | publisher=International Computers Limited | date=1995 | access-date=7 December 2024 | pages=2–3 }}</ref>

===Series 39===
The [[ICL Series 39|Series 39]] range introduced Nodal Architecture, a novel implementation of [[distributed shared memory]] that can be seen as a hybrid of a [[multiprocessor]] system and a [[computer cluster|cluster]] design. Each machine consists of a number of [[node (networking)|nodes]], and each node contains its own order-code processor (CPU) and main memory. Virtual machines are typically located (at any one time) on one node, but have the capability to run on any node and to be relocated from one node to another. Discs and other peripherals are shared between nodes. Nodes are connected using a high-speed optical bus, which is used to provide applications with a virtual shared memory. Memory segments that are marked as shared (public or global segments) are replicated to each node, with updates being broadcast over the inter-node network. Processes which use unshared memory segments (nodal or local) run in complete isolation from other nodes and processes.
<!-- if we're going to talk about public/global/nodal/local segments, we ought to explain them. Is this detail necessary? - MHK The nodal segments approach was leading edge and perhaps novel at the time, and would be worth describing I think - RW -->