The paper describes an operational requirement for the assessment of powerful single-user systems (or workstations) for the SERC Common Base Programme. All significant aspects of such systems are described, including system and applications software, hardware characteristics, graphics requirements, environmental aspects, and details of systems suppliers and costs.
Colin Prosser had moved to the ICL, Perq Business Centre, Kidsgrove, Stoke on Trent by the time the Report was published.
Over the next several years, computing resources will be increasingly provided by distributed systems, consisting of:
The set of SUSs, servers, and the LAN should be under the control of a distributed operating system, offering features such as transparent remote file access (ie any user should be able to have access to the whole distributed system filestore as an entity, subject to security requirements), task execution at remote nodes, and so on. The distributed system as a whole is seen as a single computational resource by the user, with multiple access points - the single user systems.
A range of SUSs is required, all offering a high quality graphics interface with pointing device capable of supporting an effective window management system, based on the multiple process operating system UNIX; these features are in addition to a powerful cpu and effective demand paged virtual memory management. Filestore may be available locally as part of the SUS or from the file server - this latter should be capable of supporting discless node operation to reduce costs. Detailed requirements for graphics support are contained in the body of the Operational Requirement, but an effective system should include:
It is these graphics features which effectively discriminate SUSs from conventional personal computers.
The relatively low cost of SUSs means that a large number of systems will be purchased and that a large number of vendors are available. To reduce the number of types of machine in the community, and hence both to enhance the transfer of software between research projects and decrease the time lost in re-implementing software on different hardware/system software combinations, SERC decided to support a restricted range of SUSs (initially the ICL Perq), software (the UNIX operating system, FORTRAN77 and Pascal compilers, and the GKS graphics system), and communications to academic (Joint Network Team) standards for both wide and local area networks. More detail on the Common Base Policy, as it is known, can be found in Appendix A.
As part of the implementation of this Policy, a small team was established at RAL to provide and support SUSs to the SERC community. One of the functions of this team is to assess the market for SUSs, and to this end a detailed evaluation was undertaken in 1984. One of the early stages of the exercise was to draw up a detailed Operational Requirement with which to assess the equipment; this Operational Requirement forms Section 2, the major part, of this paper. (Details of the evaluation exercise and its results can be found in a companion Rutherford Laboratory Report entitled Evaluation of Single User Systems.)
The Operational Requirement has been modified in places from the initial form as sent out to the vendors. These modifications have only been made to improve the clarity of the document - a number of discussions with suppliers' technical staff highlighted areas where tile first Operational Requirement was insufficiently clear. The major areas of improvement are in Section 2.7 (graphics) and Section 2.8 (peripherals); in the latter case, the disc requirements now refer to user file space (ie after the system has been loaded), rather than absolute disc space requirements. In all cases, the modifications describe what was originally intended, rather than what was originally said.
Repeating the evaluation exercise in 1986 would obviously require modifications to be made to the Operational Requirement; these would reflect improvements in the technology rather than any fundamental change. The following are the major areas where new requirements would seem to be necessary.
The requirement is structured into several sections each of which states the minimum essential configuration plus features regarded as highly desirable in that area. In some cases, specific implementation information is solicited.
There must be fully effective system support for an at least 24-bit demand paged sparsely addressable linear virtual address space per process. The semantics of the system call interface defined above must be maintained without excessive operational penalties. User level access to virtual memory features must permit implementation of incremental compilation techniques, such as those typically used in Artificial Intelligence applications. (See also under Memory below).
Documented operating system interfaces to virtual memory facilities must be provided.
Manufacturers are asked to state page sizes, maximum number of user level processes supported, per process address space limits, any code and data separation, per page and per process protection facilities.
Utilities and command level facilities must be provided, equivalent to those in the complete set issued by AT&T as UNIX System V Release 2.0.
Manufacturers are asked to state the extent to which this is achieved using AT&T proprietary software (and, if so, its genealogy and licencing conditions) and to list any features not supported.
There must be full inter-process communication facilities (not simply pipes or shared memory), preferably well integrated with virtual memory, graphics and networking. At present, Berkeley BSD4.2 UNIX functionality is preferred.
Documented operating system interfaces to inter-process communication facilities must be provided.
Support must be provided for programs written in the following languages:
and there must be a commitment to support programs written in the (proposed) ANSI standard C language.
In addition, full inter-language working and separate compilation must be supported.
For each of the above languages, the minimum compilation speed for optimised code, including linking, must be at least 1000 lines per minute.
Manufacturers are asked to state compilation performance in typical lines per minute of normally indented code for each of the above languages.
Vendor or third party supplied and supported:
Equipment must have access to a well defined, and preferably industry standard, bus (eg: VME bus, Multibus, Q-bus or the like).
Manufacturers are asked to state which industry standard bus is supported and how many such bus slots are provided. Contending services using the bus should be listed, with typical and maximum bandwidths for each function specified.
The system bus must permit flexible configurations within one product range so that a particular user's needs may be satisfied cost-effectively by appropriate selection of components.
Manufacturers are asked to state any restrictions on space, power etc which may limit selection of configurations.
The base system unit offered must be readily upgradeable to meet growing needs. There must be sufficient free bus slots and space to accommodate at least
in addition to the minimum operational configuration (see also under Costs below). This must be achieved without recourse to expansion cabinets. However, it is acceptable that further hardware additions require an expansion cabinet.
Manufacturers are asked to state the dimensions (in mm) of expansion cabinets, number of free bus slots provided, and associated electrical and other connection requirements.
To achieve exceptionally high performance a fast local bus may be used in addition to the standard bus. Manufacturers are asked to state bus width in bits.
Contending services using the bus should be listed, with typical and maximum bandwidths for each function specified.
The processor performance must be substantial. Typical, not just best, effective instruction execution rate must be greater than 0.5 MIPS (including programs using virtual memory larger than available physical memory).
Manufacturers are asked to state best and typical instruction execution rates (in MIPS) and percentage overheads, if any, associated with virtual memory translation, paging mechanisms, or otherwise.
IEEE single and double precision floating point operations must be supported.
Preferred minimum performance is of the following order (figures in MFlops):
| Function | Single | Double |
|---|---|---|
| Add/Subtract | 0.5 | 0.3 |
| Multiply/Divide | 0.2 | 0.1 |
Manufacturers are asked to provide best and typical measures of single and double precision floating point performance.
Additional physical memory must be configurable in multiples of at least 0.5 MByte, and must be expandable up to at least 8 MBytes.
System software, including compilers, must place no restrictions on full use of physical memory enhancements.
X.25 wide area networking facilities and higher level services must be provided as specified in section 6 of Appendix B, Communications Aspects of New Computer Systems.
Manufacturers should note that the majority of SERC supported sites are already inter-connected via a large heavily used private X.25 network with PSS gateways. At least one node per LAN cluster will be provided with an X.25 connection and associated higher level services. In many cases this will apply to the first such node installed. It is intended that such WAN services be accessible to other nodes connected via the same LAN.
There must be a commitment to provide LAN facilities conforming to the following proposed standards:
This is the closest approximation to required standards that can currently be specified in the absence of complete ISO standards. There must be a commitment to conform to ISO standards as they emerge.
As it is intended to permit shared resource access via LAN services, it must be possible to connect multi-vendor equipment on the same LAN according to the above specifications.
Manufacturers are asked to state what higher level services for access control, file transfer, mail, remote execution and login are provided and typical file transfer rates.
At least two RS232 ports must be provided per node.
The anticipated usage of RS232 ports is for attachment of printers or asynchronous serial communications links rather than for login sessions, but this should not preclude the possibility of optionally configuring systems to support further users via ordinary terminals connected via RS232 lines.
Ability to physically and logically relocate node positions on the LAN with minimal operational impact.
Manufacturers are asked to indicate anticipated operational impact.
There must be a high resolution, high performance, black and white A4 or A3 (preferred) sized raster-scan display. An integrated colour option must be available.
It is intended that the primary user interaction facilities are provided by the features listed in this section. Manufacturers should take particular care in responding to the requirements following.
Manufacturers are asked to provide a block functional diagram of the equipment, showing how the graphics functionality and performance are achieved, defining, for example, all processor speeds and functions, bus bandwidths, and the services sharing such busses. It must be possible to determine from the information supplied how and at what speed bit-maps can be operated on in user memory space and then subsequently displayed. Hardware and software support for tracking of the pointing device and cursor display must also be described.
Manufacturers are asked to state screen size capable of being written to, horizontal and vertical addressability, vector drawing rates (in Mpixels/sec), block pixel manipulation facilities (eg: rasterop) and speeds (in Mpixels/sec), number of colours displayable simultaneously and palette size.
Refresh rate must be at least 60Hz and full frame update must be possible at least 30 times per second. Persistence must be adequate to permit display of flicker free images yet not introduce unsightly ghosting of dynamic images.
Manufacturers are asked to state refresh rate and full frame update time.
Resolution must be equal horizontally and vertically, and sufficient to show 10 point text clearly. (This implies an absolute minimum of approximately 70 pixels per inch horizontally and vertically, with 100 pixels per inch being typically acceptable. The precise figure depends on the degree of static (or dynamic) font tuning implemented.)
Manufacturers are asked to state horizontal and vertical resolution in pixels per inch.
The system must support rapid smooth manipulation of multiple overlapping windows. it must be possible for the operator (user) to create arbitrary sized windows up to full screen size and specify their placement at least within the constraints of screen size; move windows around the screen; delete windows; change the order of overlapping; and grow or shrink their size. Dynamic feedback appropriate to user actions must be provided.
Manufacturers are asked to state the maximum number of simultaneously displayable windows, indicating any restrictions on their layout, sizes and manipulation.
One high transfer rate (greater than or equal to 1 MByte per second), fast average access (less than or equal to 40 msec), local hard disk storage unit with at least 20 MBytes formatted capacity available to the user. It must be possible to upgrade with a second disk in the same unit without sacrificing an otherwise free bus slot.
Manufacturers are asked to state available local disk capacities, average transfer rates, average access time and numbers configurable per system. If required, any additional cabinet dimensions and power and cabling requirements should be stated.
A demountable archive medium must be available as an option within the base unit offered. This must be capable of backing up the complete filesystem in less than one hour without operator intervention. It must be possible to protect against accidental writing of the media.
Manufacturers are asked to state media, capacity and transfer rates.
A readily portable industry standard medium for software exchange with remote (possibly international) geographic sites must be available as an option within the base unit offered. It must be possible to protect against accidental writing of the media.
Manufacturers are asked to state media, capacity, transfer rates, and whether or not the demountable archive medium is suitable for this purpose.
Availability of a range of printing devices with supporting spooling and driving software. Printers are needed to produce screen and window dumps in colour and black and white (preferably in well under 2 min), book quality multi-font text and diagrams, letter quality output (preferably with a choice of fonts) and draft quality output. There is a need to provide both shared high quality printing resources per LAN cluster, and cheaper per node printing facilities for isolated users.
Manufacturers are asked to state performance figures for any available printing facilities (in seconds for full screen dumps and characters per second for text) and indicate font availability where appropriate.
The equipment must be suitable for desktop or desk-side office use without special lighting, air-conditioning, noise or electrical suppression requirements.
Manufacturers are asked to state system dimensions (in mm), noise output (in dB), heat output (in watts), and external cabling requirements.
It must be possible to power the equipment from a single normal UK 240 Volt, 13 Amp, 50 Hz mains outlet.
Manufacturers are asked to state system electrical requirements.
It must be possible for the operator to readily adjust the relative positions of the display, keyboard and pointing device on the work surface.
Manufacturers are asked to state maximum working distances of freely movable components from the corresponding base connection unit.
2.12.1.1 Minimal Configuration
In summary, a minimal configuration is envisaged as consisting of a single unit containing:
3 free bus slots for upgrades with sufficient physical space to add as options:
This list of options and combinations is not intended to be exhaustive, but indicative of likely minimum upgrade requirements over a node's lifetime.
Other items in the minimal package must include:
Manufacturers are asked to quote the one-off and quantity or other discount costs of such a system, specifying VAT where applicable, and delivery times. For equipment not yet in production, availability dates of (a) prototype and (b) production in volume, should be supplied. It should be stated where item costs would normally be unbundled and both individual item and aggregate costs should be quoted. Any right to copy initial minimal configuration software to subsequent systems should be stated and costs quoted. For items only suppliable at a later date, manufacturers are asked to indicate when they are expected to be available, and, if possible, at what cost.
2.12.1.2 Individual Upgrades
Manufacturers are asked to quote similarly for the following individual upgrades (giving installation costs, if additional):
Manufacturers may offer quotes for other items, such as application software, that they consider relevant to the Common Base requirement.
Manufacturers are asked to supply the following information. This will be used to assist assessment of ability to continue product development and to supply and support quantity shipments over a number of years.
The appearance in the market place of cheap high powered single user computer systems with good interactive capabilities via high precision displays, linked together by high speed local area networks, heralds a completely new way for most SERC Investigators to achieve the major part of their computing requirements.
Within the next few years, many such systems will be available from different manufacturers. Consequently there is a likelihood of many different systems being purchased in the SERC environment leading to a great deal of duplication of basic software development. SERC sees a need for a coordinated development plan to ensure that the UK makes the best use of its finances and of its limited manpower. The SERC has therefore decided on a strategy of creating a common hardware and software base for software development which will encompass all scientific subject areas. Briefly the common software base will be Pascal and Fortran running under the Unix operating system implemented on the common hardware base of PERQ single user computers linked locally by Cambridge Rings and nationally by the X25 wide area network systems (SERCnet and PSS).
SERC Subject Committees will participate in the implementation of this policy by enabling central purchasing of PERQs for grant holders to be done via Central Computing Committee and by ensuring that investigators use the PERQ in all appropriate circumstances as well as encouraging them to follow the common base software development policy. The Common Base Policy is not the same as standardisation, however, and it will evolve as the state of the art improves.
The whole academic community, not just Computer Science, is a major user and developer of software and so the degree of ease with which software can be developed affects the scientific productivity of many researchers.
The SERC has approved a plan to increase the productivity of scientific research requiring computing by:
Currently the academic software technology base is very non-uniform in that the knowledge, experience, tools, techniques and equipment vary considerably between projects. The motivation to create a common Hardware and Software Base is to bring together all of the best existing tools, packages and techniques into a uniform framework so that the 'whole' is more effective than the sum of diverse parts. This will be achieved via EMR contracts to move existing software into the common base, specific purchases, the direct results of SERC research projects using the common base equipment and the 'snowball' effort that will be generated as a natural consequence of providing a state of the art hardware base. A good example of the common base 'snowball' effect is the widespread use of the Unix operating system which has enabled a large number of software tools to be made available throughout the UK academic community.
The Common Base Policy briefly is:
The SERC wish the common software base to be the Unix operating system and the common hardware base to be the PERQ. The PERQs should be networked together via Cambridge Rings, SERCnet and PSS to allow widespread cooperation between users and developers. This combination of software and hardware is widely accepted as being the best combination for developing software in the coming years. A common base does not imply rigid standardisation however.
Computer technology develops at a rapid pace and it is expected that the next few years will see the cost of single user systems decline and their quality and capability increase. Therefore today's PERQ is seen as only the first machine forming the common hardware base. The common base will develop over the coming years.
In outline the Common Base Policy comprises
The following gives a more detailed exposition of the technical components and philosophy of the policy.
Pascal and Fortran 77 have been chosen as they are the two most popular scientific languages. They possess the properties of portability and official standard definitions. There is a large amount of software already written in them which allows people to make use of existing investment.
There will be considerable SERC support for Fortran 77 and Pascal. This will take the form of software tools and techniques developed by the Software Technology Initiative and the activities of the SERC Computing Service team. Thus the CBP will act as a focus for many different activities.
Other languages will be available with the set of software tools in the CBP. For instance the Unix 'C' language is already available and Ada is under development by York. LISP and Prolog are being implemented.
These other languages will not receive the same degree of support and tool development as Pascal and Fortran. They are not 'blessed'. This situation must be reviewed regularly. Specific minority groups eg Ada community will receive minority support through individual committees eg STI.
Evolution of status from other to blessed is possible.
It is a requirement of the CBP that blessed languages should be inter-workable at the procedure call level ie a Pascal program can call a Fortran subroutine which can call a Pascal procedure etc. This is a vital capability to ensure maximum use of standard components. It is ridiculous to have to, say, reimplement a Fortran graphics package in Pascal because Pascal cannot call Fortran.
Interworking has implications for compiler construction and operating system development. It has its limitations and difficulties, eg the difficulties in enforcing type checking across procedure interfaces, but its benefits outweigh its drawbacks. (Reference Tony William's paper).
In line with the policy of supporting international standards and portability aids the CBP has blessed GKS 7.2 as its basic graphics package. GKS will be available on all SERC machines, not just PERQ, to help the transfer of graphics software and, via metafile standards, pictures themselves.
There will have to be a significant amount of software mounted on top of GKS to give the scientist the graphics facilities he requires. Much of this graphics library porting work will be led by RAL Graphics Section.
Unix is already a de facto standard in many academic institutions in both USA and UK. It has enabled a great deal of software to be shared amongst research groups and has built up a large quantity of widely applicable software.
Unix is being used increasingly by industry again both in the USA and UK. The CBP philosophy is based on the following properties of Unix.
For the scientific community Unix is likely to become the standard small machine operating system because small machines seem to get bigger every day!
The CBP Unix has the following properties
The technical specification of Unix is given in (ref 4).
There are several versions of UNIX either in existence or soon to be announced. These include Berkeley 4.1 and 4.2, Bell version 7, System III and System V.
The CBP philosophy is to run the same, stable version of UNIX on all the different types of hardware supported by the CBP ie only one version of UNIX will be supported by SERC.
There must be a balance between the benefits of new developments and the benefits of stability and standardisation. Thus moving to a new version of UNIX will be a major evolutionary step for the CBP, especially if and when more than one CPU type is involved.
The PERQ was and is the first machine which satisfies the requirement for a high performance single user system (see Appendix). Other machines are likely to follow (some are already here). The expected proliferation of machines will tend to fragment the software development activities because some things will always be machine specific. The Council therefore wishes to balance the benefits of standardisation (which acts against change) with the need to give state of the art facilities to scientists (which requires change). The future CBP is therefore expected to include more than just today's PERQ but such changes must be taken infrequently and given very careful consideration beforehand.
It should be borne in mind that the criteria for choosing a single user system must be that it runs the common software base rather than has some new hardware feature. The investment in software is already so large that computers must be purchased which run the Council's software rather than the Council's money be wasted on reimplementing existing software on some new hardware. Manufacturers will have to understand the changing balance of power between them and their customers. The manufacturer independence of Unix is a key factor in this equation.
The recommended CBP PERQ configuration is:
For advice on peripherals such as printers suitable for use with PERQ contact CBP User Support at RAL.
The technical specification of the PERQ is given in (ref 5, ref 6).
The CBP requires a fast local area network to link its machines together. The Cambridge Ring has been chosen because it is
The technical specification of the Cambridge Ring is given in (ref 7).
The Cambridge Ring is not the only LAN currently available, but has been chosen as the CBP LAN for the above reasons.
There are several different types of Ethernet and Token Ring LANs available or soon to be announced. The IEEE 802 standard initiative is having a beneficial influence but has yet to be adopted as an ISO standard.
The CBP will therefore stay with the Cambridge Ring and its associated CR82 protocols until the world wide LAN developments have stabilised sufficiently to enable an evolutionary step to be made.
Where a campus has installed an X25 system to act as a LAN then the SUS can access this via the hardware and software given under section 8, ie X25 campus LANs are blessed by the CBP.
The long term objective of the CBP is to exploit the advantages of distributed computing and LANs which can be realised as Servers. The following Server requirements can be identified as desirable but not yet deliverable as service equipment. There is an urgent need to develop such servers into commercial products.
There is a requirement for sophisticated, high quality (at least 300 pixels per inch) text and graphics printing capability to complement the Single User System's display.
Examples are hardcopy of scientific papers (camera ready including diagrams), graphical software tool output, mathematical text (proofs) and so on.
It is envisaged that this need will be met by small, relatively cheap ($10K) laser printers, one per department, configured as a LAN server. Until this technology is readily available (1984?) such items as Diablo daisy wheel printers and Versatek graphics devices are suggested (Contact RAL CBP team for advice).
It is seen that an LAN to X25 (SERCnet and PSS) gateway will be the most cost effective way of connecting a number of machines to the WAN. No products are currently available.
Single user systems cannot hold all the data to which a single user requires access. Nor can a SUS handle file backup and archiving requirements.
In the short term the CBP recommends that SUS are not used stand-alone but are connected to multi-user machines with suitable peripherals to allow file access and archiving.
The more desirable solution is to have file and/or archive servers. No products are currently available.
The CBP requires a national wide area network to link both people and machines. The network must be compatible with JNT/NMC policy. The current CBP uses SERCnet and PSS which are technically compatible X25 networks linked by a gateway.
The CBP also requires access to Europe (including Scandinavia) and the USA. Such links are not all easily available.
The PERQ-X25 connection, in the short term, will be via the York LSI-11 transport service front end originally designed for the PDP-11. Studies are in-hand for in-board solutions.
The technical specification of SERCnet X25 network is given in (ref 8).
The protocol strategy is based on the de facto UK academic standards approved by the SERC/CB JNT in their coloured books. The adoption of the Wide Area Network protocols of transport service and above for the local area network use gives a useful unification of LAN/W AN facilities. The average user sees only one and the same mechanism to move files, mail etc between machines independent of distance (ie local or wide area net). The adoption of transport service also gives a degree of hardware independence for local area networks.
The use of wide area protocols for local area networks is conservative in that it does not allow various advantages of LANs to be exploited eg speed, reliability. More LAN specific (light weight) protocols could be employed for high speed inter-machine interaction (eg remote process execution). Such protocols should only be blessed if they attain a measure of widespread acceptability. Specific research projects are likely to require lightweight protocols. They should not be discouraged in appropriate circumstances.
Transport Service around the Ring is implemented by TSBSP > (Transport Service Byte Stream Protocol) running above BBP (Basic Block Protocol). These are the de facto UK academic Ring standard protocols based on Cambridge University's work.
Currently the JNT is having the Mace box built by Orbis which will be a high speed intelligent interface having TSBSP and BBP in it so providing a DMA transport service to its host.
The protocols specifications are given in (refs 9-15).
Electronic Mail as implemented over the Grey Book is an extremely useful facility. However, experimental work at various sites in the world has shown the potential advantages of more sophisticated facilities above simple mail. Such facilities include message based conferences and public electronic bulletin boards.
No ISO approved or de facto standards exist in these developing areas. The CBP could possibly evolve to include such facilities.
The JNT coloured books and the CR82 Ring protocols are not ISO standards nor are they likely to be. It will be necessary eventually to change the protocols on both WAN and LANs in the light of current development work on protocols to whatever emerge as international standards. This will be a major change for the entire network community and will not come quickly.
Fortran 77 and Pascal will allow PERQ CBP software to be moved to and from other non PERQ computers. However it is recognised that even when programs are written in Fortran 77 and Pascal much work often has to be done to move them because of the inbuilt operating system dependencies. By using 32 bit, virtual memory Unix as a de facto standard execution environment it should be much easier to move programs in Pascal and Fortran 77 from one CBP Unix system to another.
Portability is also one of the reasons for backing national and international standards generally, hence the use of the GKS graphics package. GKS will be available on all SERC supported machines.
Portability of software is also one of the aims of the networking side of the CBP. Good communications are needed if software is to be easily shared by geographically dispersed research groups.
The CBP is expected to be expanded to include some items related to specific applications. These might possibly be the NAG library, RAL graphics library etc as well as software development tools from the STI, IKBS etc. In addition much applications specific software will be generated on top of the CBP and which will be generally available but which will not actually be part of the CBP. The CBP is supposed to form the base not the totality of available software.
The Perq is a high powered, single user computer system with a high precision display system which provides a significant improvement in the quality and speed of interaction. Its main features are:
A high quality, superbly interactive computing system is created if each investigator has his own single user PERQ linked to his colleagues' PERQs and other departmental computing resources by a Cambridge Ring, with inter-university cooperation being fostered by the National X25 network connections.
Recent advances in data communications have led to the specification of non-proprietary network protocols for which support is becoming available on various computer systems. Computer centres in universities and Research Council institutes are planning to move towards use of these protocols as the mechanism for accessing their computing resources. For equipment already installed, the protocols are being implemented by means of development projects. Any new equipment purchased will be expected to support the protocols from an early date.
Wherever possible, internationally agreed standards are being adopted. CCITT recommendation X25 has been chosen for wide-area network access and recommendation X3/X28/X29 for Keyboard Terminal Support. The definitions are those used for British Telecom's public packet-switched network PSS and are given in Reference 1. Reference 2 contains additional information and recommendations for the support of character terminals. For those functions where international standards do not yet exist, interim standards have been chosen and the specifications of these have been submitted for consideration by national and international standards bodies. These standards are the Yellow Book Service, the Blue Book File Transfer Protocol (NIFTP) and the Red Book Job Transfer and Manipulation Protocol (JTMP). Their definitions are given in References 3,4 and 5.
It is intended that data switching functions should be carried out independently of host computing resources. Facilities physically separate from any host computer system will be provided to interconnect terminals and computers and to route traffic to local or remote sites. These functions will be achieved by a combination of local-area and wide-area networks. Hosts will be attached to such networks via a small number of synchronous communication ports.
The evolution of technologies such as Rings and Ethers may lead to the emergence of alternative Network Access standards.
The major national computing centres in the academic community intend to support X29 and JTMP for unified terminal access and job submission to their computing systems.
Terminals will in general be connected to networks through terminal concentrators (PADs) which will perform data blocking and unblocking for efficiency of transmission. Hosts will normally handle terminal traffic by means of X29 calls multiplexed on relatively few synchronous host ports. (In some circumstances, directly connected terminals, each occupying a dedicated asynchronous host port, may be required. The balance between these and network-connected terminals will depend on the environment.)
Computer systems will in many cases be expected to act as RJE stations by providing job submission facilities to national centres. To comply with the longer term requirements, the preferred mechanism of achieving this will be by means of JTMP. Computer systems may also be expected to act as JTMP servers in their own right.
Local and wide-area networks will be introduced in stages. During this period, mainframes may be interconnected by dedicated leased lines carrying traffic conforming to the new protocols. Similarly, PADs may be directly connected to synchronous host ports.
The machine will be required to communicate over networks with a diversity of computers and terminal equipment from a wide variety of manufacturers. Correct and efficient operation of the computer system must not demand any awareness of the instantaneous nature and number of all other inter-connected systems. Adherence to ratified national or international system inter-connection standards will be mandatory.
The machine will be connected to one or more local or wide-area communications sub-networks directly or via a communications controller or a front-end processor which must present no obstacles to the transparent transmission of bi-directional data streams. The bandwidth of the physical connections will be commensurate with the size and capacity of the machine.
For higher level functions where standards are in the process of evolution, the academic community has adopted the protocol definitions which appear in the References. All higher level services and protocols must be implemented in a modular fashion. Suppliers must also make available appropriate operating system interfaces for users to incorporate their own modules.
The order of the items in the list below corresponds to an architecture from the communications level to the job management level.
References 1-3 are available through PSS Marketing, 5th floor, Seal House, 1 Swan Lane, London EC4R 3TH.
References 3-6 are available from the Joint Network Team, c/o Rutherford Appleton Laboratory, Chilton, Didcot, Oxon OX11 OQX.
