Following the success of our Page 3 picture and our Problem Page we bring you FORUM's very own serial. The Saga of SERC's DEC10 by Bernard Loach begins. Bernard has now retired from RAL and we wish him well.
Discussions on the Forty Report's recommendations continue; we hope that some action has been agreed by the time you read this.
The Service Line, RAL's friendly voice, has been running for two years and Lorna Claringbold's article draws on that experience to tell you how to get the best advice when you have a problem.
Our Network Supplement appears with this issue. We hope it demystifies some aspects of the black art. Unfortunately, although we tried, we were unable to elicit any user contributions. If you have comments on anything we have said, or have a favourite networking horror story, let us know.
As another financial year draws to a close it is with a sigh of relief that we note Central Computing has survived its first year of Direct Charging and is in good shape for next year. The statistics on Page 8 make interesting reading.
Finally, it is worthy of note that this is the first FORUM in which more than half the articles are written by people not on the RAL computing staff. Who knows, perhaps next time we shall have a guest editorial.
A Central Computing Representatives Meeting was held at RAL on January 14th. Forty users attended; twenty-three from external sites. The emphasis of the meeting was on RAL presentations with the general session split into two parts.
The role of the meeting was on the agenda and I outlined the reasons for moving away from a central meeting. It is fair to say that the users did not entirely agree. Points made were:
These representatives doubted the value of local meetings. However we have yet to hear from those who do not attend the central meeting. Please write and tell me why you do not attend and whether you would find a local meeting valuable.
Since the consensus was that the meeting was worthwhile I will go over a few of the points raised.
Full CCRM notes will not be included in FORUM in future; users wishing to know more should contact their representatives.
By the time this issue of Forum is printed, I expect to have handed over the chairmanship of the Central Computer Site Users' Meeting to my successor. It therefore seems an appropriate time to look back at what has happened on the Central Computing scene over the last three years.
In 1983 one could log in to Electric over SERCNET and submit an MVT job to run on the 3032 to produce graphics output on the FR80. Now everything has changed. Even the most committed Electric users have had to move to CMS (which was not so hard after all), SERCNET is incorporated in JANET, the MVS service on the Atlas 10 has taken the place of MVT and the FR80 has gone, with most of its functions taken over by new graphics devices. The design of program overlays, no longer necessary with virtual memory, and the structuring of Electric edit files to provide many options for job submission will soon be forgotten arts just like the use of punched cards or paper tape. On the other hand, the computing environment has been improved by the addition of new facilities. For example, we can now have fullscreen access to CMS, even from remote sites, disk space management has become easier with the M860 and international communications are possible through IPSS and EARN.
With all these changes, it is hardly surprising that there have been some problems and delays, but I feel sure that without the real effort from Central Computing Division to find the needs of users and to satisfy them, the disruption could have been far worse. However, we now have a very complex system with both CMS and MVS, plus the many additional packages for communications, graphics, library and dataset management, accounting, database access and so on. No one, certainly no user, can expect to be familiar with all these in detail. This means that there is a continuing need to simplify the user interfaces and provide good documentation, especially for new users.
It will be interesting to see which developments turn out to be the most significant over the next few years. Will the use of UNIX-based personal workstations make a real impact on the way the central computer is used? Shall we be programming in ADA or FORTRAN 8x? Will optical disk storage and the concept of a central filestore become realities? Clearly there are further changes to come, but my hope is that they can be introduced in an evolutionary manner and will make the Central Computing system simpler, not more complicated, for its wide spectrum of users.
About 20 users and several RAL staff attended the meeting held at RAL on 17 February 1986. The discussion covered a wide range of topics and produced some surprises. Although in general the opinion seemed to be that the SUN equipment was reliable, asking everyone present to describe the faults they'd experienced revealed a lot of problems, one of them clearly due to a bad batch of disk drives. SUN's response to hardware faults was considered to be good. There seemed to be no difficulties with SERC's (as yet relatively untried) first line software support system. It was realised that a clear statement was needed on what software was standard, and what that status entailed. Poplog, for example, does not yet exist for SUN3s, (since there are hardly any in Britain yet) and some work cannot proceed without it. Concern was expressed that responsibility for Poplog systems was to move from Sussex to SDL, since there may be reduced response time to bug reports and no access to the source to let users do quick fixes. There were some complaints about the different arrangements made by SERC at Rutherford and Swindon over equipment on grants. Merging the PERQ and SUN users groups was mooted and accepted by the SUN users on an experimental basis. The meeting closed with a SUN3 demonstration.
Part one of a two part biography.
During the last ten to fifteen years most people having some knowledge of the SERC's computing facilities will at least have heard of the Edinburgh (ERCC) DEC-10. Its particular function in the overall scheme of the Council's computer resources is probably less well known except to those who have been closely associated with the Interactive Computing Facility (ICF) as either a user or a service provider.
The position and function of the DEC-10 in the SERC's organisation has varied considerably over the years and the machine itself has undergone many architectural changes and upgrades as well as alterations in location. But for most of its life in the SERC it has been the major machine of the ICF network set up to provide Interactive Computing Facilities mainly for use by engineers in Universities and Polytechnics who hold Council Research grants.
It is pleasing to note that the machine did not end up on the scrap-heap but was purchased by the Computer Board and is now installed at the University of Essex Computer Centre alongside their other DEC-10.
The main historical events in the life of the machine are summarised, many steps of which can be likened in some ways to the life of a human being.
The story begins with the original conception of the machine when it was ordered from the Digital Equipment Company Limited (as a PDP-10) by the British Library for cataloguing purposes some time early 1970.
The machine was almost stillborn when a general election in June 1970 brought a change of Government and policy which resulted in the cancellation of the order from British Library (at the time there even appeared to be a possibility of penalty clauses in the contract being invoked!)
Thus might have been the end of the story as far as We are concerned but for the fact that at that time (the beginning of 1971) the then Science Research Council (SRC) was considering the award of a research grant to Dr John Oldfield of the Computer Science Department at Edinburgh University. Full details of this grant (B/SR/88746) can no longer be traced at the SERC's Central Office in Swindon but its title is believed to have related to a general grant for "Interactive Computer Graphics Applied to CAD". Part of the proposal included a request for the provision of what in those days was considered to be a fairly large computer - a DEC-System 10 (or PDP-10 as it was usually called then). This was to replace an Elliott 4100 system used for CAD and AI activities.
An award was eventually approved in about March 1971 - it included just under £200K for a PDP-10. The machine originally destined for the British Library was diverted to Edinburgh where it was installed in the old University buildings at No. 5 Buccleuch Place and was ready for use within three weeks of the starting date of the grant - rather a record in those days for such an event! (The invoice, dated April 1971, is addressed to HMSO Procurement Department at Norwich for the provision of a PDP-10 to be delivered to No. 5 Buccleuch Place.)
As installed the machine had a KA10 cpu with 64K of memory (36 bit words) and 50Mb of disc space (two RP02 disc pack drives). No magnetic tape drives were provided. Peripherals included a console teletype, line printer, paper tape reader/punch and a sixteen line communications controller. Dr W D (Bill) Hay was given the job of running the machine for John Oldfield's group. The operation of the machine was controlled by a committee with the late Dr Gordon Burns of Edinburgh Regional Computer Centre (ERCC) as Chairman.
During these early years Mr Art Bijl of the Department of Architecture was also given time on the PDP-10 in relation to various SRC grants for Computer Aided Architecture Design (CAAD) work.
John Oldfield and Alistair Kilgour produced a graphics system on this new machine known as SPINDLE which is fully reported in the literature. Supplementary grant applications followed for the addition of magnetic tape drives (two DEC tape and two normal magnetic tape) and 64K of memory. The former were awarded but the latter was still under consideration early in 1973.
Sometime during this period the machine was moved from Buccleuch Place to the Department of Computer Science in the James Clerk Maxwell Building at the Kings Buildings, Mayfield Road, Edinburgh.
The next significant step followed a separate request to the SRC by Professor N Feather of the Edinburgh School of Artificial Intelligence in December 1972 for a DEC System-10 machine of their own to provide improved computing facilities to be used in conjunction with a number of SRC research grants. Following discussions between the SRC and all interested parties in April] 973 it was decided to invite Dr Oldfield to submit proposals for enhancing the existing PDP/10 for general shared use by all Edinburgh grant holders needing such facilities. He duly applied for a new grant entitled "The Provision of Specialised Interactive Computing Facilities" on behalf of the CAD project with a proposed starting date of 1 October 1973 to cover the requirements of the Department of Computational Logic, the Theoretical Psychology Unit and the Theory of Computation Group. In making the application both Dr Oldfield and Professor Michaelson (Head of the Computer Science Department) recorded their view that the proposals were not in the best interests of the project concerned and that better alternative arrangements could be made. However, they were willing to implement them in a constructive manner as the SRC concluded the proposals represented the only acceptable solution under the existing circumstances.
This grant (B/RG/55678 - Interactive Computing Service) was approved with a starting date of 1 March 1974 and a change of investigator from Dr Oldfield to Dr Gray due to the former's departure to Swansea. The major enhancements to the PDP-10 included the addition of 64K memory, an RD10 drum system and 4 RP02 disc drives at a total cost of approximately £l50K. The grant also approved the appointment of the following staff: System Manager, Senior Programmer, Programmer and Documentation Clerk. £l5K was added to cover the provision of an operator service by ERCC over a period of 3 years. Operation of the installation was administered by a Management Committee under the Chairmanship of Professor G Michaelson which included Bill Hay as Manager of the DEC System-10. At this stage Mr Charles Mackinder joined the organisation as Secretary of the Committee and in charge of User Support. He was an ex-army man who had come to Edinburgh University in 1972 where he had been involved with computer operation and support in the AI community.
The Management Committee was responsible for the arrangement of resource allocations during this period and started the preparation of usage records and statistics. The CAD project had much the biggest allocation in September 1975 (27.8% of their total allocation was actually used) while CAAD with the second largest allocation actually used 103% of theirs!
Meanwhile the Engineering Board (EB) of the SRC had set up a working group in 1973 to clarify future engineering computing requirements - the group reported in December 1974, its recommendations being approved by the EB in the same month and by Council in February 1975. The EB then sent up a technical group in March 1975 under the Chairmanship of Professor Rosenbrock (of UMIST). As a result the SRC's Interactive Computing Facility (ICF) came into being and setting up of the appropriate facilities began in 1976 under the control of yet another Committee - the Interactive Computing Facility Committee (ICFC).
Amongst other plans the Rosenbrock Report had recommended the further enhancement and incorporation into the future network of the two existing SRC DEC System-IO machines - the one under consideration here at Edinburgh and a similar machine at UMIST - together with a third, new DEC System-10 machine to be located at the Rutherford Laboratory (RL). In the event this third machine was never purchased.
Responsibility for operation of the Edinburgh machine was fully transferred to ERCC, again under the charge of Dr J G Burns, with the Director of ERCC, Dr G E Thomas, formally responsible for the service contract. Bill Hay became the Systems Manager and Charles Mackinder was put in charge of the User Support Organisation (the latter included Mr Jeff Phillips). Mr Keith Jarvis was in charge of Systems and Mr David Mercer was responsible for communications. The SRC contract with Edinburgh University for running the machine as part of the ICF began a little late - on 1 December 1976. The ICF funded upgrade of the DEC System-10 for ICF use included:
The initial ICF users were basically the same group of people who had previously been using the machine - the CAD project (originally J Oldfield's group), the CAAD project (A Bijl's architect's group), together with the AI community, Computer Science (R Burstall, R Milner, G Milne et al) and the Science Board's crystallographic data base activities.
Following detailed discussions between the Rutherford Laboratory and ERCC, procedures for resource allocation and control were introduced and charging algorithms were established to suit various categories of user with different charging rates. Differential rates were adopted, varying according to the time of day and day of the week (the conventional system now generally used on all SERC service computers). Scales of direct charges were set for the sale of any spare resources to approved users. Full allowances were made to existing users to ensure that none of them would be disadvantaged relative to newcomers. Usage statistics were compiled regularly and made available to management.
Development was slower than ideal but the appointment of Peter Davey as Head of the ICF in January 1978 helped clarify the role of the ERCC DEC System-10 in the ICF network. Permanent DECNET communication links to UMIST, the Rutherford Laboratory and Sussex University were established at this time (with DECNET nodes at RL and Sussex) and represented the first national network.
The next stage begins with an agreement with the SRC early in 1978 to re-locate the machine and terminal rooms in its own self-contained suite within ERCC itself in the James Clerk Maxwell Building and to rationalise the communications arrangements. The move actually took place in late August 1978 with only ten days interruption of the service. As a result of this move and consolidation of the installation the reliability and service improved considerably. Keith Jarvis took over from Bill Hay as Systems Manager and from April 1979 the machine came under the direct control of Dr Thomas and remained so until his departure to Australia in July 1985, when he was succeeded in turn by Peter Williams as acting Director of ERCC.
During the 78/79 academic year all the major network links were established, including one to the RL IBM 360/195. Many additions and upgrades to the software took place - APL, PASCAL, HELP, and SCRIBE were installed. The Usage Algorithm was revised to give more realistic performance. One very active paying user (Compeda Ltd) brought very considerable financial benefits to the installation.
By the year 79/80 the machine and associated equipment had become stable, providing an established and reliable service. Communication facilities were improved further by the addition of the Gretna York type gateway between the DEC-10 network (DECNET) and the developing SRC nation-wide academic network - SRCNET.
However doubts about the long term future of the two DEC System-10 installations were beginning to be felt as discussions on the subject continued throughout the years 78/79 and 79/80.
The final chapters of the story will appear in the next issue.
Shortly after taking up my post as Director of Networking, I wrote an article for IUCC's journal, University Computing. One sentence ran: "The Joint Academic Network has been established by the Computer Board and the Research Councils with the specific intention of evolving from the present rather ad hoc provision to a single network, using common standards, and to which any member of the academic community will have access."
I then went on to enumerate some of the problems I anticipated in achieving this objective. Roughly two years later it is worth-while to assess what has been achieved, what remains to be done, and what new plans are emerging.
As Ian Smith's diagram (Figure 2) of the present topology shows, part of these early objectives has now been achieved. JANET now offers connection to the greater part of the academic community. The principle exceptions are the Polytechnics, where the licensing situation has caused some delay in connection. I very much hope that recent developments in regularizing the situation of JANET will allow the connection of the remaining Polytechnics in the near future. What Ian's diagram does not show is the extent to which JANET uses common standards, and the way in which this supports communication between a range of different services. JANET is not the largest network in the world; JANET is not the most reliable network in the world; but JANET is almost certainly the most heterogeneous network using a single set of commonly adopted standards, and integrating a large number of independent Local Area Networks, in the world.
My 1984 paper described plans for improvements in the trunk network which interconnects the switches, and for the introduction of manufacturer supplied and supported software on the switches. Again, the configuration diagram shows the extent to which the trunk network relies on 48Kbit/sec Kilostream lines, and that all the switches are now running GEC supplied software. Neither of these changes has been entirely without problems and some of these are still with us. However, this phase of development is nearing completion; the emphasis is now on rationalisation of the network and the introduction of still faster trunk and link connections. It is intended that these plans will produce a significant upgrade in network throughput for a relatively modest increase in total expenditure.
In 1984 I also described plans for the overall management of the network and for the initiation of User Groups, to safeguard the interests of the users who are, of course, the ultimate justification for the expenditure of so much money and effort. The management structure is now in place and functions effectively; it may even achieve the ultimate accolade of any management group and secure a major injection of funds into JANET. The User Groups meet regularly. The groups are based partly on their regional location and partly on subject; I count as a major success here the steps which are being taken to introduce a group based on the activities of libraries.
There is an enormous amount still to be done. The hoped-for levels of availability have yet to be achieved; many of the techniques of managing the physical network have yet to be introduced; there are major problems in the transition from standards which were defined by the UK academic community to those which are emerging from the International Standards Organisation; the limited value-added services which JANET offers need further development. However, one thing is certain. The mere existence of JANET has served to bring together the academic community, and there is no doubt in the minds of those of us who work on JANET that this counts as a most significant achievement. I am grateful to my colleagues who work with me on JANET, and to those users who work over JANET.
Many of our users require access to sites outside the scope of JANET, and many non-JANET related people require access to JANET services. This is achieved by use of the public data networks, both within the UK and Internationally. Use of these services costs money - in particular every block of data sent or received and the elapsed time of the connection is charged for.
Consequently, the use of these services from JANET has to be controlled. We currently have two gateway computers, one in RAL and one at ULCC, for providing access to the public networks. Users are registered on one or the other but not both. The system in use at present was developed by Rutherford Appleton Laboratory several years ago and was mainly intended for terminal users. Use with bulk data transfers is also possible but somewhat inflexible. In addition, the registration of large numbers of users on these systems is proving an administrative burden on the staff of the Executive and the RAL accounts staff (who collect the money), so that we are forced to try to limit the number of accounts issued.
All this has led us to seek new ways of controlling and accounting for access. There has been considerable discussion on this item, but so far no real progress has been made in terms of a new system implementation. We hope to begin work in this area within the next few months, but it would be unrealistic to expect a new product in service before late 1987.
Many site computer services have received a block allocation of user accounts, and people interested in obtaining an account should initially approach the campus computer service.
EARN (European Academic Research Network) together with BITNET (American) and NETNORTH (Canadian), is a world wide network for academic use. About 600 computers from a variety of manufacturers are connected. IBM are generously financing the international communications lines until 1987 and have also provided equipment and expertise.
EARN uses the IBM RSCS communications protocols which provide a file transfer and mail service. Together with the other European academic networks, EARN will be migrating to use ISO protocols in the next few years.
There is a gateway between EARN and JANET at the Rutherford Appleton Laboratory. This allows file transfer between computers connected to JANET and to EARN, BITNET or NETNORTH. The JANET computer has to provide Blue Book File Transfer facilities. The Gateway will also allow mail between computers on the networks. The JANET machines must have Grey Book mail and the machines on EARN, BITNET or NETNORTH should be running a compatible mail system (which 50 percent of them do already). It is possible to pass mail through EARN to many other networks both in Europe and America. The development of the EARN gateway has been financed by IBM but the operating costs are provided courtesy of RAL.
To use EARN a site has to 'join' EARN and sign the EARN Charter. This commits a site to use its best endeavours to ensure that the network is not misused. The principle misuse is to use EARN for commercial purposes but since JANET has similar, if not tighter, restrictions this is no problem. Currently the use of EARN is free, although it may be necessary to impose a small charge to defray administration costs. A larger charge may have to be set when IBM withdraw their patronage in 1987.
For further details, please contact me at RAL.
GIFT (General Internetwork File Transfer) is an implementation of a multi File Transfer Protocol Converter among a number of File Transfer Protocols. It allows users of a certain protocol (which usually implies a certain user interface) to see another protocol domain as an "extension" of their service network. This means that file transfer requests can be specified in terms of the usual services at the originating node, carried up to the gateway where they are trapped and relayed on to the second domain.
The protocols currently implemented are CERNET (the Wylbur IBM only at present), DECNET and Blue Book (the File Transfer protocol used by machines connected to JANET). For example, a Blue Book machine can initiate a transfer to the CERNET WYLBUR machine as if WYLBUR was a normal Blue Book machine, and also initiate a transfer to a DECNET VAX as if that too was a Blue Book machine.
The main use of GIFT at present is for Blue Book machines to perform file transfers to WYLBUR on CERNET (because previously the only way to perform file transfers to WYLBUR was to stage the transfer through another machine). It is planned to extend the range of CERNET machines accessible through GIFT.
If you would like more details on the present GIFT service please refer to the manuals GIFT LISTING and POCKDOC LISTING available on RL.IB in directory USDOC 193. (See the January/February issue of FORUM86 for details of how to access USDOC on RL.IB from another machine.)
Connection to JANET is supported by software written within the academic community, namely VMNCP, MVSNCP, NIFTP and CMS-PAD; MVSNCP runs under MVS, the rest under VM.
The X.25 (level 3) protocol is brought into the mainframe over Binary Synchronous links via a Memorex 1270 communications controller. VMNCP and MVSNCP handle the X.25 and provide direct support for incoming terminal calls to CP/CMS and TSO/Jobstatus respectively. Line-mode or 3270-style access can be used in both cases.
NIFTP and CMS-PAD are special applications which interface to VMNCP. NIFTP handles the Blue Book file transfer protocol (FTP), and the Grey Book JNT-Mail protocol. It provides the usual P-end and Q-end facilities for the transfer of CMS files in and out, together with facilities for shipping job input and output between JANET machines and MVS batch processing systems at RAL and elsewhere.
CMS-PAD allows logged-in CMS users to access (in line mode) any machine on JANET, or (in full-screen mode) any IBM system running VMNCP or MVSNCP. At least nine external sites now run one or other of these, including CERN and ULCC.
New developments to be implemented in the near future include the following. Binary Synchronous access via the Memorex 1270 will be replaced by HDLC access via an Amdahl 4705 front-end. This affects only the bottom-level code in VMNCP and MVSNCP. A gateway will be provided under VM to allow network mail to pass freely between the EARN and JANET domains. JTMP facilities are likely to be introduced under both VM and MVS, but the timescales remain uncertain.
Information for users on the mainframe machines at RAL is available in Help files on CMS. and in on-line Network User Notes on USDOC 193. The introductory Help file for FTP is obtained by typing HELP FTP. That file points to further Help files for P-end and Q-end working. It is also possible to type HELP at any stage during the FTP P-end user dialogue, to get information about what to input next. For CMS-PAD, a Help file can be obtained by typing HELP PAD.
CCD Systems Group has a VAX 11/750 which is used to provide central support for VAX networking software. This comprises DEC's PSI plus the FTP program from UWIST and the St. Andrew's PAD which are now supplied by DEC. Over 40 sites are supported in both the UK and Overseas (CERN, DESY, Saclay, etc). The sort of services which are provided include:
Both versions 3 and 4 of VAX/VMS are maintained together with the relevant versions of the network products. This is because version 3 is still required for development of the GIFT software (described elsewhere). Good contact is maintained with DEC through their normal support services and also through a quarterly progress meeting between representatives from their sales and engineering staff and other interested groups at RAL (CCD, HEP, ISIS, ID, EBL and Starlink).
We are continually being bombarded with requests for information about JANET. The dissemination of such information is a major headache, and we attempt here to indicate possible sources rather than to provide the information itself.
This computer is intended to provide on-line information about JANET and services connected to it. It is not intended to contain dynamic status information, but can be used to provide details of future plans as well as other relevant documentation. The NRS name of the service is JANET.NEWS (network address 000050005002). Once connected, log on as NEWS, after which you should be led through the responses required.
There are various newsletters circulated from time to time, some explicitly for network users and others, such as FORUM, containing information about Networks as well as other items. The main vehicle for network news is NETWORK NEWS, available from the JNT at Rutherford Appleton Laboratory.
RAL has published a number of user notes, available from the Documentation Officer at the Atlas Centre, Rutherford Appleton Laboratory.
A series of regional user groups has been set up to facilitate a dialogue between users of JANET and those who provide the service. Each site is entitled to two representatives. In practice, one of these should normally be a computer service representative and the other an end user. Many sites have had difficulty in recruiting an end user to attend the meetings, and I would urge end users to consider putting themselves forward as possible representatives by contacting their local computer service. Only by having end users present can these meetings be totally representative. The regional meetings appoint representatives to a National User Group, which meets about three times a year. The Chairman (or his nominee) of the National User Group is then ex-officio a member of the Network Advisory Committee, which oversees the work of the Executive on behalf of the Computer Board.
It is extremely difficult to ensure that information about possible down-times on the network reaches all Users. Scheduled down-times are necessary to ensure the continued reliability and smooth operation of the systems - for instance back-ups of system discs must be taken and new versions of the system brought into service from time to time. Consequently, we have defined an at-risk period during which we may take switches out of service without prior notification. This is from 8am to 10am on Tuesday mornings. If we believe a scheduled outage will last longer than this, or if we wish to do something outside this period, then we attempt to give users at least two weeks notice (see the NEWS machine). It should be said that interruptions to service in the at-risk period are fairly infrequent in any one switch and generally only last a few minutes.
From time to time there are bound to be faults in any system as complicated as JANET and its attached campus networks. A fairly detailed scheme for fault reporting has been devised; the bare essentials are listed below.
The basic concept is that faults should be reported initially to the point of contact with the network. This is generally expected to be within the Campus to which your terminal or host computer is connected. If the network staff there are satisfied that the problem is not local, then they (and not the user) should escalate the problem to the JANET Network Operations Centre (qv) to which the site is connected. Once this has been effected, the JANET NOC will take over responsibility for tracking the problem and ensuring that it is fixed, and will then report back on its resolution. A number of departmental minis and PADs are still directly connected to JANET, and users there should inform their local departmental manager of difficulties, again leaving it to the manager to contact the appropriate NOC.
There is a Network Operation Centre (NOC) at each JANET switch, manned by local staff who also normally deal with local network problems as well. It is their responsibility to deal with faults on JANET, to produce fault reports for a central database and generally to assist the Network Executive in providing an operational service on the network. They are normally able to deal with problems as they arise, but any particular problem which is not resolved within a few hours will be reported to (and may require action from) the Network Executive. As a final resort, if a user is not satisfied with the service afforded him, he may make use of the User Group structure to place his complaint ultimately before the Network Advisory Committee.
The aim of the NRS is to:
The NRS is not new, its history goes back to 1981 when the Joint Network Team (JNT) circulated a questionnaire with the intention of producing a manual directory. Open Meetings in 1982 and 1983 led to the basic design of the NRS and the database was started and "legal bodies" were invited to register. In 1984 the pilot version of the central NRS database was made available and the number of services registered slowly increased. Implementation of remote procedure calls and automatic distribution of output was proceeding. In 1985 some sites started using derived tables for their local services, while the number of registered institutions increased to over 130 and the number of registered entities to over 1300.
In 1986 the NRS service is scheduled to be moved onto a dedicated system. The naming scheme allows the components of the name to consist of alphanumeric characters plus a hyphen. It has two forms: STANDARD, which may be of any length, or ABBREVIATED, which is limited to 18 characters for the fully qualified name. It is hierarchical with components separated by full stops. Each fully qualified name (in both STANDARD and ABBREVIATED forms) include the domain identifier for the country and community, eg UK. AC. An example of a STANDARD name is UK.AC.UNIVERSITY.DEPT.SERVICE and UK.AC.UNIV.SERVICE might be its ABBREVIATED name.
Each "Legal body" is responsible for registering details of its own institutions together with details of systems and services available. The registration is made by the site NRS Technical Administrator who has access to the NRS database. The details registered for each system are: the STANDARD name, the ABBREVIATED name, the description of entity, the address, and the Yellow Book string for each of the following contexts: X29, TS29, NIFTP, MAIL-NIFTP, MAIL-X29, MAIL-TELEX, JTMP, JTMP-FILES, JTMP-REG, YBTS-NODE and YBTS.
System managers should know who their site NRS Technician Administrator is and ensure that details of their system are registered.
The NRS database holds a number of files to allow the Administrator to correct his own entries and find out details of other sites. It is not designed as a user service but as a source of network services and addresses for use by academic sites.
A description of the total JANET topology is beyond the scope of this document. However, Figure 2 shows the layout of the trunk network. You will note from this that the maximum number of hops between JANET switches is three. We are currently awaiting delivery of further 48Kbps links, to enable us to upgrade a number of links out of the Daresbury switch, namely those to ERCC, UMRCC, ULCC, and RAL.
Following the installation of new software on our switches, (which has been progressing since last Spring and is now complete) we had hoped for a period of stable running with only minor configuration changes of the type outlined above. However, the Government has recently approved substantial extra funding for academic networking, and a sum in excess of £1 million over three years will be available to further enhance JANET. The proposals contained in the Forty report, if implemented, are likely to produce a significant extra load on the network. This, together with new applications coming on-stream which require to ship large volumes of data quickly, leads us to believe that we must push ahead with plans to improve the throughput and response of the system, and, if funds permit, to look at ways of increasing the reliability still further. (It is unlikely that there will be any impact on the service from these new plans before mid 1987.)
Computer networks is probably one of the most confusing topics of the moment; even the experts are confused. To start to understand what it is all about a knowledge of the history is vital.
In the dark ages of the early 1970s networking was simple and easy and there was not much of it. Moreover it did not achieve a great deal. In general you went to the supplier of your computer and he connected up a few teletypes (remember those ghastly klackity klac devices!) and if you had plenty of money he would also connect up a few remote card reader and line printer devices.
Two developments ruined this cosy situation. First, sites started to install a variety of computers and it was painfully obvious that equipment bought to connect to one manufacturer's machine would not connect to another, resulting in a number of expensive networks around a single installation. Second, manufacturers started to produce more sophisticated networks which would allow groups of their computers to be interconnected with a richer range of facilities. Such networks had even less chance of connecting to a variety of computers.
Whilst such a situation obviously made the manufacturers happy, locking the customer into his products, it did not please the customer who was faced with a high cost and a restriction on his freedom to choose the best equipment for a job.
Clearly the solution to the problem was for all suppliers to adopt a common set of networking methods which would provide a rich set of facilities. Human nature (or is it corporate nature?) is not like that. Whilst everyone would pay lip service to such ideals, in practice the suppliers response was fine as long as these methods are based on MY ideas. In other words, expecting DEC to abandon DECNET in favour of the IBM SNA network methods was just not acceptable to DEC and visa versa.
The only route forward was to attempt to define a set of non-proprietary standards which all manufacturers could subscribe to. To cut a long story short, such an activity was set up under the International Standards Organization, and the so called Open Systems Interconnection standards have to a large extent been produced. This was quite a remarkable achievement.
So why isn't the world beating a path to the ISO standards? The first fly in the ointment is that manufacturers have already developed their DECNETs and their SNAs and these work very well. Why allow other manufacturers to interconnect their equipment to your machine easily, and why give up your ability to alter your protocols at will? The second fly is that manufacturers have tailored their hardware and software with great care and existing methods do not map with great accuracy onto the ISO protocols.
So what happens next? We, as the customers, have a choice. We make the best of what is offered or we take an aggressive approach and say we will only buy equipment which conforms to the ISO standards even though in the short term (which may be a lot longer than we would like) we will suffer the loss in richness of the facilities in the interests of achieving interworking and forcing manufactures to support standards enthusiastically. Ideally we would want to get to the situation where to buy a computer not offering ISO network facilities would be as inconceivable as wiring your house with anything but 230 volt equipment.
However, there is a problem, the ISO protocols are all things to all men and to make then really work you need to define so called Functional Standards. Functional Standards are based on the ISO ones but define exactly how a standard is to be applied. The definition of Functional Standards is now in full flight and the work has been supported by the European standards organizations CEN/CENELEC and the PTT organization CEPT. The academics are taking a keen interest and active part in this work and already Functional Standards for several areas are in draft form. It turns out that this work is far easier than the initial production of the basic standards.
One encouraging sign is that both IBM and DEC are dedicated to providing ISO networking. In fact in the case of DEC it is expected that DECNET will eventually migrate to conform to the ISO protocols. The smaller manufacturers such as ICL and GEC have always been keen supporters of ISO and they have made similar if not stronger comments to IBM and DEC.
You may now well ask when it will all happen. Not overnight- particularly in JANET where a very large network has to migrate from its current set of Coloured Book protocols to the ISO protocols without upsetting the users. The migration is expected to be on a 'functional' basis; an application such as mail will migrate on a particular machine possibly leaving the other applications unchanged. This requires that gateways will be needed al strategic places to convert traffic to and from Coloured Book and ISO methods. This will not be easy. Estimates range from 5 to 20 years for the complete migration. Fortunately the underlying X.25 JANET network is more or less ISO and so there is no need to set up a completely new network. Already there are examples of the ISO mail protocols operating experimentally within Europe and even within JANET, and the pace and extent of this work is increasing as the Europeans get their act together.
The UK in conjunction with all the other European academic networking groups has committed itself to the use of ISO protocols and there is now a vigorous movement to achieve ISO networking across the continent.
The basic principle is that if we all back ISO network methods then interworking problems will vanish. It is currently possible to get a better quality of service between sets of homogeneous machines using proprietary methods. However, the quality of the ISO products is likely to improve and it is worth having a little less quality now in the interest of a better tomorrow. (Do users agree?)
There are now a large number of ISO standards which are complete. The principle ones still to be finalised are job transfer and sophisticated terminal protocols. The most advanced ones are mail and X.25 (or rather its ISO equivalent); these have a lot of backing from the PTTs as they wish to base public services on them. The local area Ethernet standard is very mature which leads to the belief that this is a technology to follow.
There is now much more emphasis on the exploitation of the protocols. It turns out that the protocols have a lot of options in order to satisfy as many activities as possible. It is thus all too easy to implement non communicating but conforming products. There are a number of groups defining how interworking should be achieved and good progress is being made. These groups are Europe wide and not confined to academics.
It is gratifying to note that most manufacturers, including the two giants IBM and DEC, are producing ISO products. The protocols are being heavily backed by the European Community and nearer home the DTI and JNT. Migration from the current Coloured Book protocols used within JANET will take several years to achieve and there is a determination to make sure that this transition does not adversely effect the users.
The development of a high speed local area network has been far slower than expected; there have been many hardware and protocol problems. In fact it is still not possible to buy a network to connect a reasonable range of heterogeneous machines.
In the UK sites are constrained by the JNT, and rightly so, to follow various standards; in particular those being produced by ISO. Although hardware products are now fairly common the software to exploit this hardware is only available for a very small number of machines. At RAL local area networking is provided by the relatively slow X.25 network. There are a number of high speed networks put in for special or experimental purposes. These are based on Ethernet or Cambridge Ring technology.
There was a project to use Cambridge Rings widely on the site. Unfortunately the equipment required was so delayed that eventually confidence with some of the manufacturers was lost. It now appears that Cambridge Ring technology is unlikely to be popular or widely available and Ethernets are a much better option just now. Rather than plan a further local area initiative, a number of small scale experiments are under way to evaluate various products. In fact an interface to the large IBM computers has been developed, IBM PC products have been purchased and also interfaces for VAX computers. Considerable experience has been gained on the hardware aspects. There is still a lack of software but several promising products should emerge in the new year. Fortunately the demand for a high speed sitewide local area network is not strong; the large demand is for such facilities between specific heterogeneous machines in divisions, and this need can be met by pragmatic methods.
The following networking terms are just a few taken from a list of over 150 in Network User Note 16. Please refer to the January/February edition of FORUM86 for an article explaining how to access and print copies of these Network User Notes. The article also explains how to do this from machines other than the Central Mainframes at RAL.
This is a supplement to the March/April edition of FORUM86. It was compiled and edited by Jacky Hutchinson (User Support and Marketing Group, Central Computing Division, RAL) who would like to thank all those who contributed articles.
