The main reasons for the visit were to attend the National Computer Conference in New York and see a number of sites using Univac, DEC and CDC equipment similar to the ones being offered for the Interactive Facility.
Two minor or, at least, secondary reasons which came up later were:
The order of the visits were to be:
I am writing this as I go along so the schedule above is the anticipated one.
This conference must be just about the largest so far. The expected number of attendees is 40,000 - that is to the conference and/or exhibition. It suffers somewhat from the size. Whereas IFIP65 was contained within the New York Hilton, NCC76 is situated at the Hilton, the American (3 minutes walk away) and the Coliseum (half a mile away). The latter contains the exhibition on 3 floors of a building the size of Olympia.
The Conference Proceedings is about 1100 pages long and contains a subset of the papers presented. The decision had been made to only allow authors about 10 minutes to give an abstract of their paper which either allowed more time for the discussion or allowed equal time for another person to comment on the paper. The latter I found quite useful. An apparently existing well-thought out paper was often completely destroyed by the person commenting on it!
There were about 280 exhibitors including most of the mainframe manufacturers including ICL showing a 2903. My general view was that it was dominated by second-source suppliers, peripherals and micro-computers. I tried to talk to some of the people we have been involved with but got a variable response. The usual problem of the person on the stand knowing less about the product than you do. Assuming that my baggage limit is not exceeded, I will send around the brochures etc that seemed of interest. A few of the more interesting exhibits are mentioned below.
PRIME had a 300 and 400 on show. Most of the applications were business ones that were being demonstrated. The salesman did not think there were any new systems likely in the near future.
HARRIS was demonstrating their VULCAN operating system on a Series 200 machine with 96 Kwords store. It had 9 users doing a mixture of COBOL/BASIC/FORTRAN jobs including a FORTRAN compilation and one using FORTRAN floating point and I/O routines extensively. Grand claims were made for its Virtual Memory system, ability for programs to be in non-contiguous addresses, re-entrant code, batch/interactive JCL being the same. Just sounded right for our specification and response was good.
DEC, for some reason, did not exhibit. MODCOMP, Interdata were there but mainly showing small systems.
Tektronix were showing their complete range of equipment which seemed to be much as I had seen before. The only things that I found interesting, and may or may not be new, the 5953/54 graphic tablet (both large and small with pen or pushbutton cursor) and the 4952 joystick.
IMLAC had a number of PDS-4 and PDS-1 systems on display. The main items that were new are:
They had a number of peripherals attached including tablet, joystick, 4,6,6,6,6,4 arrangement of 32 buttons, etc.
They had a 21 inch tube on display with a P12 (orange) phosphor which looked similar to the old 928 display of Elliott's. It has a long persistence phosphor although ghosting did not seem too bad. They recommended this phosphor for the UK if you are using 50 cycles. The 21 inch tube employs a new gun from Thompson which is a lot sharper than the old one.
Vector General had their standard system on display with hardware rotation. Salesman could not understand why we got hardware problems in England. He said he would look into it. The 3400 display looked better than the Series 3 at Leicester.
Hughes C-9 is a video terminal which looks as though it is a normal CRT. You seemed to be able to define your own character set. Hardware had 16 grey levels, dashed lines, rotation etc and all for $10,000. The resolution could be better. Apparently it will be available in the UK next year.
Princeton 801 is a storage tube (there are other manufacturers!) marketing at $8,000 for a 17inch display, three character sizes, 32 grey levels, selective erasure etc. The catch is that it is a TV system again. There are several of this type of system around and they look as good or better than Tektronix. The 801 has a nice tracker ball.
Lundy 314 and 206 were both large high quality displays. They are not available in the UK. Looked very good. Similar to the old Cossor display.
COMTAL 8000-S is a colour video system specially set up for image processing.
Versatek had a number of printers and plotters
Full details of the displays given above should be coming around.
These seem to get smaller every year. The really bulky ones weigh about 18 lbs and are 15in by 17in by 5in. Of course, they do run at 30 chars/sec (upper and lower case). The coupler is built in and you have paper output. Cost about £1000.
At the other end is the MICON Pocketerm about 5in by 5in for £200 and battery driven with video output and coupler included! How can it be so small? Well really it is just the coupler and a very small keyboard and one line of output display! You can buy a larger 24-line video screen version for £350. In the middle there are a number of brief case versions with their own little video screens. You seem to be able to plug them in to your TV if you do not like the size of the screen.
If none of these satisfy you and you have a limited repertoire of commands, digits etc to read in, VOTRAX allows you to talk into your telephone. But how do you get your output back you say? Believe it or not, the signals get changed back to sounds and you get your answers read back to you in American!
I am not sure whether this is useful or not. Suppose you have a data tape and you have carefully taken the write-ring out. There is nothing to stop an operator putting the ring back in and writing over it on one of our computers. Well, you stick this ring in and wedge it down so that it is impossible to get a write-ring in the back.
On the whole, the Exhibition was good. I feel that Paul Bryant might have enjoyed it more. Lots of cassettes, modems, microcomputers etc.
Most of these are in the Proceedings which can be borrowed from me if you have the endurance to wade through it. I will concentrate on points of direct interest. Obviously I only managed a small fraction of the sessions. I tended to concentrate on graphics, minis and engineering/AI applications. If the papers are in the Proceedings, I will not bother to comment.
The session had an interesting paper by Richard Watson of SRI talking about a large system for users of various disciplines and levels of expertise. He outlined a number of design criteria for a system of this type which gives a good check list.
One interesting innovation was a Key Set looking like 5 piano keys which was used to input text by hitting chords of keys. Users preferred this to a keyboard as you could use it without taking your eye off the screen. Apparently they became quite proficient at it.
In the same session was a description of a Terminal Transparent Display System for the PDP11. It was a bit like GINO-F/PIGS with a random set of graphic primitives. I think this was typical of a number of presentations. There was little aim towards standardisation. Nobody really thought it was possible. Even so, the paper is worth reading.
There was an interesting session on current robot projects in the USA. Most of these were government sponsored in some way or other with specific aims. The two largest projects were a Mars rover Vehicle and a Smart Fish submarine-like device.
The Mars Rover is about 6 months away from completion. Because of the long delays in time between transmission to and reception on mars, the Rover needs to have a reasonable amount of intelligence otherwise all manipulations will be rather slow and it will be impossible to stop it falling over a crevice! The vehicle is about 6ft by 6ft by 6ft. The vision system consists of a laser range finder together with stereo video cameras. It can currently execute commands such as Pick up the large green rock and put it in the collection bag. A film was shown of it performing in real time. It first looks at the scene for about 2 minutes with its head scanning backwards and forwards. Then, in a flash, it picks up the rock with its pincer hand and puts it in the bag. If it drops it, it can calculate the possible trajectory so that it can estimate where it landed so that a large scan is not required the second time.
The Smart Fish program is due for completion in 1978. It is an unmanned free swimming robot/submarine with a 1000 miles endurance capable of performing a wide range of tasks on the sea bed. It will, for example, be used for disasters like the THRESHER submarine which was found and raised several years ago. It will also be used for geographic studies. It has a nuclear PU238 engine. The aim will be to send it on missions for about 6 months at a time. the thing keep popping up to the surface every now and again to check its position.
There was a complete session on this topic but none of the papers appear in the Proceedings. Max Matthews of Bell Labs who has written a book on the subject and is author of the MUSIC 2, 5, 10 and MUSIC 360 systems gave a long presentation of the work at Bell Labs.
Most of the early work was with special purpose hardware capable of generating voltages from hardware directly. They could achieve 30,000 pulses per second which gave them good response up to 15K cycles per second. He estimated that each bit in the output gave a 6dB signal/noise ratio so that a 12-bit output gave you 70dB signal/noise.
There are a number of papers on this work so no need to go into great detail. Degenerate oscillators are used to control the attack and decay of a second oscillator. The MUSIC 5 language is similar in complexity to ours. It does not look particularly easy to use.
They have a newer system called GROOVE which allows real-time playback after computing what is required. Again similar to ours. Hardware, however, is much more extensive. It has a DDP224, 12 8-bit and 2 12-bit D to A converters, 16 relays all tied to an analogue synthesiser. It had a large patch board, 50 potentiometers, a variety of filters etc - two complete bays of electronics. You could set up any kind of instrument with relative ease.
The other contributor to the session was Bob Lee from Livermore who showed the films I brought back last year. His presentation was similar to the paper in the recent issue of Computer Graphics. He has taken over from Fernbach as Head of Computation at Livermore. There was one new film shown of a Tungsten crystal where the sound was used to indicate the energy of the crystal at each point in time as it was bombarded by neutrons.
Steve Levine, who chaired the session, gave me his molecule film and will let me have a copy of the Tungsten film in exchange for an ANTICS demo (Eric to give it to him at SIGGRAPH). He will also let Eric have a copy of Ken Knowlton's ATOMS program which generates molecules rotating with solid atoms and hidden line elimination.
Livermore have purchased a colour system from DICOMED which gives good quality output - possibly better than the FR80 as it is set up just for that. Cost is about half an FR80 and uses the same Lytton tube as our FR80.
Tom de Fanti described his video system at the University of Illinois (see Alan Francis for further details) and showed one or two educational uses. The first demonstrated that 3D-rotations were not commutative while the second did Continental Drift yet again. The quality of both was awful and would put people off. He also showed some autistic video in another session which was quite beautiful but repetitive.
Martin Tuori described the work of Rom Baecker's group at Toronto and showed a number of very good films some of which I had seen before. Films included childhood dental development, binary addition, sorting (various methods), hashing, disc head movement algorithms etc.
Nestor Burtnyk talked about the Canadian work and showed the finished Old Man and Flute sequence which is really first class - all the joints on all the fingers moving beautifully. Nestor has been promoted and Marcele Wein is doing other graphics work so that the animation work has stopped.
Bruce Cornwell showed a number of films he has made on Relativity which were a mixture of conventional and computer animation. I showed the FE Film and got an enthusiastic reception.
The programme ended with Nelson Max again producing his definitive film on turning the sphere inside out. For readers of previous reports, Max has been producing the final film on the subject ever since 1968. This really looks as though this is it. Max suffers from not knowing how long a film should be. He starts by introducing the mathematicians involved, spends a while showing you how you generate chicken mesh intermediate views by soldering etc and eventually you get to see the computer animation. The sphere rotates as the transformation takes place so it difficult to understand what is happening. He first shows it as a mesh, then a coloured solid, then a different mesh, then a solid broken in two etc by which time the audience is losing interest.
The assertion was that the session was to discuss possible standardisations. There were two papers, one on SPEAKEASY which is an extensible Graphics BASIC and DISSPLA. The first system is interesting in its limited environment. Hirschsohn talked about DISSPLA and was selling it quite hard. It has a degree of acceptance in the USA. They claim it runs on 70 sites. The main area that was new since I last heard a presentation was some nice 3D contouring routines which gives output looking like a four-poster bed with the contour underneath and the relief on top. They have included an 1800 colour set for the FR80 and these extensions all seem to have been done by Argonne. When questioned, he was quite strong in making the point that you can only get machine independence by having an absolute line draw as the only primitive so that all characters are drawn as vectors and, if you have a character generator, you just do not use it.
The general conclusions seemed to be that you needed both. That the way to go was to connect your large batch processor to an intermediate machine which provided overflow resources for cut-down single-user mini systems. That is the existing small machines in universities (in our context) should be directly linked to the PDP10 and through this to the 360/195. There was some mention of multi-user minis. Nobody pushed them very hard and the possibility of them taking over from single user systems never came up. I am sure the reaction is that minis are so cheap, why not buy each of your users one each and connect them to any other resources they need over a fast line.
Of direct interest (possibly) to us was a description of PL/11 developed by Bob Russell of the University of New Hampshire. Dennis Ritchie of Bell Labs also talked a bit about UNIX. He seemed to be still involved with it. It was written by the Computer Science Research Centre as a research exercise in operating system design. Initially they tried to get Bell labs to buy them a PDP10 but finally settled on a PDP11. The main aims, he stated, were device independence, a simple file type and written in a high level language (C).
The Conference was certainly not as good as IFIP last year. There were too many discussion sessions where the questions being asked were quite trivial. The format for sessions varied depending on the organiser. On the whole, I would have preferred less question time and more time for the speakers. This is the reverse of the usual complaint.
Hugh Davies and the local UNIVAC representative, Jim Tresselt, met me and took me out to the university. The head of the Computer Centre is John Menard and the head of the Systems Group is Pat Hagerty.
The current system consists of a dual-processor 1108 which is used for batch and interactive use and a 1106 which is more for interactive use. They have 256K of store on the 1108s with 16 8424 discs for filestore. They find this inadequate and get quite a lot of catalogued files migrating on to tape. Swapping is done to 432 fixed head discs (2 × 256Kwords) and 1782s (2 × 8Mwords). The 1106 has 256K of store and one 1782 fixed head disc.
They will soon be installing a 1141 to replace the 1106. This will have 384K of store together with the 256K slow secondary store taken from the 1106.
The 1108 has about 90 ports connected to it. There are software constraints to keep the number of DEMAND (interactive/edit) users down to less than 70. They have Tektronix connected at both 300 and 1200 asynchronous. They use MICRODATA computers to concentrate lines into the 1108. For example, one MICRODATA controls 24 lines of which 6 are Tektronix and the remainder teletypes/VDUs. These come into the 1108 as a 4.8Kbaud line. They have the system set up so that it automatically recognises the baud rate of the terminals. They have a CTMC into which most of the lines go. They have just purchased a C/SP and are currently writing code for this. One MICRODATA is similar to our GEC 4080 in that it switches users between the 1108 and 1106.
Menard felt that the 1108 system was well tuned apart from the lack of filestore. When I saw the machine, response to editing was comparable to the 1906A while the machine had about 50 terminals on it and a large batch load (there were about 96 jobs in the input well).
The site has a great deal of expertise and the system works well. they have about 15 systems programmers. This contrasts with running both the 1106 and 1108 with a single operator. They had about 15 to 20 tape decks and the disc storage is in a separate room. Exofiles are not allowed except in real need. They keep the system on its own disc and a back-up on another disc just in case it is needed quickly.
The Group has modified the Operating System and associated software considerably. It now amounts to 100,000 lines of code which they make available to other sites on a pair of magnetic tapes with documentation on the front. They have tended to make the minimum of changes in the basic operating system and force most of the changes into user programs. Thus a new facility might just patch one word of UNIVAC code to call some other routine. Where they have had to make significant changes, they have tended to delete the UNIVAC module completely and overwrite it with their own.
Most of the updates are done in ASSEMBLER although they have introduced MACROS such as IF-THEN-ELSE so that the code does look quite readable.
They find that installing a new mark of the operating system is time consuming although it tends to be straightforward. They keep all the changes in an edit file and edit this to get line numbers etc correct for the new version using SSG. They are currently in the middle of implementing Version 33. Version 31 was installed in September 1975 and Version 32 in February 1976. They tend to be a pre-release site but, due to the scale of their changes, they are not always the first place to have a new version up and running.
The reliability of the hardware is not very good but this is entirely due to the local power supplies which go down whenever they have a thunderstorm. Apart from this, they feel the hardware reliability is good. The 1106 tends to average about 5 hardware/software breaks a month although they have had periods when it has been as low as 2. The 1108 is less reliable partly due to a heavier load and also because it takes the main proportion of software breaks. They regard a week as bad if they have 5 or 6 hardware/software breaks. They are currently installing their own battery power supply to carry them over the thunderstorms.
They seem to have a good relationship with UNIVAC and get most of their modifications accepted by UNIVAC eventually. It does take a long time if the changes are large. For example, they changed the course scheduler and it has taken 2 years to go through the internal validation within UNIVAC. Other major pieces of software are:
I asked them about the addressing problem across 256K on the 1112 and 1121. They were not absolutely sure but felt that there were no problems in the hardware. Apparently, a 19th bit is added to the relevant register and does get used in additions etc. However, there was likely to be a problem with UNIVAC I/O software if the buffer crosses the boundary. They did not think it would be difficult to alter but felt that UNIVAC might take the easy way out and just stop programs crossing the 256K boundary.
The file accessing system is efficiently organised and an element can always be accessed in two block reads as long as their are not a large number of entries in the file.
They take a dump of all the damaged files once a day using SECURE. Once a week, they take a complete dump and merge the files from the incremental dumps. They currently have a 70% over-commitment of filestore. The automatic dumping or ROLL-OUT of files when more space is required first checks for unchanged files and will recover this space (not taking a copy) first. They currently never need to roll-out files that have been altered. The file chosen for roll-out depends on the UEF (Unload Eligibility Factor) which depends on whether file is Public, how many times accessed, last accessed etc. It is probably not ideal for Maryland but is low priority on their list of improvements.
They indicated that they did not have many Engineering users. Even so they do have ISYS, COGO and NASTRAN up and running. The latter gets used quite a lot. The version obtained from NASA reserved a massive file space even when it was not required. They modified this and also have put in a check to limit the number of simultaneous NASTRAN users. They also have SPSS running.
On the Communications side, they have kept to UNIVAC protocols. PDP11s tend to interface to the 1108 as though they were fast teletypes.
Their main comment on our proposed workload was that 10 or 15% of the machine might be required to handle the I/O. It takes about 100 instructions per character output.
They felt it was important that a large fast swapping device was available. Apparently a subsidiary of UNIVAC called ISS is producing a Charge Coupled bulk store of about 2 Mbytes for $300K. They suggested that we should try and get UNIVAC to offer this as an alternative to 8405s (these replace the older 432s).
The Centre seems to have a large amount of internal documentation. They have two series, Technical reports and Computer Notes. Also, elementary manuals (such as Demand Users Manual (DUM)) have been produced. They are going to send a list of publications and the directory on their system tapes which indicates the changes they have made to the Operating System.
One major change that I forgot to mention is a complete change in the way they handle interactive use. The standard UNIVAC system CTS is inserted between the user and the system and does degrade the system. The Maryland alternative allows the user to get directly at the system functions. However, it stops him doing interactive compilation and other unreasonable interactions by changing the compilers. They felt that their system was considerably more efficient than the UNIVAC one.
The Centre was quite happy for us to send additional people to visit if it looked as though we would purchase UNIVAC. They have had a number of people from other sites coming for a period between 2 and 12 weeks. the Centre gives them work to do and ensures they get trained in the process.
As well as the Computer Centre people, I also talked to a member of Rosenfeld's Pattern Matching and Image Synthesis Group. They have their own home-made scanner and film recorder. The latter has about 4000 by 4000 resolution with 64 grey levels. It was a Ferranti tube and a Polaroid camera for output! I was amazed at the quality they achieved. they produced colour output using a high-precision IBM device that they accessed at a bureau.
I also talked to Jim Stewart for a while. He was complaining that all this interactive use of the machine slowed down his batch turn-round. He gave me a new Manual for the latest X-RAY system to give to Pella Machin. His Group has now decreased until he is now a 1-man band.
The National Ship Research and development Centre is situated at Bethesda and used to be called the David Taylor Model Basin Centre. We have had dealings with them many years ago when they were active in computer animation. They have an SD4020 and a SD4060. Most of the people who were doing animation have left (mainly to have babies). The Centre has a large wind tunnel and also the largest tank for ship design in the world. Must be 200 yards long at least. It is the usual high security US Government establishment with escorting required.
The hardware consists of a CDC 7600, 6600 and 6400 each with 128 Kwords of memory. They are just in the process of changing a variety of disc systems for the single density 100Mbyte 844-41s. When these were installed on the 6400, the immediate reaction of the users was to wonder what had happened to all the others as the turn-round suddenly improved. The CDC 6600 is used for batch work and the CDC 6400 mainly for interactive work while the CDC 6700 runs both. They have no file exchange facilities other than magnetic tapes so it is quite difficult to move from one system to another. Users tend to choose one and stay on it. I have a complete list of their hardware. It extends over about 8 pages. Their main interactive graphics consists of three 1744 Digigraphics systems each connected to their own CDC 1700 which also acts as a remote batch entry terminal. They are situated in buildings remote from the main machine. They have a number of 1700s and other RJE stations connected from other Naval Departments throughout the country.
I have a manual which gives their charging policies on the three machines and scheduling parameters for different periods of the day. The site has a large batch load and an interactive service is provided in spite of this. Because of the batch load, response is poor.
All three systems are running under SCOPE 3.4 and INTERCOM. As INTERCOM allows up to 4.8 kbaud, they do not have the problem with high speed Tektronix. The Centre has had a reasonable amount of interchange with the CAD Centre in Cambridge who should be familiar with the Engineering packages that they can make available. There are security problems and I could not get too much information directly. They are mostly concerned with ship design.
The main area of interest was the fact that they are about to benchmark for a machine to provide an interactive service for 47 users. They are about to go out to tender in the near future. Unfortunately they were rather guarded in their replies as the CDC representative was present.
The benchmark is being set up with the assistance of the National Bureau of Standards who seem to be doing a similar job to CCA and charging $1000 per benchmark. NBC have a 3-volume book on Performance Monitoring, Stimulating and Benchmarking which they thought we could obtain if we write direct or through the Embassy. Philip Hayden (Code 189.2) promised to send me more details.
The benchmark is to be stimulated but will have one genuine teletype. Jobs are categorised approximately into:
The benchmark will have a set of criteria that have to be obtained. Some of these need the real teletype to get the required information. Parameters include time to echo a character, saving a file, simple edit, merge file etc. They seem to be similar to the set of parameters that we will measure. I was unconvinced that a real terminal was essential and they could not really put up a convincing reason other than it might help if a certain stimulator had some facilities missing. The scripts were genuine programs rather than synthetic. I tried to get a feel for what stretch factor was expected. Again they were reluctant to say but implied it was around 24. On the CYBER 173, they did not feel this could be obtained without 256Kwords of store and might also need ECS!
One point of interest was that a better swapping device than the 844-41s might be available. It is possible that CDC may make the 819 (300 Mbyte) disc available on the smaller CYBER machines. It is currently only available on the 7600. It is possible to swap 2Mbits/sec using this device.
At the same time as going out to tender for the interactive machine, they are also going out to tender for a front-end processor and also the relevant code changes to support a variety of protocols.
CDC looked as though they might offer NOS/BE with INTERCOM as the interactive operating system and not standard NOS. Apparently, CDC have had a great deal of pressure from SCOPE users so that they have had to introduce NOS/BE which is more akin to SCOPE than KRONOS. The aim is to merge the two operating systems into a single NOS eventually.
It is surprising that they are benchmarking both NOS and NOS/BE here and yet this has not been mentioned to us.
I also talked to Jim McKee of their NASTRAN group. They seem to be the main USA user of NASTRAN and have generated a number of programs for NASTRAN data generation and verification. Thus you can describe your surface in terms of geometric structures such as cylinders, spheres etc and these get translated into the relevant NASTRAN data cards.
The Digigraphics displays are used for data validation. The NASTRAN data can be displayed, edited, rotated, zoomed etc. Editing seemed rather cumbersome. You picked the relevant point with a lightpen and it told you its internal name. You then had to get out the relevant NASTRAN data card and type in the updated value. It seemed very cumbersome and it was made much worse by the poor response. To generate a new view of the submarine (or was it a torpedo?) took about 30 secs to a minute and it was not very complicated. Perhaps 200-300 rectangles.
They do not seem to be very adventurous. They still use SD4020 software on the SD4060. They use IGS on the Digigraphics and PLOT10 on the Tektronix which they have only just started installing. They are considering changing IGS so that it also supports Tektronix. The only major modification made to IGS was to allow a number of files to be open at the same time.
On the whole, they seem a rather conservative organisation. The main interest is their benchmarking exercise and they promised to keep me informed of anything they are able to tell me. They hope to go out to tender in about 2 weeks and will give the manufacturers 60 days to reply.
They did not seem to have made many changes to the Operating System and their expertise is not particularly relevant as it is all SCOPE-based.
They have a copy of Pl/I obtained from Courant Institute and it is missing about 20% of the language features.
I had to leave Charlottesville straight after lunch to catch a plane to Boston so this was to be a short visit. I arrived at the University by 09.00 and, as it happened, this proved to be more than enough time. I rang the CDC salesman, Vest, the previous week to confirm that the visit had been arranged. He was not there but his secretary confirmed that I was expected although Vest, himself, was thinking of taking a vacation. I asked the secretary to confirm the arrangements had been made with me at my hotel in Washington. When I arrived in Washington, a note had been left saying that Vest would be away but that Plesmus, the Director of the Computer Laboratory, was expecting me.
Charlottesville is out in the country and serviced by one of the smaller and more unreliable airlines. When I arrived at the university Plesmus had left for a meeting in another town and would not be back that day. There was no record of any arrangement having been made. After trying to get me to talk to Head of User Services and Operations, I finally convinced them that I would like to see the person in charge of Systems Development, J. S. Klinedinst.
The site has a 6400 with 96K of store and four 100 Mbyte discs. Communications is provided through a 6671 (supporting about ten 2000 and 4800 lines), 6676 (supporting 16 teletypes, 110 and 330) and a 6673 (supporting a 777 Digigraphics display at 40.8). The first two are going to be replaced by a 2550.
They run SCOPE 3.4 and use INTERCOM for the interactive jobs. They will be replacing the 6400 by a CYBER 172 (which is slower) primarily because it is cheaper to rent. As the PPUs are twice as fast and this seems to be their main bottleneck, they hope to get much the same throughput. With the CYBER 172 they will move to NOS/BE which, in its current release, is identical to SCOPE and INTERCOM just as NOS and KRONOS are identical.
They had no intention of going to NOS. CDC had indicated that NOS and NOS/BE would eventually merge but they estimated that this would take at least five years and the final product would look more like SCOPE tan KRONOS. Going to NOS is, therefore, of no real use to users as they would have to convert systems twice. The replacement of the KRONOS loader by the SCOPE loader was given as an example of the move away from KRONOS and towards SCOPE.
On the hardware side, they did not really feel that there would be any advantage of the CYBER 172 over the 6400 apart from the parity checking. It is possible for the current system to run for several days without a memory fault being discovered if it is intermittent. Their 6400 already has the main machine exchange-jump command added as an ECO. As CDC moved a great deal of code out of the PPUs into the main machine at the same time it is not obvious what advantages had been gained. The motivation for the addition of the command by CDC seems to have been that most sites were PPU limited. Whether this is true for the double-speeded PPUs is not clear.
The reliability of their 6400 was very good. The worst down-time recently was 5 hours lost to an air conditioning failure. It is very hot and humid at Charlottesville! The down-time for the previous month was zero (both hardware and software). They also seemed to have a fairly hard definition of down. They regarded the system as down if a lineprinter or card reader was down even though they had a number of campus RJE stations. They felt that it averaged out at about one significant hardware break every two months. When a new version of the operating system was installed, they might have a software break rate of 2 or 3 a week which soon went down to 1 or less.
The changes they have made to the operating system was about 50. The type of change was of the type: automatic layout, banner headlines etc. Nothing very significant. They mostly used standard CDC software although they used the London Dump Tape Analyser, University of Texas's Algol, SNOBOL and PASCAL from Colorado, SPSS from North Western.
The main internal additions have been to mount their own version of the KRONOS editor. The SCOPE editor is a single program resident and used by all users. As it crashed fairly frequently, many users were losing their editing at the same time. Their own editor runs as a straightforward user program with one copy for each user.
Performance of the system was very good when they demonstrated it. However, at 11.00 am, I later found out that we were the only interactive user and no batch work was in the queue! It is currently out of term time. However, they never have more than 4 or 5 interactive users normally. The most they had ever seen was about 10! This is partly due to their charging policy which made interactive use expensive. Also, they have a number of HP2000 systems providing a BASIC service which is about a third of the cost of the same facility on the 6400. This site is, therefore, of little value to us in terms of assessment.
They do not appear to have any Engineering users other than on the HP2000. On the 6400, they use FORTRAN (83% of the jobs) and COBOL (10%, mainly working out Parking Tickets and orders for towing cars away!).
they purchased the display system assuming people would use it but virtually nobody has. The 777 is an improvement on the earlier system. It has depth queueing in the hardware. Still very expensive.
They had just installed a QUANTOR 48X fiche recorder which was quite compact. Processing was done within the system which was about the size of a card reader. Cost is about $30K.
Minor points which came up:
The first day at the DEC end of the visit was spent at the Marlboro plant which supports DEC10, DEC20 and PDP15s. The day consisted of a number of informal discussions which had been arranged by Ian McKean. Initially, I gave about an hour long presentation of SRC's hierarchy, committee structure etc for DEC's benefit.
John Jorgensen and Alan Wilson gave me a good deal of information about the current state of the hardware and software. On the hardware side, dual porting of the disc drives will be supported by the autumn. This will allow a given set of disc drives to be accessed by two controllers and from two channels.
DEC now have TU72 tape drives available which are plug-compatible with IBM drives. They can run at 125 ips and transfer 780Kchars/sec. We had some discussion as to whether four TU72 drives might be more effective than purchasing TU70 decks and a second controller. DEC have no plans for marketing mass storage on the DEC10 for at least two years.
It is possible to support both 100 Mbytes and 200 Mbyte drives on the same controller so that it would be possible to purchase a 100 Mbyte drive if compatibility with UMIST and Edinburgh was required.
It is possible to upgrade our DEC10 KL hardware (if we buy it!) to a system capable of supporting TOPS-20. Virtually all the changes can be made in the field (includes changes to microcode and I/O changes).
On the software side, little seems to have changed as far as deliveries of specific facilities were concerned. The new ANSI FORTRAN was unlikely to be available before 1978 or 1979. DEC would not start working on it until the Draft was officially approved.
Little work seems to be going on as far as Accounting software is concerned. An agreement has been reached with DECUS that when they have defined a specification of what is required, DEC will implement it. Unfortunately, DECUS had still not replied after many months.
A Corporate Command Standard for JCL on DEC10 and DEC20 has been proposed. The way things are likely to go can be seen by looking at the PDP11/70 IAS system which adheres to it. There is no policy within DEC to clean up the current multiplicity of command formats although, in time, they are likely to change to the SCAN format.
I raised a number of specific questions which were still bothering us (me).
The main problem with choosing a cluster size are that too large a cluster will result in wastage of disc space while too small a cluster size will cause the SAT table to get very large. This contains 1 bit per cluster. Approximately a cluster size of 16 would give a SAT of 300 words while a cluster size of 1 would give a SAT of 4800 words. The situation is not as bad as I had expected for two reasons:
On my hypothetical 1 Mbyte user with 50 files, they suggested a cluster size of 10 blocks.
The Locked Down Core per user job is between 250 and 300 words. Assuming all possible features of the Operating System were in use then the total locked down core would be about 90K words and this includes the 60 × (250 to 300) words locked down for the user jobs.
The information we had been given that the RIBs of open files were locked down in core is not correct. For each open file, there is a 32-word Device Data Block which contains information about the file being accessed and will contain a part of the RIB - the relevant part at the moment.
RIBs are read initially into MONITOR buffers and the default number is 2.
The situation as far as Operating System Maintenance charges on our PDP15 was explained to Mike McCarthy. He felt that Mike Mulloy had complied with the letter of the law as far as the maintenance contract was concerned. However, he was sympathetic to our problems and was happy to allow us to have the MULTIACCESS option free of charge as long as we realised the old arrangements of providing copies of source twice a year were no longer in force. He also said that, in return, he would like us to be active in setting up SIG18. I agreed that we would contact the European SIG18 Head, van Poelgheest at the Academic Hospital in Utrecht and Dr Joe Gallagher of the Dept of Radiology at the university of Kansas Medical Centre, who is SIG18 Chairman to see what help we could give. MULTIACCESS should be available in September.
One interesting announcement that will be made at the European DECUS meeting is a second generation Unit Channel product based on RSX11-M and a PFDP11/34. It came in two main options:
Both interface to the PDP15 via MX15-B, XM15. The cost of the second is about £27K and would allow the PDP15 to be connected via a DAS87 synchronous line to the DEC10. By user level programming only, it will be possible to communicate with the DEC10 using DECNET and a PDP15 subsystem called TENLINK. The only method at the moment would be to connect to an asynchronous port using the Hurley protocol. One interesting point coming out of this connection is that, if the PDP15 is powered down, the PDP11 can use the PDP15's memory so that the PDP15 turns into a 96K PDP11/34.
I was given a tour of the factory which contains the production lines for DEC10 and DEC20. The building at Marlboro is grandiose by DEC standards. It was built for RCA and is quite elaborate. A large RCA entrance hall is used for storage. RCA went bust and DEC were able to get the building very cheap.
The building gets wider as you go up. All the production is on the top floor and, as the building is on the side of a cliff, loading and unloading is done at this level.
Most of the logic is put together here. There is a considerable amount of board testing equipment, all controlled by DEC10 KLs. Seemed a waste! I saw the Dundee and Bangor systems in a well advanced state of being put together. The York machine has already left. Oslo University have a system similar to the one proposed by us and has RP06s on it.
I talked to the person who refurbishes the KIs. They had about ten KAs on the floor and no KIs. They were expecting about four any day now and he thought three had already been committed. The systems seem to have a complete check which lasts about 3 months for even a relatively new machine. All outstanding ECOs are added, motors etc replaced if the age was greater than a specified value. Wiring was changed if it did not conform with current standards. As DEC have no machines in-house now, it is impossible for them to supply the machine for Edinburgh before September and possibly later. Right next to the refurbished area is a big empty space which is being made ready for the DEc20 production.
There were one or two TU72 decks around and a new chain printer with a double chain which you can turn over to get a different character set.
They have three PFDP15s using VT15s and a modified REDAC package for circuit design. They were in heavy use.
The software development teams have a mixture of DEC10 KLs, KIs and KAs plus a DEC20 for software debugging. There are a number of RJE stations with teletypes connected scattered around the building. The one in the DECNET communication area is called CATCH 22!
I first talked to Fred Wilhelm who is concerned with DEC's ARPANET interests. Apparently, the American defence organisations are becoming interested in using ARPANET as a means of communication together with stand-alone computer facilities that they can buy off the shelf with little support required. DEC have already sold a number of KL1080T systems to this market. The first would be delivered in December. It consists of a fairly standard DEC10 with an ARPANET box called an AN10 which provides the connection to the BBN TIP. The ABN10 seems to be based on a DAS87.
Brian Samuels talked to me about DECNET. The system is up and running in-house and it is the standard means by which the systems programmers access the KL10s etc. First Data in Boston will be linking three DEC10KLs and 12 remote stations together using DECNET in about 6-8 weeks time. The facilities in DECNET can be divided into a number of areas:
Facilities (1) to (4) are supported by 6.03 free-of-charge. Only (5) costs the money quoted in the Edinburgh and UMIST upgrades.
I was shown the system in operation and it seems to work well. Certainly in our timescale there is every reason for this to be a reliable DEC product.
DEC have a number of projects involved with IBM protocols and equipment. They currently have the 2780 protocol available. The 3780 protocol should be available by November 1976. They then have the possibility of releasing staff to do the standard HASP protocol. This would be scheduled for completion in July 1977 although, if a sale depended on it, this could be available by April 1977. It is impossible for two DEC communication protocols to reside in the same DAS87. The code is not written to make this possible. Thus, to support HASP, we would need another DAS87 which would cost approximately £40K.
We talked a bit about other protocols. DEC realise the importance of being able to support protocols that require bit stuffing such as X25 and HDLC. Thus they are providing a DVP11 which supports bit stuffing for both HDLC and SDLC. The DMC11 is a microcoded interface which allows a variety of protocols to be handled. DEC also provides a KG11 which, by hardware, does Cyclic Redundancy Checking. Details of these new facilities will be given at the DECUS Conference in Las Vegas in the autumn.
The other hardware of interest that DEC is working on is primarily aimed at TU70 tape deck support on the DEC20. A DX20 hardware device is being produced which interfaces a DEC mass storage bus to an IBM channel (selector or multiplexor). The device can also be used for connecting DEC machines to 360 machines in a close-coupled environment. Thus the DX20 has been developed so that it can look like both a peripheral and a mainframe. This could be a method of getting a fast interface between the 360/195 and DEC10KL if we purchased one. Unfortunately, the hardware will not be available until February 1977 and the software to support the hardware may be considerably later.
the Telex from Graham (Robinson) had arrived and Nancy Ohm had looked at it before I arrived. We had a brief meeting in the middle of the day to discuss what needed to be done and agreed to come in in the evening to sort out the problems. Nancy had booked the machine from 6.00pm onwards.
Some of the problems cannot be solved quickly. The SIM11 simulator in the PDP11 is designed to keep all the output generated and it is not possible to throw output away. This results in a bottleneck in getting the information from the PDP11 to magnetic tape with the consequent disastrous results. It is not clear that the situation will be solved by just throwing the output away. A certain amount of output processing is done before it is put in the tape output buffer and some of this will still be done even if the output is thrown away. Thus a bottleneck could still arise.
Nancy Ohm had uses SYMLOD rather than SIM11 so that she could get some results. The make-up of the scripts is similar in both systems and preparation for one run is a good debugging technique for the other.
The designer of the SIM11 simulator, Ed McHugh, was unfortunately away in Texas and no changes could be made to the simulator until he returned. I suggested that they should attempt to throw away the output and, if this did not cure the bottleneck, to consider outputting the major parts of the Tektronix output to genuine devices. It is unclear whether the stimulator, in its present form, can support real and simulated terminals at the same time. This will be checked when McHigh returns. It is quite obvious that the simulator is still under heavy development. For example, when we tried to run the latest version we found that it had a bug in it. The older version which had worked before was also found to be corrupt.
The evening session was a bit of a disaster. First the tape deck would not load tapes. Later we had a number of funnies with the PDP11. By about 11.30 pm we gave up attempting to run the benchmark having achieved very little. However, most of the errors in the previous runs had been identified and a test run under SYMLOD seemed to have no bugs. The main solutions were as follows:
Once the bugs had been removed, the scripts were run one at a time and checked out.
A POLYATOM bug took a long while to narrow down. There is an expression -A*B*DAB*T1 in a routine as an argument of an EXP function. The optimising compiler codes this as ((A*(-B))*T1)*DAB. Thus if T1 is small and A*B is small then underflow could occur especially if DAB is not small. We have decided to run POLYATOM with brackets around the expression (this turns the optimising off) to see if it then runs correctly. It is a bit worrying especially as DEC seem to have experienced this type of fault a number of times in the past.
I apologise for the quality of this write-up. It is now 2.00am!
For some unspecified reason, it was decided by DEC that visits to First Data and MIT would be more beneficial than a trip to the University of New Hampshire.
First Data are a timesharing bureau in Boston which has the unfortunate distinction of having had the biggest computer fire in history. They had a number of KA and KI systems on the Third Floor of a multi-storey building which caught fire on a Saturday evening. The fire was on the first floor and was sucked up the power cable to the Third Floor by the air conditioning. Before firemen could get it under control, parts of four KA an KI systems were total right offs. It is an impressive and rather tragic scene at the moment with burned out cabinets etc.
The company is about the largest timesharing organisation around and were able to keep running on their existing equipment. DEC managed to supply them with a KL system to replace the damaged systems on a Wednesday after the order had been placed on the Monday. The fire happened recently (within the last two months) and had caused the company serious problems. Luckily they were completely insured. The floor of the building has warped considerably and will need to be re-concreted. Consequently they decided to move to another factory. A suitable building was found and it has been refurbished to hold eight DEC10 KL systems in two fire-proof computer rooms.
When I visited they were in a rather chaotic state having machines in three different locations. It was difficult to count what they had but it is about 2 KLs, 3 KIs and 4 or 5 KAs that still work.
The workload appears to be quite varied and reasonable in size. It is predominantly FORTRAN although there is a significant amount of COBOL and virtually no BASIC. Their main problem seems to be to keep a good mix of jobs on a particular system so that they can get good performance and response. Basically a user will be dedicated to a single system although the system he is using may change from day to day. The files belonging to the user are moved from one structure to another.
Most of the use is via slow and fast VDUs but very little graphics. On a KI they would expect to run 60 or 65 concurrent users on 512K words of core with 8 RP04s and achieve a CPU utilisation of about 80%.
Due to having to move communications from one building to another, the KL is not fully loaded. They are currently running about 40 users with a CPU utilisation of about 60%. To some extent they did not feel any requirement to give users over-good response and would load the system until it just began to hurt. They felt it was dangerous to give users too good a response. If they did not know any better, their current response was always acceptable.
The changes they have made to the operating system were not extensive except in the area of communications. Here, they have produced their own system which coupled the systems together and provided remote concentrators in Washington and New York.
They have decided to go over from their own system to DECNET and will be the first main external DEC user.
They have their own accounting package which uses a DEMON program distinct from DEC's to take snapshots of usage from which the necessary statistics are obtained.
They run with four different structures on eight drives - each having its own cluster size, typically 2, 4, 5 or 7. A user is allocated to the most appropriate structure.
The performance on their KI systems had been good and they were expecting better performance and reliability from the KLs. They would expect a MTBF of about 1 month.
The operating system core requirements was at least, for their type of workload, 80K words. It depended on number of users and size of backing store available and type of devices. They suggested that a sensible rule-of-thumb was to purchase 128 Kwords of store for the operating system.
The dumping philosophy was to do an incremental dump once a day, a full dump once a week. The only time the dumps get used is to restore files inadvertently lost by the user. In fact, as they do not charge for this service, they have begun to notice a few users deleting files this way on purpose and later restoring them so that they could avoid the charge for archival storage.
The new building had considerable thought put into the fire safety. Each water sprinkler has its own detector so that the minimal amount of equipment would be damaged. As well as this, the system first triggers Haylon gas to stop the fire. The sprinklers only come on later if this is unsuccessful.
It was interesting to see that a large amount of the 100Mbyte drives were CALCOMP ones and a considerable amount of memory was AMPEX. They had also been able to get DECtape drives on their newest KL.
An interesting visit which seemed to indicate the potential of the KL.
The visit to MIT in the afternoon was less satisfactory. They have a KL and three KAs in the AI Laboratory and associated Departments. However, they all run using MIT's own operating system ITS which is completely different from all the other operating systems available on KLs and seems to run LISP and its derivative languages and virtually nothing else.
Joel Moses implied that the DEC operating system was useless and TENEX not much better. Their own operating system uses different paging algorithms which are built into the microcode. Thus they have modified the hardware. The reasons why the DEC operating system was so bad were not given even though I tried to press the point. Statements came out like paging algorithms are poor and communications bit rate is poor. I was unconvinced. My impression was that they had decided to use their own operating system when they purchased the KAs and have not reconsidered it.
Most of their software seems to depend on their operating system and is not transportable. However, MAC-LISP should be transportable. This would allow CONNIVER and similar MIT languages to be made available if we needed them.
They estimate that for their applications, even though they have 512K words of memory, the KA can not support more than 10 users and the KL not more than 20. Perhaps they should go back to the DEC operating system?
The KL is to be used solely for Symbol Manipulation while the KAs are used for Automating Programming and other AI research. They expected a hardware break rate of about 1 every 8 hours and felt this was acceptable.
They had had the KL about a year. It was 4 months before they had the operating system working and another 4 months before they could make it available on the ARPANET.
On the third day at DEC I visited Maynard to talk to the people responsible for their new CAD system being written for internal DEC use to replace CALDEC (DEC's name for the REDAC package). There is a need for a replacement as REDAC does not deal with all the applications required - in particular, schematics are not treated at all. They currently use a program developed at Stanford. However, the two systems do not have a common database and, frequently, instances occur of one database being updated without the other.
There are two main parts to IDEA. The first is a low level graphics package which drives virtual graphics devices called PGPs (Programmable Graphics Processors). These are simulated on actual devices which are either PFDP15s with VT15s or PDP11s with GT40s or the new fast display (VS60?). The outline of the graphics system was given at the EUROCOMP Interactive Graphics Conference last year. The other part of the system is the application side which will cover much more than the REDAC system eventually. Currently it caters for the REDAC system almost in its entirety and also allows Stop and Repeat of etch patterns, automatic gate/leg swap during placement and routing and improved routing layout. The main feature of the REDAC system not to be implemented is the altering of the logic during the optimisation process. They feel that this is bad practice.
Lou Abel spent a considerable amount of time going through the details of the system with me. I have complete documentation for the graphics part of the system and a preprint of a paper to be given at SIGGRAPH if anybody is interested. It is unlikely that the application side will be made available to users in the next two or three years. It is a commercially attractive piece of software which they need to exploit.
On the other hand, it may be possible to get a source version of the graphics part of the system which is comparable in its facilities to GPGS-F and certainly an improvement over GINO-F. Also, it would allow good communication between PDP11s and a PDP10 for graphical interaction. The main cost is a stripped down PDP11 to act as a DAS87 but with some special features. Unfortunately, we could not make use of one of our existing DAS87s.
The whole system is written in BLISS apart from a small part of assembler code. They have found it a very attractive language in a situation where flexibility of data structure definition is required and not very much floating point arithmetic. The database for boards designed by the system is extensive and resides on three different DEC10s using DECNET to access them (just being installed - previously used their own interim system).
The connection from the PDP15 to the DEC10 may be of interest irrespective of IDEA. They have modified a DA11 to produce a DA15 which is a fast parallel interface which, over short distances of 100 ft or less, can pass a word every 2 µsecs which is 1.5Mbytes/sec approximately.
the system was demonstrated to me and gave very fast response. they currently use light pens for all interaction but have been looking at tablets. They were warned off the SAC tablet very early on. Apparently TALOS make a good tablet and it is the one used by Tektronix. It may also be the basis of the Computek one but Abel was not sure.
Ian McKean will find out the company's policy on the low level graphics side of IDEA and let us know.
The last afternoon at Marlboro was spent in checking up on a number of matters that had arisen earlier.
I talked to John Shabell who is in charge of maintenance on the DEC10 KLs and also DEC20s. As the KL was the first machine to use ECL logic and also the first DEC machine to have more than one processor, it was decided that this should be taken account of in the method of maintenance. Also, they were involved from the start and so had some influence on the design.
The aim has been to localise functions so that intermittent faults or failures at a particular point must be attributable more easily to a single or set of modules. Due to the speed of the KL it is difficult to put a scope on it and also putting on Extender Boards warps the machine's characteristics. the aim has been, therefore, that the PDP11 should diagnose at least 95% of faults as being on a particular board or at least within 1 of 3. A comprehensive set of diagnostic programs have been produced and been tested by rigorously going through and grounding or floating every pin in the machine to check that the correct diagnostic is obtained. So far, in the field, there has only been one CPU fault which was not diagnosed correctly.
Normally diagnosis is done from the PDP11 teletype although it is possible to slow the machine right down so that it can be scoped if all else fails. The PDP11 teletype does not have to be local to the computer and, in the USA, diagnosis is done remotely. The diagnostician calls up the PDP11 and, when the fault is located, instructs the local engineer what board to fix and how! In the UK, the local on-site engineer is likely to be the diagnostician although DEC will insist on a line (not an Abingdon extension) being installed for this purpose. They would like an extension from this line in the engineer's office. This should be large enough for the office and spares (approximately 20ft by 12ft).
the diagnostic program on the PDP11 can usually detect errors before they appear on the DEC10 itself. The layout of the machine is basically:
Micro Instruction Processor
|
Arithmetic Logic Unit
|
Instruction Processor of DEC10
Thus, the DEC10's instruction processor generally only accesses the microcode in a particular way. A particular ordering of micro instructions may only be accessed by a single DEC10 order in a particular situation. However, the PDP11 is able to exercise the microcode itself. So that it can check out all combinations of microcode instructions and discover errors which are there but do not currently effect the DEC10 or only rarely effects it.
The SYSERROR reporting system certainly seems a great improvement over the 1906A. All re-reads are noted and they always refer to the physical device. Each device has its own internal device number unique to that physical device which can be interrogated by the system. Even if the PDP10 processor goes down, it is possible to get the information out in a rather poor format by the PDP11 processor. When the system restarts, the diagnostic information is read back in and then output in the correct format. Thus even on a catastrophic break, system status can be discovered.
With most of the devices, the controllers tend to be PDP8As so that considerable off-line checking can be done. For example, it is possible, while the system is running, to off-line two decks; load a tape on one deck which is used to read diagnostic programs into the controller; this can then be used to test the second deck with no intervention of the main PDP10 or PDP11 CPU. Copies of the Hardware Description and SYSERROR are being brought back by Ian; my case is full.
As there were no KI processors being refurbished, I had been getting rather worried about the delivery schedule and so had arranged a meeting with the person responsible. In fact, the situation is better than expected. There are two new KI processors which have only been used for diagnostic testing and are being replaced by a KL. These two will be shipped out as refurbished KI processors at the end of July. Currently, one of them has been allocated to Edinburgh assuming the order (not just the letter of intent) has been received by the end of June. Allowing time for passage and passing through customs, this could mean it would arrive in Edinburgh at the beginning of September.
Three KI processors arrived back in the factory just before I left. The management says these should be available in 60 days (mid-August) although the people on the floor say mid-September. I prefer to believe the second. There is, some benefit in getting a genuine order to DEC before the end of June. It probably gives us a bonus of the difference between the price of a new and refurbished KI whatever that is.
I checked back with Nancy Ohm whose run on the benchmark had run out of time before it was finished and so will have to wait until next week. She will telex the results to Ian McKean and will also let us know how they intend to cure the bulk output problem.
The POLYATOM program still failed with UNDERFLOW even after the code of the failing line had been changed so that it was identical to the non-optimised run. A new version of the compiler that we tried also stopped on DIVISION OVERFLOW! It is possible that there is a bug in the version of the compiler being used in the factory. The version numbers are:
FORTRAN 10 VERSION 4A EDIT 317 FOROTS EDIT 460
I agreed with Nancy Ohm that we would run POLYATOM on both compilers on the Oxford machine and would tell her the results (Nancy Ohm, Benchmark Group, MR1-1, M54, Marlboro). If we get the same failure, I said that we would localise it at this end. If both jobs run OK at Oxford, we would let her know the Version numbers. If possible, I would like her to concentrate on the interactive benchmark. She has a number of other commitments.
The fault may be due to the limited word length of the DEC machine. Have we tried it at REAL *4 on the 360/195? that would also be worth trying.
When contacting Nancy Ohm, use the full address on the telex. Otherwise it seems to take about five days to reach her through their internal post!
I think the visit has been helpful in getting a better impression of the various machines. On the whole, the number of KLs in house and around Boston is extensive and doing good work in an interactive mode. DEC impressed me by their general efficiency. The company has enlarged considerably since I was last at Maynard and it now has a genuine production line for the equipment.
On the CDC side, I found things much more difficult to quantify. Certainly CDC locally have not been giving us the complete picture of plans for NOS. Neither of the sites I visited enhanced my view of their systems.
The UNIVAC visit was surprisingly good and I think we need to do further work looking at their system. It can be made to run a large interactive load if the will to do it is there!
If some staff members come out to do further evaluation later on this year, a visit to Carnegie seems highly desirable and possible Stanford. I would like somebody to get a second view of the University of Maryland site. On the CDC side, it appears that we shall have to vet the offerings by CDC as they obviously have little idea what is being done with their equipment out in the field.