Paul Bryant's Networking Correspondence
Dear Henrik,
Thank you for your letter concerning the support of the AUSCOM boxes on our IBM computer. I have now discussed your offer with my management.
We are happy to accept your offer of software support although indications are that it is working well and hopefully will require no attention. Are there any further formalities needed on this agreement?
We also intend to accept your offer on hardware maintenance of the equipment as set out in your letter. This is being progressed by my colleague Mr. Paul Thomson who will be in touch with you shortly.
Thank you for your help and I look forward to a trouble free future.
Yours sincerely
Paul Bryant.
Dear Odd,
I am sorry that the order for the G-box has taken so long. We had the offer from DEC on 7th December. This was late as I was attempting to make EARN the owners in accordance with the EARN policy. This proved impossible. My contracts division were unhappy with the offer as there was no indication of the responsibility for maintenance. Christmas also effectively lost us a week. However, a FAX was sent to DEC on Wednesday and I understand that the formal papers went to DEC yesterday (Thursday). Unfortunately, large organisations have contracts departments who are unhappy with unusual orders. I hope this is all behind us.
I have had my development VAX connected to the NT switch with only minor problems. I am connecting our IBM as soon as a cable can be laid when I hope to run some tests between the two machines to obtain some confidence. The connection between the UK switch and Irish switch has not yet taken place as there is a cable being made up for the Irish end.
You asked for details of the X.25.
Unfortunately all the NT documents are in Ireland and all I have is the output from the generation program from which it is not 100% clear exactly what the settings are. In addition some changes are being made. What I have done is to Xerox the relevant pages of the output and marked it with some comments. I also enclose the EARN documents on X.25 and addressing. The status of these papers is unclear since I wrote them and I have had no feed back from other EARN experts although they have been on file for a long time.
You will see that there is some discrepancy between the original addressing proposal and the one now adopted. This is because we have found that the NT switch has limitations on the addresses we can use. I am still having discussion with NT to find out exactly what our limitations are.
I attach a few pages from ENV 41 104 which I have marked. Unfortunately, the ENV refers to the DTE and not the DCE but none the less we expect the NT to communicate with conforming DTEs.
I hope this is the information you need.
Yours sincerely
Paul Bryant.
TMPC have asked NTMPC to set up a working party to study and report on the use of communications processors for the IBM. The committee is asked to set up the group and comment on the terms of reference.
What needs to be done to bring the 3745 into use?
Is there sufficient hardware for all requirements?
Is any additional software needed?
What activities are needed and by who to bring it into use?
What are the time scales?
What is the future of the 4705, 3705, and 3725?
What developments are expected for the 3745 in the long term?
Keith Benn Roland Brandwood Paul Bryant John Gordon (or representative) If necessary an IBM representative.
The working party will report to NTMPC and ISSC.
There are now two LISTSERVs and two mailers - one of each in the EARN domain and one of each in the JANET domain. Readers will be aware that this duplication is caused by the different ordering of the components of a mail address known as the 'domain ordering problem'.
+------------+ +------------+
| | | |
| LISTSERV | | LISTRAL |
| | | |
+------+-----+ +------+-----+
| |
+------+-----+ +------+-----+
| | | |
EARN-----+ MAILER +------------+ EARNGATE +----JANET
| | | |
+------------+ +------------+
Both LISTSERV and LISTRAL can support lists and file distribution in EARN or JANET. It is far more convenient and efficient for EARN lists to be in LISTSERV and JANET lists to be in LISTRAL.
The lists currently available are:
On LISTSERV-
HUMBUL 75 members. In support of humanities database. Most members are in EARN.
Owner May Katzen at Leicester.
JCGTEST 5 members. Test list for John Gordon. Owner J Gordon.
VUGMEMB 37 members. Used for messages to the SERV VAX group.
All members are in the UK. P Chiw.
VAXVMS 140 members. An open list for discussions on VAX and VMS.
Most members are in the UK. Owner P Bryant.
On LISTRAL-
DEARRAL 1 member. Not in use. Expected to be used to collect
comments directed at CCD. Owner P Bryant.
PLASMAS 1 member. Not is use. Expected to be used for the plasma
physicists using the super computer. Owner Carol Nairn.
The GEC supports about 80 lists. 70 of these are for JNT. Of the remaining 10 only 2 or 3 are for CCD and include the FORUM and FLAGSHIP lists which are very small.
Mail and mail distribution lists are an important use of networks. Originally, within CCD, distribution lists were provided on GEC computers and these are no longer well supported. The continued provision of list facilities on these machines could prevent their removal. LISTSERV provides an alternative and more sophisticated service. Being used on 100 or so machines it is better supported than the GEC mail.
LISTSERV provides three services:
Mail distribution operates by the subscriber sending mail to a userid with the name of the list. LISTSERV transfers the mail to itself and then distributes it.
The list is kept in a file on LISTSERV's disc. The list is manipulated by sending mail messages to LISTSERV. A list has an 'owner' and he sets up the characteristics of the list - for example, who can join it, whether it is moderated, where failures go, and so on. In general users add and subtract themselves to and from lists. Lists may me free for all to join or restricted, they may be open for all to send mail to or restricted to members of the list. Thus little effort is needed to maintain lists.
Lists which span both EARN and JANET are awkward as traffic from JANET to an EARN list has to be forced through the two MAILERS to get the domain order correct. This requires entries in the tables of both MAILER and EARNGATE.
The effort required to maintain a list is to set it up in the first place which is about an hour's work. After that failures have to be monitored. These are frequent due to the curiosities of other mail systems. There are often questions from the users.
So far 3 working distribution lists have been set up. The major one is VAXVMS which has attracted 150 clients and an average of about 6 messages a day. This list is on the EARN side and should really be moved to the JANET side.
Proposals to amalgamate the two mailers should not effect the use of lists.
The file distribution facility allows a subscriber to register an interest in a file or group of files. When the file is changed a copy will automatically be sent to the subscriber.
In addition a file may be sent to LISTSERV with a header defining who the file will be sent to. It will then be distributed using other LISTSERVs in order to reduce network traffic.
Files may be requested from the data base by sending a mail message to LISTSERV containing a request for a file, files, or directories.
The documentation for LISTSERV is contained in the data base and users are encouraged to fetch their own copies.
A file-list is set up by sending a directory to LISTSERV. The owner of the database can maintain the databases with minimal intervention from Computing Department staff.
Three data bases have been set up. One for the the humanities containing about 100 files, one for EARNs transition containing 20 files, and one for the minutes of EARN meetings containing about 20 files.
If a supported mail distribution, file distribution, or file data base service is to be provided then a suitable staff level must be provided within Service Group. The effort required depends on the use to be allowed. However, a major part of the effort is understanding LISTSERV and the incremental cost of each list is small. For 30 lists and 200 files 0.25 of a person is required. If the current lists on RL.GB are to be moved this will require an additional two man months to move the lists.
The lists on the GEC are maintained by S Wood of JNT with some help from W Knowles. There are 86 lists many of which are dormant.
Computer costs depend on the traffic generated. The current costs of the EARN gateway and LISTSERV are 0.3% of the IBM and the additional traffic caused by lists may give an increase of 0.1 which is a guess.
The documentation is good - at least for EARN users. For JANET users it can be confusing as examples are always from EARN. It is suggested that a short introduction for JANET users should be provided.
Because of the curious situation of there being two LISTSERVs - one in EARN and one in JANET - additional documentation is needed for support staff. This is under production.
It should be added that tables and diagnostics that users see from time to time can be confusing as they refer to UK.AC.RL.IB as UKACRL and addresses are often in EARN order. It is proposed to modify the messages for LISTRAL to reflect NRS names
The use of lists by SERC and the supported activities needs no justification.
There are several other groups who would like facilities who are not supported such as the existing VAXVMS and HUMBUL lists.
It is recommended that:
TMPC have asked for a statistics section in the Quarterly Progress Report in order to give some sort of comparison between various access methods and to identify weak components.
It is impossible to compare the various access methods accurately. I am proposing that we provide a table of 'interesting figures which we fill in as best we can. Section 2 shows the draft of a possible section for NTMPC comment and approval.
The table below shows performance and failure figures for the various network components on the Rutherford site. Comparisons between various access methods are not comparable and must be read with some background knowledge. Major incidents are ones where a substantial number of connections are lost. Minor incidents are ones where only one or a few connections are lost.
Component Major Minor Traffic passed Traffic number
incidents incidents Mbytes/quarter of calls
X.25
JPSE 1 6 234 na
CPSE 1 0 4 50 na
CPSE 2 2 1 75 na
lines/modems 0 1 - -
PADs 1 3 na na
Backbone LAN
Backbone H/W 0 0 75 np
Backbone S/W 0 0 - -
CCD LAN
CCD LAN H/W 1 0 50 np
CCD LAN S/W 0 0 - -
Hyperchannel
H/W 0 0 np np
PIXNET
PIXNET H/W 0 1 np np
PIXNET S/W 0 0 - -
PACX
PACX H/W 0 3 np na
VAX VMSFE
Ethernet H/W 0 0 np np
Ethernet S/W 0 1 - -
X.25 H/W 0 0 na na
X.25 S/W 1 2 - -
SUN ARCU
SUN H/W na na na na
SUN S/W na na - -
IBM
4705 H/W 0 0 na na
4705 S/W 0 1 - -
VTAM 0 6 na na
VMNCP 0 0 na na
AUSCOM H/W 0 0 np np
AUSCOM S/W 0 1 - -
3270 H/W 0 6 np na
3270 S/W 0 4 - -
Note:
np indicates that it is not possible to provide figures.
na indicates that figures could be made available with effort.
- indicates that the figure is not relevant.
It is realised that it is not possible to collect many figures and that producing further ones will require effort. It is intended that in the introduction to the Quarterly Progress Report it will be noted that should further or more detailed figures be required then this may require further effort which will have to be sought by the managers of the various groups. The statistics section will not prevent the inclusion of further statistics and comments in the various sections.
Italy proposes to operate SNA between CNUSC and CNUCE. The Executive is invited to approve the proposal.
Stephano Trumpy states-
I notify that CNUCE and CNUSC plan to move their link from BSC to SDLC. The usage of SNA will improve the efficiency of the network. At present the technicians are testing the SNI interconnection and we foresee to be ready by the beginning of February. Specific attention will be paid to the parameter definition which will not allow interactive traffic; at present only the 'link in object' will be connected to the international backbone in SNA mode not allowing virtual circuit coming from other nodes in Italy other than ICNUCEVM. We are waiting for other international nodes to adopt SNA in order to establish virtual circuits especially serving connections with nodes having higher traffic from and to Italy (CERN, CUNY). This situation will be maintained at least until we upgrade the present line speed.
Provision of high speed workstations from Daresbury into the Cray.
Provision of high speed workstations from RAL to high speed computers at Daresbury.
The ethernets at Daresbury and RAL will be connected by means of bridges and a 256K band on the JANET Megastream links. TCP/IP protocols will be used.
There are a number of problems which have yet to be resolved which include:
The Vitalink bridges will be bench tested. It was originally thought that a modem eliminator would be required between the bridges, this is incorrect.
The bridges will be moved to the VAX area. Tests will be carried out with SUNs and or PCs to check that they can operate across the bridges. This will require the SUN to be taken out of service for short periods.
One bridge will be connected to the development ethernet and the tests repeated. A VAX will be connected to the remote bridge and tests carried out to ensure that the bridges provide adequate filtering. It may be necessary to consult Vitalink and or DEC if there are difficulties.
The local bridge will be re-located in Telecoms and the connection made to the Daresbury bridge and a vestigial ethernet at Daresbury and tests will be repeated. Daresbury have purchased an alternative model of the bridge and this may cause problems.
The remote bridge will be connected to the Daresbury ethernet and further test run. Great care will be needed as this will be potentially disruptive.
The local bridge will be moved to the CCD service ethernet.
Order Vitalink bridges for RAL (A Jesset) Complete Delivery of bridges (Vitalink) Feb. 14 Order modem eliminator (R Brandwood) Not needed Possible order of multiplexer cards (R Brandwood) A.S.A.P. Testing at RAL (A Jesset) Apr. 14 Possible delivery of multiplexer cards (R Brandwood) Apr. 21 Harmonisation of IP addresses (ID) Apr. 21 Locate equipment in Telecomms (R Brandwood) Apr. 21 Connection to Daresbury (R Brandwood, A Jesset, DL) May. 1 Tests to Daresbury (A Jesset, DL) May. 14 Service May. 14 Change of broadcast address (ID) ?
Tests of bridges etc. 3 man months A Jesset
DECNET tests 2 man weeks M Waters
Telecoms 1 man week R Brandwood
Management 1 man month P Bryant, G W Robinson, R Evans,
B Day, A Jesset, M Waters
ID resources 1 man week B Day
DL resources Not charges to CCD
Dear Dr. Terpin,
I enclose some documents about EARN.
As we discussed it is probably best if you access EARN via Daresbury or Liverpool and you would have to organise this with the relevant computer director.
I require a letter from you asking for associate membership of EARN. You need to state that you wish to communicate with your associates in university x for purposes of non commercial academic research. You should state that you have read the 'EARN charter' and the 'code of conduct' and agree to abide by them. I will forward your letter to the membership committee with a recommendation for approval.
I hope you will be able to negotiate suitable arrangements with Daresbury or Liverpool.
Yours sincerely
Paul Bryant. EARN UK Director.
Present: Eric Dunford, Klaus Blank (ESOC), Peter Smith (BNSC) Mike Palmer (RAE), Ian Smith, Mike Hapgood, Dave Territt Chris Muller, Dave Giarretta
Klaus gave a long description of the ESA communications ideas. In brief:
In the past a lot of lines have gone in for specific purposes. It is recognised that a lot of rationalisation is possible. Ideally they would like a single unified network. The ideas presented exclude telemetry links and is restricted to the management and non time dependent scientific activities.
The community involves academic scientists, industry, and banks (yes - they want to do all their finance via their network).
There are two main communities - IBM using RSCS SNA and PROFS - DEC using DECNET. There is a growing TCP/IP community.
Because of the many pressures they are unable to impose a quick clean solution but have to move in an evolutionary way towards their goal.
They appear to have a lot on money.
The first objective is to form a network of physical channels which can be used for any purpose. This is provided by a network of 64K and analogue circuits which connect to 'Link' multiplexors from Timeplex. The multiplexors are sophisticated and have a management scheme allowing the easy setting up of end to end real connections.
The various links are used for X.25, RSCS, SNA, TCP/IP or whatever is needed.
As time progresses it is hoped that the level of commonality can be raised from real connections to virtual X.25 connections and possibly higher. Clearly it is possible for DECNET and SNA to move in that direction although ESA seems to have reservations over the performance of SNA over X.25. Ways of operating TCP/IP over X.25 are emerging which could be useful.
Klaus showed many maps. This showed a core high speed network between ESTEC (Holland), ESOC (Darmstadt), ESA (Paris), and ESRIN (Frascati) with large multiplexors at each site. Shown were some 30 connections to other sites. There are two connections to PSCS (NASA). They use the same multiplexors but as the NASA addresses clash there is some 'jiggery pokery' with back to back multiplexors between the two domains. About 8 of the lines are shown as 64K.
Klaus commented that international 64K digital connections are currently very poor compared with the analogue ones. In many cases connections are impossible - for example to Italy.
They are concerned at the tariffs in Germany and like EARN are thinking of pulling out except for a single connection.
They expected that the introduction of 64K would give them plenty of bandwidth but this has already been taken up.
The maps show connections to public and other data networks. These are expected to be via gateways as they are frightened by security.
They have some X.25 based on switches from Hughes Aircraft which are apparently also used by Hewlett Packard and Motorola.
There are already links to the UK via British Aerospace. ESOC would be happier for a UK connection to come via a non-commercial site. BNSC is a vestigial organisation and so has no infrastructure. RAE is not strong in communications. This leaves RAL.
The proposal is to install a 64K line between ESTEC and RAL with a multiplexer at RAL. This would onward link to BAE Stevenage, BAE Bristol, RAE Farnborough via existing or new lines.
At RAL there would be a DECNET connection to the local network of VAXes. There would also be an RSCS connection for the IBM and PROFs.
It is unclear what the connection to RAE would be as they are bereft of VAXes, they have a PRIME, and they seem to want interactive access. The connections to BAE would seem to be via multiplexer links.
We talked about an X.25 switch at Rutherford and this is not seen as a short term requirement although in the long term it would seem to be in line with ESOC's ideas.
All lines and equipment would be funded by ESOC. ESOC would arrange maintenance contracts for equipment.
Klaus expected that it would take 2 days a year to look after the equipment. This seems a bit low to me but I suspect that the amount of effort is small and could come out of the support we already supply to the Department. I estimate that it would take a week's effort to order and install the lines and equipment.
It is suggested that the lines should terminate in Telecoms area and we would have to find room for a single 19 inch rack supplied by ESOC. There may well be connections to the DEC router, the ethernet, and the IBM and further study is needed to evaluate the requirements.
There was a long discussion on the legalities of the operation which like most discussions got nowhere.
A straw poll identified about a dozen projects which would use the connection depending on which rockets went up or not.
Another long and fruitless discussion on the sharing of lines, MDNS and EARN. The arguments from ESOC were that from a security point of view it was frightened to use other networks. They had spoken to MDNS but there seemed to still be a credibility gap which put it beyond the timescales of ESOC. They have a connection to EARN but as with MDNS they have little faith that EARN could provide what they want. I have to agree in that they already have many more international lines than EARN does and of greater bandwidth.
The general view was that the project should proceed subject to no nasty problems and that Dave Giarretta should co-ordinate activities. Dave was the only person out of the room at the time!
Currently I can see that the link will have substantial benefits for RAL. I have to accept the manpower figures from Klaus but I think they are on the low side but none the less my view is that they are small. I suggest we support the connection but monitor its progress carefully.
Appended is a table showing what the countries contributions would have been in 1989 if all countries were paying the full year. This gives an indication on a possible share of EARN expenses in 1990.
This proposal does not take account of any reduction due to the possible use of MDNS, which was requested by the BoD, since before including that, further information on the possible saving is needed.
For the same reason, the 1991 forward look is not included.
-----------------------------------------------|-----------------|------------| | | 1990 PROPOSED EARN BUDGET | Expenses | Income | | | | | | |-------|--------------------------------------|-----------------|------------| | 1. | PRESIDENT OFFICE | | | | 1.1 | *(1) Salaries (Secretary) | 12 | | | 1.2 | Travels | 20 | | | | | --------- | | | | TOTAL : | 32 | | |-------|--------------------------------------|-----------------|------------| | 2. | EARN OFFICE | | | | 2.1 | Salaries /Manager | 75 | | | 2.1.1 | Secretary | 30 | | | 2.2 | Travels | 20 | | | 2.3 | Telephone | 8 | | | 2.4 | Space rental | 8 | | | 2.5 | Miscellaneous | 8 | | | | | --------- | | | | TOTAL : | 149 | | |-------|--------------------------------------|-----------------|------------| | 3. | EARN STAFF | | | | 3.1 | Salaries (4 people/10 months) | 160 | | | 3.2 | Travels | 40 | | | 3.3 | Miscellaneous | 8 | | | | | --------- | | | | TOTAL : | 208 | | |-------|--------------------------------------|-----------------|------------| | 4. | OTHER EXPENSES | | | | 4.1 | RARE fee | 1 | | | 4.2 | EXEC meetings (Four) | 20 | | | 4.3 | Other travels | 30 | | | 4.4 | Printing | 12 | | | 4.5 | Auditor | 3 | | | | | --------- | | | | TOTAL : | 66 | | |-------|--------------------------------------|-----------------|------------| | 5. | EARN INTERNATIONAL LINES | | | | 5.1 | EARN backbone | 1800 | | | 5.2 | Line MOP-CUNY | 115 | | | 5.3 | Second US line (9 months) | 115 | | | 5.4 | *(2) X.25 backbone (9 months) | 190 | | | 5.5 | Lines speed upgrade | 170 | | | | | --------- | | | | TOTAL : | 2390 | | |-------|--------------------------------------|-----------------|------------| | | T O T A L B U D G E T | 2845 | | |-------|--------------------------------------|-----------------|------------| | | EARN backbone | | 1800 | | | Manufacturers' contribution | | 300 | | | Countries' contributions | | 745 | | | | | ---------| | | TOTAL : | | 2845 | |----------------------------------------------|-----------------|------------| *(1) 50% of secretary's salary to be paid by UNI-C *(2) Difference between 64 Kb lines and 9.6 Kb lines
EARN countries contribution based on 1989 algorithm, showing full year contribution for all countries, including those which are not yet connected.
1.ALGERIA 18 299
2.AUSTRIA 19 561
3.BELGIUM 20 823
4.CYPRUS 2 209
5.DENMARK 18 299
6.EGYPT 10 096
7.FINLAND 17 984
8.FRANCE 79 822
9.GERMANY 94 019
10.GREECE 10 727
11.ICELAND 2 209
12.IRELAND 9 150
13.ISRAEL 9 465
14.ITALY 64 362
15.IVORY COAST 2 524
16.LUXEMBURG 2 524
17.MOROCCO 5 048
18.NETHERLANDS 31 550
19.NORWAY 18 615
20.PORTUGAL 9 150
21.SPAIN 34 705
22.SWEDEN 28 080
23.SWITZERLAND 28 711
24.TUNISIA 4 417
25.TURKEY 17 984
26.UNITED KINGDOM 74 774
27.YUGOSLAVIA 17 353
TOTAL : 652 460
To: All those who plan to attend EARNTECH, EARN-NOG, EARNEXEC, and/or EARNBOD on Crete, Greece, in May, 1989.
From: Stelios Orphanoudakis
Subject: Hotel Reservations
Note the following dates:
Th.-Fr. May 25-26 EARNTECH, EARN-NOG Sat. May 27 EARNEXEC Mo.-Wed. May 29-31 EARN89 Th.-Fr. June 1-2 EARNBOD
Please use the form below to indicate your arrival and departure dates so that we can reserve rooms for the preEARN89 and postEARN89 meetings. It is important that we receive your hotel reservations as soon as possible. For those who may want to turn this trip into a holiday on Crete, there will be additional information included with the 2nd Announcement which you will receive by regular mail. However, if we can help you with anything, please send a message to the EARN89 electronic address shown below.
Those of you who have sent in the similar form included with the EARN89 2nd Announcement, please do not send a duplicate form unless the other one does not include the extra days above.
-1- Minutes of the 1st meeting - Montpellier, September 5 -2- First status report dated 20 September. -3- Minutes of the 2nd meeting - Montpellier, December 6
The above documents are appended.
-1- CNUSC will send an organisation chart to be included in the final
report.
-2- CNUSC will define an emergency procedure available from any node
24 hours a day, 7 days a week.
-3- CNUSC will define a new procedure for sending messages to LINKFAIL.
-4- Eric Thomas will change the 'REPLY' option of LINKFAIL to
'REPLY to SENDER'.
-5- CNUSC and CUNY will co-ordinate their technique to restart the line.
The objective is to have less than 5% downtime (monthly average).
If a regular restart is chosen, it should be 5 minutes or less.
-6- It is recommended to CNUSC to investigate the possibility to have
a dedicated computer as EARN international node.
-7- CNUSC is requested to produce statistics on lines down time
(including CPU down time).
-8- CNUSC is asked to look at the possibility to have trained operators
24 hours a day, 7 days a week.
-9- CNUSC and CERN are requested to investigate the problem of idle line
even when queues are not empty and to propose a solution.
-10- It is recommended to CERN to use RSCS V2 to communicate on lines
with RSCS V2 at the other end.
-11- CNUSC is requested to suppress the priority ageing on files queued
on international lines, and, more generally, to implement all EARN
directives.
-1- Done. See previous minutes/status report.
-2- Done. See previous minutes/status report.
-3- Done since January 15, 1989.
-4- Done. See previous minutes/status report.
-5- Done. See previous minutes/status report.
Notes: A) CNUSC restarts the line every 3 minutes and CUNY every
----- 5 minutes.
B) Due to satellite problems, the line between FRMOP22 and
CUNYVM is down at least once every day (but not for a
long time).
-6- No immediate action. See first status report. Checkpoint next April.
-7- LMON, the Eric Thomas's procedure cannot easily be adapted to JES2.
Other ways (such as NETMASTER) are investigated, No implementation
date available now. Checkpoint next April.
-8- Not possible. See first status report for more details.
-9- The problem disappeared with the use of the 64 Kb/s line since
February 2nd.
-10- Done. See previous minutes/status report.
-11- Done. See previous minutes/status report, and report on
implementation of directives/recommendations.
Participants: J.L. Ambrosino CNUSC - Montpellier
Michel Auffret CNUSC - Montpellier
Alain Auroux EARN - Paris
Jose Maria Blasco GMD - Bonn
Jean-Loic Delhaye CNUSC - Montpellier
Olivier Martin CERN - Geneve
Eric Thomas CERN - Geneve
As Montpellier is the most important EARN international node, with nearly 50% of the international lines, including both 64 Kb/s lines, the availability of this node should be very high, particularly on the most heavily used lines (to USA, CERN and Germany).
In the past few months, there have been complaints on the availability of this node, and more precisely on the availability of the lines to CUNY and to CERN.
The objective of this meeting was to review the validity of these complaints, the actions already taken by Montpellier, and to recommend further actions if needed.
-1- Difficulty to contact people in Montpellier having technical
networking responsibilities on EARN.
J.M. Blasco distibuted an organization chart of GMD Bonn showing
the responsibilities of various people involved in EARN.
ACTION:
J.L. Delhaye will provide the same information for Montpellier.
-2- When a problem in Montpellier is detected from another node, it is
difficult to get an answer/explanation from Montpellier when
Dominique Dumas is absent (week-end, night...).
ACTION:
Montpellier will define an emergency procedure available from any
node 24 h/day. This procedure will not be through telephone, as many
people have difficulty to access foreign telephone numbers.
-3- Messages posted on LINKFAIL by Montpellier are not explanatory enough
and are sent using a standard form.
ACTION:
Montpellier will define a new procedure for sending messages to
LINKFAIL:
- Reasons for failures will be explained
- Messages will be signed, and it will be possible to reply to
the sender (for example to ask for additional information).
- Scheduled downtime (maintenance) will be announced only once.
- Link down will not be reported if shorter than one hour
- Unscheduled link down will be explained afterwards if longer than
one hour (at least on the major links, and during prime shift).
ACTION:
Eric Thomas will change the 'REPLY' option of LINKFAIL to
'REPLY to SENDER'.
-4- On the line MOP-CUNY, the technique used at both ends of the line
to restart it is different (MOP restarts every 10 minutes, and
CUNY when a cut down is detected). This leads to an unacceptable
down time.
ACTION:
CNUSC and CUNY will coordinate their technique to restart the line.
The objective is to have less than 5% downtime (monthly average).
If a regular restart is chosen, it should be 5 minutes or less.
-5- The line MOP-CERN was not reliable enough during the past months.
A new communication controller is installed at CERN since 17/8.
No specific action is needed.
-6- Based on other international nodes experience, a small, dedicated
computer is generally more reliable than a big, general purpose,
computer. As FRMOP22 is the EARN international node with the greater
traffic and the greater number of lines, it would be better to
have all EARN international lines in Montpellier on a small,
dedicated computer.
RECOMMENDATION
It is recommended to CNUSC to investigate the possibility to have
a dedicated computer as EARN international node.
ACTION
CNUSC is requested to produce statistics on lines down time
(including CPU down time).
-7- FRMOP22 operators are present only from 6:00 to 20:00 (week days)
and 6:00 to 13:00 (Saturday). No operator on Sunday.
ACTION
CNUSC is asked to look at the possibility to have trained operators
24 hours a day, 7 days a week.
-8- It is a protocol problem on the CNUSC-CERN line: it happens that,
after a line failure and a restart from CERN, JES fails in attempting
to re-establish the connection. This means that, although the line
is up, it is in wait state at both ends, and no files are sent, even
when the queues are not empty. Automatic procedures to restart
the line are useless, it is then needed for operators at both ends
to speak to each other.
If this happens when it is no operator at CNUSC, the line stays down
until the next day (or next Monday if during week-end).
ACTION:
- See point 7 above
- CNUSC and CERN are requested to investigate this problem, and
to find a solution.
- It is recommended to CERN to use RSCS V2 to communicate on lines
with RSCS V2 at the other end.
-9- CNUSC uses a priority aging on files queued on the EARN lines: this
may cause a huge file to be sent before smaller ones. This
is in conflict with the EARN directive number 1, adopted by the
BoD in April 1988.
ACTION:
CNUSC is requested to suppress the priority aging on files queued
on international lines, and, more generally, to implement all EARN
directives.
-1- CNUSC will send an organization chart to be included in the final
report. Due date: 12 Sep.
-2- CNUSC will define an emergency procedure available from any node
24 hours/day, 7 days/week. Due date for procedure definition:
12 Sept.
-3- CNUSC will define a new procedure for sending messages to LINKFAIL.
Due date for procedure definition: 12 Sept.
-4- Eric Thomas will change the 'REPLY' option of LINKFAIL to
'REPLY to SENDER'.
-5- CNUSC and CUNY will coordinate their technique to restart the line.
The objective is to have less than 5% downtime (monthly average).
If a regular restart is chosen, it should be 5 minutes or less.
-6- It is recommended to CNUSC to investigate the possibility to have
a dedicated computer as EARN international node.
-7- CNUSC is requested to produce statistics on lines down time
(including CPU down time).
-8- CNUSC is asked to look at the possibility to have trained operators
24 hours a day, 7 days a week.
-9- CNUSC and CERN are requested to investigate the problem of idle line
even when queues are not empty and to propose a solution.
-10- It is recommended to CERN to use RSCS V2 to communicate on lines
with RSCS V2 at the other end.
-11- CNUSC is requested to suppress the priority aging on files queued
on international lines, and, more generally, to implement all EARN
directives.
-1- CNUSC will send an organization chart to be included in the final
report. Due date: 12 Sep.
Done. Enclosed are the organisation charts from GMD - Bonn, Montpellier
and CERN
Name Function EARN Phone
Jose Maria Blasco All DEARN JMBLASCO@DEARN +49 228/81996-51
Manfred Bogen Concerns, MABOGEN@DEARN +49 228/81996-50
VM, RSCS,
LISTSERV,
EARNCC.
Jochen Hirsch Lines,NCP- GRZ028@DBNGMD21 +49 228/81996-44
System-Generation
Peter Sylvester EARNunder GRZ027@DBNGMD21 +49 228/81996-45
MVS, NJE, JES2
Peter Wunderling SNI, SNA, XI, GRZ017@DBNGMD21 +49 228/81996-46
X.25,AGFNet.
Klaus Birkenbihl Director of GRZ003@DBNGMD21 +49 228/81996-41
Computing Center
Name Function EARN Phone
Dominique Dumas EARN Country BRUCH@FRMOP11 +33 67 14 14 14
Coordinator (NCC)
Jean-Paul Sauter Telecom. lines SAUTER@FRMOP11 +33 67 14 14 14
and NCP, SNA, XI
Jean Oudeville etc... JEAN@FRMOP11 +33 67 14 14 14
Jean-Louis Ambrosino Operations manager AMBROSI@FRMOP11 +33 76 14 14 14
Jean-Loic Delhaye Technical director DELHAYE@FRMOP11 +33 76 14 14 14
Jean-Claude Ippolito Director of CNUSC IPPOLIJ@FRMOP11 +33 67 14 14 14
Olivier Martin All CEARN and CERN MARTIN@CEARN +41 22 83-4894
with respect to the
EARN service at Cern,
in general.
Central Cern Operations Everything CONSOLE@CERNVM +41 22 83-5011
(e.g. line problems)
should normally go
through them.
Eric Thomas On a voluntary ERIC@LEPICS +41 22 83-4992
basis, only! ERIC@CEARN
(LISTSERV, etc).
Dave Underhill Cern Operations (IBM) DJUCT@CERNVM +41 22 83-4920
Mick Draper Network Operations MICK@CERNVM +41 22 83-3348
-2- CNUSC will define an emergency procedure available from any node
24 hours/day, 7 days/week. Due date for procedure definition:
12 Sept.
PUPITRE@FRMOP11 will be the emergency contact, starting 1st of October.
The owner of this network address will be responsible for any further
action needed.
-3- CNUSC will define a new procedure for sending messages to LINKFAIL.
Due date for procedure definition: 12 Sept.
Starting 1st of November, the above mentioned network address
(PUPITRE@FRMOP11) will be the LINKFAIL interface. Operators are
presently being trained to efficiently send messages to and use
information from LINKFAIL.
-4- Eric Thomas will change the 'REPLY' option of LINKFAIL to
'REPLY to SENDER'.
Done. Today all LINKFAIL peers are Reply-To=Sender.
-5- CNUSC and CUNY will coordinate their technique to restart the line.
The objective is to have less than 5% downtime (monthly average).
If a regular restart is chosen, it should be 5 minutes or less.
Starting 1st of October, Montpellier will restart all EARN international
lines every 5 minutes. CUNY has been requested by Montpellier to react
to line failure as quickly as possible.
-6- It is recommended to CNUSC to investigate the possibility to have
a dedicated computer as EARN international node.
After a 6 month period, Montpellier will review the results of the
actions taken which should improve the availability of the Montpellier
international lines. If the improvement is not good enough (down time
higher than 5% on major lines) Montpellier will study the possibility
to have a dedicated computer as EARN international node.
It should be noted that the implementation of the OSI migration plan
will have an impact on the infrastructure.
-7- CNUSC is requested to produce statistics on lines down time
(including CPU down time).
This will be done starting 1st of October.
-8- CNUSC is asked to look at the possibility to have trained operators
24 hours a day, 7 days a week.
For budget reasons, this is not possible. However, night operators will
be trained to take simple actions, and to call at any time the trained
operator on duty if his presence is needed.
-9- CNUSC and CERN are requested to investigate the problem of idle line
even when queues are not empty and to propose a solution.
Since the meeting, the cause of the problem seems to have been
identified (monitoring of NACK) and remedies will be taken before the
the 1st of October.
-10- It is recommended to CERN to use RSCS V2 to communicate on lines
with RSCS V2 at the other end.
RSCS V2 already installed at CEARN, and will be operational soon.
-11- CNUSC is requested to suppress the priority aging on files queued
on international lines, and, more generally, to implement all EARN
directives.
Will be done no later than 1st of October.
Participants : J.L. Ambrosino
M. Auffret
A. Auroux
D. Dumas
J. Oudeville
J.P. Sauter
References : Minutes of the meeting and first status report dated 20 September.
-1- CNUSC will send an organization chart to be included in the final
report.
-2- CNUSC will define an emergency procedure available from any node
24 hours a day, 7 days a week.
-3- CNUSC will define a new procedure for sending messages to LINKFAIL.
-4- Eric Thomas will change the 'REPLY' option of LINKFAIL to
'REPLY to SENDER'.
-5- CNUSC and CUNY will coordinate their technique to restart the line.
The objective is to have less than 5% downtime (monthly average).
If a regular restart is chosen, it should be 5 minutes or less.
-6- It is recommended to CNUSC to investigate the possibility to have
a dedicated computer as EARN international node.
-7- CNUSC is requested to produce statistics on lines down time
(including CPU down time).
-8- CNUSC is asked to look at the possibility to have trained operators
24 hours a day, 7 days a week.
-9- CNUSC and CERN are requested to investigate the problem of idle line
even when queues are not empty and to propose a solution.
-10- It is recommended to CERN to use RSCS V2 to communicate on lines
with RSCS V2 at the other end.
-11- CNUSC is requested to suppress the priority aging on files queued
on international lines, and, more generally, to implement all EARN
directives.
The resources needed to implement some of the recommended actions were initially underestimated, and corresponding implementation dates shifted.
CNUSC is now committing to meet the new dates below.
-1- Done. The chart was included in the first status report. (20 September)
-2- Done. PUPITRE@FRMOP11 is the emergency contact since November 1st.
However, it is not used very much. A mail is sent on December 15.
to LINKFAIL to inform every body.
-3- For the moment the messages to LINKFAIL are sent from NETOPER
at FRMOP11, through an automatic procedure initiated by the
operator. No mail should be sent to this ID.
A new procedure will be define and operational on January 1st,
1989 to send messages from PUPITRE at FRMOP11 and operators
will be trained to use it.
-4- Done. See the 1st status report.
-5- Done. Since the 1st of November, CNUSC restarts the line with
CUNY every 3 minutes. Since the 1st of December, CUNY restarts
the line every 5 minutes. This additional delay was due to the
lack of answer from CUNY to the initial requests from CNUSC.
Note : Due to satellite problems, the line between FRMOP22 and
---- CUNYVM is down at least once every day (but not for a
long time).
-6- No immediate action. See first status report. Checkpoint next April.
-7- LMON, the Eric Thomas's procedure will be installed on FRMOP11 next
January, tested in February and the results published every month
starting in March.
-8- Not possible. See first status report for more details.
-9- The problem of the 9600 Kb line between CEARN and FRMOP22
is not identify, neither by CEARN nor by CNUSC but the
problem should be solved with the SNI 64Kb line.
-10- Done. See the 1st status report.
-11- The CNUSC suppressed the priority aging on October 1st.
The directive number 3 cannot be applied by JES2 sites:
JES2 is capable of multi-streaming but it is impossible
to dedicate a stream to large files.
Holding large files during the day is not today technically
possible.
Those of you who, like me, are a bit long in the tooth will remember the glories of Metronet which used manufacturers job entry protocols to pass jobs across concatenated machines. EARN works in the same way but with the advantage that only the IBM Network Job Entry (NJE) protocol is used. Although the protocol is not sophisticated its implementations are highly reliable, available on a wide range of machines, and well maintained by the manufacturers.
It has proved that it is possible to build networks with thousands of machines which work remarkably well. In the case of EARN, various services have been added to provide mail and database access facilities. The mail service has become particularly sophisticated with the advent of LISTSERV which allows linked distribution lists to be maintained thus reducing network traffic.
There are many good reasons for wanting to use better protocols. Store and forward networks are no good for interactive traffic, and they are dependent on large computers. There are also political pressures from CEPT, RARE, and others dedicated to the use of a common set of protocols for the community. The delay has been the lack of products and finding ways of insulating users from changes.
The low level protocol to be used is not surprisingly X.25. Discussions suggested that a strategy based on developments of TCP/IP towards TP4 had many unknowns and was at variance with current European ideas for wide area networks. The TP4 ideas are probably more appropriate for high speed networks (greater than 64K) and such lines look to be very expensive in Europe. X.25 is satisfactory for slow and sometimes unreliable lines currently available.
X.25 technology is now very mature and its characteristics well known. Equipment and software is reliable and easy to obtain.
Examination of the public networks revealed that they would be impossibly expensive for EARN traffic patterns. Costs would have risen by a factor of 10. It also seems that the data rates to be expected on public networks can be fairly low.
Thus a private network is being developed.
The strategy is to provide an international transit network. Each country would have its own network(s) which may be the current EARN service, a national X.25 network, or a network of some other technology. Thus there will be gateways or relays between the international part of EARN and national parts.
As an aside it is believed that this is a better model than the PTT one where each country connects to many others via bilateral agreements. With an international transit network a national network only has to negotiate with one other network and it is the international one which guarantees the bandwidth required with any other network.
Whilst the strategy looks nice and clean the practice is not so. There are a large variety of gateways and relays needed. For example:
The requirements for the switches and topology is to minimise costs and maximise performance. Unlike JANET, the line costs are very high, the number of connections low, and the cost of switches zero as they have been generously donated by Northern Telecom..
To maximise performance there would be one switch with a high speed connection to each country. To minimise costs there should be a number of switches located in low tariff countries.
The result of these conflicting requirements is to have 4 switches located in the UK, the Netherlands, France, and Switzerland. Although Switzerland is not cheap it does contain CERN which is a large source of traffic. These switches are to be interconnected by a square of 64K lines thus giving a measure of redundancy. The other countries will connect to the switches with existing 9.6K lines or new 64K lines depending on demand and finance.
The switches are being supplied free by Northern Telecom - model DPN100/20S.
These are near the bottom of the range of NT switches and have the following specification:
Further developments will allow the use of 2M connections.
Variations on the above configuration are possible to meet local requirements. Other models of the switch can be very large but they are all are made from the same basic components.
The switches are managed from a DEC VAX. Operator consoles connected to a switch are only able to interrogate its operation and cannot control it. All control comes from the VAX and all alarms are sent to it. In the event of failure the management can be taken over by another VAX in the network.
A lesson quickly learnt is that switches from different manufacturers are very different and reflect the market of the supplier. In the case of Northern Telecom the switches are designed with the needs of PTTs in mind where high reliability is demanded and very strict adherence to the CCITT recommendations. The addressing mechanisms reflect the needs of the public networks in that X.75 is provided and a network is to a great extent a set of switches with a common DNIC and X.75 connections to networks with different DNICs.
As EARN expects that eventually the international infrastructure will only interconnect other networks it is not expected that there will be a need for many ports. In the short term provision has to be made for a small number of connections into a country for an X.75, and other gateway connections.
The structure of a Data Terminal Equipment number on the international network is:
+-----------+---------------------+---------+-------------+ | DNIC | 3 digit country | 5 digit | 2 digit | | 4 digits | code based on X.121 | address | sub address | +-----------+---------------------+---------+-------------+
The DNIC is 2000 but is not registered with CCITT. It is unclear whether such a registration application would be successful.
The 3 digit country codes of each county connected to the switch is allocated to that switch and any equipment in that country has that code. The country code 200 is reserved for the network management equipment which needs a set of addresses.
The 5 digit addresses are allocated from 1 upwards.
The 2 digit sub address is not policed.
This structure reflects the transit nature of the network. Eventually it is expected that each country will either have an X.75 connection or a connection to a single gateway. In the short term there may be all sorts of connections to get over any temporary problems.
EARN will use the ISO DCC scheme for NSAP addresses. Where possible existing registrations of the academic communities will be used. This raises problems as there are few such registrations and it would be counter productive for EARN to make registrations as these would eventually cause some entities to have dual registrations. Thus in the short term EARN will 'invent' interim registrations.
There is also a problem with the part of the NSAP below the organisation as there are few schemes in existence and the directory mechanisms for NSAP to X.25 DTE are not available. EARN's interim strategy will be to place the X.25 DTE in this part of the address pending further developments. This will allow an algorithmic conversion from the NSAP to the X.25 DTE.
The principal requirement is to maintain the current services. This means devising a scheme for carrying NJE across X.25.
It was not feasible to convert NJE to FTAM, or similar schemes, since these would need a lot of implementation effort and there may well be loss of quality.
The first scheme studied was to run NJE across an IBM SNA session across X.25. This would be easy as the products exist. The draw back is that the software only exists for IBM machines and about half the machines are VAXes.
The second scheme, which has been adopted, is to implement NJE over ISO session layer. This can be easily implemented on VAX and IBM computers. It has the psychological advantage that it uses more ISO protocol than SNA session.
For an IBM computer the required code has been developed by IBM in Heidelberg. This uses the IBM ISO products OTSS and OSNS. The system is now available. This is known as an E-box.
For a VAX computer under VMS the required code has been developed by Joiners Associates using as a basis the JNET NJE code. It uses the DEC OSI products OSAK, VOTS and PSI. The system is now available. This is known as a G-box.
The scheme works by the E-box or G box operating as relays between NJE over X.25 and NJE over bi-synch. The E or G boxes set up virtual calls between each other over which NJE operates. Unfortunately it is not easy to detect the end of an NJE document and so the calls are left up permanently. This limits the number of E and G boxes which can be interconnected before you run out of call capacity. It is hoped to overcome this limitation with further developments which will drop connection on a time out or if the end of an NJE file can be detected.
The expectation is that there will be an E-box, a G-box or both in each country. DEC is kindly supplying the G-boxes.
Other ISO protocols are expected to operate over the network. So far the only one sufficiently developed from the point of view of available products is X.400. It is hoped that this will operate in late 1989. A gateway between X.400 and the currently used RFC822 mail is being developed by Joiners Associates and will reside in the G-box. Details of the use of X.400 have still to be worked out but will align with the Rare work.
Although not strictly ISO some X.29 interactive use is expected.
FTAM should be available in a year or so but it is to early to lay plans. JTM and VT are not expected in the foreseeable future.
EARN believes that Europe should be provided for by a number of national and international networks. These will provide services to all or parts of the community depending on who runs them. They should be interconnected under suitable arrangements and this implies that they use harmonised standards to allow the interconnection. The work of the functional standards groups, RARE, and COSINE will be followed if at all possible as EARN is not in the standards business.
Thus EARN expects to connect to national parts of EARN, other international, and other national networks. The exact nature of these connections is unclear. However, EARN would prefer X.75 connections as this follows the X.25 model which is well established. The connections will be very dependent on the plans within a country and it is not EARNs intention to influence a country in any particular direction as long as the service to the user can be maintained. None the less there are benefits in European countries following a common path.
P M Girard T Kidd R Brandwood W A Knowles B J Day P Chiu M Waters G W Robinson P Overy K W Benn P Gill
May I have your contributions for the communications QPR for November, December, and January. Please remember to give me information for the statistics section as defined in the NTMPC paper. Also, please try to keep to the style of the previous QPR.
Thank you.
Here is the current situation with respect to the funding of EARN and its effect on the transition plans of EARN.
The UK contribution to EARN central funds is 74774 ECU (49000 UKL) which was determined at the EARN Board of Directors meeting in October 1988. At that time the UK was unable to confirm their agreement as this would have to go to the NAC. The increased funding are as a result of the ending of the IBM contributions and the move towards splitting costs on a GNP basis rather than on the basis of the 'RARE keys'.
The UK international line cost is 55844 ECU (36600 UKL).
Bob Cooper issued a paper to the NAC requesting 35700 ECU (23000 UKL). A further 28000 ECU (18000 UKL) might be available for specific EARN projects. It is understood that the project funds would be for the use of the MDNS/COSINE X.25 network by EARN and cannot be seen as part of the EARN central costs. He sees the line capacity being provided free by the expected EARN 64K connection to CERN.
EARN has issued an invoice for half the full contribution noting that the second half is for further negotiation. In addition Dennis Jennings (the past president) will be writing to Bob Cooper.
I was asked by the EARN Executive to seek other funds for the support of EARN. I wrote to Bob Cooper to seek his approval and he replied that this would undermine his funding strategy and he was not happy for this to take place. Such funding sources could be SERC or 'associate' members.
EARN's migration strategy sees four X.25 switches (now in place) at RAL, CWI Amsterdam, CERN, and Montpellier interconnected with four 64 K lines. DEC will be funding the upgrade costs for such lines. Thus the two 64K lines from the UK would cost the UK 36600 UKL. In order to cut costs JNT have negotiated the loan of a 9.6K channel on the HEP line on a temporary basis (until end 1989) by which time they expect the EARN X.25 or MDNS/COSINE X.25 networks to be in place. They have therefore made no provision for the cost of the 9.6K line. EARN has ordered a 64K line from RAL to CERN for the X.25 network with an expectation that the RAL to CWI link would follow. In the light of the reluctance of the UK to part fund this line EARN is currently revising its plans. These are not yet definitive but envisage the EARN backbone being reduced to CWI, CERN, and Montpellier. To this end the lines CWI to CERN and CERN to Montpellier are being ordered. It is further envisaged that after the initial test between RAL and CERN the RAL to CERN line will be removed together with the UK switch. The Irish line will be relocated to CWI. A side effect will be that the Irish part of JANET will be removed.
A further complication is that the 64K HEP line to CERN is not yet delivered and it looks as though the EARN line will be very late. This will cause further funding problems by the need to retain the current 9.6K EARN line.
Dear Jean-Claude,
Here is my claim for my travel with respect to the EARN EXEC 23/24 February.
Air fare Paris 176.60 UKL
Please make cheque payable to 'Rutherford Appleton Laboratory'.
Thank you.
With best wishes,
Paul Bryant.
Although good progress is being made it is slow due to the low staff levels and the increasing work load. After a decade of X.25 and Coloured Book protocols with much of the developments 'in house' we are now moving into an era of new technology and new protocols. The hope is that the manufactures will supply all our needs. The truth is that changing the way we operate is difficult and time consuming. In addition, the adoption of manufacturer products seems to cause as much effort as DIY! Although it is hoped that we will come out of this phase with our communications absorbing little effort this desirable situation does not seem to be in the foreseeable future.
Any increase in staff to meet the current requirements is highly unlikely. Even if there were the compliment places attracting staff, especially good staff, is a slow process. The alternative would seem to be to put priorities on work and stop some activities. Unfortunately, it is often the maintenance that gets priority and the exciting tasks that get stopped or delayed.
1.1.1 JTMP Host-end Service
The specific problems mentioned in the last report have been satisfactorily resolved. There is currently another problem which is not too serious: that files are sometimes not purged from the VMJTMP reader after being processed. This is being looked into. There are also problems with getting status information out of the Cray, and with killing Slacbatch jobs.
The VM JTMP machine will not work under CMS 5.5. It is hoped that Salford will solve this, but if their timescale is too long we will probably have to provide an interim solution ourselves.
1.1.2 NIFTP
The main change to NIFTP has been to route all incoming mail from JANET to the Mailer virtual machine instead of delivering it directly to CMS users. This change is now firmly in place, but required several attempts to get it fully correct.
The new retry mechanisms for NIFTP introduced just prior to the last report appear to be working well. No problems have been reported.
All aspects of NIFTP are now compatible with CMS Version 5.5, and the NIFTP service at CERN already runs under that system.
1.1.3 NETJOB and NETFILE
The TRIKE meeting has agreed that the NETJOB portable user interface for JTMP should be supported at all the National Centres. We have now created a version of this based on the ULCC code, but adapted to submit the jobs via NIFTP in the same way as the existing RAL-JTMP interface. This implementation is ready to go into service at short notice, initially in parallel with RAL-JTMP. A deficiency of NETJOB relative to RAL-JTMP is that it has no status/modify support, so it seems sensible to retain RAL-JTMP as well, at least for a while.
It is not envisaged that NETFILE will replace the FTP user interface, but it could be provided as a secondary interface for those who prefer it or are already familiar with it on other systems. This is less easy to adapt than NETJOB, and at the moment no active work is taking place to implement it.
1.1.4 SSMP
Nothing to report. Usage of SSMP compared with Network/3270 remains low. It is believed that the software will work under CMS 5.5.
1.1.5 Pink Book
Still not a service. A fair amount of progress has been made, but this is slow due to competing commitments. The software now runs in a virtual machine called VMNCPE (instead of NGUN), and the maintenance of this software has been fully integrated with that of VMNCP. CMS-PAD and incoming line-mode terminal support have been added.
A MAC Registration database and associated software are being worked on.
1.1.6 CMS-PAD
No changes.
1.1.7 VTAM
VTAM is in service for supporting line-mode terminals, and for connections to Swindon via the special Lee Data equipment. There appear to be some problems with the latter, but not necessarily caused by VTAM.
VTAM itself has been upgraded to Version 3 Release 2, and this appears to have got rid of the un-reliabilities that showed up in abends of the VMNCP virtual machine. Version 3 Release 4 of the System Support Programs (SSP) package is also installed. These versions of VTAM and SSP are compatible with both the 4705 and 3745 front-end systems.
1.1.8 IBM 3745 and Amdahl 4705
A 3745 is now on site, and the necessary EP/NCP/NPSI versions to run in it have been ordered. A working party was set up and has produced a report: essentially its conclusion is that the 3745 should be able to take over the role of the 4705 in the fairly near future, assuming that the remaining problems with NCP/NPSI can be solved.
During another week-end session with NCP/NPSI in the 4705 a new problem has emerged: an abend of NPSI itself. As yet, all attempts to understand this have failed. The IBM Support Centre has been contacted.
The issue of how to apply necessary fixes to NPSI is unresolved. IBM at La Gaude have been sent the RAL fixes, and are considering whether they can provide equivalent 'official' fixes or not. If not, there will be a problem, as later versions of NPSI are 'object code only'.
There is a problem in the existing COMM-PRO software in the 4705, which causes calls to be lost occasionally for no apparent reason. Attempts to diagnose this have not succeeded. The problem should go away, fortunately, when we move to new front-end software.
1.1.9 Line mode terminal support
This service has been plagued by intermittent hang-ups at call set-up time. The problem was eventually found to be in VMNCP, and a fix has been installed.
1.1.10 VMNCP
Changes during this period mostly relate to the interface via VTAM/NCP/NPSI that is not in service yet.
However, the maintenance system for VMNCP has been totally reorganised on a better basis, and integrated with the maintenance of MVSNCP and VMNCPE (Pink Book). New documentation has been added covering IUCV support, line-mode terminals, VTAM, and the new VMNCP maintenance system. Most of the other documentation is also up to date again.
1.1.11 RSCS
Much work has gone into this, and a service is now available using RSCS Version 2.2. There are some minor problems being investigated, but in general it appears to be reliable.
RSCS Version 2.3 has been received and is being evaluated.
1.1.12 TCP/IP and the IBM 8232
Software and manuals for IBM's TCP/IP product have been received, and installation of the software is in progress. It is hoped to do some initial testing via the Hyperchannel.
TCP/IP has been made available on the Cray X-MP also.
The IBM 8232 hardware is on order but has not arrived yet.
1.1.13 Routine Maintenance
Nothing specific to report.
1.2.1 Production testing of Coloured Books over VTAM/NCP/NPSI using the 4705 will continue, and if possible a service using this method will be introduced. Depending on timescales, this might be superseded by a service based on the 3745.
1.2.2 Fixes to allow the JTMP services to run under CMS 5.5 will be needed, either from Salford or produced locally.
1.2.3 The NETJOB user interface for JTMP should be made available for service use.
1.2.4 There should be substantial progress with the TCP/IP software and evaluation of the IBM 8232.
1.2.5 The Pink-Book software will continue to progress as fast as possible towards service status.
In the longer term, migration towards ISO protocols using manufacturer-provide software.
2.1.1 LOCAL
a. The Two GPT CPSEs were merged into one on 5th November. Thus making a saving in recurrent cost and easier routing. The merge went smoothly and there have been no reported or observed degradation in the service. Coincidentally there has been an increase in the traffic levels, which appears to be associated with Vaxs and CERN traffic.
b. The PAD tables have been changed to support INFLOW to be X-ON/X-OFF, update of mnemonics and addresses, and to support TS29 calls by CALL TS29.address.YBTS string.
c. The SEEL Multipac has been brought into service to support X.21 links, it currently is connected to the JPSE at 64K, to the CPSE at 48K on V35, to CERN EXCITE at 9.6K, and the Spider X200 gateway. Ports have been allocated for CERN X.21 link when the line is ready and the Dec Router at 64K.
d. GPT type 3.1.1J was loaded on the CPSE but the load-sharing for the two lines into the JPSE did not work as expected - a SIR has gone to GPT about this and new microcode is expected.
e. The time to repair Pilkington boards leaves a lot to be desired and the power supply problems have not yet been resolved.
f. The multiplexors for the CERN 64K line have been delivered but as the line is not yet ready they cannot be installed and tested.
g. Camtec PADs still cause the most number of incidents, but most are fixed by local action and about 10 percent require boards or crates to be sent back to Camtec.
h. Seven line faults, three being international lines, were dealt with by BT.
i. Since becoming a production service there has been one fault on the LAN Backbone, this being the failure of one port on a Fibre Optic Multiport Repeater (FOMPR).
2.1.2 JANET
a. The JPSE is still not very reliable. GPT Engineering have visited on numerous occasions to set up analysers and make modifications. The number of C I TIMEOUTS has been reduced but not cleared. They now believe that the fault is due to interference being picked up on the channel cables and re-routeing of the cables has reduced the number of incidents. A new type of cable is being made and a further two mods are planned.
b. GPT Type 3.1.1J has been loaded, the first attempt was withdrawn as load-sharing for high-speed lines did not work properly. The second attempt was with load-sharing on the low speed lines only and this has not given any problems. 'Trapped Proc' errors are cured in this version.
c. A number of BT line problems have occurred. The major ones concern two NERC links, one to Swindon and the other to Wormley. The Swindon line gives a high number of errors, the problem was traced to the pairs between RAL and Rowstock but BT were unable initially to find a decent pair. BT National Support have been involved in rectifying the problem. During the test BT stated that the lines were routed via a frame-room in AEA Harwell and access at times is barred. A letter has been sent to BT expressing concern that lines are routed via a third party property. However the installation of the Kilostream Plus equipment will overcome this problem.
The Wormley line will not support 19.2K working; the number of errors on the line fluctuate in end to end tests. However 9.6K is OK.
d. The Swindon GEC was decommissioned and returned to RAL for the Network Executive. It was then re-configured to act as a third JANET/PSS gateway, to be situated at RAL but connected via the Megastream Multiplexer to the UMRCC JPSE.
e. The two PSS Gateways and JANET NEWS systems were moved within the Telecoms area during the Christmas/New Year period to allow room for the IBM 3745 comms controller to be installed.
f. The Cray VAX front end has had its name changed VMSFE and has had its connection moved from the CPSE to the JPSE.
a. Installation of the Cern 64k line and multiplexer.
b. Installation of the Kilostream Plus equipment and a migration of the Kilostream lines to it.
c. New connections for the EARN G Box and new Cray VAX Front End.
d. Reorganisation of Dial-up connections.
e. Installation of second Megastream line to Swindon and Megastream multiplexors for additional Lee Data Accelerators.
a. Automatic statistic gathering program for PADs and SEEL X.25 equipment.
There was a 10% decrease in the number of faults reported to the sub-section in this quarter, which included the Christmas period.
During the period 113 faults were reported to the sub-section, of which 50 were repaired by sub-section staff, some 44%. The remaining 63 were repaired by maintenance agencies.
The distribution of agency repairs is as follows:
MSM 31 Movable terminals
KODE 29 Non-movable terminals
SIGMEX 2 Sigmex terminals only
DPCE 1 Contract for Tally Printers
The 113 faults have been analysed for divisional distribution. Of this total, 38 (33%) were CCD terminals and the rest were handled for other RAL divisions.
___________________________________________________
| | REPAIR AGENCY | |
|Division|_________________________________| |
|-Project| TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|________|______|______|______|______|_____|________|
| ADM | 1 | | 5 | | | 6 |
| AG | | | | | | |
| ALVEY | 1 | | | | | 1 |
| BNSC | 1 | | 4 | | | 5 |
| CCD | 17 | 12 | 6 | 2 | 1 | 38 |
| CO | | | | | | |
| EBW | 3 | | | | | 3 |
| ECF | 6 | 1 | | | | 7 |
| HEP | 5 | 5 | 1 | | | 11 |
| ID | 5 | 5 | 4 | | | 14 |
| INS | | | | | | |
| ISIS | 4 | 4 | | | | 8 |
| LASER | | | | | | |
| ND | | | | | | |
| SL | | 1 | 3 | | | 4 |
| TEC | 7 | 3 | 6 | | | 16 |
|________|______|______|______|______|_____|________|
| TOTALS | 50 | 31 | 29 | 2 | 1 | 113 |
|________|______|______|______|______|_____|________|
No significant changes are expected during the next period.
This was a quieter period than usual for installations as the wiring contractors were busy for a large part of the time working in the ISIS area on safety wiring. This has meant that most of the work for data communications has been delayed. It is believed that the ISIS work will finish at the end of February and then the communications work can re-commence. Currently I would estimate the delay for jobs coming in now would be about two months.
As always, however, there were the usual round of office changes around the site entailing the move of connections from PACX to PAD to DECserver etc.
The CCD4 ether changed its status to Production. Fanout units are available to connect Services as they become available ( i.e. acceptable to the village manager and fully documented).
The GEC at Swindon Office was decommissioned.
Discussions were started with Harwell to provide connection to the Harwell Stores Database for stores personnel at RAL.
A number of Tricom MNP 5 modems were supplied to users to test a new trial 2400 bps dial-up service.
Another DECserver was installed in R25.
The MNP 5 2400 bps dial-up will become Production.
A 100 pair cable will be installed to R65 in order to rationalise the links to R12, R63, R65 & R66. The equipment in the R65 communications room will be rationalised when an air-conditioning unit is installed.
The coax cables to the R61 library should be installed.
Thin ether cables will be installed in the Atlas Centre for NNU and to provide links to R26 F1-F15. A thin ether cable plus other wiring will be installed between R25 & R46. A thin ether link will be installed in R25 for diskless SUNs and a file server.
Data links will be provided for the Chessington Payroll Project.
The following lines are on order with BT and BTI:-
a SWINDON Megastream
ordered Oct '88
due after March '89
b SHEFFIELD 64 Kilostream
ordered Oct '88
due Feb '89
c CERN EARN 64 Kilostream
ordered Oct '88
due Feb '89
d BRUSSELS analogue for Joint Research Councils' office
ordered Sept '88
due not known
e OXFORD New College for HEP conference
ordered Jan '89
due March '89
f Kilostream Plus
ordered Oct '88
due phased March onwards
Future PW Requirements
PW to BNSC at Millbank Tower London
5.1.1 Network Software
CBS V5.0 was released in mid-December and sites have started upgrading their systems with this software. A major problem was found with this release of CBS in that it failed to respond to a specific transport service error and caused a network process to go into compute bound state. This is thought to be due to negotiation failures in one of the switches in the path to CERN. This is still under investigation.
JTMP V5.0 was released at the beginning of this year. The major improvement in this release is the support of Task Status Enquiry.
LLC2 V1.1 was also released in late January. This release supports CBS V5.0 and provides a more transparent user interface to MAIL, FTP and X.29 over Ethernet.
5.1.2 Network Hardware
There has been no change of hardware on both the development VAX and the Cray VMS Front-End VAX.
5.1.3 Support Areas
The regular networking support of PSI, CBS and Red Book continues. In particular, some considerable efforts have been spent on assisting SERC VAX managers to install the recently released CBS, PSI, JTMP and LLC2 software. A new set of NRS updates have been produced to work on CBS V5.0. Queries on Pink Book, DECNet, LAVC, PSS/IPSS, VMS-COMMS, EARN and Janet mailshr (a VAX mail agent) continue to be handled.
5.1.4 Security
Shortly before the Christmas holidays, a "DECNET Worm" was uncovered in some machines at RAL in that a command file was found propagating itself around DECNet both at RAL and at other sites in the UK and abroad. The "Worm" did not seem harmful but it used up resources on machines in setting up numerous DECnet connections. This incident has been stopped and warnings have been sent around to other VAX managers with appropriate instructions to protect the systems against further attempts.
5.1.5 GIFT
No major problems have been reported. It has been confirmed that this service is to run down by 3rd April 1989.
Sites have started installing the recently released CBS, JTMP, LLC2 and PSI software. It is anticipated that considerable efforts will be required to resolve problems that they may come across when there is a growing use on the software from the users.
The Cray VAX Front-End machine is to be replaced by a cluster of a VAX 8250 and a VAX 3600 and at the same time, the CCD development VAX will be replaced by the existing Cray Front-End Microvax II. The replacement is scheduled to take place in mid-March.
The network statistics on the Cray Front-End had not been collected during this reporting quarter and are now waiting for further software development before they can be reported.
None identified.
6.1.1 NJE
Further changes to separate the EARN and HEP traffic have taken place and this is complete for the time being.
6.1.2 File transfer between EARN and JANET
No changes.
6.1.3 Mail
Line folding now takes place on incoming mail from JANET. This has reduced the amount of rejected mail.
All mail from JANET now passes through EARNGATE. This has reduced the large amount of rejected mail for distribution which had to be dealt with manually. There is now no difference between UK.AC.EARN-RELAY, UK.AC.RL.MAIL, UK.AC.RL.IB. There were a number of minor difficulties with users who relied on mail lines not being folded.
6.1.4 LISTSERV
The experimental lists are working well. The operation of the lists is manpower intensive due to the large amount of mail which is rejected by recipients and returned to the POSTMASTER. This is a failing of others mail systems - in particular UNIX systems have a habit of rejecting mail when their file stores fill up.
A few remaining problems have been solved mainly to do with looping mail.
6.1.5 EARN management
The poor performance at Montpellier has now been solved with the introduction of the CERN-Montpellier and Bonn-Montpellier 64K lines. Both these lines operate with SNA.
The December Executive meeting was mainly concerned with the mechanics of getting the new committee working. This now operated on NTMPC lines! The Executive is:-
Frode Greisen - Denmark - President Michael Hebgen - Germany - Vice President Paul Bryant - UK - Secretary General Jean-Claude Ippolito - France - Treasurer Stephano Trumphy - Italy Avi Cohen - Israel Dennis Jennings - Ireland
6.1.6 Transition
All the NT switches have now been installed. They have not been interconnected due to lack of lines. There is a 64K line on order between UK and CERN which was scheduled for mid February. This has not yet been delivered.
The G-boxes have been delivered to about 8 countries. The UK G-box is on order.
6.2.1 NJE
RSCS V2 is expected.
The service should be moved to a 9.6 channel on the HEP 64K line until the end of 1989 and the 9.6 line terminated.
6.2.2 File transfer between EARN and JANET
No changes expected
6.2.3 MAIL
An attempt will be made to adopt a new version of the MAILER but this is difficult as there are extensive changes which are incompatible with the RAL exits.
MAILER will be tested under CMS 5.5.
6.2.4 LISTSERV
A LISTSERV will be set up in the JANET domain to deal with lists within JANET.
A list distribution service will be launched.
6.2.5 EARN management
The principle problems faced by EARN is its financing.
The organisations structures are being re-vamped due to a number of organisational problems which have arisen.
6.2.6 Transition
The NT switches should be interconnected.
The G-box should be delivered by DEC, commissioned and connected to the NT switch.
The E-box software should be delivered and installed by staff from Heidelberg. The IBM will be connected to the switch.
Initial experiments between the SEEL and NT switch will take place.
It is not expected to operate a service in the next quarter.
A service via the NT switch should be in place in the middle of the year.
In view of the reluctance of the UK to contribute to the 64K lines for the EARN backbone it is likely that after initial test using the RAL to CERN 64K line the line will be removed and the line to CWI Amsterdam will not be ordered. Thus the EARN backbone will reduce to a triangle based on CWI, CERN, and Montpellier. The RAL NT switch will probably be relocated when a need arises.
The Hyperchannel and all its connections performed without trouble during the period.
Connection of a new MicroVAX 3600 to the A400 adapter to replace existing MicroVAX 2.
ECMWF should be connected to RAL in the next quarter.
A early beta test version Edinburgh Rainbow software has been tried and seem to meet a lot of RAL's requirements. FTP, VT100 and Network/3270 appear to work with only minor bugs. Problems with the IBM FTP (unable to accept long binary records) and the Spider Gateway have prevented new versions being obtained. The software has been purchased by the JNT and will be free for the whole academic community. The contract will be administered by CHEST.
MOS version 2 has been released to users and no problems have been reported so far. Misgivings about its reliability outside the RAL environment have proved unfounded. No further development work has been done this quarter.
The PC based Console Monitor program for the GPT X.25 switches was effectively completed to its initial specification and documented before S J L Addams' resignation. It has now been handed over to the Network Executive and they will be responsible for further development. The product meets the NE requirements.
Subject to delays in CHEST finalising the agreement to purchase the Edinburgh Rainbow software a proper release could be received this quarter. This should enable testing within CCD and a full evaluation to commence.
The release of MOS v2 has generated further additions to the wish list. These include better support for modems, especially the new 2400 dial up service. The production of RAL versions of the IBM SEND and RECEIVE programs is still outstanding and will need to be done soon. Problems of code conversion for both the MOS and IBM versions will also have to be addressed as it is currently impossible to send the full Ascii character set to and from the IBM.
There have been two minor incidents this quarter. One concerned a failing Fibre Optic Multi Port Repeater and the other was a virus attack on VAX machines from external DECnet machines.
The Backbone went to a Production service on January 12 as planned and is now managed by CSD. The CCD Production LAN came into service the following week but as yet no machines have been moved onto it. The new LMC chairman is Brian Day and he is also Backbone and CCD LAN Manager. Roland Brandwood is his deputy. Secretary to LMC is now Nick Moore. Andrew Jessett remains manager of the CCD Development LAN.
Dramatic rises in Pink Book traffic to the IBM were due to one user trying to send 30Mbyte files from a VAX. Otherwise traffic has been growing only slowly. VMS version 5 is gradually being installed on more VAXs thus increasing the potential use of the IBM Pink Book service.
Some problems have arisen in the statistics collection on the Backbone and it is likely that some programming effort will be required to cure them.
The hardware faults on the spare Auscom boards have proved irreparable and new boards are being supplied by KMW. A maintenance contract for the hardware is now with Harwell Contracts. The software will be maintained by KWM (actually N Gunadhi) on a daily contract rate as required.
The latest release of firmware for the Spider PADs has still not arrived so the problems on this equipment remain. A Camtec PAD loaned for evaluation was not available long enough to make it work.
The Spider X200 X.25 gateway has been installed on the CCD ethernet. After a minor addressing problem was sorted out it is now possible to make calls to and from the X.25 network. Some problems with packet size negotiation have been found with the Rainbow software and investigation awaits the latest release of the latter. How the tables in the gateway are to be maintained has still to be decided.
Vitalink bridges for the link to Daresbury have been ordered.
An IBM 8232 has been ordered to give TCP/IP access to the IBM
The majority of CCD machines including the IBM should move onto the Production LAN.
A trial service for machines on the ethernet to access a limited number of X.25 sites via the Spider Gateway should commence.
Evaluation of the Vitalink bridges should commence.
Evaluation of the IBM 8232 should commence.
It is vital that the IBM Pink Book service becomes a Production Service in the near future.
10.1.1 Current Situation
Syntax problems
I have discovered that double quote escapes are not needed to access the TELEMAIL gateway (by far the most useful application) as the gateway allows the address to be in the text with a Forward: command to send out the mail. I have added TELEMAIL documents to "NETSERV". A length problem with addresses (which cannot be overcome by line folding as the addresses are used at the other end of the link too and they don't expect them to be wrapped) is usually circumvented by using a domain name - the latest to be added is .ac.jp for JUNET (Japanese Unix). We found that BSMTP imposes a further length limitation so a max of only 70 characters are available for the address path. Double quote syntax may be useful for DECNET mail, however most such machines adopt a domain name when the software is running well.
Mistranslations - "work-arounds"
We have found that we accord with CUNYVM's translation tables. Some reported problems occur because JANET machines get unvarnished EBCDIC if that is their own character set. The opening of the UCL gateway means that TEX etc can be sent to the US without translation problems by either using FTP or mailing to ARPA direct. A user with the translation problem who sent the file back and saw it un-corrupted has at least proved that we don't usually lose data when this happens here and IBM users are recommended to either send binary (to and from BITNET) or adopt an encoding method.
New requirements of mail
The syntax @relay:user@site is much used by lists. If there were any way we could implement it for BSMTP and turn it into a sensible JNT header/ From: field, we would have future-proofed the gateway for a long time to come, as it is as yet not general in the USA and will certainly be the standard (it is in fact the only syntax in RFC822). JCL-like batch commands to LISTSERV cause it to fail sometimes. I have tried to simulate the error but have so far failed. (Multiple Reply-to: entries are NOT the cause of the problem)
Hardware
The CEARN line has caused backlogs - the problem is "fixed" at the moment. I am providing more help about modems than I used to - US academics coming here and some companies producing academic journals have acquired IBM accounts and PCs and are using full screen access by MOS.
10.1.2 Routine tasks and Investigations
Routine "postmaster" functions
I am gradually becoming more familiar with the LISTSERV functions. Eric Thomas wrote back to an enquiry about batch in a way which seems to suggest there is a bug and not that I am doing things wrong.
The various "postmaster" aids in ET and PO2 get a lot of use. I have written some more - they are very labour-saving. It may be possible to send back quite a lot of mail just by a single command now that the sub-commands are more sophisticated.
IBM's VNET apparently throws mail away when CUNYVM is off-line. It is therefore an "occasional black hole" - it's nice to be warned of these problems. IBM now set up their own links and get a number to mail back to (unless we delete the link)- CP SMSG RSCSKING CMD VNET VC QUERY from MAILER (without stopping it) tells us who is linked. We receive table update requests for some tables which should be maintained automatically. Since the main list (and the biggest table) BITNET NODES is on the same disk of NETSERV, I think no one is distributing the MAILER, XMAILER and DOMAIN NAMES files at the moment. Ireland have later copies but even those are flawed and recently we had to put FRIBM11's new route in by hand as there was NO table (not even in France) reflecting the alteration and removal of this main French site's old machine which was due the same week!.
UKC has been getting annoyed by senders of illegal From: fields. I use the command "boun user@address" and GET ILLEGAL FIELD to send a standard ticking-off. There are about six persistent errors of this type, which can only be dealt with by user education. The EARN membership often mail asking to be added to the EARNUS list, which is usually fairly reserved but which has been used to sling mud at the EARN gateway on a few occasions, mainly for reasons which repeat in cycles (the gateway does not do things the way UNIX users expect; it is a good idea to know about the DEFICIENCIES of UNIX implementations, otherwise we would waste man-years re-implementing things which don't work anyway). Scandinavian networks continue to be awful, however MCVAX continues to reach UUCP and this is what most European mail people are in fact using.
There are now some X400 mailers around. CAM.PHX has one and the idem service is linked to EAN. "Alvey" users are now on Eurokom or using commercial mail - Peter Hemmings in Informatics is the contact. There is now interest in Macintoshes - a demonstration showed that linking them up can be done but has un-implemented holes and Kermit still doesn't work to them from the IBM. There is a file only available from JANET telling users which UK.CO sites are accessed via a relay like UKC (by user%uk.co.site@ukc)
10.1.3 Changes in December 1988 and Early 1989
Incoming mail is now going through our mailer and wrapping is being improved to make this more satisfactory. Lists are now being redistributed. So far this doesn't work 100 per cent. This is all part of upgrading the mailer to the standard of rl.gb .
None identified.
Error recovery
An "automatic" postmaster able to cope with some of the error forwarding is definitely possible for a few repetitive errors. Since we are now down to about 20 real errors, mainly originated elsewhere, in traffic of 7000 files each day, this makes the gateway at least informative - we are definitely not a "black hole". Obviously error mail is part of the 6980 which get through, however this low number means that at the very worst we get 20 loops per day, most of which are stopped without operator intervention. An auto-postmaster would be useful if operator intervention WAS needed as you then need to re-originate mail, not just put it back on the mailer ID from some parking place (otherwise it is seen as illegal mail).
X400
We need to find out quite what plans there are for X400 on EARN. If we can make EARN conform with a NEW standard for a change, we may be able to participate more in the problem-solving effort and thus get more information and less criticism (in the past I have certainly been caught out by some of the upgrades to ARPA and EARN).
X-WINDOWS
Full screen terminal services are now commonly used across JANET. There is already effort connected with a de facto standard called X-WINDOWS which is used across LANS to access single user systems and supercomputer graphics.
There were two incidents in the period:
November 21: Some users were unable to sign on after the weekend shutdown. Both ends were reset to cure the problem.
January 26: Intermittent hangs on several terminals. A dump was taken. The cause is under investigation by Paradyne and there was a loss of service of 10 minutes.
The Lee Data Accelerator trial is continuing though somewhat delayed due to software problems in VTAM. The hardware appears to function according to specification.
The VTAM problems are expected to be solved and expansion of the Lee Data system will occur in order to accommodate the Chessington Payroll Project. The hardware required for this project initially will be installed locally in mock-up form for test, then 'exploded' to the remote sites.
Continuing expansion of PROFS at Swindon Office and installation of hardware for the Payroll Project will require additional data circuits between RAL and Swindon, and within Swindon itself to Holbrook House and Exfinco House. Details of these proposed circuits are not yet finally specified.
TMPC have asked for a statistics section in the Quarterly Progress.
The table shows performance and failure figures for the various network components on the Rutherford site. Comparisons between various access methods are not comparable and must be read with some background knowledge. Major incidents are ones where a substantial number of connections are lost. Minor incidents are ones where only one or a few connections are lost.
Component Major Minor Traffic passed Traffic number
incidents incidents Mbytes/quarter of calls
Local
X.25 CPSE 4 10 15921 911325
SEEL 0 0 na na
PADs 2 19
PACX 0 1
LINES/MODEMS 7 0
Multiplexors 2 1
JANET
JPSE 31 11 29618 2940906
Lines/Modems 10 2
Local area network
VMNCPE na na 2370 na
Auscom H/W 0 0 - -
S/W 0 1 - -
370E - - - -
Auscom H/W 0 0 - -
S/W 0 1 - -
Backbone LAN
H/W 0 1 10080 np
S/W 0 1 - -
CCD LAN
H/W 0 0 na np
S/W 0 0 - -
Hyperchannel
H/W 0 0 np np
PIXNET
PIXNET H/W 0 0 np np
PIXNET S/W 2 0 - -
VAX VMSFE
Ethernet H/W na na np np
Ethernet S/W na na - -
X.25 H/W na na na na
X.25 S/W na na - -
SUN ARCU
SUN H/W na na na na
SUN S/W na na - -
IBM
4705 H/W na na - -
4705 S/W 5 few call losses na na
VTAM(since V3R2) 0 0 na na
VMNCP some reloads for line mode 13,000 1,000,000
Network/3270 0 0 2,000 60,000
SSMP 0 some 60 800
NIFTP 0 0 9,000 850,000
JTPM 0 some 800 15,000
Line-mode Intermittent hangs at setup 1,200 80,000
CMS-PAD 0 some 65 80,000
3270 H/W na na np na
3270 S/W na na - -
Note:
np indicates that it is not possible to provide figures.
na indicates that figures could be made available with effort.
- indicates that the figure is not relevant.
Dear Mr. Titley,
Further to our telephone call requesting associate membership of EARN may I ask you to write to me giving the following statements and information:
Your application will go before the EARN membership committee but I do not foresee any problems.
There are some technical problems with your membership. I believe that you were accessing EARN via the gateway to JANET at Kent University. Although there seemed no problems in the EARN-ward direction I am not sure that traffic from EARN to yourself was succeeding. If it was all well and good but I know Kent run an authorisation scheme to enable them to recover costs.
As an associate member you would be entitled to put in a leased line between yourself and Rutherford but I suspect that this would be an un-necessary expenditure. It is possible to use PSS for traffic to EARN. Again, traffic from EARN to members via PSS is difficult as this costs money and we have no funds for such calls.
You will see that EARN has certain regulations regarding the physical connection of computers. In your case you can ignore these as the technology used in the UK is entirely different and the connection of systems is normally via JANET or networks connected to it.
We do not currently charge members and the network is funded by the UK academic community. However, this situation may change as we do have funding difficulties. I will give you a long warning should we find charging to be necessary.
I hope this gives you sufficient information but if you have any further questions please contact me.
Yours sincerely
Paul Bryant.
Below are answers to legal issues raised by the EARN Executive Committee; these are translations of letters from the EARN auditor (AGRET-MAINE) the French original copies of which are available on request.
A) EARN employs people through contracts with universities or other associations
a) provision of work
b) payment of the work provided
c) power of the employer to manage, supervise, educate and be in command of anything related to work, with regard to the employee.
In the latter case, the administrative authorities should not be able to report a link of subordination, otherwise this would mean that a work contract does exist, and therefore costs pertaining to it should be paid.
Both parties are bound to by riders included in contracts of this kind (Temporary agencies, contract with universities) ; thus, one should refer to the contract and determine what the obligations and conditions of each parties are.
B) EARN employs people directly
1 Work contract - social and tax-related obligations
a) registration as employer and payment of contributions to :
. Social security fund
. Unemployment benefit fund
. Retirement pension fund
b) payment of tax on salaries
a) In the following instances, contracts of limited period are made possible
. specific and non durable task ;
. professional training (contract of qualification,
rehabilitation...)
b) Such a contract should be accurate and clear ; it may be renewed twice but must not exceed 24 months in total (unless it is a contract for an unknown length of time).
c) When a contract comes to an end, the following compensations are to be paid :
. paid holidays
. 5 % on the total net wage that was due to the
employee during the length of his contract
(regardless of the paid holidays mentioned above)
d) Breach of contract before end, for any of the following reasons :
. accident
. illness
. serious professional misdemeanour
. legal cancellation
Unpaid contributions
When assets of the Association are made up of members' contributions (see Statutes) upon which the majority of the members in the Association have agreed, then these contributions are due for payment. Theoretically, a country that has failed to settle its debt could be constrained only by a court decision to do so.
In the case of Ivory Coast, given the fact that the outstanding contribution is a small amount (570 ECUs), an amicable arrangement should be contemplated.
Present: R Brandwood, P Bryant, R Evans, B J Day, A Jesset, G W Robinson, M Waters (CCD) N Calton, R A Day, I Johnson (ID)
There is a requirement for high speed workstations from Daresbury into the Cray and for access from RAL to high speed computers at Daresbury.
The aim is to connect the LAN at RAL to the LAN at Daresbury by means of bridges and a 256K channel on the JANET Megastream link. The link will initially use TCP/IP protocols. The use of other protocols is for further study.
After study Vitalink bridges have been purchased because of their ability to operate up to 2M and their good filtering capabilities.
There have been a number of project meetings and this is a report of the latest. This is being distributed to LMC for information and comment. A number of topics not directly associated with the Daresbury link are discussed which LMC should be aware of.
Order Vitalink bridges for RAL (A Jesset) Complete Delivery of bridges (Vitalink) Complete Order modem eliminators (R Brandwood) Complete Contrary to earlier comment these were needed. Possible order of multiplexer cards (R Brandwood) Not needed Suitable cards were available at RAL and Daresbury. Testing at RAL (A Jesset) Apr. 14 A number of difficulties have been encountered which are being discussed with Vitalink. Possible delivery of multiplexer cards (R Brandwood) Not needed Harmonisation of IP addresses (ID) Apr. 30 Locate equipment in Telecomms (R Brandwood) Complete The equipment will be in racks near the other LAN equipment. Check timescales for delivery of DL Vitalink Mar. 30 Check distance at DL Vitalink to multiplexer Mar. 30 Manufacture DL Vitalink to multiplexer cable Apr. 15 Connection to Daresbury (R Brandwood, A Jesset, DL) May. 1 Tests to Daresbury (A Jesset, DL) May. 14 Change of broadcast address (ID) May. 14 Check that P Kummer is contact at DL Mar. 30 Check DL IP addresses and Broadcast addresses May. 14
It is expected that the RAL and DL IP addresses will be harmonised by April 30 and before any connection is made. The harmonisation is being co-ordinated by ID. After the change RAL and DL addresses will be within the international scheme which should protect against any further changes.
The 'big bang' broadcast address change should be complete by May 14 before an IP connection is made to Daresbury. This will be carefully co-ordinated by ID. Since this requires co-operation between villages the exact timescale is not firm. To avoid complications the DL link must not be made before the changes at RAL and DL are complete. Again, this change should protect against further changes in the future.
There is considerable concern over security with the use of NFS. This is thought to be a temporary problem which should be solved within two years. Various schemes were considered to overcome the problem. There was some reluctance to complicate the topology or purchase further equipment for security.
The Vitalink bridges will be connected to the CCD village. It is proposed that the IBM 8232 will have one channel connected to the CCD village and one channel connected to the ID village. This should provide protection for ID while allowing the 8232 to be exploited by CCD and possibly other villages.
This needs agreement with the IBM 8232 working party.
ID already co-ordinates the allocation of IP addresses by issuing blocks of addresses to village managers. It is proposed that this be extended to cover the allocation of Unix userids and groupids and the domain names used by 'Yellow Pages'. This would be part of the 1/10 man provided by ID and financed by CCD. Should more than 1/10 man be required this must be agreed between CCD and ID.
April 25, 1989 at 1400.
Further to our 'phone conversation, I enclose the licence agreement which requires signature.
May I remind you that the software is now in our possession and we intend to use it as part of an international collaboration supported by DEC. Thus the software is supplies free by DEC.
May I draw your attention to section 14 of the licence agreement which unfortunately includes references to the US government. As far as we are concerned we are happy to agree not to export the software under any circumstances.
I would be grateful if you would obtain the required signatures for a possibly amended agreement as soon as possible to regularise our position.
Dear Alex,
I have a little bad news. We are unlikely to be able to sign the agreement with Joiners in its present form. I draw your attention to section 14 which precludes the export of the software without obtaining an export licence with the US government. Unfortunately UK government departments are barred from signing such licences as it infringes UK sovereignty. Thus our contracts branch will have to negotiate with Joiners to amend that section. apparently they have an alternative form of words that mean the same but preserve our so called sovereignty.
This may all take time. I hope that you are happy for the testing to start pending the signature.
I return copies of the agreement filled in but not signed for what use they may be to you.
The VAX is being put together this very day. I believe we have now nailed down the so called NT problem between UK and Ireland which seems to be a modem incompatibility to which the NT switch is sensitive. I have donated a modem to Ireland which they should receive by Friday when we should be in business.
Yours sincerely
Paul Bryant.
Dear Alex,
I have now obtained a signature on the Joiners licence.
My contracts division have taken the liberty of amending the licence in line with UK Government directives and local regulations.
May I draw your attention to clause 14 on "EXPORT". Here we state that UK rather than US government permission is required before the software is exported. As I explained in my earlier letter the UK Government believes that it impinges on its sovereignty to allow the UK Government to determine whether an article may be exported.
In clause 14 on "GENERAL PROVISIONS" in the last sentence you will note that my contracts division require that the contract is governed by English laws rather than Wisconsin ones.
I regret the necessity for the changes and I hope they are acceptable to you.
Yours sincerely
Paul Bryant.
All 5 switches were delivered and installed before the end of January. See Section 20 of ISO documentation. Installation was undertaken by Clayton Thornton of NT. Pre-installation meetings were held and I attended the one at Montpellier.
There have been no failures in Northern Telecom equipment.
The network control software has been delivered and installed on a VAX in Dublin.
Clayton Thornton has now been replaced by Neal Berriman
A UK to CERN line has been ordered and was expected in mid-February. It has yet to be delivered. I line ordered earlier on behalf of HEP is also not yet installed.
It is intended to use the existing UK Dublin line.
The Executive has requested that CWI to CERN and CERN to Montpellier lines be ordered but the state of the orders is not known to me.
The Dublin to UK line was split into 3 channels - 4.8K for NJE, 2.4K for JANET connection, and 2.4K for the Northern Telecom trunk link.
Tests in January were not successful. The connection between the countries is complicated and it was not clear what was failing. The set up is:
+--------+ +---------+ +----------+ +--------+ +---------+ +--------+ |Northern|-|V.35 to |-|Racal V.29|-|EMI V.29|-|V.25 to |-|Northern| |Telecom | |V.25 | |Modem | |Modem | |V.35 | |Telecom | |Dublin | |converter| | | | | |converter| |RAL | +--------+ +---------+ +----------+ +--------+ +---------+ +--------+
The Northern Telecom trunk protocol is proprietary and we were thus unable to run tests with our extensive X.25 test equipment.
The modems were eliminated as NJE and JANET connections were working well. The V.25 to V.35 box at RAL was tested.
Northern Telcom suggested that the trunk interface could not operate at a speed as slow as 2.4K. Tests at 4.8K and 9.6K gave different results on line monitors but still did not work.
Further tests in April showed that the Northern Telecom switch was seeing a high error rate on a loop test (13 per minute). It was also noted that the NJE line had a high error rate but not high enough to cause concern. We now understand that the Northern Telecom switch needs to transfer 10 packets error free before a link can be established. Looping the line showed that the error rate was a bit lower (4 per minute). So we changed the RAL modem and the error rate went down to a satisfactory level considering that the transmit and receive lines were in tandem (2 per minute). However, when looping through the Dublin modem the rate went back up. Thus we concluded that the modems were not very compatible or the Dublin modem was faulty. I therefore sent a Racal 9.6 Multimode modem to Dublin and prepared another one for RAL. The Dublin line then went down and the opportunity was taken to put on the new modems. Tests showed that the error rate was now low but the line came and went line 'a fiddlers elbow'. In the brief time the line was up the Dublin switch did not transmit anything for reason not yet determined.
The conclusion reached is that it is very difficult to bring up a circuit when the protocol is not documented and understood. The complexity of the link also made fault location difficult. It is a pity that the trunk interface will not work over the slow V.24 Northern Telecom ports which would have removed some unknowns.
The Northern Telcom X.25 interfaces were set up in a fairly arbitrary way and not as specified in the EARN documentation. In addition only one X.25 interface was set up.
There was no difficulty in connecting a VAX to the switch although extensive testing was not possible as fast select was not available. The connection of an IBM was not successful as NPSI refused to negotiate the quality of service and closed all calls. The connection of a PC with an X.25 card had no problems.
New software was provided with fast select, no negotiation, and 6 X.25 ports. All the equipment now operated and coloured book protocols were operated through the switch with no further problems. Extensive and throughput tests have not been completed due to other demands on staff time. It is unclear whether the very old copy of IBM NPSI caused the problem or whether it was caused by our non-understanding of NPSI.
This worked as expected. That is, calls from hosts connected to the Seel switch were successful as long as the calling address was suppressed. Unfortunately this cannot be done in the Seel switch and the checking of the calling DTE in the Northern Telecom switch cannot be suppressed. It is not possible to make calls from the Northern Telecom switch as the relevant DTE addresses cannot be generated and passed to the relevant port.
This was surprisingly difficult to make work. Eventually the problem was traced to a faulty cable (a Rutherford problem).
Assuming the trunk interface problems will be solved there are several other tasks.
Further work is needed to set up the X.25 ports. Ideally a 'standard' set of parameters is desirable but it is unclear as to whether this is possible with the current observed differences between DEC and IBM equipment. Unfortunately, without the connection of the Northern telecom control machine it is tedious to re-configure ports for testing (it requires a disk to be brought from Maidenhead).
64K trunk connection have yet to be tested.
The DTE connections have been at 9.6K and higher speeds need to be tested. The PC has operated correctly at 64K but extensive test were not carried out.
Hardware and software maintenance of RL.VE including consumables
10000 UKL
Sub total 10000 UKL
Terminals (4 Vt320s) for spares and courses 2000 UKL Decserver as the current device is full 3500 UKL DSV11 X.25 interface for MVAX2 (RL.VE). This is required for testing as the machine, unlike the 750 has only one X.25 interface. 4500 UKL Backup device (video 8) for RL.VE and possible use for Cray front end 10000 UKL Two VAX stations for Workstation familiarisation 15000 UKL Sub total 35000 UKL
Travel/conferences including VUG costs 10000 UKL Sub total 10000 UKL
Training for existing and particularly new staff 6000 UKL
Sub total 6000 UKL
=========
Total 61000 UKL
=========
Outside maintenance of the Sections 15+ machines and associated printers, display etc 1500 UKL
Spares stock of disc drives, displays, adapter cards etc. for in house maintenance of 200+ RAL machines 4000 UKL
Sub-total 5500 UKL
Enhancements to demonstration PC and PS/2 machine's memory, displays and adapters 5000 UKL Evaluation printers: HP Paintjet 1000 UKL Printer splitters and other sundry hardware items 2000 UKL Demonstration/evaluation machines: Hard disc portable 2300 UKL IBM PS/2 486 machine (to be announced) 4600 UKL IBM PS/2 386SX machine (to be announced) 3300 UKL PC Bus 386SX clone 3000 UKL PC Bus 386 clone 3500 UKL PC Bus 486 clone 4500 UKL Contingency for evaluation of unannounced hardware 2000 UKL Sub-total 31200 UKL
Evaluation copies of MS and IBM OS/2 Operating System and toolkits 1600 UKL OS/2 compilers and applications 2500 UKL OS/2 and PS/2 technical reference manuals 2000 UKL Evaluation copies of Xenix and AIX operating systems 2000 UKL Evaluation copies of TCP/IP and NFS 700 UKL Evaluation copies of current software packages of interest to RAL including mathematics and Lotus123 v2.2 and v3 1400 UKL Evaluation copies of software yet to be announced 5 @ 150 UKL each, 4 @ 250 UKL each and 3 @ 350 each 2800 UKL Sub-total 13000 UKL
IBM PC User Group subscription 100 UKL Manuals and text books 200 UKL Sub-total 300 UKL
Maintenance on time and materials basis 1000 UKL Sub-total 1000 UKL
Meetings and conferences 1500 UKL Sub total 1500 UKL
New staff and undating current staff 1500 UKL
Sub total 1500 UKL
=========
Total of IBM PC 54000 UKL
=========
Fileserver (IBM PS/2 model 80 with 300Mb discs) 6000 UKL Evaluation IBM optical disc for backup 2100 UKL PC and PS/2 BICC ethernet cards 1500 UKL Software licences for networking 3000 UKL Sub total 12600 UKL
JNT meetings and conferences 1500 UKL Sub total 1500 UKL
New staff 1500 UKL
Sub total 1500 UKL
=========
Total 15600 UKL
=========
Circuit design software/hardware maintenance/upgrades 1500 UKL
Parts, cable etc. for in house hardware development 1500 UKL
========
Total 3000 UKL
========
Overseas travel and conferences 1500 UKL
========
Total 1500 UKL
========
Following the meeting in Amsterdam on April 12, 1989, I was asked to prepare a monthly summary report on the progress of the network interconnections for the EARN Northern Telecom DPN backbone network.
Until the completion of this project, the responsibilities will be:
Paul Bryant co-ordinator from EARN and
Johanne Mayer project manager/co-ordinator from NT.
This project has been divided into 6 phases:
Phase I: Connectivity between Network Management Module (NMM) in
Dublin and Resource Module (RM = DPN100/20S) in
Rutherford.
TARGET DATE: May 1, 1989 (COMPLETED DATE: April 22, 1989.
Phase II: Connectivity between RM In Montpellier and RM in CERN.
TARGET DATE: June 1, 1989.
Phase III: Connectivity between RM in Montpellier and RM in
Amsterdam. TARGET DATE: June 15, 1989.
Phase IV: Connectivity between RM in Amsterdam and RM in CERN or
between RM in Amsterdam and RM in Montpellier.
TARGET DATE: June 22, 1989.
Phase V: NMM and NAS move from Dublin to Amsterdam.
TARGET DATE: June 1, 1989.
Phase VI: New DPN 100/5 installed in Dublin *
TARGET DATE: June 1, 1989.
* Pending upon Northern Telecom's decision. Allan Leth to inform EARN.
PROJECT PHASES
+----------+ +---------+
| RM | | RM |
| | | |
|Rutherford| |Amsterdam|
| (RAL) | | (CWI) |
+------+-------------+----------+ +---------+
|NMM | \ / |
|Dublin| \ / |
|(UDC) | \ / |
+------+ \ / |
Phase III |
\ / |
/ |
/ \ |
/ \ |
Phase IV? / \ | Phase IV?
/ \ |
/ \ |
/ \ |
+-----------+ +-----+
| RM | | RM |
| | | |
|Montpellier|---------------|CERN |
| (MTP) | Phase II |(CRN)|
+-----------+ +-----+
X.25 profile information: An initial X.25 parameter information package will be sent to Paul Bryant to allow him to add or change X.25 lines in the networks.
April 28, 1989
NT access to EARN mailing system:
NT will get a connection to the EARN backbone network in Amsterdam through GNET over OSI from NT's lab in Frankfurt using a microVAX II. Odd Jorgensen will provide NT with necessary equipment list and costs. For an immediate solution, NT could get an account on Inet (Intelligent Network offered in Nord America) which will have X.400 gateway available April 30, 1989.
If you have any comments or questions, please call me.
Best regards
Joahanne Mayer
Well, letting each of the five sub indexes go from 1 to 99 makes 10 digit account numbers. Let's see if it does not suffice with one digit per sub index. I'm not sure I understood the discussion in Amsterdam very well, but here is my proposal:
The budget chapter sub index for income should be 9, I believe. If we re- use 1,2 and 3, we may have the same account number for an income and an expense, which would inhibit the use of data processing unless and extra indicator is added. This sub chapter seems to be mainly historical, but we need to keep it for comparison.
I take it that sub chapter 2 means the kind of expense, or income. Here we may need 99 items, although the proposed 12 expenses might be compressed- I have no strong feelings about it. The list looks OK, although we probably need interest as well.
Then sub chapter 3, exec area, could be called responsibility. We have not (yet) implemented procedures and budgets according to this, but it may come useful. One digit will do.
Sub chapter 4 might be projects which could or could not span several exec areas. I think that was what the BOD asked for in Tel Aviv. Also we could use this sub chapter for permanent activities to the extent they are not sufficiently in accordance with budget main chapters. Here we start with 1 and go on.
So 1.2.1.0 might be my travel to see Eric to keep listserv operational, and 6,6,4,1 might be the first bill for the X.25 backbone. As you see, we rarely need the project subchapter, but since the BOD asked for it, we had better include it. I cannot think of a need for a fifth sub chapter.
Present: P Bryant EARN
D Jennings EARN
J M Stripin DEC
J Mayer NT
F R Willink DEC
A Leth NT
It was agreed that the object of the meeting was to make the network operational. To do this the project must be defined, the management reporting defined, and the technical detail resolved.
The critical resources are the Einstein Centre and the staff at sites.
Germany is in control of all NT support:
Pat Dowling (Frankfurt)
/ | \
/ | \
Germany Rex Benning Maidenhead
(Software)
|
Johanne Mayer
(Software engineering and prime contact)
All support for EARN now goes through J Mayer in Frankfurt.
J Mayer will produce a project report once a month which will be contributed to by NT and EARN. The EARN contact will be Paul Bryant or ultimately Amsterdam staff.
APR MAY JUN JUL AUG SEP
P1 Dub/RAL working |
P2 CERN/MOP working |
P3 RAL/CERN working |
P4 CERN/CWI working |
P5 Move Dub. switch to Amsterdam |
P6 New switch at Dub. |
Gateway X.25 should be provided by the end of 1989 in release G25
X.75 will be available in G24 available now.
These will be made as required.
+----------+ +----------+
JANET X.25-------| | 9.6 | |----------JANET X.25
+-AMDAHL BiSynch---| Racal |-------| Racal |----------IBM BiSynch
| NT--V35/V24------| Multimode| | Multimode|--V24/V35-NT---+ |
| | +----------+ +----------+ | |
| | | |
+-G-Box G-Box----+
The detains of the NT switches, G-boxes and the contacts on sites are in documents PROJECT SEC20 and PROJECT SEC21. These are not necessarily accurate. The details of the connections between the NT switches and the 64K lines are not known except in the case of the UK/CERN line. These details need to be confirmed
Documents are required for:
The rules and regulations of the network Rules for connection Change control Administration management
A training catalogue will be sent to P Bryant with a view to sending staff on an NT course.
Once an Executive document has been given a number and considered by the Executive it is frozen. Any updated versions are given new numbers. This index contains all papers which have been considered by the Executive whether they are published or not. A published paper is available in LISTSERV at UKACRL. Published papers are those which have been 'approved' by the Executive or, in the case of information papers, 'noted'. Confidential papers, ones which are be be re-drafted, ones which are ephemeral, or ones which are trivial may not be published. Superseded paper are removed. Each paper has a code associated with it comprising one or more letters and possibly a number:
P - A paper which is approved or noted by the Executive, published and is currently available in LISTSERV at UKACRL. Such papers should be read in conjunction with any relevant Executive minute.
U - A paper which is approved by the Executive subject to changes. Such a paper may eventually be published under a new number when the current one will be marked as superseded, that is marked Snn.
Snn - Superseded by paper nn
C - A paper which is confidential and may never be published.
N - A paper which is not published as it is ephemeral (the Executive agenda), rejected by the Executive, trivial, or not available in machine readable form.
EXEC1 88 P Minutes of EARN Executive meeting number 23
EXEC1 89 S27 Proposal for more effective EARN Executive meetings
EXEC2 89 P Proposal to operate SNA between Belgium and Montpellier
EXEC3 89 P Proposal to operate SNA between CNUSC and CNUCE
EXEC4 89 S30 Recruitment procedures
EXEC5 89 S29 Draft agenda for EARN BOD meeting
EXEC6 89 S25 Proposal for EARN operation and technical staff
management plan
EXEC7 89 S28 Revised OSI transition plan - for approval
EXEC8 89 UC EARN cost sharing - proposal
EXEC9 89 U Proposal for re-organisation of EARNTECH - Draft
EXEC10 89 P Proposal for sharing the costs of EARN
EXEC11 89 S35 Revised EARN Charter - for approval
EXEC12 89 S26 Proposal for SNA working group
EXEC13 89 N EARN EXEC-MEETING NUMBER 24 AGENDA
EXEC14 89 S37 Proposal for EARN accounting mechanism
EXEC15 89 S42 Proposal for 1990 budget
EXEC16 89 S31 Proposal for rationalising lists
EXEC17 89 S42 1989 budget update
EXEC18 89 C Approval of contracts
EXEC19 89 C Staff recruitment
EXEC20 89 U EARN/Nordunet agreement
EXEC21 89 C OSI Operations Centre Staffing
EXEC22 89 C Staff recruitment
EXEC23 89 N EARN EXEC-MEETING NUMBER 25 AGENDA
EXEC24 89 P Minutes of EARN Executive meeting 24
EXEC25 89 P Proposal for EARN operation and technical staff
management plan
EXEC26 89 P Proposal for SNA working group
EXEC27 89 P Proposal for more effective EARN Executive meetings
EXEC28 89 C Revised OSI transition plan
EXEC29 89 N Draft agenda for EARN BOD meeting
EXEC30 89 C Recruitment procedures
EXEC31 89 P Proposal for rationalising lists
EXEC32 89 P Proposal to approve section 0 of the EARN project
documentation
EXEC33 89 P Proposal to approve section 2 of the EARN project
documentation
EXEC34 89 P Proposal to approve section 16 of the EARN project
documentation
EXEC35 89 N EARN Charter
EXEC36 89 N EARN contributions
EXEC37 89 U Proposal for EARN accounting mechanism
EXEC38 89 U EARN accounting codes
EXEC39 89 Not allocated
EXEC40 89 Not allocated
EXEC41 89 Not allocated
EXEC42 89 U 1989 EARN budget and 1990 proposed EARN budget
EXEC43 89 C Proposal for support of LISTSERV
EXEC44 89 C Proposal for the EARN Manager
EXEC45 89 U List of EARN technical documents
EXEC46 89 N Cost sharing proposal for 1990
EXEC47 89 P Report of tasks performed under EARN contract with
Nijmegan
EXEC48 89 P Auditors report
EXEC49 89 EARN EXEC-EXECUTIVE MEETING 26 AGENDA
EXEC50 89 Minutes of EARN Executive meeting 25
EXEC51 89 EARN code of conduct
EXEC52 89 Proposal to approve section 2 of X.25 project
documentation
EXEC53 89 Proposal to approve section 16 of the X.25 project
documentation
EXEC54 89 List of technical documents
EXEC55 89 Proposal for EARN account codes
EXEC56 89 Proposal for an EARN project on routing table generation
from EARN Germany
EXEC57 89 Project proposal for LISTSERV maintenance from EARN
Germany
EXEC58 89 Proposal for an EARN study project on value added
services from EARN Germany
EXEC59 89 Legal issues on EARN contracts and membership
EXEC60 89 Letter from IBM
EXEC61 89 Proposal for the control of lists
EXINF1 89 N Hotel reservations EARN '89
EXINF2 89 N EARN89 Brochure
EXINF3 89 U The EARN statutes - English version
EXINF4 89 P Financial statement
EXINF5 89 P EARN contributions as of February 9, 1989
EXINF6 89 P Status report on Montpellier meeting
EXINF7 89 P MDNS requirements
EXINF8 89 P Status of new countries
EXINF9 89 P CERN-MOP link, Morocco-Italy link, decentralised
maintenance, statistics
EXINF10 89 P Status of directives
EXINF11 89 P Document index
EXINF12 89 P Document index
EXINF13 89 Document index
BOD1 88 Minutes of Board of Directors Meeting 20
BOD1 89 EARN Board of Directors Meeting 21 Agenda
BOD2 89 EARN President's report
BOD3 89 Operations report
BOD4 89 Proposal for SNA working group
BOD5 89 Liaison report October 1988 to May 1989
BOD6 89 Detailed project plan for transition
BOD8 89 EARN accounts
BOD9 89 Update of EARN 1989 budget
BOD11 89 EARN proposed 1990 budget and 1991-1993 forward look
BOD12 89 Organization of technical work in EARN
BOD17 89 EARN Charter
BOD18 89 EARN code of conduct
BOD19 89 The report of the EARN General Secretary
BOD20 89 Proposal for the EARN annual report
BOD21 89 The EARN statutes
BOD22 89 The cost of EARN international lines
BOD23 89 EARN payments to date
BOD24 89 EARN statistics
P Bryant, R Evans, K Jeffrey, C Osland, G Robinson, P Thompson, M Waters
A strategy for workstation has to take account of the complete computing scene since computing is becoming a co-operative process between the user, the terminal, the back end, and the infrastructure linking the parts. In that co-operation the users should not be aware of the separation of functions.
It is taken as an axiom that the future of the department is largely linked to the exploitation of large scale computing. Most of the other activities such as graphics, data storage, and communications are supportive of this role.
The strategy must recognise that the requirements of the users are paramount and it is the job of the Department to attempt to steer the community in a coherent direction rather than adopting the heavy handed approach which has characterised some earlier initiatives. On the other hand there is a duty to operate as economically as possible both in terms of expenditure and manpower which suggests some standardisation and restriction of options.
The conclusion drawn is that any strategy must support popular equipments and popular ways of operating. It is believed that following any exciting new developments that arise from time to time is likely to be less successful as it may lead to high costs and possible dead ends such as PERQs. A pro-active strategy of forcing the use of approved equipment is equally as bad as a reactive one and a middle path should be taken which attempts to guide and persuade the use of approved equipment while recognising that there may well be requirements which cannot be met with such equipment.
The 'character' plus 'attribute type' of terminal is a throwback to the mid 1970s when computing and memory were expensive. Currently the mass market for high definition TV, video, and home computers for games and more serious work will mean that high quality bit-mapped displays become mass market items. They will soon, if not already, be less expensive than character terminals. Likewise the on-board processing power will become faster and cheaper - it is possible to buy an Atari with a Motorola 68000 for 300 pounds, this is about 1 MIP and is already two years old. Clearly anybody who wants one will soon be able to afford a good quality bit mapped display with 2-3 MIPs of power on board. Likewise RAM and hard discs become cheaper by the week, 40 Mbytes for 250 pounds is par for the course for a 5 1/4 Winchester.
Users will expect to have better equipment at work than they have at home.
It is difficult to find anyone who has used a bit-map display who would willingly return to text only. The possibility of mixing fonts, colours and icons, coupled with a mouse or other powerful interfaces makes learning to use such systems much easier. This explains why Apple has had such success with the Mackintosh. The comparison with PROFS menus (where you variously type PF2, PF7, ENTER or whatever after performing an action) is interesting!
In short the 'workstation' is becoming the mass market device of the future and the 327x will seem archaic and expensive. Users will opt for the service that is easier to use and does not require them to buy dedicated display hardware. IBM's traditional method is to lock users into IBM hardware including terminals. The PC and PS2 interface may make this less of a restriction in future, but we should beware.
The workstation type of interface will aid everybody, from text preparation with genuine WYSIWYG, display graphics like Harvard Graphics, debuggers line CODEVIEW, wider displays on spreadsheets, linking text and images in databases, to just drawing graphs from a FORTRAN program online.
The requirements broadly fall into three groups.
Although there is a measure of hardware commonalty the software structures are largely exclusive, for example XWINDOWS is not a popular way of accessing CMS applications.
UNIX has now become the system adopted by many manufacturers as their strategic direction. IBM and more so DEC follow this trend but still press their proprietary systems VMS, VM/CMS, and MVS. Many special purpose machines have adopted or migrated to UNIX, for example Cray. Thus it is available on a wide range of equipment. It has a large user base and its communications method, TCP/IP, is mature. The UNIX workstation is most useful in accessing a UNIX system. Its use for accessing other systems depends on the provision of TCP/IP. On non UNIX systems TCP/IP is limited by how well the higher layer protocols can integrate into the operating system and for CMS the match is poor and VMS a little better. UNIX is available on a number of very high quality workstations such as SUN and DEC (under Ultrix).
PC users have a variety of requirements and broadly fall into two camps. One contains Office Automation with the requirement for word processing and fast IBM based communications to the mainframe. They are the main users of menu based systems. The second is the scientific community who have a wide variety of stand alone applications ranging from running large packages to code development. In the main, the user friendly front ends and windowing systems are of less interest. There is some overlap particularly in the area of access to the IBM mainframe. Although the quality of PC displays have improved they are still only of modest resolution. The basic problem is that high quality displays are expensive and could not be driven effectively with relatively slow small memory PCs. The emergence of high speed 386 machines with large memories should change this.
The strategic direction for graphics within IBM appears to be via 3270 connections into PS/2 equipment. There are some indications that IBM will support XWINDOWS. However, it does seem that this will only be useful for the scientific community while the office automation area will remain with IBM proprietary offerings.
Most PC users at present backup data onto floppy discs and the advent of 1.2 and 1.44 Mbyte floppies mean that for many this continues to be a viable proposition. However the increasing use of large discs means that some methods of file store backup will be a requirement in the near future. The cost of high capacity high integrity backup for each or a small group of machines is likely to continue to be expensive and back up to a central file store is attractive.
The increasing use of DECNET and TCP/IP on machines around the site means that there is a need for PCs to support these protocols. Low cost high speed graphics access to machines such as the Cray is likely to be something that could be met, in many cases, using a PC.
DEC provide a range of high quality workstations which are based on VAX architecture running VMS or Ultrix (the DEC version of UNIX). They have also announced an Ultrix only workstation based on the Mips processor. Communication between VMS machines can be DECnet, TCP/IP, or X.25. For Ultrix DECnet or TCP/IP may be used.
For close connectivity (resource sharing etc.), DEC VMS workstations are generally purchased as 'diskless' machines and integrated into a VAXCluster environment. At RAL and in most Universities this appears to be the preferred method of attaching workstations as it involves almost no extra management as all the resources are managed centrally on the cluster boot node.
Absent is mention of ISO communications protocols. Communications support is essential for all three groups. How it is achieved is not of interest to the users. However, although the low levels of ISO can support DECNET, SNA, and IP the higher levels are of less use and can only provide some connectivity between different regimes and for mail. There must be doubts as to whether the higher level ISO protocols can provide the close coupling of systems that good workstations demand in the near future. The low levels are only of use where there is sufficient bandwidth to support the applications. The required bandwidth is application dependent and with the more demanding applications there is no doubt that the currently available sub 64 K ones will be insufficient.
The basic requirements for a workstation are;
I hope you will have received your copy of my spread sheet of the EARN finances by now. If not then save this message until you have.
I have now discussed our finances with the Rutherford accountant. The principle problem he sees is with the contingency fund and the surplus carried forward. The "traditional" way EARN organises its budget is to assume that the income must match expenditure and no account is taken of surpluses from former years. These now amount to about 200000 ECU - a considerable sum. The accountant suggests that we abandon the "contingency fund" and "surplus carried forward" in favour of "working capital". Working capital is the capital we want to have at the end of the financial year and this would increase each year until we had the amount we wanted (I forget the amount - was it 690000 ECU?). We should then compute the contributions so as to provide the working capital we want. This makes the computations somewhat easier and also shows clearly the build up of the working capital. Remember that the contingency fund vanishes into a "black hole" and is only seen the the bank balance in the auditors report.
If we take this view then we have a further problem - does the surplus or deficit from a previous year get set against the volume dependent or independent contributions? A second problem is what to do with the expected 1989 surplus of 198915 ECU - do we want this to continue as working capital or do we want to reduce the 1990 contributions?
I have re-worked the spread sheet on the above lines and will bring it to the Amsterdam meeting. I have taken the view that surpluses or deficits are set against the volume dependent contributions. I have also improved the layout. Don't let that stop you playing with the one I distributed since I would like suggestions for improvements.
I have put a proposal to adopt this spread sheet as our financial model in order to discuss it at the next meeting.
Paul.
Dear Ms. Tait,
Thank you for your letter of December 2, 1988 in reply to my letter of November 29, 1989.
My licence to operate EARN in the UK has now expired. I am continuing to operate EARN according to the licence pending your further deliberations. I trust this meets with your approval.
Yours sincerely
Paul Bryant. UK EARN Director.
Dear Mr. Horrocks,
I wrote to you in August 1989 concerning the allocation of a UK DNIC for the EARN network and again in November 1989 seeking information on any progress.
We have now built our X.25 network which is now partly operational. We are about to offer a user service.
May I ask whether there has been any progress with our application for a DNIC? We have constructed out address architecture so that it would be easy to take advantage of an allocation.
Please contact me if you require any further details and I look forward to the results of your deliberations.
Yours sincerely
Paul Bryant. UK EARN Director.
Dear Mr. Titley,
I am happy to report that your Associate membership of EARN was confirmed at the recent Board of Directors meeting in Crete.
At that meeting we agreed a revised Charted and Code of Conduct. I do not believe that the changes will have any effect on your use of EARN.
I hope you and the academic community will benefit from your use of the network. Please contact me should you have any questions or problems with EARN.
Yours sincerely
Paul Bryant. UK EARN Director.
Dear Dr. Bolman,
am happy to report that your Associate membership of EARN was confirmed at the recent Board of Directors meeting in Crete.
At that meeting we agreed a revised Charted and Code of Conduct. I do not believe that the changes will have any effect on your use of EARN.
May I remind you that we have not furthered our discussions on how you should access EARN. The options would appear to be a leased line between yourselves and Rutherford or some form of dial up access to our computers. In the latter case we would have to levy a charge for the use of computer resources. I would be happy to discuss the technical aspects of your connection at your convenience. I hope your membership will be beneficial to yourself and to the academic community. Please contact me should you have any questions or problems with EARN.
Yours sincerely
Paul Bryant. UK EARN Director.
Dear Dr. Moncada,
Thank you for your letter requesting Associate Membership of EARN.
At the last meeting of the Board of Directors of EARN it was decided to delegate the acceptance of Associate Members to the national Directors. I am therefore happy to accept your organisation's application.
We still have to resolve the question as to how you gain access to the network and I will be happy to discuss this with you at your convenience.
May I take this opportunity of welcoming you and hoping that your use of the network will be beneficial to yourself and to the other members of EARN.
Yours sincerely
Paul Bryant. EARN UK Director.