All systems have performed reliably during the last month with all user demands satisfied in terms of batch and interactive use. There have been some problems with access (caused by Memorex 1270 and PSE faults) which do not appear to have prevented users getting their work done. The Memorex problems have been cured but investigations are still continuing on the PSE.
This is the issue with the Graphics emphasis and there is a 12 page supplement from the Graphics Section. Major items of general interest include an overview of the FR80 replacement devices, GKS and Graphics on the Primes and GECs. The whole of this supplement was produced on the IBM 4250 which is one of the FR80 replacement devices.
There is an important article from Professor Hopgood announcing a major reorganisation of the Computing Division at RAL into two new Divisions. Unfortunately it is not possible to provide complete information on this until a few key issues are resolved. A full description of the new Divisions and their functions will appear next time.
The Computer Review Working Party Report has now been sent to Boards and to Council. The June meeting of Council included a preliminary discussion of the report and there will be a major discussion at the July meeting when the comments of the Boards will be available. It is anticipated that Council will make decisions on the Working Party recommendations in July. A full report of these recommendations and, hopefully, the Council decisions will appear next time. Meanwhile full discussions are being held in the various User Group Meetings and users are being invited to comment on the recommendations. A paper summarising the views of the RAL User Liaison Committee has been sent to the Working Party Chairman.
The last few years has seen a significant and steady increase in the size of the Computing Division despite moving specific Board-funded projects to other Divisions. Consequently discussions have taken place concerning the possibility of splitting the Division into two.
The Central Computing Committee's Computer Review Working Party has recommended that:
The last recommendation provides the opportunity to split the Division between those projects funded directly by the Engineering Board and the rest, keeping both Divisions of a significant size.
From 1 July 1984 it has been decided to reorganise the Computing Division as follows:-
Fuller details including the structure of the Divisions will be published in the next issue.
The Atlas 10 has been run in the front-end role on several occasions during the past few months for two specific reasons, firstly to investigate the MVT storage overwrite problem and secondly to determine whether it is a viable alternative to the 3081 in running the interactive CMS service.
These have occurred at a very low level for many years but increased dramatically to around 10 per week at about the time the new 3081 was installed last October. Unfortunately, a number of software changes had to be made within a very short time to support the new hardware. These were a new release of VM, the installation of VM/HPO (High Performance Option) needed to support more than 16 megabytes of memory and considerable changes in MVT to support 4K rather than 2K keys.
Since the problem appeared to be only in MVT, a lot of time and effort was spent on trying to find a bug in the 4K key software. When this produced no results and other factors, such as twice losing the VM spool, indicated that the problem might be elsewhere, a plan was devised for exonerating the various pieces of software one by one. This involved running the Atlas 10 as the front end because it could be run with or without VM/HPO and with either 4K or 2K key software in MVT.
Fortunately, the first test produced the desired result very quickly. The Atlas 10 was run with the 4K key software but without VM/HPO and the storage overwrites immediately disappeared, or at least dropped to their pre-September level. With a strong indication that VM/HPO was the guilty party the IBM faults database was scanned and a fix was discovered which it was thought might cure the problem although it was not very obvious why.
The fix was applied on 16 April and shortly afterwards the 3081 was reverted to the front end role. The storage overwrites have not come back and other problems such as HASP abends have dropped to a low, acceptable level also. Clearly the VM/HPO fix has solved the problems.
During the times that the Atlas 10 was run as the front end it was noticed (and monitoring data confirmed) that the CMS performance, particularly the response to trivial commands, was not as good as on the 3081. However, the 3081 had 32 megabytes of real memory whilst the Atlas 10 had only 16. Certainly the paging rate on the Atlas 10 was considerably higher and might well be a major factor in the difference.
Another factor was the maximum throughput on the channel to the paging device. On the 3081 this was 3Mb per sec but on the Atlas 10 it was limited to 1.5Mb per sec because of cross channel configuration restrictions. The recent acquisition of an additional channel processor for the Atlas 10 has removed these restrictions and allowed the full 3Mb per sec to be attained.
There still remained the difference in memory and in order to carry out a more realistic comparison we were fortunate in being loaned an extra 16Mb by ICL for one month. This was installed early in June and the Atlas 10 was put into the front end role on 18 June for a trial period.
The indication from monitor data for the first three days of this trial is that the response times for trivial commands are at least as good as on the 3081. However, to achieve this the Atlas 10 CPU appears to be working flat out and the VM overheads are very much higher, particularly as the number of users increases. This has an effect on the low priority high cpu virtual machines such as the MVS development system and CMS batch which are spending a much greater percentage of time in an involuntary wait state.
So, although a 32Mb Atlas 10 does provide a good alternative to the 3081 as far as interactive response is concerned, there is clearly a CPU overhead problem, which is being investigated further.
The second joint SERC/CB Regional Meeting was held on Thursday 28 June. It was attended by nearly 80 representatives from Universities, Polytechnics and various AFRC, NERC and other science based establishments in Wales and the South West.
The meeting was chaired by Dr Geoff Manning, (RAL Director and SERC Computing Coordinator) and included talks on the Common Base Programme, JANET, National and Regional computing, SERC computing and the Alvey Programme.
In his summing up of the meeting, Dr Manning included the following views of the audience.
It was generally felt that regional meetings are beneficial. The plan is to have something like a two-year cycle for these.
Text of a supplement to the July 1984 edition of the Forum newsletter
Nothing could be further from George Orwell's prediction for 1984 than the year as seen by Graphics Section. Whereas Orwell foretold of grey and dull uniformity, we have been involved in projects that signal a minor revolution for graphics on RAL (and SERC) computers.
Last December the CCC (SERC's Central Computing Committee) gave the go-ahead for the FR80 replacement project. As a result, an NCR 5330 microfiche system was purchased and a Xerox 8700 laser printer rented; we had already ordered an IBM 4250 electro-erosion printer.
In January this year all the software for the Xerox laser printer and the graphics software for the IBM electro-erosion printer were delivered.
March was busy: on the 1st the NCR was delivered; on the 2nd the Xerox arrived; on the 7th they both produced their first output. The IBM 4250 arrived on the 14th, followed by some paper for it on the 16th; on the 18th we printed 120 pages on it for distribution at the Graphics Day on the 19th; that was where we tried to explain to everyone what was going on.
Since then development of the software has taken place and in June an experimental service was made available on the Xerox. In July the same was done for the IBM 4250.
In the first article, you will find further details of the services that will be available on these devices.
Feverish activity was not confined to new hardware: most of Graphics Section was completing work on GKS. The project began in May 1982 when a collaborative project was set up with ICL to develop a transportable GKS system. In November 1982 the pilot system drew its first lines and text.
Throughout 1983 the team brought the system from being a pilot to being a proper system at GKS level 0a and then adding input and segment facilities so that it conformed to GKS level 1b. This was achieved in January 1984 despite changes of operating system (POS->PNX), Fortran compiler and even GKS specification (7.0->7.2).
During January and February the user manuals were written and the system was released for field trial by ICL during March. The final system was released by ICL as a program product in May. Julian Gallop, the project leader for distribution of GKS around the SERC, gives you all the news in the second article.
There have been changes resulting from Computing Division's reorganization into two divisions and from revised ICF support levels: Ruth Kidd brings you up-to-date in the third article.
This supplement provides an ideal opportunity for us to publish answers to recent questions: some of your favourites, including some that were raised during the Graphics Day, are in the fourth section.
Although Graphics Section has had rather fewer changes of name and staff than the rest of the (Central) Computing Division, we thought you might like to know Who's Who in the section; the next time we do this, let's hope we have a graphics scanner and can give you actual pictures of them.
Computer Graphics is, of course, for end-users and so we asked you to tell us how you are using graphics. Kate Crennell takes the opportunity with an article on Molecular Display Programs. Kate also has a request for more examples of FR80 output. Finally, Brian Bramer has some information about a Painting System for PLUTO Colour Graphics Display.
On the day this article is written, Graphics Section is in a new group of a division with a new name, providing access to new devices through new software. While one era may seem to have ended with the removal of the FR80, another starts with the advent of the new devices. The installation of GKS throughout SERC and University computer centres is a major step towards compatible software systems.
We have planned these new systems and devices so as to continue to serve the needs of the SERC computing community; for this reason, any revolution has been contained and much of the software development has been to provide software bridges so that most users do not need to do anything. For some it may be an appropriate time to review their own methods to see if the new facilities provide an opportunity for improvement.
Most of you will have heard by one means or another of the FR80 Replacement Project. The aim of the project is to replace all functions of the FR80 that are extensively used by using modern, online hardware. The resulting savings to the SERC are considerable - of the order of £120,000 per year.
All the hardware for the project is now installed:
The CCC (see front page) had originally requested that migration to the new devices should be complete by the end of March this year; granted that the equipment was delivered in March, this was never feasible. However, all devices were installed and produced output during that month. Development of the software to link the MVT FR80 spool to the Xerox 8700 and IBM 4250 has proceeded slower than was originally hoped but is now close to completion. An experimental service on the Xerox 8700 provided access (direct or via FTP and/or VNET) from CMS, MVT, MVS, VAX, Prime and GEC systems and was heavily used. This is now an initial production system.
A similar experimental service has been launched, for CMS users only, for the IBM 4250 and one is imminent for the NCR 5330. The plan is now to run a test user service on the replacement devices during August and a full user service on them during September and then switch off the FR80 on October 1st.
The hardcopy facility on the FR80 has been used for both graphical output and production of documentation originals. This latter task has also been accomplished on daisy-wheel printers. The Xerox 8700 laser printer and the IBM 4250 electro-erosion printer together provide a much simpler method of producing both text and graphics output.
Both devices are being attached to the system in such a way that current FR80 users and other users have equally simple access. For FR80 users, the MVT and VM DESPOOL systems are being modified so that hardcopy output will be sent automatically to the virtual machines that control the new devices. This will redirect SYSOUT streams specified as (G,,HCM and G,,HCS) under MVT and GRAPhics FR80 streams specified as HCS and HCM under CMS. It will also redirect all output from graphics packages on ICF computers.
Most of the work on the DESPOOL interface is now complete; we aim to install this at the beginning of August, have in-house testing during the rest of August and a parallel service during September.
In addition to providing FR80 emulation, new applications of the devices are possible. The Xerox 8700 is a fast system printer with extensive font and format capabilities. We have defined a large number of output formats for different applications. These are all described at present in the "User Guide to the Xerox 8700", available from RAL User Support and Marketing Group. This document also describes the ways in which the Xerox 8700 may be accessed directly via FTP from most types of computer on JANET and from MVT and MVS on the RAL computers.
The IBM 4250 is directly supported by DCF (Script) and GDDM (IBM's mainline graphics system). Direct interfaces from DCF and GDDM (and both together for mixed text and graphics) have been provided and are being documented in "Using DCF at RAL", available shortly from RAL Graphics Section.
The experimental services on the Xerox 8700 and IBM 4250 have provided some selected users with an opportunity to see what sort of output is possible. I: has also allowed us to sort out most of the operations problems in the service. Interestingly, a great deal of the usage of the Xerox 8700 has been from network users.
There were three main paths to the FR80 so far as microfiche as concerned:
The last path cannot be provided on the NCR 5330 microfiche system, since it is a text-only system. All tapes containing graphics will be sent by daily courier to the Stock Exchange COMp80 in London and the fiche will normally be returned the next day, excepting weekends. We have run tests on this machine and the results were excellent.
Fiche produced using the FLIST procedure (which currently produces graphics fiche, albeit the only graphics are characters) will continue to be supported. The FLIST program has been completely rewritten so that it supports all options that were relevant to microfiche output but it now drives the NCR 5330 instead of the FR80. This in turn provides support for CMS NFLIST, GEC RARESYS.FLIST, PRIME CPL > FICHE and VAX IBMFICHE. Users of these systems do not need to convert their jobs.
Production of fiche by SYSOUT = M will also continue to be supported. This in turn provides support for the COM option of CMS NPRINT. The MVT DESPOOL system will no longer be involved, so output will be processed as soon as the microfiche recorder is free.
The NCR 5330 has a fixed reduction ratio of 42 x. This provides a fiche with 14 rows of 16 columns: at least one row will always be a title line.
Before the CCC agreed to the FR80 replacement programme, it had already suggested that RAL look at the possibility of using the Dicomed film recorder at ULCC and this was being investigated. The Dicomed machine is broadly similar to the FR80; its addressability is 32k x 32k and its resolution and colour capability much the same as the FR80.
An FR80 emulator exists for the Dicomed which allows tapes that would otherwise be processed on the FR80 to be taken as input to the Dicomed. We are in the process of obtaining and testing this emulator -at present we believe it emulates the FR80 faithfully.
The existing mechanisms by which FR80 output is produced will be left working: MVT graphics packages + MVT DESPOOL, CMS graphics packages + VM DESPOOL, ICF graphics packages and programs that write their own tapes, on IBM or other machines.
The tapes produced in this way will be sent to ULCC and recorded on the Dicomed. ULCC have film processing laboratories close at hand and aim to process the film in about 24 hours. The processed film will be returned to RAL for distribution.
Several points should be noted about this service. The first is that, because ULCC have laboratories close at hand, they will have excellent turnaround on that part of the process. The second is that many users requiring film were only using RAL computers so that they had access to the FR80: we would regard it as natural if those that also had access to ULCC sought to move their applications there, since this would further reduce turnaround times.
The final point is that a survey of the usage of film over the last couple of years has shown that 8 users (or small projects) have accounted for all the film output that could not be handled on a much slower film recorder - of the order of minutes per frame rather than seconds. We hope that such a film recorder, which would be permanently loaded with 35mm colour film, may be purchased and located at RAL. This would provide a slide-making facility for which fast turnaround would be simple to achieve and whose quality would rival that of the FR80.
All the methods of accessing all three devices - both as FR80 emulators and as native mode devices - are being documented in a single report Use of RAL Specialized Output Devices. This will bring together all the material in the individual User Notes mentioned above; it will also repeat relevant parts of the information previously found in RL-78-086 Text Output Facilities on the FR80 Film Recorder. RL-78-085 GEROFF User's Guide, the RAL Prime User's Guide and a number of VAX/Starlink Local User Notes.
Graphics support from RAL has rested on a variety of basic graphics packages (GINO, FINGS, SMOG, etc), to a large extent doing the same task in different ways. This has been difficult for users wanting to move programs from one computer to another It is also difficult for users of only a single machine who may want (for example) the contouring routine provided with a particular package, but output to a device only available with some other package Clearly supporting multiple packages has stretched our own human resources.
By installing GKS on the various computer systems that RAL Graphics Section supports, we hope that we can achieve the following.
Figure 1 shows how both high-level graphics routines and device support can be unified through GKS. Our system design encourages better access to the capabilities of intelligent devices.
The draft of the GKS document currently in circulation (GKS 7.2) has existed since December 1982. Comments from ISO member nations have resulted in only minor changes which will lead to the publication of a new (and we hope final) GKS document later this year (GKS 7.4).
At RAL, we have implemented GKS 7.2 in collaboration with ICL. The implementation has taken place on Perq under PNX and VAX under VMS with source code being frequently exchanged between the two machines. At the time of writing (early July), it is ready for general release by ICL on the Perq and almost ready for release by SERC on Vax VMS.
The implementation is complete to GKS level 1b except that we have omitted segment highlighting and PICK input for the time being: this was done to avoid further delay to the release.
Installing GKS on the RAL supported computers is a significant task in itself. To provide a GKS-based graphics system that we can recommend to users in place of existing packages, we have to do three things.
Write GKS drivers for the devices we support. For each driver this will be about the same order of magnitude as writing one for GINO. We will provide drivers for the following devices, amongst others:
Other devices will be available indirectly, through graphics metafiles, such as:
Transfer GKS to the computer systems on which Graphics Section supports graphics. GKS is now available on Vax under VMS and PERQ under PNX. We will install GKS on Prime under Primos and IBM under CMS and MVS. We will not be installing GKS under MVT. We also expect to install GKS on the Unix systems run by Informatics Division (Vax, UX63 and UTS).
We cannot install GKS on GEC machines that predate the 4090, since they have no Fortran 77 compiler. Our plans for the GEC 409x and 41xx will be reviewed later this year once manpower (both graphics and systems) is known. We will also be studying the outline recommendations of the "Needs of Engineering Computing" working party set up by the Engineering Board.
GKS will be tailored to the environment in which it runs. For example it will work through spooling systems where that is the best method and also (for example) CMS graphics will be able to view graphics files created by MVS.
Re-implement high level graphics routines using GKS. Graph and contour routines (for example) are not part of GKS itself, just as they are not part of GINO, SMOG or FINGS. However for many people, the high-level routines are an essential part of the graphics software we provide.
We are investigating using the Nag graphics chapter on as many machine ranges as possible (Primes, GEC's and CMS have this already). Nag graphics has many facilities that do not exist in RAL's own high level graphics: it also has the advantage of being externally supported. We may well not re-implement some of our own high-level routines, where we believe Nag does it better.
We envisage that, on a given machine range, we will release GKS in at least 2 stages:
Preliminary Release There will be no high level graphics routines and very few devices will be supported: perhaps limited to Sigma 5000 series (not high resolution) and Tektronix 4010. Despite these limitations some users may well be sufficiently keen to use GKS that such a release would be adequate for the time being.
Full Release This release will include the well used high level graphics facilities that we currently support (at least graphs, contouring, curve-fitting) and it will support all the essential devices. When a full release is available, we can recommend that the majority of users change over their graphics calls to GKS.
After Perq and Vax, our priorities will be Prime and CMS. We want to achieve a preliminary release by September/October and a full release at the beginning of next year. Currently staff in post in the section is low compared with complement (about 70%). Therefore achieving these goals will be more likely if we succeed in approaching our complement and if there is good progress on FR80 replacement software, thus releasing people with IBM expertise.
The way in which our GKS system may be distributed is controlled by a contract between SERC, ICL and British Technology Group; it is also affected by our desire that GKS should be maintained wherever it is installed, not just put onto the system and left to decay.
Despite this, we will supply GKS to some machines that are financed directly by SERC grants. As at present, we will not be able to provide continuing support on such machines.
We are also supplying GKS to the Computer Board for them to install and support on the machines that they finance. This means that other computers in the universities will be using the same implementation of GKS. The Computer Board may, if they have the effort available, provide GKS to other UK academic institutions.
Our GKS system has been written so that different levels can be generated from the same base source; however, at present we only anticipate distributing and supporting level 1b.
There is obviously no lack of work involved in just getting GKS installed on all the machines for which we are responsible. However, a number of further developments are planned: most of these will, as long as effort permits, be done in parallel with the main installation program and with each other.
Since completion of all of these tasks is likely to take us into 1986, there will be further reviews of relative priorities as the installation project continues.
Category a. will be served by GKS and category b. will be served by 3-D high-level graphics that will use GKS. We believe that among our users category c. is small. For such people, the old packages will remain available but frozen. A standard which extends GKS to 3-D is being developed internationally and an implementation of that would answer the needs of category c. and will greatly simplify a. and b.
As with other areas, CCC has reduced the amount of effort for graphics on the PRIMEs and GECs, and this is reflected in the effort available. At the same time, there is more work on the GECs with the support of additional graphics libraries (ie. those for FORT3). Also, effort is being put into the provision of GKS on the PRIMEs. This has led to a rationalisation of graphics support, which will now be provided in the following manner.
These libraries will continue to be supported but with limited development. User support will continue but bug fixes may be delayed. (On the GECs, development, maintenance and user support of the FORT2 libraries has been frozen. Users experiencing problems will be referred to the FORT3 or FORTY libraries. This will inconvenience very few users as these libraries are only used at all at one or two sites.)
GINO-F Mark 2.7 will not be implemented. This is because CADC rewrote a large part of the internal code in GINO-F when providing the new facilities in 2.7. As so many changes have been made, there are potentially problems remaining in 2.7, and so 2.6 is a much more stable system and a better version on which to move to limited development.
With regard to new device drivers, site managers have been given information on writing drivers. However, the need for low-cost desk-top plotters is recognised, and a driver for one will be provided in the near future. This will be for the Calcomp models 81 and 84 which are already used by Computing Division and are low-cost.
On the GECs, FORTY and FORTS versions have been supplied and will be supported as for GINO-F. The purchase of the NAG Graphical Supplement for the PRIMEs is going ahead, and it will be supplied and supported as for GINO-F.
The Graphical Supplement provides routines for graph plotting, curve drawing, contour maps and surface views. In this implementation, the Graphical Supplement sits on top of GINO-F.
Development is already frozen. (No FORT3 version will be provided on the GECs.) Documentation will not be revised, but a supplement describing use of the Benson will be produced. Maintenance will be low priority. User support will continue.
There are very few users of this package. Development will be frozen. (On the GECs, no FORT3 version will be provided.) Mark 2 will not be investigated. Documentation will not be revised. Maintenance will be low priority. User support will continue.
It will be a high priority to bring all the graphics documentation up to date. On the GECs, the existing GEC Graphics User series will be updated and expanded. On the PRIMEs. the graphics documentation will be included in the Applications Manual. This is nearing completion.
This has been dealt with in depth by Julian Gallop in his article above.
Many scientists need to display molecules or chemical diagrams. At RAL this may be done both interactively and in batch mode. The well known program PLUTO78 has been enhanced and now runs on the IBM and the GEC computers. Contact Graham Crisp (GMC @ RLIB) for instructions on running a Do-it-yourself demonstration.
CPK82 running on the IBM can be used to make multi-coloured shaded plots either on a Sigma terminal or the FR80. Users wishing to Browse through their molecule can use R.Hubbard (York)'s BLOBS program on the GEC computers.
I have written a new program, TETRA, to design diagrams of materials conventionally shown as linked tetrahedra. This was used for the first time in the production of a computer animated film Silicates in Solution which has recently been incorporated into a video recording on the same subject. A sample frame from this is shown in figure 2. Copies of this may be obtained from the University of Aberdeen, audio-visual aids department.
Grey scale images of molecular models or electron microscope simulations can be displayed on Sigma terminals or on the FR80. Work is in progress to see how well these images can be plotted on the new devices.
I should like to thank all those who have already given me interesting examples of output for the FR80 Archive. The collection is a little biased at the moment; in order for it to truly represent all the sciences I need a few more examples. The plots do not have to be very complicated or use exotic graphical techniques. Your usual old plot may be just the one which I need. Plots showing many contours, computer aided design, or output from programs such as HBOOK. would be particularly welcome: please send them to Kate Crennell, Atlas Centre (KMC @ RLIB).
The PLUTO unit produced by IO Research is an add-on unit that can be attached to many computer systems to provide a cheap, high quality colour raster graphics system. The device has a resolution of 640 × 576 pixels with 8 or 256 colours selected from a palette.
The unit contains firmware for the generation of lines, circles, area fills, copy functions, etc. A painting system has been implemented in UCSD p-System Pascal that allows the user to paint or generate pictures, diagrams, flowcharts, etc.. using a tablet or a mouse as the input device.
The facilities include, amongst others:
The painting system is currently available on the Sinus 1 and Sage microcomputer systems running the UCSD p-System. Tablet drivers are available for the Summagraphics Bitpad 1, SummaMouse and the terminal keyboard. The system is available free for teaching or research purposes from:
Dr Brian Bramer