A number of people have contacted the RAL Computing Division under the misapprehension that there is a pool of unallocated PERQs to be bid for. All the PERQs delivered to RAL are earmarked for specific Boards and projects. Bulk purchases have been made by three Engineering Board projects, Engineering Board Computing Committee, Distributed Computing Systems Specially Promoted Programme (SPP) and the Software Technology SPP. All the systems purchased by the the first two projects have been allocated.
If a PERQ is required for a research grant it should be specified on the grant application in the normal way. The PERQ development team at RAL will be happy to give any help they can.
The Computing Division has two systems which can be loaned for short periods. Both are currently allocated and will not become available until the summer.
F R A Hopgood - Division Head
2. QUESTIONS RAISED AT CCR MEETING (17/3/82)
Q2. Should users worry about loss of batch hours if the 195s are replaced?
A2. We have estimated that once both 360/1 95s have gone, there would be a net loss of about 1500 batch hours per year. However, because of the overlap period of the second 195, this really only becomes a critical issue in Financial Year 1983-4. We are hoping that the replacement plan can continue by then with the addition of further hardware. See Article 7 on page 4. (C J Pavelin)
Q3. Please comment on the performance of the 3081 as an interactive system.
A3. At the relatively small scale of our CMS system (relative that is to a 10 MIP machine), there should be no problem. One of our benchmarks simulated 100 CMS users, the networking and a large batch workload without any degradation of CMS response. (C J Pavelin)
Q4. Are you satisfied with the reported reliability of the 3081?
A4. We have no worries. Such problems as there have been in the field seem to have arisen at sites which installed 3081 s very early. (C J Pavelin)
Q8. Does SYMBUG support FORTRAN 77?
A8. The current version of CA-SYMBUG/F cannot be used with the VS FORTRAN compiler. However, Computer Associates estimate that the support of this compiler should be available in 2 or 3 months time. The current version can be used with both the H-Extended compiler and the G1 compiler. (T G Pett)
Q9. What plans are there to end ELECTRIC?
A9. A plan for the run-down of ELECTRIC is being prepared. This contains a proposal that the lifetime of ELECTRIC should not be longer than that of MVT batch. This puts a possible closure date as some time in 1984. However, no firm date has been set yet. (T G Pett)
Q10. What facilities will be provided to preserve archived ELECTRIC graphics files?
A10. Archived ELECTRIC graphics files will not be preserved after closure of ELECTRIC. They should be restored and hardcopy or FR80 copy taken. Alternatively the files can be re-created under CMS. (T G Pett)
Q11. There are practical difficulties for users if there is to be a total ban on ELECTRIC registration.
A11. Current situation - there is no bar on ELECTRIC registration. Since each Board receives an allocation for ELECTRIC it can decide for itself who should be registered. Future situation when ELECTRIC is on a route to a termination date - no policy has been agreed as yet. The policy which will be made will certainly be flexible and hence a total ban on registration would never be imposed. (M R Jane)
Q12. How much system dependence is there on graphics software implemented on GEC machines?
A12. The main section of RAL GKS implementation will be in Fortran 77 and will be machine - and -operating system - independent. This will include the whole of the kernel and the majority of device handling code. On each system interfaces will be written as necessary to the operating system as supported by SERC. (C D Osland)
Q13. What is the future of FR80?
A13. We are actively investigating all forms of output from the central system (lineprinter, hardcopy, fiche, film, typewriter) and modern methods of satisfying the needs of users, including future network requirements. A review of the FRSO's role is included. Currently replacement of all functions of the FR80 is expected to take about 3 years. It is however likely that access to any replacement facilities would be very similar (or identical) to access to the FR80. (C D Osland)
Q14. Has Computing Division considered obtaining the Siemens Fortran 77 Compiler which CERN claims is better than the IBM product? This would make the two laboratories compatible.
A14. We see a requirement to have a compiler which will correctly compile programs which conform to the Fortran 77 and provide efficient object code. We share the opinion of several laboratories that version 1.0 of the VS Fortran compiler failed on both counts. We have carried out many tests with version 1.1.0 of the compiler and so far we see no reason why it and its successors should prove unacceptable. The Siemens compiler is not currently supported under CMS nor is there any support office in the UK. We see that compatibility should lie in conforming to the Fortran standard. (P J Hemmings)
Q15. Is there local support for CERN Library?
A15. Yes. Please get in touch with PAD if you have any problems. They will be able to deal with straightforward queries but CERN will be contacted on your behalf if the problem proves difficult. (C P Wood)
Q16. Are ELECTRIC files written with the TAPE command compatible with CMS?
A16. ELECTRIC files written with the TAPE command can be read into CMS files. However, since users do not have access to tapes from CMS they would have to be copied to disk first and then copied into CMS. ELECTRIC edit files would need to be restored into the ELECTRIC filestore as only ELECTRIC understands them. (T G Pett)
Q17. What is the general policy on CMS archive?
A17. The policy is to provide an archive system which initially will allow CMS files to be archived to tape. We are looking at archive systems written by other installations and will probably adapt one of these to our needs. (T G Pett)
Q18. Will JOBFILE utilities be copied to CMS?
A18. Yes. Work is in progress. The commands will be based on XPLANT and redesigned for CMS and possibly slanted towards MVS. (P J Hemmings)
Q19. Will there be ICF PRIME and GEC implementations of GKS?
A19. Yes. (C D Osland) See Article 3.
Q20. What are the plans for' routing output to workstations under VNET?
A20. The existing route cards and the recently introduced names are acceptable. (P J Hemmings)
Q21. Should allocation changes involving ELECTRIC and CMS AUs be first dealt with by category representatives?
A21. Yes. It is essential that Resource Management is aware of the trade in order to adjust the contracted levels of CMS and ELECTRIC delivery. (M R Jane)
Q22. Why was it a problem running P1 jobs?
A22. Traditionally P1 has been allocated at a rate of 10 hrs/account/week. If the machine is lightly loaded as it has been during this present Financial Year (1981/82), there is a high probability that the P1 queue is cleared over a weekend. A consequence of this is that users can greatly exceed their total allocations. In the case of a small community on the RAL IBM system (eg Nuclear Structure) this could mean they grossly exceed the allocation for their Board. This indeed happened this year and caused a lot of problems for Nuclear Physics Board. (M R Jane)
Q23. Can the CERN Back to Back link be improved?
A23. No. We had an agreed program with HEP Division (James Hutton) to bring the system up to an acceptable level. Daresbury provided the effort to achieve this but it was agreed by HEP Division that we would make no further calls on Daresbury to provide programming effort for this system. The long term solution to this will be to implement an IBM to IBM link such as the connection between CERN and SACLAY. Computing Division is at present investigating such a link between RAL and DESY. Once this is completed attention will be paid to the CERN link. (M R Jane)
Q24. What is the future of private 3330 disks? What should users do about data sets on private disks?
A24. In deciding how best to use the spindles vacated by moving the public disks we have sought to identify which disks are used so frequently and extensively that they should become permanently mounted and to identify those disks which although used frequently contain a few small busy datasets. In the latter case we relocate them. In general, the private disks have contained a mixture of active data and effectively archived data. We have not been provided with such an amount of disk space that we can blindly mount everything. Therefore we require users to delete old data after copying to tape what they wish to retain. This applies equally to disks that are permanently mounted and those that are not. (P J Hemmings)
Q25. Can the end of Prime Shift on Fridays be defined as 1600 for the purpose of logging into ELECTRIC and CMS to allow production jobs to be submitted?
A25. We have changed the ELECTRIC and CMS systems to allow users to login after 16OO hrs on a Friday if their allocations are exhausted. The charging factor will remain unchanged. (M R Jane)
Q26. Does CMSELEC command require both CMS and ELECTRIC AUs?
A26. No. (MR Jane)
Q29. Changes UNIT = DISK30 to DASD did not work on a SETUP card. What should one do?
A29. Just give the volume name. You need only give device information on the SETUP card if you are not sure whether it is correct in TDMS. In the latter case the TDMS entry should be modified as soon as possible. (There is some doubt that tapes which date from before 1979 may not be recorded correctly). (P J Hemmings)
Q31. In place of SMSG VNET ... why not just a transfer command?
A31. An EXEC has been provided which will afford a more friendly interface between CMS users and VNET in the case of issuing commands to VNET from CMS. (J C Murray)
3. FUTURE GRAPHICS DEVELOPMENTS
During 1981, Graphics Section were extensively involved in the development of an international standard for computer graphics, GKS. While GKS is a specification of a graphics system, not a package, implementations of various stages of GKS development have been written and one of these is currently In use on Starlink VAX systems (GKS 6.2). The current document describing GKS (GKS 7.0) is likely to become the agreed standard after minor corrections.
Users and system planners obviously need to know how RAL will be involved with GKS. Graphics Section will be working to provide a fully engineered, Fortran-callable implementation of GKS 7.0 on Starlink VAX (under VMS) and PERQ (under Unix) by Christmas 1982, and on IBM systems by Easter 1983. The implementation on the IBM systems will be under MVT or MVS and VM/CMS.
We consider that a proper implementation of GKS requires three parts:
A common section that implements GKS as a user-callable routine package, engineered to the word length, operating system and scale of the target computer and operating system.
A set of device handlers for each device commonly used on that system.
A set of high level routines that call GKS and provide the user with graph-drawing, curve fitting and similar facilities.
All the high level routines described in the graphics manual (with the possible exception of the Archuleta package, chapter D6) either have been or will be made available above GKS. Many device handlers have already been written for GKS 6.2 and will be adapted to GKS 7.0.
The relationship between GKS and other graphics systems at RAL is simple: GKS will neither call nor be called by any other basic graphics system that RAL support (SMOG, GINO-F, MUGWUMP, FINGS). Users will continue to have the option of using the package of their choice. The recommendation will be to use GKS unless another supported package is more suitable. Support for SMOG will continue. It may be the only system that exploits various idiosyncratic features of some graphics devices, notably the FR80. Support of new releases of GINO-F will continue as at present.
The high level routines, which currently use SMOG as a basic graphics system, will be available above both SMOG and GKS with their current calling sequences. Users should note that because GKS contains an extensive range of inquiry facilities, the GKS versions of the high level routines may, in time, produce much better output than their SMOG equivalents. Only the GKS versions will receive development effort.
It is our intention to provide implementations of GKS on all appropriate computer systems supported by RAL. The work involved in producing the VAX, PERQ and IBM implementations will reduce the time required to implement GKS on GEC and Prime systems. However, a wide range of graphics terminals is supported by the GEC and Prime systems already and so more work is involved in producing a complete set of device handlers. Work specific to the GEC and Prime systems is likely to start at the beginning of 1983.
If users have any special queries about their plans and GKS they should contact C D Osland, ext 6565 and discuss their requirements. During 1982 aeminara will be arranged to tell users about GKS and the RAL graphics software system.
4. RAL COMPUTER USER LIAISON COMMITTEE TERMS OF REFERENCE
The remit of the RAL Computer User Liaison Committee is to consider matters concerned with the efficient operation of the RAL managed computer installations (as measured by the quality of the service provided) and to offer advice (agreed by a consensus of users) to the RAL management, to the Computing Co-Ordinator and to the Central Computing Committee.
The Committee will also act as an important channel for information on policy to be passed to the users and for the users to comment upon the implications of that policy.
The membership of the Committee will be determined by the RAL management after consultation with the Chairman and will be chosen to represent all users of the RAL computer systems. Since the size of this community is very large the RAL management will set up a suitable sub-committee structure to interface to the users. It is important that neither the composition nor venue of these committees should diminish the ability of remote groups to express their views.
The Committee will meet about three times per year and will provide a report on the users views of the service provided once per year. This document will be an important input for forward planning on policy and computer provision and should be prepared for the five year forward look exercise.
RAL Computer User Liaison Committee Membership and Representation
Prof D C Colley Chairman of ULC and member of Central Computing Committee
Dr G Thompson (proposed) Chairman of IBM user
representative meeting and Particle Physics Committee representative
Dr J C Baldwin Chairman of GEC Users Group Dr J F Eastham Chairman of Prime Users Group
Dr A D Milne Chairman of ERCC Users Group and EB Computing Cttee representative
Dr T D Benyon Laser Facility Cttee representative
Dr R Richardson Neutron Beam Cttee representative to be nominated
Science Board Computing Cttee rep to be nominated
Starlink Advisory Cttee (+ Vax)
Dr R Maybury Chairman RAL site users group
Dr B Davies Daresbury Laboratory
Prof Hopgood/Dr C Pavelin RAL Computing Division
Mr D House RAL Computing Division
Dr G Manning Director RAL
Mr R E Thomas RAL Comp Division - Secretary
6. DIARY
8 July 1982 - Central Computer Representatives in RAL Lecture Theatre
IBM PREVENTATIVE MAINTENANCE DATES
Routine Preventative Maintenance will take place on the following days from 1800 - 2200 hours.
Login messages on the ELECTRIC and CMS services will be issued prior to each maintenance session as a
reminder.
22 Jul
19 Aug
16 Sept
21 Oct
18 Nov
16 Dec
7. GOOD NEWS
On 9 May 1982 the Council approved the purchase of the IBM 3081 and coupled with that the purchase of an ICL Atlas 10 (Fujitsu M380), subject to a number of issues being satisfactorily settled.
The installation of the IBM 3081 will begin on 5 July and the first week will be taken up with physical installation (20 hours), acceptance tests and operator training. On Saturday 10 July all the IBM systems will be taken out of service to enable the engineers to disconnect the IBM 360/195/2 and cable in the 3081. The service will then be resumed on the IBM 3032 and 195/1. During the week beginning 12 July the Systems Programmers will carry out the final testing on the software to enable the 3081 to be run as a back end machine (ie replace 195/2). This configuration will be used for approximately one month while verifying the software to enable the 3081 to become the front end machine. Then for two months the system will be the 3081 driving the 3032 and 195/1. After that period 195/1 will be taken out of service.
By this time the users will have two 4M Byte MVT systems in the 3081 and a 6M Byte MVT system in the 3032.
If all outstanding issues are solved then the ICL Atlas 10 will be installed May/June 1983. It is stated to be a 15 MIP
machine (3×195) uniprocessor. It will be benchmarked in Japan in June 1982.
