OS 2200 is the operating system for the Unisys ClearPath Dorado mainframe system. The OS 2200 operating system kernel is lineage descendant Exec 8 for UNIVAC 1108. Documentation and other information about the current and past Unisys systems can be found on the Unisys public support website.
View the Unisys 2200 Series system architecture for descriptions of machine architecture and its relation to the OS 2200 operating system.
Video OS 2200
History
There were previously 1100 systems going back to 1101 in 1951, but the 1108 was the first Series 1100 computer designed for efficient multiprogramming and multiprocessing support. Along with this new hardware comes the operating system Exec 8 (Executive System for 1108).
The UNIVAC 1108 computer was announced in 1964 and shipped in late 1965. The first 1108 computers used Exec I and Exec II, which had been developed for UNIVAC 1107. However, UNIVAC plans to offer a symmetric multiprocessor version of 1108 with up to four previous processors and operating systems true basic monitor ) is not designed for it, although they support limited multiprogramming.
When the UNIVAC 1110 was introduced in 1972, the name of the operating system was changed to OS 1100 to reflect its support for a wider system. The name of OS 1100 was retained until 1988 with the introduction of the Sperry Series 2200 as the sequel to the 1100 Series when its name was changed to OS 2200. Since then, Series 2200 became Unisys ClearPath IX Series and then Unisys ClearPath Dorado Series, but the operating system retains the name of OS 2200.
The company name and the name of the product also change over time. Engineering Research Associates (ERA) of Saint Paul was acquired by Remington Rand Corporation. Remington Rand also acquired the Eckert-Mauchly Computer Corporation of Philadelphia which later built the UNIVAC computer. Both were merged into the UNIVAC Remington Rand division under the direction of William Norris. William Norris has become one of the founders of ERA and then left Remington Rand to start Control Data Corporation. UNIVAC Division Remington Rand Corporation became the UNIVAC division of Sperry Rand Corporation after Remington Rand merged with Sperry Corporation. In the 1970s, Sperry Rand embarked on a corporate identity program that changed its name to Sperry Corporation and all division names to start with Sperry, resulting in the computer systems division becoming Sperry UNIVAC. Then the names of the divisions were dropped and everything became Sperry.
The operating system kernel is still referred to as "Exec" by most Unisys and customer personnel. However, when Unisys began releasing a series of products tested together as a system-based release, which was then called "ClearPath OS 2200 Release n ", the term OS 2200 was changed to refer to the entire range of products in system and other releases, such as BIS, released asynchronously to the Dorado hardware platform.
In 1986 Burroughs and the Sperry company merged into Unisys (which some long been said by the 2200 Series clients of "UNIVAC Is Still Your Supplier"). The major mainframe product lines of both companies continue in development including the MCP Operating System from Burroughs and OS 2200 from Sperry.
In 2016 Unisys creates a virtual Microsoft Windows OS2200 version available at no cost for educational and recreational purposes.
Exec 8
EXEC 8 (sometimes referred to as EXEC VIII) is a UNIVAC operating system developed for UNIVAC 1108 in 1964. It combines the best features of the previous operating system, EXEC I and EXEC II, used in UNIVAC 1107. EXEC 8 is one the first commercially successful multiprocessing operating system. It supports simultaneous mixed workloads consisting of batches, time divisions and real time. The one-file system has a flat naming structure in many drums and spindles. It also supports a well-received transaction processing system.
Previous systems are all real-mode systems without hardware support for the protection and separation of programs and operating systems. Although there is support for multiprogramming in the previous system, it is limited to running a single user job along with some well known behavioral support functions, such as card readers, printers, and blow card spoolers.
The Exec 8 operating system was designed from the beginning to be a multiprogramming and multiprocessing operating system because 1108 was designed to have up to four CPUs. Memory and mass storage are major system constraints. While the Series 1100 is envisaged as a more general market targeting, extreme real time processing is a key requirement.
The specifications for Exec 8 were compiled by December 1964 as the Programmer Reference Manual of the introduction (user manual) and work began in May 1965.
Exec 8 begins as a real-time operating system with most early use in common scientific and engineering work, but is also used in message redirection, process control, simulation, and missile firing control. It is designed to run on systems that often have only 128K words (576K bytes - less than the maximum memory size for IBM PC XT), and is focused on real-time and batch processing. Although the initial release rate was successful at 128KW, the enhancement of functionality in subsequent releases made it untenable, as it did not provide enough space for programs of useful size. The maximum memory capacity of 1108 is 256KW (1,148 KB) so that efficient memory usage is the most important constraint since core memory is the most expensive part of the system.
Mass storage consists of a 6 foot long rotating drum that holds 256KW (in FH-432) up to 2MW (in FH-1782). The highest mass storage capacity is the FASTRAND drum, which has 22 MW (99 MB). File fragmentation is handled by a process called "file storage", which is generally done once per day, at night. It involves scrolling all files to tape, reinitializing the drum file system, then reading the file again.
With heavy memory constraints and real-time usage, storing only one copy of the code loaded to the core is a requirement. Since 1108 is designed for multitasking, the system is completely "reentrant" (thread safe). Each reentrant module accesses the program data through a single "memory base address", which is different for each instance of data being run. Changing the execution context can be done in one instruction by simply setting a different base address in a register. The system uses fine grained locking to protect the shared data structure. Executives, compilers, utilities, and even sophisticated user applications may have multiple copies running concurrently written so that their code can be shared. It takes just loading one copy into memory, saving the space and time it takes to load the code.
Another reason for separating code and data into different load entities is that the memory is implemented as two independent banks (separate physical cabinets) called IBANK and DBANK (instructions and data). Each has its own access point, so the CPU can read both banks simultaneously. By loading executable code into one memory bank and data to another, the processing time of many programs can be nearly half.
The reentrant code must be secure (only execution); self-modifying code is not allowed. For other programs, modifying executable code during processing time is still an acceptable programming technique at the time of the 1100 series computer, but users are encouraged not to do so due to striking performance. The security benefits are mentioned but are not much appreciated because hacking most of the 1100 series apps will not benefit anyone, and because of a few nasty hackers later.
Exec 8 is primarily a batch processing system that delivers apps (called "tasks") excellent control of the CPU scheduling priority for its thread (called "activity"). The process of processor redirection is preemptive, with higher priority threads getting processor controls that currently run the lowest priority threads of each program. Except in realtime system, even the lowest priority task gets processor time. It is a multiprogramming and multiprocessing operating system with fully symmetric processor management. The built-in test-and-set instruction in hardware enables very efficient and smooth locking in both the OS and in multi-threaded applications.
In Exec 8, jobs are organized into jobs, called "runs," which are scheduled based on their priorities and the need for lockable resources such as Uniservo tape drives or Fastrand drum files. The syntax of the control language uses the symbol "@" (called Univac "master space") as a symbol of the introduction of control statements. It is immediately followed by a command or program name, then any commas and options change. After a space character, the rest of the statement is different for a particular command. The command to compile the FORTRAN program will look like "@FOR [, options] sourcefile, objectfile". The input data for the application can be read from a file (generally a card image), or immediately follow the @ command in the run stream. All lines until the sentinel command "@END" is assumed to be input data, so forgetting to include it causes the compiler to interpret the next command as program data. For this reason, it's better to process the data in a file than to include it in the run stream.
In 1968, work began by adding time-sharing capabilities to Exec 8. It was delivered with a level 23 from executives in 1969. Time sharing (called demand mode) has the same capabilities as batch and real time processes. Everything that can be done in batch can be done from ASCII terminal. In demand mode, the workflow I/O is attached to the terminal handler rather than the image file of the card (input) and spool (output). The same run control language is used for both. Several years later, more specific time-sharing orders are added, and some control statements can be issued asynchronously for immediate processing, even when neither the executives nor the running programs expect data. The commands, which can be entered only from the terminal, start with "@@". Because they can be done without stopping other ongoing work from the same terminal, they are called transparent commands. At first this is just a statement to kill the current program or redirect the terminal output to the file, but finally, almost all control statements are allowed to "immediately."
Both batch and query runs end with the @FIN statement, and if the user queries end the session while the run is active, Exec automatically stops the process without requiring @FIN.
Communication software
Transaction processing capabilities were developed in the late 1960s as a joint project with United Airlines and later refined in other joint projects with Air Canada. This capability was fully integrated into the operating system in 1972 and became the basis of much of the future growth of the Series 1100. Initial users controlled the channels of communication directly from within their real time program. Part of the development of transaction processing includes a communication messaging system that governs the communication path and message presented to Exec 8 for scheduled transactions. It transfers all the management and protocols of the physical line of low-level communication from the application and into the CMS 1100 application.
CMS 1100 itself runs as a real time multi-threaded program with privileges to gain control of communication lines and send transactional messages for scheduling. This led to the idea in Exec 8 that applications of any nature need to be carefully controlled to ensure that they can not cause integrity problems. Security is of course a concern, but in the early days the reliability and integrity of the system is a much bigger problem. The system is still mainly batch and transaction processing and there is little chance that anyone can install unauthorized code on the system. The CMS 1100 then adds the ability to be the interface for the request terminal as well as the transaction terminal so that the terminal can be used for both and the initial terminal driver can be removed from Exec. The CMS 1100 was later replaced by a combination of CPComm (ClearPath Enterprise Servers Communications Platform) and SILAS (System Interface for Legacy Application Systems). For the Intel-based Dorado server model, lower level communications are transferred to firmware, with upper levels handled by SILAS and CPCommOS (ClearPath Enterprise Servers Communications Platform for Open Systems).
The Exec
The Exec contains all the code in the system that is allowed to run at the highest privilege level. There is no mechanism for other codes to be promoted to that privilege level.
The Exec is responsible for managing system hardware, scheduling and managing work, and communicating with operators and administrators.
On Release 16.0, Exec is level 49R2 (49.70.5). The internal system level uses three-part numbers such as 21.92.42 (which is the first widely used production system even though previous releases were used in production on a number of sites). The first part of the number is the primary level and shows a new version of Exec with all the previous updates that are integrated into the new base version. This is a rare process and occurs at an interval of years. The second part of the number shows the update version to the primary level and often occurs several times per week. When a decision is made to freeze feature content and prepare for release, the third part starts playing and shows a pre-release level version when minor feature improvements and updates are applied. Along with setting up a level for release, updates on "main line" continue as engineers integrate changes in preparation for future releases. Over the years the official release rate is a full three-part number. Later releases were named only 44R1, 44R2, 49R2, and so on even though the three-part number is still used internally.
Doing work
The Exec is the heart of a real time multi-threaded batch processing system. Everything has been built around that model. The Exec itself is largely structured as a real time program. Functions performed as Services in Windows or Daemons in Linux and UNIX are implemented as activities in the Exec program or as batches that always run in the background.
The time division (known as request mode) and transaction processing are implemented as special batch cases. One result is that there are some restrictions on what a time-share user or transaction program can do. There are many warnings for transaction program authors that they will not be happy with performance if for example they request a tape mount, but are allowed.
The largest work unit is "Run." This is taken from the factory "factory" factory terminology and is generally equivalent to work or sessions on other systems. J Run is determined by "run stream". Run flow is a sequence of control statements that represent steps to take. They may include file handling, program execution, and control branches. A Run batch is usually saved as a file and is scheduled by the "Start" command from within another Run or by operator. The Running time share starts with entering from the time share terminal and entering the @RUN command. Often the @RUN statement and the second control statement (often @ADD or program execution) are generated automatically based on the user profile. The security authorization is validated based on the authenticated user-id and other information provided on the Run control statement.
Transaction is a special case. There is actually no control statement, but the internal data structure of a run is created. This allows Exec to link the same security, accounting, debugging, etc mechanisms to the transaction program. Generally security profiles are cached in memory when user transactions are authenticated and copied from user session data to transaction run status when transaction is scheduled. Because every transaction instance is essentially Run, accounting, logging, and error handling are all encapsulated by the Run mechanism.
Batch
The batch (Run) job is marked by having a runstream (job control language statement) stored in the file. The batch job always contains the @RUN statement as the first recording in the file. This statement assigns the run name, defines the priority, and determines the maximum number of SUPS (Standard Processing Unit) jobs expected to be used. The work starts from some other work with the @START control statement or by the operator via the ST key. The system can be configured to automatically issue the @START statement for some work on boot. This work serves the purpose of initializing, restoring, and background functionality.
All fields in the @RUN statement can be overwritten by the corresponding field in the @START statement. Except when @START is executed by a privileged user, userid and other security status are always taken from runs that do @START.
There are two priority areas in the @RUN statement. One is used to define the backlog priority. There are 26 priority backlog levels (A - Z). The Exec has a set maximum number of open batch operations. When these levels are reached, the job is then selected from the backlog queue in priority order. In the priority selection is usually FIFO. However, Exec pre-scans the job control statement until the first program execution looks for the file name and reel number. If the job is about to stop because some of the required resources are not available, it may be skipped to start another job at the same priority level.
The second priority level defines the group of processor resource execution. In general, higher group execution priorities usually get more processor time.
While the OS 2200 job control language does not support full programability, it allows dynamic addition of the control language sequence via the @ADD control statement. Files to add may be created by the same job immediately before adding them. @ADD and most other control statements can also be sent from within the program that is running through the API. Additional programability is available indirectly through the use of Symbolic Stream Generator (SSG). SSG is a programming language for manipulating and creating text files from input parameters and system information. This is greatly used for configuration management (making) processing and other functions where text images must be programmed. The resulting output can be "@ADD" in the same run so it provides an indirect programmable runstream.
Command operators are available to change both the backlog and priority operations. Because all operator commands are available by API for privileged users, these can be automated or controlled by remote administrators.
The deadline is a special batch case. A deadline looks like another batch of batch except that the deadline time is specified on the @RUN or @START control statement. The timeout deadline is used in conjunction with the maximum SUPS (estimated time) on the control statement. Deadline jobs run on normal batch priorities unless or until it appears that it could lose its deadline time. The more the mismatch between the time to the time limit and the remaining SUPS, the higher the priority. While deadlines can not completely shut down transactions and have no effect on real time, it can effectively shut off most other processing in the system if necessary to achieve its objectives.
Request
OS 2200 session called time-sharing request (from "on demand") runs. They use the same control language as batches that run with some additions known as "direct" control statements. Direct control statements using "@@" sentinel indicating that they must be run immediately even if the program is running. While they can be used to create or assign files, most importantly allow the user a request for errors stopping the running program or even sending them a signal.
Transactions
Transactions are executed as run but without control statements that are stored or sent. Conversely, when a message is received from a session defined as a transaction session, it is scanned to determine the queue for the transaction to be placed. This is usually determined by the first character of the message but the user-written scanner can be added.
The communications manager, capable of handling up to 250,000 active sessions, retrieving incoming transaction messages and forwarding them to the message queuing software. It can handle unlimited queuing messages using message queuing architecture. Calls are made to the Transaction Interface Pack (TIP) API in the operating system to queue up transactions at the appropriate queue point. Each queue point identifies the priority and concurrency level of the work and associated transaction program to be executed.
The transaction program scheduling tree allows the client to assign relative usage to the program group of transactions. The concurrency limit avoids one type of work that dominates the system to the exclusion of other work and avoids creating excessive commitment to resources. Up to 4094 nodes can be created in the tree.
- The maximum concurrency specified for each node in the tree
- The concurrency of the higher nodes restricts the total dependency of the dependent node
- The concurrency of the highest node limits the system concurrency
Priorities (0 through 63) and concurrency levels (1 through 2047) can be specified for each transaction program.
The highest priority transaction is selected for scheduling unless limited by concurrency policies that apply to higher nodes and nodes.
Real time
Real time is not another type of run. Instead it is a set of priority levels that any activity can solicit. Real time is usually used by long-running batch programs, such as OS 2200 CPComm communications manager, but not limited to that.
There are 36 real-time priority levels available by the API for the applications to use. Users and accounts must have the privilege to use real-time priority. It's up to sites to control how their apps use priority levels. Real-time prioritization really dominates all lower priorities so it is possible for real-time programs that are not appropriate to bind one or more processors.
Real-time priority applies to individual activities (threads) so that a program can perform real time and non-real time threads that are executed at the same time.
CPU Delivery
Once the run has started, gaining access to the processor controls the rate of its development. The core of Exec is Dispatcher that manages all the processors.
The Exec supports up to 4095 shipping priorities even though most sites only set a fraction of them. The two highest "priorities" can not be changed. They are recognition of certain types of processing that should be allowed to continue on the processor they start until they voluntarily give up control. An interrupt termination occurs when an interrupt arrives or in some special cases when another Exec code prevents all interrupts (to change some data that can also be accessed by an interrupt handler).
Interlocks are used by interrupt post processing routines that must be run on the same physical processor or should not be interrupted. The Dispatcher, I/O completion, and I/O initiation are some examples. All keys used by these two priorities are shortcut keys because the only way they can be set by others is on other processors and the design requires that they only be tuned for a very short sequence of instructions.
High Exec Priority is used by command handler operators and some other functions that may have to run even when real-time programs have control. They are expected to use only a very short time. If they need more time, they have to queue up the job to be processed by the Low Exec activity.
Real-time activity has unlimited quantum processors and runs without a switch unless interrupted by higher real-time activity or higher High Exec activity. Real Time Activities are given control of all available processors that run lower priorities. Interrupts are sent between processors when necessary to ensure immediate availability. Real time is used by customers to fly missiles, run simulators, and other functions that require immediate response.
Priority transactions can be handled in two ways as defined by the site. They may be some sort of lower real-time priority because only priority issues and quantum sizes are essentially unlimited. This is suitable for very short transactions such as airline reservations; if one of the loops is due to programming error, Exec will stop it when it reaches the maximum configured time is very small. Another form allows Exec to vary the priorities within the range to optimize the use of system resources. This approach gives higher priority and shorter time to programs that are of limited I/O priority and lower but longer time slices for those who are computing. The Exec dynamically adjusts this priority based on behavior because programs often behave in two directions at different times. This approach is suitable for longer-lived transactions such as database queries or airline price quotes.
Batches and requests always use dynamically-adjusted priorities. Programs that I/O are limited or are in conversation with time share users get higher priority but shorter chunks of time. More computation-oriented programs get lower priority and longer time.
The Exec has two additional mechanisms to optimize delivery. One is affinity-based delivery. If possible, Exec will run activities on the same processor as the last time to get the greatest benefit from the rest of the cached content. If it's not possible try to keep the activity on the "nearest" processor from the point of view of cache and memory access time. The second is the "justice" policy mechanism. This site can determine the relative percentage of resources to be allocated for each transaction, request and batch. In transactions and batches there is a priority group that can better indicate what percentage of their group time will be allocated for priority. This ensures that transactions can not so dominate the system so no batch work is done. In various priority groupings, this ensures that some progress can be guaranteed for each group (unless the group percentage is zero). This "fairness" algorithm only comes into play when the processor is very busy, but the OS 2200 system is often run with all the processors near 100% used.
Measurements
OS 2200 supports several models for system performance management. Customers can purchase certain fixed performance levels, and Exec will monitor the use of processors to ensure that performance does not exceed that level. Customers may also purchase additional performance either temporarily or permanently until the system's full capacity if their workload increases or emergency needs it.
Recently the system has added meter usage capabilities. In this mode the full power of the system is always available to customers (although they administratively limit it). Use is accumulated for a month and then reported usage submitted to Unisys billing. Depending on the terms of a particular contract, the client may be billed for excessive use over some contract basis for the month or just a statement indicating that the total contracted usage has been reduced. The first form is like a mobile phone bill with potential charging for a few minutes. The latter is like buying a pre-paid phone card.
File system
OS 2200 does not have a hierarchical file system like most other operating systems. Instead it has a structured naming convention and the idea of ​​a container file called a program file.
Files in OS 2200 are simply containers that can be resolved either with offset words in files or by sector (28-word units) offsets in files. 28 words is the historical unit of the initial mass storage device (drum FASTRAND) that can accommodate 64 such units per physical track. Nonetheless, it is a profound historical accident. Four units of 28 words or 112 words that occupy 504 bytes. With today's mass storage devices all using 512-byte physical records, the 2200 OS client almost all adopts a multiple of 112 words as the physical record size and database page size. I/O processor automatically adjusts for 504 & lt; - & gt; a 512-byte mapping adds 8 bytes of zeros to the writing and deletes them on the reading of each physical record. OS 2200 handles applications that use sizes other than a multiple of 112 words by unlimited reading of physical records that contain and rewrite unchanged and changed sections with chaining data. The special locking function ensures inseparability even when there are device errors and across multiple systems in a cluster.
The file format and other internal data structures are described in the Data Structure Programming Reference Guide . File name
Since Exec-8, the file name has taken the form: Qualifier * Filename (f-cycle) (for example, "PERSONNEL * EMPLOYEES (1)"). Qualification and filename are twelve-character strings used to create whatever naming structure the client wants. F-cycles are numbers from 0 to 999 that allow multiple generations of files. These can be referenced by relative numbers: (1) the next or new cycle, (-1) the previous cycle, (0) the current cycle. Leaving the default dead cycle to the current cycle. Batch production runs that create a new generation of files use this approach. The numbers wrap up after 999. Only 32 consecutive number of consecutive cycles may exist at a time. Make the deletion (1) (-31).
Any file can be used as a program file. Program files contain elements that generally act as files. Naming element is Qualifier * Filename (f-cycle).Element/version (e-cycle) (for example, "PERSONNEL * PROGRAMS.TAXCALC/2008"). Elements and versions are names of twelve characters used in whatever way the user wants. E-cycle is similar to f-cycle in this case is the generation number but without restriction for 32 concurrent cycles and the limit is 256K cycle. However, the e-cycle applies only to text elements and each line in the text element is marked with the number of cycles in which it is inserted and deleted. Elements also have type and sub-type. The most commonly used types are "text" and "object." If the default type does not match, select the appropriate type option. Text elements also have sub-types that typically represent programming languages ​​(eg, "ASM", "C", "COB", "FOR"). The default element name of a file object is the same as the text file from which it was created.
The object element can be executed if it is the main program or associated with other object elements including the main program. Links may be static or dynamic. The main program can be run without pre-linking provided that all necessary sub-programs exist in the same program file, is a system library, otherwise known. Rules can be included in the program files to direct dynamic link searches for unresolved references. Linkers can also be used to simultaneously connect multiple object modules simultaneously to form a new object module that contains all the instructions, data, and other information in the original object module.
Omnibus elements can be used as data by applications or can serve to store structured information for system applications and utilities. There is no assumption structure for omnibus elements.
For compatibility with the initial programming model (base mode), there is an element of relocation and absolute types. The relocatable element is the output of the basic mode compiler. They can be combined with a basic static mode linker (@MAP - collector) to form an executable "absolute" element.
File management
OS 2200 implements a fully virtual file system. Files can be allocated anywhere in all and all mass storage devices. Mass storage is treated as a large space pool similar to the way virtual memory is managed. While the adjacent space is allocated where possible, mass storage is treated as a set of 8KB size pages and files can be placed in many areas of the same or different devices as required. Dynamic file extensions attempt to allocate space adjacent to previous allocations, but will find space wherever available. In fact, files do not need to be present in mass storage to use. The Exec and file backup systems are fully integrated. When the backup file is created, the reel tape (s) number is recorded in the file directory. If space becomes short on mass storage, some files are only marked as "unloaded" if they have a current backup copy, and their space is available for use. If enough space can not be found that way, the backup starts.
Any references to disassembled files will be queued while the files are copied back to mass storage. The entire system is automated and generally transparent to the user.
Access method
In general, Exec does not provide access methods. File is just a container. Access method is provided by system run time language and database manager. The only exception is the fixed block access method provided for high-volume transaction processing. It has much less overhead than the database manager, but does not participate in all locking, grouping, and recovery mechanisms.
Packages that are removable
When clients want more explicit control over file locations, they can use the concept of "removable packets". At one time it actually represents physically transferable disk packets, and the operating system will automatically generate packet-to-operator requests as needed.
Today they are still used to place files, usually database files or transaction files, on one or more disk volumes. The file may still reach many disk volumes, and now the list of volume names is given when the file is created. The files in that volume group are still backed up but are not subject to automatic virtual space management.
CIFS
OS 2200 also provides full implementation of Common Internet File System (CIFS). CIFS implements the SMB protocol used by Microsoft servers and Samba UNIX/Linux software. CIFS for ClearPath OS 2200 is file server and client file for other CIFS-compliant systems. This includes a desktop PC running Windows. CIFS supports SMB signing.
To maintain the security of OS 2200, CIFS for ClearPath OS 2200 provides two levels of protection. Firstly, OS 2200 files are not visible to the network until they have been declared as "shared" with CIFS commands. Certain privileges exist to control who can declare a section. The second level of control is that all access is still protected by OS 2200 security. Clients accessing OS 2200 via CIFS must be identified automatically via NTLM or Kerberos or they will be presented with a request for their 2200 user ID and password.
CIFS allows OS 2200 files to be presented in a hierarchical view. Normally qualification will appear as the highest level in the tree followed by the file name, element name, and version. Additionally, files can be stored on the OS 2200 server using the full Windows file name format. The Windows app will see OS 2200 as another file server. The OS 2200 application has an API available for reading and writing files that exist on other servers that are compatible with CIFS, such as Windows file servers, in the network. Text files are automatically converted to and from the internal format of OS 2200. Binary files must be understood by the application program.
The CIFSUT utility running under OS 2200 can exchange encrypted compression files with other software, such as WinZip.
Subsystem
The concept of subsystems and protected subsystems is very important for the design of OS 2200. Subsystems are very similar to.dll in Windows. These are codes and data that can be shared among all programs running on the system. On OS 2200, each subsystem has its own set of banks that are located in a separate section of address space that is not directly accessible to any user program. Instead of hardware and OS provides a "gate" which may be the target of the Call instructions. See Unisys 2200 Series system architecture for more information.
Database managers, running time libraries, messaging systems, and many other system functions are implemented as subsystems. Some subsystems, usually consisting of pure code, such as run time libraries, may be direct targets of the Call instructions without requiring a gateway. This subsystem runs in user program protection environment. Other subsystems, such as database managers, consist of code and data or privileged codes and can only be called through the gateway. This subsystem also has access control lists associated with it to control who can call them. More importantly, the gateway controls the specific visible point of entry, the protection environment in which the subsystem will run, and often the user-specific parameters that provide additional secure information about the caller.
Security
security B1
The OS 2200 security system is designed to protect data from unauthorized access, modification, or exposure. This includes the implementation of the DoD Orange Book B1 level specification. OS 2200 first received a successful B1 evaluation in September, 1989. The evaluation was maintained until 1994. After that, OS 2200 developers continued to follow the development and documentation practices required by B1 evaluation.
Center to system B1 is the concept of user and object. The user has an identity, permission level, compartment, and privileges. Objects require certain combinations of them for different types of access. The objects in OS 2200 consist of files, protected subsystems, devices, and band reels.
User session security profiles include user identity, permission level (0-63), compartment set, and permissible set of privileges. OS 2200 implements the Mandatory Access Control (MAC) and Discretionary Access Control (DAC) based on the Bell-La Padula model for confidentiality (unread, not written) and Biba integrity model (unread, no writing). To run to read or execute a file, the run execution completion rate must be greater than or equal to the file permission level, and the file permission level must be 0 or within the permission level range of the run; in addition, the run run compartment set must contain a set of file compartments. Because OS 2200 incorporates the requirements of the Bell-La Padula and Biba models, the completion rate of the run execution and the compartment set must match exactly the file that allows writing to a file or deleting it.
DAC associates an access control list with an object; the list identifies users and groups of users who have access and specifies the types of access allowed by users or groups (read, write, run, or delete).
Because the complete set of B1 controls is too tight for most environments, the system administrator can configure the server by selecting the controls that will be applied. A set of security levels from Fundamental Security through Security Level 3 serves as a starting point.
Security officer
Each OS 2200 system has one user designated as a security officer. On systems that are configured with basic security, only security personnel are allowed to perform certain tasks. On systems configured with higher levels of security, other trusted users may be allowed to perform some of these tasks.
OS 2200 provides a good security mechanism based on the principle of the least privilege. This principle requires that only minimum privileges are given as necessary to perform the required tasks. Thus, OS 2200 does not have the concept of a "Super User" role that any user can assume. Instead of using a large number of specific privileges that can be assigned separately for each user. Each privilege is associated with a particular authority.
File security
On systems configured with a security level of 1 or higher, the user who created the object is the owner of the object. The default is that the object is private to the user who created it, but may also be public or controlled by access control lists. The owner or security officer can create access control lists for that object.
On systems that are configured with basic security, files have no owner. Instead, they are made private for an account or project, or they are public. Access to them can be controlled by reading and writing keys.
Authentication
When users log into the system, they identify themselves and optionally select the permission level and the compartment set they will use for the session.
OS 2200 offers a flexible authentication system. Some authentication mechanisms are supported simultaneously. Authentication software written by client or third party can also be used. Standard authentication capabilities include:
- The user ID and password are retained in an encrypted file by OS 2200
- Authentication is performed by an external system such as Microsoft Windows using user id and password mechanisms
- NTLM
- Kerberos
- LDAP
The latter two allow the use of biometrics, smart cards, and other authentication mechanisms supported by the technology.
Encryption
OS 2200 provides encryption for data at rest through the Cipher API, a software subsystem that encrypts and decrypts caller data. The Cipher API also supports the use of hardware accelerator cards for bulk data encryption.
For Dorado-based CMOS servers, CPComm provides SSL/TLS encryption for data in transit. For Intel-based Dorado servers, SSL and TLS are provided by openSSL, which is included in the Dorado firmware. All Dorado servers support TLS levels 1.0 to 1.2, as well as SSLv3, but SSL is disabled by default due to vulnerabilities in the protocol.
Both the CPComm and the Cipher API use the CryptoLib encryption service, FIPS certified encryption software module. The AES and Triple DES algorithms are one of the algorithms implemented in CryptoLib.
The OS 2200 also supports an encrypted tape drive, which provides encryption for archive data.
Maps OS 2200
Clustering
The OS 2200 system can be grouped to achieve greater performance and availability than a single system. Up to 4 systems can be merged into database and cluster share files via shared disks. Hardware, XPC-L, provides coordination between systems by providing high-speed key managers for database and file access.
A clustered environment allows each system to have its own local files, databases, and apps group together with shared files and one or more groups of shared apps. Local files and databases are only accessed by one system. Shared files and databases must exist on disks that can be accessed simultaneously from all systems in the cluster.
XPC-L provides a communication path between systems for action coordination. It also provides a very fast lock engine. The connection to XPC-L is via a special I/O processor that operates with very low latency. The key manager in XPC-L provides all the necessary functions for key files and databases. This includes deadlock detection and the ability to free keys from failed applications.
XPC-L is implemented with two physical servers to create completely redundant configurations. Maintenance, including loading new versions of XPC-L firmware, can be performed on one server while the other continues to run. Failures, including physical damage to one server, do not stop the cluster, as all information is stored on both servers.
Operation and administration
Operation
Operating OS 2200 is built around active operators and one or more consoles. Each console is a terminal window, a section provided for fixed screens that are updated frequently with summary information about activities in the system.
The rest of the console is used as a scrolling event view. When a message is issued that requires an operator response, it is assigned a number from 0 to 9 and remains on the display until it is answered. Tape mount messages scroll with other messages but will be repeated every two minutes until the tape is installed.
The Sentinel operation is used for all OS 2200 operations. The OS 2200 console is just a window in the Sentinel Operations screen. There may be a lot of PC display you want. Remote operation is typical. The Sentinel operation supports a number of ClearPath, Windows, Linux, and UNIX systems.
Automatic action message database is released with the product. This database enables Sentinel Operations to recognize messages. Scripts can be written to automatically respond to messages that require a response, hide unwanted messages, translate them into other languages, create events, etc. Full dark room operation is used by some clients. At most they will have Operations Sentinel displayed in remote locations that monitor the system and make warnings when certain events occur.
Administration
The administration of the OS 2200 system is performed using a variety of tools, each specific to a specific area of ​​the system. For example, there are tools used to manage a transaction environment that allows new transaction programs to be installed, specifies all the necessary information about them, alters the queue structure, priorities, and concurrency levels, and so on.
Other tools specific to security personnel and enabling user creation, changing permissions allowed, changing system security settings, etc. , ,
Most of the tools have a graphical interface though some do not. All provide a saved file interface in which all actions are specified in the control stream. This allows scripting any and all administrative interfaces of the local site either, perhaps based on time of day or other events, or from remote sites. Unique privileges are required for each administrative region.
Application group
The application group is a logical construct consisting of an instance of the Universal Data System (UDS), an instance of the message queuing subsystem, and multiple series of transactions. Each app group has its own audit trail. OS 2200 supports a maximum of 16 groups of applications in a system.
The idea of ​​an app group corresponds to what is often called "app." That is, a set of programs and data representing some of the larger connected processing units. For example, an app group may represent an airline system. Other application groups may represent the company's financial system. Alternatively, the app group may represent the same instance of application and data model, as in a bank branch. What matters is that each app group has an environment, session, recovery, etc.
Application groups can be started, stopped and restored independently.
The app group does not have its own accounting and scheduling rules. Transactions in some application groups can share the same priority and have the priority inserted. This allows the site to control the relative priority of transactions across the system.
See also
- Unisys 2200 Series system architecture for information about hardware architecture.
- Unisys OS 2200 programming language for information about compilers and connectors OS 2200.
- Unisys OS 2200 databases for information about the OS 2200 database and database manager.
- Unisys OS 2200 communication for information about OS 2200 communication.
- Unisys OS 2200 distributed processing for information on processing that is distributed OS 2200.
Other locations of source material
The Unisys History Newsletter contains articles on the history of Unisys and computers. In addition to all Newsletters History of Unisys there is a link to other sites.
Most of Unisys's history files are in the Charles Babbage Institute at the University of Minnesota and at the Hagley Museum and Library in Delaware. The Charles Babbage Institute stores archives from the ERA, some early Remington Rand archives from Saint Paul, MN, and Burroughs archives. Hagley Museum and Library stores most of Sperry's archives.
References
Footnote
Source of the article : Wikipedia
0 Comments