Found the following article on the Internet. Copied here verbatim -- Tuesday, October 23, 1973 The Age, Page 20 The Age 250 Spencer Street Melbourne, Australia http://news.google.com/newspapers?id=spwQAAAAIBAJ&sjid=wZADAAAAIBAJ&pg=5116%2C5621234 Sperry Univac has strenghtened both its product range and market position with the announcement this week of its 90-60 and 90-70 series of computers, The 90-70 is simply the former 9700 series with semiconductor main storage. But the 90-60 is new from the ground up and pses a real threat to the leaders in the medium size computer market place. As with many recent releases, the makers claim significant cost savings over competing machines. In this case Univac claims that the 90-60 model, which costs about as much as IBM's 370-135, offers about 1.6 times the processor power than the IBM machine. All the 90-60 central processors work under microprogramme control and contain an interval time, storage protection register stacks, multiplexor, selector channel and floating point arithmetic. The microprogramming implements each instruction for the computer by a series of sub-routines instead of hard-wired logic. This gives the 90-60 the capacity to emulator another machine's logic processes. Emulation is a valuable capability to have in a machine because it allows a user to continue using his old programmes, written for another machine, on his new Univac. But the 90-60 spans a wide power range. The minimum main memory size is 131k while the maximum is 524k ann eight main memories have an access time of 350 nanoseconds and a cycle time of 600 nanoseconds for a four byte word. Registers: The processor register stack has 16 registers for supervisor functions and four registers for floating point arithmetic operations. The registers act as "inquiry counters" because they contain the value of the program relocation bases currently active. The 90-60 can also dynamically change the programme starting address, giving a flexible and efficient programme roll in, roll out ability. The supervisor puts the rolled in programme in any portion of the main storage by adjusting the associated relocation address. Univac has released a new operating system along with the 90-60. The new system, OS-7, is designed to make the most of the 90-60's capabilities, including multiprogramming. The OS-7 system automatically logs all perinent data displayed on the console so it can be printer. Gives each job account and project numbers and schedules and initiates jobs. Systems: It incorporates the integrated communications access method (ICAM) and two proprietary processing systems (IMS 90 and DMS-90). In addition, Univac will offer a wide variety of application programs including Unis, the Univac Industrial System, MCS, the management control system, and Newscomp, a newspaper production system with the ability to accept all text required for new classified and display copy. Univac says a small 90-60 system will rent for about $8000 a month and cost $420,000 to buy, while a typical large 90-60 system will rent for $18,000 a moneth and sell for $860,000. Deliveries of the 90-70 will start later this year while the first deliveries of the 90-60 will be made early in 1974. ---- VS/9 User Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1972 VS/9 Programmer Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1975 Retrieved from "http://en.wikipedia.org/wiki/VS/9" ---- Wikipedia is sustained by people like you. Please donate today.The Wikimedia Board of Trustees election has started. Please vote. [Hide] [Help us with translations!] VS/9 From Wikipedia, the free encyclopedia Jump to: navigation, search VS/9 was a computer operating system available for the Univac 90/60, 90/70 and 90/80 mainframe during the late 1960s through 1980s. It provided the capability to allow both interactive and batch operations on the same computer. Contents [hide] 1 Background 2 Interactive use 3 Batch use 4 Account access 5 Terminal functions 6 System commands 7 File name conventions 8 See also 9 References Background In the late-1960s, RCA decided to exit the mainframe computer business after losing about a 1/2 billion dollars trying (and failing) to compete against IBM. Most of the assets of the computer division were sold to what was then Univac. This included RCA's Spectra series of computers, various external hardware designs (such as video terminals, tape drives and punched-card readers), and its operating system, Time Sharing Operating System (TSOS). TSOS may have been a better operating system from a user standpoint than any of IBM's, but at the time, operating systems were not considered something sold separately from the computer, the manufacturer included it free as part of the purchase price. Univac introduced some additional new features to TSOS, and renamed it VS/9. The name 'TSOS' however, remained as the username of the primary privileged (System Manager) account, which on Unix-type systems, is called 'root'. Interactive use Interactive use of VS/9 was done through terminals connected to a terminal concentrator unit, which passed control signals to and from the terminals, in a manner similar to the way IBM would provide with its IBM 3270-style terminals. This provided, in general, for input to the terminal to be sent in response to an enter key, as opposed to the practice on PCs of taking input one character at a time. The concentrator unit was originally known as the Communications Control Module, or CCM. However, RCA had sold the patents and designs for its CCM terminal controller to Singer Corporation, so Univac developed an emulator device for the CCM which was known as the Multiterminal Connection Controller model 16, or MCC-16. The MCC-16 supported both the Univac standard terminal (from RCA) called the Video Display Terminal or VDT, as well as ordinary ASCII dumb terminals. Univac's VDT provided sophisticated (for the time) editing capability including the ability to edit text on screen and make changes a line at a time or a page at a time, then transmit the text back to the computer. The VDT also supported direct cursor positioning and input protection through a cursor which indicated that only text after the cursor was to be recognized. It also supported special scroll mode in a subset of the screen, or "window" in which, instead of the entire screen scrolling upward when the last line is displayed, it was possible to make the scroll area only the bottom half of the screen. (The same feature for "split screen scroll" would become available about 20 years later in the Apple II microcomputer.) Batch use VS/9 supported one or more card readers, which were connected to the computer and activated by the user placing a card deck in the hopper and pressing the "Start" button. Presumably, the computer would read the source deck, and place all of the cards read in the output hopper. If the card deck consisted of a valid login, it would process the card deck as a job to execute. Account access VS/9 controlled access through the use of an account name and a user name. The account name was a 1 to 7 character identifier, and the user name was also a 1 to 8 character identifier. Identifiers for account names and user names could only be letters and numbers. The account name was the equivalent of a directory name under Unix-style user accounts, with the note that the user name indicated which person sharing that account was the party using it. Thus, for example, if there was an account name of S0103, if there were two users, whose name were Pat and Leslie in that account, they would have a complete identifier of S0103,PAT and S0103,LESLIE. All of their files would be stored in the directory S0103 and thus, they could not create files with the same name. Note that if there was an account name of, say, PA5, if there was a user named Pat, their identifier would be PA5,PAT and would be completely unrelated to any other user named Pat. Accounts could be given restrictions such as requiring a password to use, limits on amount of files, amount of usage, time of permitted usage (such as only allowing logons after 5 p.m. or before 8 a.m.) and CPU limits. A user could also issue commands to have the system interrupt a program if the current session used more than a certain amount of wall-clock or cpu time. A user at a terminal that was not logged on, who wanted to start a session would press the red Transmit key on a Univac VDT, or use Control-C on an ASCII terminal. VS/9 would issue the following response: Welcome to the VS/9 terminal system. Please logon. Followed by a slash ("/"), and in the case of the Univac VDT, the prompt character, which looked like an inverse color greater than sign (">"). The user would logon by typing the word 'logon followed by their identifier, e.g. their account name, a comma, and their user name. If they had a password on their account, they would type a comma followed by their password, which could be from 1 to 4 characters. If it contained one or more spaces (other than trailing spaces, which could be omitted), it had to be typed in single quotes. If it contained non-printable or binary characters, it had to by typed in by using the letter X followed by a quote and the 8-character hexadecimal value of their password. So if the account S0103 had the password (in hexadecimal) A0B0C0 and a space, then user LESLIE would logon to the system by typing /LOGON S0103,LESLIE,X'A0B0C0' If their credentials were incorrect, either because the account name, user name or password were incorrect, they would get the message, Logon invalid, please try again. and would be given a / prompt to logon again. If their credentials were correct, then if the system manager (the owner of account $TSOS) had posted a system message, it would display at this time. The user would be at command mode, and a standard / prompt would appear where they could type various commands. The user would finish their session by typing LOGOFF and pressing transmit on the Univac VDT or Control-C on an ascii terminal. Terminal functions Univac's VDT terminal had four function keys at the top, and VS/9 specifically recognized them. F1 was the equivalent to the break key on an Ascii terminal. If a program was running, it would be interrupted, and the user would enter break mode, in which they could issue a command. They could type R or INTR to resume running the program where the break had been struck. F2 and F3 could be set up to be recognized by a program for various functions, but were not used by VS/9. F4 performed an immediate forced logoff of the user if struck, by accident or on purpose. This would be the equivalent on MS-DOS of pressing CTRL-ALT-DEL, which force-reboots the machine immediately. System commands VS/9 accepted commands by typing the command and any options. Commands issued in a batch stream either as cards or as a batch file required that they be preceded by a slash; commands entered at a terminal did not require use of the slash. Commands included the following: EXEC to load and run a program LOAD to load a program into memory and break to command mode without running, to allow debugging commands DO to run a batch file in the current session ENTER to run a batch file as if it had been submitted to the card reader SYSFILE to specify the disposition of printed output LOGOFF to end one's session. If someone was going to use the terminal, or they wanted to change accounts, they could also type LOGOFF BUT to issue an immediate request for a new login. Any printed output the user had generated during their session would be spooled to the line printer and printed at this time. The option 'TAPE' could be used, as in "LOGOFF TAPE", "LOGOFF BUT,TAPE" or "LOGOFF TAPE,BUT" to indicate that pending printed output should be spooled to magnetic tape instead of being printed. A request would be sent to the system operator. If one had issued a break to a running program (through the Break key on an ASCII terminal or the F1 key on a Univac VDT) or had used the LOAD command instead of EXEC, one would be in "break mode" in which the program was suspended to allow the user to be at command mode. They could issue the above commands as well the following: R to resume a program interrupted by the break key INTR to issue an Interrupt-Resume to a program supporting INTR Debugging commands VS/9 included the Interactive Debugging Aid (IDA) which provided commands to view memory and registers, trap program errors, and store memory in locations. Unlike other systems where an interactive debugger required either you run a program to use it or link a module into a program, IDA was a part of the operating system and its commands were available from break mode. File name conventions File names could be up to 56 characters in length. A file could consist of letters, numbers, dashes, and digits. A file name of all digits was permissible, but a file could not have two consecutive periods. To access a file in another account, it was necessary for a user in that account to make the file public. If the file was public, it could be accessed by another user by prefixing the name of the file with the indicator that a file being referenced is in another account, which was the dollar sign ("$"), followed by the account name, followed by a period. If there was a file named "A" in account S0103, and a user in account PA5 wanted to access the file in account S0103, first, the file would have to be marked as public, and second, it would have to be referenced by account name and the name of the file. So a user in account PA5 who wanted to access file A in account S0103, if the file was public, would reference it as "$S0103.A". Note that a user in account S0103 could reference the file simply as "A" or could reference it with a fully qualified file name by including a dollar sign and their own account name, followed by a period and the name. Public files in the special account TSOS could be accessed by using $ alone as the first character of the file, unless the file began with a name that was identical to an account number, in which case the explicit account reference $TSOS. would be required. Also, $TSOS. was what would be called the path name for missing files referenced by name which were not found in the user's account. For example, if there was a file called S0103.XYZZY in account $TSOS, and there was an account on that system named S0103, any user wanting to access it would have to access it as "$TSOS.S0103.XYZZY". TSOS was also the "default" account for a file that was referenced that did not exist locally. For example, to execute the EDT text editor program, one would issue the command to run a program, EXEC, followed by the name of the file, which was called EDT. So, if the user had not created a file named EDT, they could execute the EDT editor by typing /EXEC EDT and pressing the transmit key. If they had, for some reason, created a program of the same name, to use the system editor, they would have to type /EXEC $EDT or they could explicitly type in the system account /EXEC $TSOS.EDT When Unisys discontinued sales of the 9000 series mainframes in favor of the Exec-8 series computers (probably because they were no longer cost effective, and the market for mainframes had shrank), VS/9 was effectively abandoned by the company. See also BS2000 Timeline of operating systems References VS/9 User Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1972 VS/9 Programmer Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1975 Retrieved from "http://en.wikipedia.org/wiki/VS/9" Categories: UNIVAC software Views Article Discussion Edit this page History Personal tools Try Beta Log in / create account Navigation Main page Contents Featured content Current events Random article Search Interaction About Wikipedia Community portal Recent changes Contact Wikipedia Donate to Wikipedia Help Toolbox What links here Related changes Upload file Special pages Printable version Permanent link Cite this page This page was last modified on 20 February 2009 at 03:03. Text is available under the Creative Commons Attribution/Share-Alike License; additional terms may apply. See Terms of Use for details. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. Privacy policy About Wikipedia Disclaimers ---- Help us provide free content to the world by donating today!The Wikimedia Board of Trustees election has started. Please vote. [Hide] [Help us with translations!] BS2000 From Wikipedia, the free encyclopedia Jump to: navigation, search For the music group, see BS 2000. To comply with Wikipedia's guidelines, the introduction of this article may need to be rewritten. Please discuss this issue on the talk page and read the layout guide to make sure the section will be inclusive of all essential details. BS2000 Company / developer Fujitsu Siemens Computers Working state Current Initial release 1975 Latest stable release BS2000/OSD v8.0 / 2008 Marketing target Mainframe computers Supported platforms Siemens 7.700 and 7.500 mainframes, /370, RISC, SPARC, x86 Website BS2000/OSD BS2000 (renamed BS2000/OSD in 1992) is a mainframe computer operating system developed by Fujitsu Siemens Computers. Mainframe systems are optimized to enable many programs to be installed in parallel and run concurrently on a computer. This helps reduce the number of computers required to a minimum. Originally this was a way to achieve cost savings, since at that time hardware components were considerably more expensive than now. Today, the advantage of an architecture that gets by with significantly fewer computers is that it greatly reduces the complexity of the IT infrastructure, thus saving on IT running costs and increasing IT robustness. To avoid different applications and users on a computer adversely affecting one another by contending for resources, mainframe systems must be able to segregate the different users and processes from one another in an optimum manner. They do this by virtualizing all the resources used by the applications and by centralized resource management controlled in a finely graduated way based on access rights and priorities. At the same time the high degree of virtualization decouples the application software from hardware and implementation details and so creates the foundation for the long-term compatibility, high flexibility, high availability, extensive scalability and great robustness of the services running on mainframes. Unlike other mainframe systems, BS2000/OSD provides exactly the same user and programming interface in all operating modes (batch, interactive and online transaction processing) and regardless of whether it is running natively or as a guest system in a virtual machine. This uniformity of the user interface and the entire BS2000 software configuration makes administration and automation particularly easy. Contents [hide] 1 History 1.1 1970s 1.2 1980s 1.3 1990s 1.4 2000s 2 See also 3 References 4 External links History Looking back over the history of its development, BS2000/OSD has its roots in the TSOS operating system (TSOS: Time Sharing Operating System) first developed by RCA for the /46 model of the Spectra/70 series, a computer family of the late 1960s related in its architecture to IBM’s /360 series. It was one of the very first operating systems in which the principle of virtual addressing and a segregated address space for the programs of different users was systematically introduced. Right from the outset TSOS also allowed the data peripherals to be accessed only via record- or block-oriented file interfaces, thereby preventing the necessity to implement device dependencies in user programs. 1970s 1973 BS2000 V1.0 – Porting of the TSOS operating system to models of the Siemens system 7.700[1] 1975 BS2000 V2.0 – In June 1975, Siemens shipped the enhanced version of the TSOS operating system for the models of the Siemens 7.700 mainframe series for the first time under the name BS2000. Even this first BS2000 version supported disk paging and three different operating modes in the same system: interactive dialog, batch, and transaction mode, a precursor of Online Transaction Processing (OLTP mode). 1977 The TRANSDATA communication system marked the entry into modern computer networking. 1978 The introduction of multiprocessor technology brought an improvement in system availability. From that moment on, the operating system had the ability to cope with a processor failure. At the same time the new technology considerably extended the performance range of the system. 1979 A transaction processing monitor, the Universal Transaction Monitor (UTM), was introduced, providing support for online transaction processing as an additional operating mode, and one particularly important for mainframes. 1980s 1980 Introduction of the Siemens system 7.500 hardware family, ranging from desk size models for use in office environment to large models with water cooling. 1987 BS2000 V9.0 – BS2000 is ported to the /370 architecture and now supports 2GB address spaces, 512 processes and the XS channel system (Dynamic Channel Subsystem).[1] BS2000 is subdivided into subsystems that are strongly decoupled from one another. This increases flexibility for ongoing development and in shipment of software. 1990s 1990 With the advent of the VM2000 virtual machine, multiple BS2000 systems, of the same or different versions, can now run in parallel on the same computer. The new hierarchical storage management system HSMS automatically swaps out infrequently used data to cheaper storage media. As soon as this data is needed again, it is restored, again automatically, to high-speed access media. The MAREN tape archiving system supports the connection of robot systems. 1991 Security evaluation to F2/Q3 completed. 1992 / 1995 BS2000/OSD V1.0 – BS2000 is realigned to make it open to application software and from then on bears the name BS2000/OSD (Open Server Dimension). Full support of the XPG4 standard is achieved in 1995 after the porting of the POSIX interfaces in 1992.[1] 1996 BS2000/OSD is ported to the RISC architecture.[clarification needed] Although the operating system now runs on different hardware architectures (S servers with /390 architecture and SR2000 servers for the RISC architecture), object-compatible execution is guaranteed for BS2000 applications. Applications produced for /390 can be used on computers based on RISC architecture without recompilation. 1997 With WebTransactions, existing BS2000 applications can be easily internet-enabled, with no need for programmer intervention in these applications. 1999 BS2000/OSD is the first operating system worldwide to be awarded Internet Branding by The Open Group. 2000s 2002 BS2000/OSD is ported to the SPARC architecture, leading to the creation of the new SX server line. This marks Fujitsu Siemens Computers’ consistent pursuit of its strategy of hardware independence while at the same time maintaining full compatibility. 2004 Support for enterprise-wide storage area networks (SANs) based on Fibre Channel technology enables throughput rates to be increased by as much as 50%. 2005 The mainframe system celebrates its 30th birthday in July.[1] 2006 BS2000/OSD V7.0 – Support of new server generations, Unicode support, improved SAN integration.[1] 2007 Release of the new BS2000/OSD version 7.0.[citation needed] Development highlights are: the Snap and Clone functionality of the EMC Symmetrix DMX storage systems made available for BS2000 files and disks; online provisioning for pubsets (this function automatically adds disks from a free disk pool to a BS2000 file system as needed or returns disks to this pool when they are no longer required); autonomous, dynamic control of I/O resources (IORM). Like the priority control used in the allocation of CPU timeslices, this function implements a priority control system for processes when accessing I/O resources. 2008 BS2000/OSD is ported to the x86 architecture. Introduction of the new SQ server line. See also Fujitsu Siemens Computers Timeline of operating systems References ^ a b c d e Präsentation: BS2000/OSD V8.0 External links BS2000/OSD Homepage BS2000/OSD System software manuals BS2000/OSD High-end platform for the DDC Retrieved from "http://en.wikipedia.org/wiki/BS2000" Categories: Proprietary operating systems | Mainframe computers Hidden categories: Wikipedia introduction cleanup | All pages needing cleanup | Wikipedia articles needing clarification from May 2009 | All articles with unsourced statements | Articles with unsourced statements from July 2008 Views Article Discussion Edit this page History Personal tools Try Beta Log in / create account Navigation Main page Contents Featured content Current events Random article Search Interaction About Wikipedia Community portal Recent changes Contact Wikipedia Donate to Wikipedia Help Toolbox What links here Related changes Upload file Special pages Printable version Permanent link Cite this page Languages Deutsch Português ?? This page was last modified on 20 July 2009 at 11:53. Text is available under the Creative Commons Attribution/Share-Alike License; additional terms may apply. See Terms of Use for details. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. Privacy policy About Wikipedia Disclaimers ---- Uniscope Protocol Support Uniscope is a proprietary polled protocol developed by Unisys (Sperry) that uses sync transmission method and multipoint addressing. Each Uniscope terminal has a unique, two-level address: a RID (Remote Identifier) and a SID (Station Identifier). The terminal only answers polls with the correct address. If several terminals are attached to a Terminal Multiplexer, the terminal will answer polls with the General or specific RID and a General SID. The MUX then determines which terminal can send to the network. If the terminal is configured for Screen Bypass (dual screen), the terminal will define a separate screen buffer for two or more consecutive SID Addresses. Each screen buffer can be accessed by the host or through the keyboard. The second screen is often used for background printing. Uniscope Terminals The following Uniscope terminals are connected through RS-232C cables and support different screen formatting commands: SO/SI FCC Expanded FCC U100 U200 UTS 400 UTS 20 SVT 1120 UTS 30 UTS 40 UTS 60 (Mapper Color/Graphics) PC with emulation card The terminal formatting commands are upwardly compatible. A terminal that supports Expanded FCCs will also support SO/SI and FCCs. All UTS terminals introduced since the UTS 400 support Screen Bypass. The UTS 4020 and UTS 4040 are cluster controllers that attach UTS 20W and UTS 40W terminals through coax cables. They act as a T-MUX and provide local intelligence (through COBOL programming) and disk storage. The IBM Personal Computer (and compatibles) can be attached through a Uniscope emulation card, allowing the PC to act as a UTS terminal. The UTS 60 supports Expanded FCCs and Color/Graphics. The formatting commands for color and graphics are supplied by special versions of the MAPPER application program. Screen Formatting Uniscope data streams consist of control codes and data formatting codes. The control codes are used for the transmission of the text through the Uniscope protocol network. The data formatting codes differ from one terminal to another. There are three types of data formatting codes: SO/SI, FCC, and Expanded FCC. SO/SI (Shift Out/Shift In) These formatting codes were introduced with the Uniscope 100 (U100) terminal. The U100 terminal's screen is defined as Protected (keyboard entry not allowed). When the application program wants to allow keyboard entry, an SI code is placed in the screen buffer. When an SI code is entered by the user or application, the data entry field shifts to Unprotected. The user can then enter data into the field from the keyboard. The host application can place data anywhere on the screen. Other U100 formatting is provided by TAB STOPS and FS and GS Markers. FS and GS Markers are blinking markers that are used to indicate error conditions. The formatting codes, except SO and SI codes, require a screen position. FCCs (Field Control Characters) These formatting codes provide more functions than SO/SI codes. FCCs were introduced with the Universal Terminal System 400 (UTS 400 terminal). The FCCs define the following: Screen Formatting Protected entry Unprotected entry Unrestricted entry Numeric Only Alphabetic Only Right Justified Video Presentation High Intensity Blink Off (non display) Reverse Video or Low Intensity TAB Stops: Allows faster cursor movement. Changed Fields: (see Transmission Methods) Expanded FCCs These formatting codes are an enhancement to normal FCCs and were introduced with the UTS 40 terminal. In addition to all of the definitions supported by the FCCs, Expanded FCCs define the following: Video Presentation: Different combinations of video. For example: blinking from High Intensity to Reverse Video. Special emphasis characters Protected entry Underscore Strike through Column Separators Downloaded character set: (for graphics) Control Page The Control Page is used by the UTS terminal to define the network addresses and control the physical characteristics of the terminal. Either the operator or a host application can access the Control Page. Entries in the Control Page determine how the terminal performs Transmit (XMIT), Transfer (XFER), and Print operations. Transmission Methods The Uniscope terminal supports several different types of transmission options. The transmission options are: All All data is sent. VAR All unprotected data is sent. CHAN Only the fields with changed data are sent. The FCC has a bit used to indicate if the operator has entered data into a field. If it has, a flag is set. The host can also set the changed field bit. When the XMIT (Transmit) key is pressed, the terminal scans backwards from the cursor location until it finds an SOE (Start of Entry character) or the Home position. The data between the SOE (or Home) and the cursor is eligible for transmission to the host. The terminal then looks at the Control Page to determine which part of the data and FCCs should be sent to the host. Indicator Line The UTS terminal uses an Indicator Line to inform the operator of the terminal's status and network activity. The indicator line and the Control Page provide extensive information for the operator. Print Options The UTS terminal supports two types of printing. With either method, the eligible data is selected in the same manner as the XMIT function. The Print function is used to print the text only. The Print options are: PRNT All data is printed except for trailing spaces on a line with a CR inserted at the end of each line. FORM Only unprotected data is printed with spaces substituted for the protected data and a CR is inserted at the end of each line. XPAR All data and control codes are printed, including trailing spaces. The Transfer function is used to print the text and FCCs. The Transfer options are: ALL - All data, including FCCs, is printed. VAR - All unprotected data, including FCCs, is printed. CHAN - Only the fields with changed data and associated FCCs are printed. Error Reporting The UTS terminal uses an error log to keep track of errors. The error log can be sent to the host to report problems to the application program. The terminal can also perform a Power-on Confidence test at power on to check its functions. ---- Wikipedia is sustained by people like you. Please donate today.The Wikimedia Board of Trustees election has started. Please vote. [Hide] [Help us with translations!] Uniscope From Wikipedia, the free encyclopedia Jump to: navigation, search The introduction to this article provides insufficient context for those unfamiliar with the subject. Please help improve the article with a good introductory style. Sperry Rand UNIVAC Uniscope 100 data terminal. Sperry-UNIVAC UNISCOPE 200 data terminal.A Uniscope was a class of terminals made by Sperry Rand Corporation, Univac Division, and successors since 1969 that were normally used to communicate with Univac mainframes. As such, it was the successor to various models of TeleType. Due to the text color on the original models, these terminals are informally known as green screen terminals. Unlike TeleType terminals, the Uniscope minimizes the number of I/O interrupts required by accepting large blocks of data, and uses a high speed proprietary communications interface, using coax cable and hardware devices known as multiplexors. A Uniscope operator awaits a prompt from the remote mainframe. The prompt indicates that the mainframe is ready to receive input. The operator enters data, offline from the mainframe, and then presses the Transmit button. The terminal locks the keyboard and sends to the mainframe what the operator entered. All the data goes in a single transmission and that causes a single interrupt at the mainframe. Eventually, the mainframe responds, sometimes with a single line; other times with a screen-load of data. And the cycle repeats. Uniscope was a registered trade mark for a set of Sperry Univac dumb terminal products. The trademark was applied for October 13, 1969. Several models were produced: the Uniscope 300, Uniscope 100, Uniscope 200, the UTS 400, the UTS 10, the UTS 20, the UTS 30, the UTS 40 and the color UTS 60. There was also the UTS 4000 cluster controller and terminal line, and the SVT-1120. Various models supported 16x64, 12x80, and 24x80 display formats. The UTS 4000 line had a COBOL compiler available that made it possible to do local processing in the cluster controller, and the UTS 60 was also capable of being programmed. This line of terminals roughly paralleled the similar IBM product, the IBM 3270. A proprietary communications protocol was common to all members of the Uniscope product line. Groups of terminals were generally dropped off a common communications line via a multiplexer (mux) and identified by remote identifier and station identifier symbols. Some terminals may have been equipped with peripheral devices such as printers and recording devices (cartridge tape or floppy disk) which were identified on the communications line by a device identifier. Terminals on a drop were sequentially polled for traffic, sometimes with a general poll to which any terminal with traffic could respond. A fairly complex data presentation protocol permitted application programmers to format a screen for any number of business purposes. For example, fields could be described that would accept only numeric or alpha-numeric characters. Some fields could not be changed by the terminal operator. A protocol extension permitted programmers to specify color for each field and lines on the borders of each cell (underline, or vertical bars, etc.) The Uniscope display protocol, while proprietary, roughly parallel the ANSI X3.64 standard. The color UTS 60 terminal using two Motorola processors arrived on the market at about the same time as desktop computers with EGA monitors. The general consensus was that the UTS60 was over-engineered and overpriced for the emerging market. Eventually emulation software for the Uniscope line running on desktop computers ended manufacturing of the genuine article. Screen size of the original Uniscope 100 was 12 X 80 or 16 x 64 characters. All letters were in capital. Each character was individually drawn as a series of splines using technology developed for displays in military cockpits. Later Uniscopes supported a 24 X 80 screen using raster technology, and upper and lower case characters. There were versions that had the various national code sets for different European countries to enable pound signs, and various accented characters, etc. There were also versions that had Katakana code sets for Japanese. Unisys developed the INFOConnect terminal emulators for PCs that included use of the Uniscope protocols in the early 1990s. There continue to be vendors that sell terminal emulators for these machines. The Uniscopes were Sperry Univac dumb terminal, devices with a keyboard and display to allow a person to interact with a Univac mainframe computer. Several models were produced: the Uniscope 100, Uniscope 200 were hardwired terminals with fixed functionality. The UTS 10, UTS 20, UTS 30, UTS 40 and the color UTS 60 were "intelligent terminals" powered by 8-bit microprocessors, predecessor of today's powerful chips that run today's PCs. The UTS-400-TE was specialized terminal that had a powerful text editing program burned into firmware intended at first to allow for the editing of simple copy such as that for a newspaper, and later adapted as a prototype word processor with 8" floppy disks and driving Letter Quality daisy wheel printers. A proprietary communications protocol was common to all member of the Uniscope product line. Groups of terminals were generally dropped off a common communications line and identified by remote identifier and station identifier symbols. Some terminals may have been equipped with peripheral devices such as printers and recording devices which were identified on the communications line by a device identifier. Terminals on a drop were sequentially polled for traffic, sometimes with a general poll to which any terminal with traffic could respond. A fairly complex data presentation protocol permitted application programmers to format a screen for any number of business purposes. For example, fields could be described that would accept only numeric or alpha-numeric characters. Some fields could not be changed by the terminal operator. A protocol extension permitted programmers to specify color for each field. The color UTS 60 terminal arrived on the market at about the same time as desktop computers with EGA monitors. The general consensus was that the UTS60 was over-engineered and overpriced for the emerging market. Eventually emulation software for the Uniscope line running on desktop computers ended manufacturing of the genuine article. Screen size of the original Uniscope 100 was 12 X 80 or 16 x 64 characters. All letters were in capital. Each character was individually drawn as a series of splines using technology developed for displays in military cockpits. Later Uniscopes supported a 24 X 80 screen using raster technology. See also List of UNIVAC products History of computing hardware Retrieved from "http://en.wikipedia.org/wiki/Uniscope" Categories: UNIVAC hardware | Character-oriented terminal Hidden categories: Wikipedia articles needing context | Wikipedia introduction cleanup | Articles lacking sources (Erik9bot) Views Article Discussion Edit this page History Personal tools Try Beta Log in / create account Navigation Main page Contents Featured content Current events Random article Search Interaction About Wikipedia Community portal Recent changes Contact Wikipedia Donate to Wikipedia Help Toolbox What links here Related changes Upload file Special pages Printable version Permanent link Cite this page Languages ??????? This page was last modified on 9 August 2009 at 05:06. Text is available under the Creative Commons Attribution/Share-Alike License; additional terms may apply. See Terms of Use for details. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization. Privacy policy About Wikipedia Disclaimers