The expected high level of activity after the holiday period has not yet materialised. In particular the demand for IBM batch has been very low, averaging well under 150 hours per week with no Monday morning backlog. Interactive Facility usage has been steady with the usual emphasis on demand for Prime rather than GEC. The very small use made of the GEC machines is of major concern to SERC and will force another review of their future. The DEC 10 is as busy as ever despite the fact that it is closing towards the end of next year. Presumably this represents increased effort by users to finish projects before the service ends.
The move to release 19.1 of the Prime operating system is now complete and we now await an assessment of the impact of the new system on the performance of the machines. This has been a major effort over a short period of time and Phil Newton and Jeff Jarvis should be congratulated on a very efficient operation. The associated manuals are also available after an annoying delay for which I apologise.
By the time this reaches you the exchange of the IBM 3081D will have taken place. The initial system will have 16 Mbytes, with an 8 Mbyte upgrade due in November and the final 8 Mbytes scheduled for April 1984. Naturally we hope the changeover has virtually no impact on the users. The final outcome can only be of enormous benefit to IBM users.
There are reports of three User Group meetings in this issue of FORUM. I would like to bring to users' attention the importance of all the User Group meetings to SERC. The Chairman of each User Group sits on the RAL User Liaison Committee and provides an effective interface between the SERC Computer Coordinator and the whole user community. To date this has been a very successful structure because of the attitude of the respective Chairmen. However, a User Group can only function if users are prepared to give the necessary commitment to attend and participate in the meetings.
We have had very little response to the request for comments on FORUM despite a number of reminders. Please send comments or suggestions for articles to me at RAL.
An M860 Mass Storage System will be installed before next April . It will eventually provide additional storage space for the central processors. The M860 is a tape cartridge store. Data is stored on a short piece of wide magnetic tape which is housed in a cylindrical cartridge about I ins long and about 1.5 ins diameter. The cartridges are the same as those used in the IBM MSS, but the data is packed more closely so that each cartridge holds 175 Mbytes. An M860 consists of one or more units each of which contains a honeycomb of cells to hold the cartridges, two read/write stations (DRDs), and an accessor mechanism for automatically loading the cartridges into the DRDs. The average time to load a cartridge and locate a data set is of the order of ten seconds. The M860 we have bought consists of two units and has a total capacity of 110 Gbytes.
The configuration of the M860 means that it is impossible to load cartridges from one unit onto a DRD attached to another. This makes it unrealistic to allow user programs to access data in the M860 directly. User programs would tie up DRDs for comparatively long periods, which would cause a bottleneck for other people wanting to get at their data. The M860 will therefore be used by the system as a first level backup store for disk data. Data which has not been used recently will be migrated automatically to the M860, and will be brought back onto disk the next time it is accessed. This process will be completely transparent, so you should be able to treat the M860 as though it were an additional 110 Gbytes of on-line disk space. A widely used data management package, ASM2, will be used to perform this function.
At the moment software support exists only for MVS. The device will therefore be introduced as a part of the MVS conversion programme. It will never be available from MVT. The possibility of accessing it from CMS will be investigated after the MVS system is working. A certain amount of in-house development will be necessary before it is put into use. ASM2 must be installed and we must work out how to use it most effectively. Also it is planned to mechanise the accounting and control of disk space. We hope that this will make it easier for you to use the system. By mechanising the control, and by putting all the control data on-line, it will be possible to devolve the day-to-day management of space to user representatives. That means it should not be necessary to request space from Computing Division before creating a dataset.
The programme for installation of the M860 is that the acceptance tests will be carried out before Christmas and the device will be fully working with a complete set of cartridges early in 1984. Software development should be completed in time to allow thorough testing on the experimental MVS service before the final switch to MVS is made.
The capacity of the M860 should be sufficient to contain the majority of the small and medium sized datasets currently held on either disk or tape. In future it will be our policy to encourage you to keep this data on disk and not on conventional tape. It should be better for you to do so. With good data management, most datasets should be on disk when they are wanted. Even if they are not, it will be much quicker to retrieve them from the M860 than to have a tape mounted.
In 1980 it was decided that a new system for studentships should be constructed as the existing system based on batch COBOL programs and files on the 1906S computer at Sheffield University was not satisfying the user requirement. In the years 1977 to 1980 a new system for Grants had been built (to replace a system such as that for existing Studentships) by a team at RAL using teleprocessing and database techniques. This system runs on an ICL 2904 computer and uses the teleprocessing monitor TPS and the database manager.er.t system TOTAL. This team (with some changes in personnel) was asked to work jointly with staff of the new Electronic Data Processing Unit at Swindon to build the new Studentships system. This started in 1980 using techniques of user requirement analysis, data analysis and procedural analysis. By January 1982 the Operational Research for a required computer was complete, but was not released because SERC had other administrative computing requirements and an integrated approach had been advocated by the team.
In all the SERC establishments, but particularly at Daresbury Laboratory, there was a need for ar. up-to-date financial management system. A working party under Mr J. Visser (Director, Administration) asked a small team from DL to evaluate packages on the market and recommend. The choice was the financial suite of packages from MSA, and there was a requirement to find a computer system upon which to mount these packages as a pilot project.
A sub-committee of the Computing Coordination Panel (CCP) recommended use of the IBM 3032, as the vehicle for the pilot MSA financial package and for Studentships development, rather than purchase of new hardware, until the style of SERC administrative computing was sufficiently established to allow firm proposals to be made. This recommendation was accepted by the CCP and by Council and so the SERC Administrative Computing project was set up, to establish the RAL IBM 3032 as a vehicle for the development of administrative computer systems and for the provision of a pilot service for Studentships and the MSA facility.
SERC has made some policy decisions. The foremost is the use of IBM or IBM-compatible hardware for administrative computing. The second is to purchase software packages where possible. The effect of these two decisions is to put a requirement on the project team to provide the most popular software environment for administrative computing; namely MVS, CICS, DL/1 which provides a teleprocessing/database environment required by many packages. However, there are some interesting spin-off effects :-
There is one other aspect to the whole project, not intimately related to the use of the IBM 3032. At the same time as it was decided to purchase a financial package for use SERC-wide, it was decided to extend the use of the personnel system developed by RAL Administration Division and Computing Division and applied to RAL, to the whole Council. This system currently runs on a PRIME computer at RAL and uses the database system INFO. Staff of RAL Administration Division are currently investigating the possible personnel packages available to recommend a solution for use throughout SERC and integrated with the financial package.
The project presents challenges of organisation, coordination and technical skill. The project should provide us with a better understanding of the computing environment required for SERC administration, which has some similarities with and some differences from - normal commercial environments. The production systems which follow should ensure better information for administration and management.
In FORUM 32 (February 1983) users were given an outline of our plans for converting the central computing complex from MVT/HASP to MVS/JES3. In general, the work is keeping on schedule. This note brings our plans up-to-date and highlights some changes and points of interest.
We now have two MVS virtual machines which we can run under VM, one which Computer Services Group are using to familiarise themselves with new operational procedures and one onto which we are grafting the modifications to provide the extra facilities detailed in FORUM 32.
Along the way our investigations have provoked one change in strategy involving the MESSAGE facility. Because we feel that JES3 will be able to cope, by other means, with the situations necessitating messages from the user to the operator this facility will not be provided. The complementary facility for the operator to send messages to the user has been installed and Computer Services Group have built for themselves a system of retaining information they may generate about jobs (e.g. why they have had to HOLD a job). It will be possible for users to get messages into this latter system for the odd case which can not be coped with automatically.
As a result of the decision to purchase the M860 cartridge store we were able to finalise our strategies for data management and protection. We will be using a product called ACF/2 to provide data security and around this we are designing our resource management and allocation control systems.
Because of loss of man-power we have problems undertaking one of the large items on our original plan - providing an equivalent to the MVT MULTIJOB facility. As we understand, from further consultation with the users, that there is a considerable amount of dependence on this facility within the community we will make our best endeavours to provide it, but may not be able to undertake its availability at the time MVS goes into production - users will be kept informed of developments. JES3 has its own form of dependent job control which works in a very different way from MULTIJOB but which may satisfy some users' needs at least in the short term.
Work on TDMS is well under way - JES3 can now communicate with a version of the MVT TDMS data-base. The remaining effort in this area is to provide a better and more efficient data-base.
At present, because of additional software support required to cope with the many hardware changes and additions, systems group effort has had to be diverted from MVS work. As a result our plan to start an external trial MVS system has been put back one month and is scheduled to start in February 1984. Our target of July 1984 for a full MVS service still holds. In the meantime, anyone with any particular concerns about running work under MVS should contact USG now - please don't leave it until the last moment!
Job submission and output retrieval between RAL and the IBM-compatible processors at these sites is via RSCS-JES Networked Job Entry (NJE) Links.
The documentation for the use of these NJE links is stored in CMS on the 193 disk of user USDOC. For the CERN link see the file CERNLINK LISTING, for DESY see DESYNJE LISTING. Both files are in a form suitable for printing. Users of other machines can obtain the files either by using FTP or in hardcopy form from The Program Advisory Office.
We hope to make this a regular feature in FORUM, where one or two problems raised by users of each of the systems are printed, together with the replies, because in our view they are of general interest to all users of that system. It is hoped that this will be used to answer problems that keep cropping up in the support office and forestall problems which may arise following a change to the system. This month we only have queries from the central mainframes and the GEC. In future we hope to add Prime and PERQ queries.
How do we find out information on a particular subject/command? If we have a question/problem, what do we do?
If your problem is related to software on the IBM complex, then you should first try to use the HELP system. You are given brief instructions on this in 'HELP INFO MENU'. A fuller description of HELP is given in 'HELP INFO HELP' and 'HELP CMS HELP'. Remember that HELP is a limited facility and its knowledge is not encyclopaedic!
If this does not get you anywhere, and your manual(s) do not get you any further, then you should contact the Program Advisory Office. This should be done using one of three commands on CMS:
ASKUS - Used to ask a question of PAC, to which a reply will always be sent. If you are having difficulties using a command, or have a programming problem, or need some help in any way, then this is the command to use.
GRIPE - Often thought of as a synonym for ASKUS, which it isn't, this command should be used to report a bug in any aspect of the system to PAC. Again, a reply is always sent.
TELLUS - This command should be used to inform PAC of something, often in continuing a previous conversation. No reply will normally be given.
TELLTC - This command should be used to inform Telecomms of something, or to ask them about a telecommunications problem, a reply is sent, if appropriate.
How do we move our Electric Edit files into CMS for Reference purposes?
With the use of the CP SPOOL command and a little help from CMSELEC it is perfectly possible to move Edit files into CMS.
From the CME environment type:
SPool CONsole * STart
Call CMSELEC and continue normal login procedure.
TYPE to the terminal the relevant Edit file:
Type TEST.ED
Finally Quit from CMSELEC and:
SPool CONsole * CLOse STOP
At this point you should have a class T Console file on your virtual reader awaiting your pleasure!
Will we ever get a GEC Reference Manual to put in the binders delivered at the beginning of the year?
Reference manual Volume 2 is currently being reproduced and should be available for distribution by the end of October. It is designed to be updated so your long wait shouldn't happen again!
Reference manual Volume 1 is currently being planned and will not be available until mid 1984. This is a major task (more so than Volume 2). The time we take to produce the manual is (up to s point) inversely proportional to the amount of effort we have. At present we have one person..... We aim to do all the planning for the chapters, producing a skeleton of the contents, at which stage we hope to share these out to volunteers to complete.
GEC files which come onto disc from the HASP system have a block allocation that is very much larger than the actual number of blocks used. Is there any way of making the block allocation correct? We are having problems when we do a lot of work and use up our storage allocation with mainly empty files.
A garbage collection of the user's disc should shrink the files down to their actual size. The storage problem can be alleviated by first creating the GEC file before sending HASP output to it. The output will always be appended to an existing file, so unless the file is to grow indefinitely, it should be deleted and recreated each time before it is used. One possible reason for an almost empty file having a disproportionately large block allocation is if the file has been repeatedly emptied and rewritten. The problem is that once space has been allocated to a file, it is not released by emptying the file. The block allocation figure may thus represent a large number of blocks used in the past, but not currently required .
The meeting was once again poorly attended with only 7 users present. The discussion was dominated by the proposed AI/IKBS Infra-structure. In particular concern was expressed over the likely timescales for the provision of the appropriate software on the Infrastructure machines in relation to the planned closure date of the DEC 10.
The chairman agreed to bring this concern to the Engineering Board's attention once again. She will also ensure that the possibility of extending the life of the DEC 10 is discussed at the Management Meeting on 29 September. Such an extension, if agreed, would only be for the AI community currently using the DEC 10.
Arrangements for accommodating the non-AI community on other SERC facilities are well in hand. The specific need of the larger users in this category will also be discussed at the Management Meeting.
The next meeting of the DEC 10 User Group is on 16 November at ERCC.
The meeting was held at the Engineering Department, Warwick University. The chairman Professor Eastham was unable to attend and Gordon Dixon from Manchester Polytechnic took the chair.
All Prime sites were represented apart from Nottingham, Surrey and University College, London.
A few of the items to come out of the meeting that may have immediate interest to users are as follows:-
Changes in the maintenance arrangements of terminals and Prime hardware, which will improve the service and save money.
Prime support at RAL has been increased by two man years per year. The chairman emphasised the significant influence of the user group in this decision.
If sites are not used or managed effectively SERC will consider redeployment of such facilities. Existing users would continue to be supported on other facilities over the network.
GKS would be available around June 1981 and would initially be available in parallel with existing graphics packages.
The next system product available to users would be JTMP, which allows the transfer and manipulation of job processing. This would mean that a job could be set up on a Prime sent to a large computing facility (e.g. the CRAY at ULCC) and output routed to yet another facility (e.g. FR80 at RAL). All the time the job would be in progress a user would be able to obtain status information on the job and modify it if necessary.
All representatives agreed upon the need for a screen editor and that this should be EMACS. This will be taken up with the RAL Management.
PROLOG is being purchased for all Primes.
NAGF10, NAG library mark 10 will be mounted shortly.
Users wishing to raise any issues at future meetings are invited to contact their local representative or site manager. The next meeting is on 1 May 1981 at City University.
Although this was set up by the RAL User Liaison Committee, it is SERC-wide because there are so few VAXs under the aegis of Daresbury.
All the invited user representatives attended this first meeting in London.
Mike Jane outlined the Central Computing Committee support for VAX (VMS) systems. It was decided that Computing Division support was needed in the areas of Networking, Applications and User Interface, rather than VMS, which is a solid, reliable system.
It was agreed to set up a catalogue of available software, how to obtain it, the current version of software in use on each machine, and any recent problems (with solutions where available). All sites will provide information and Mike Waters (RAL, HEP) will manage the database.
A number of the sites represented have non-DEC supplied hardware attached to their machines. It was agreed that a catalogue of this hardware together with experiences including the maintenance would be established. Amongst the items suggested for the next meeting are a presentation by DEC on their future hardware and software plans for VAX (VMS) and a discussion on accounting and performance measurement facilities. The meeting will take place on 6 December.
The function of the Program Advisory Office is to provide advice and assistance to users of the mainframe complex at RAL. Most of these users are not based at RAL but are at universities and the two HEP centres in Europe (CERN and DESY).
Users contact the PAD by one of three methods:
The reduction in the PAO opening hours has most affected users wishing to visit the office. There is an Ansaphone service so that when the PAO is closed or the duty adviser busy, users can leave messages. Computer mail can be sent at any time provided the computer is running and the network is up and working. Mail is the method which we ask users to use whenever possible.
Files sent to User Support by computer mail are not simply left until the office is open. They are read in and checked for reports of possible serious problems. Many files need to be forwarded to specialists for their advice. Although replies are generally sent to users during PAO opening hours, the background work necessary in the preparation of the replies is not restricted to these hours.
I believe that with our present manpower this is the best way to provide the advisory service. There is no point spreading the available manpower too thinly. The reduced opening hours will stay in force but be reviewed regularly in the light of users' needs and our manpower.
Yet another reminder that ELECTRIC closes on 31 December 1983. The EXEC command was removed on 30 September as previously advertised.
Users have been extremely cooperative so far in sorting cut their ELECTRIC archive files and we have now been able to dispense with the second level archive altogether. It is equally important that we can get rid of the first level archive and have all the remaining ELECTRIC files online. This will require users to remove some 45000 blocks and we are seeking their further cooperation to do this as quickly as possible.
When the service closes the online ELECTRIC file store will be available from CMS and will be backed up to tape. We are beginning to look into the question of how long we will need to keep this. The initial view is that the file store should only be kept on line for one year. The tape backup can in principle be kept indefinitely although the real value of this is questionable.
Can I please seek the user view on this particular issue? Anyone who feels strongly enough about this subject should send a note to me at RAL giving his or her views.
I attended a three day seminar entitled "Ergonomics in Computer Systems" last month and would like to impart some of the more memorable gems of wisdom. Note, however, that in this idealistic view of the design of a computer system there is no shortage of effort or money, and the programmers do not have a myriad of other jobs to interrupt or tempt them.
Before designing a computer system of any sort, whether it is a new application program, an updated debugging aid or a method of storing and updating addresses, the first consideration should be to the user and the ultimate use of the system.
The users' technical ability must be the first (and is the most obvious) consideration. A less obvious, but rather intriguing, consideration is motivation. Providing a system that is really wanted (a brand new, easy to use, long awaited screen editor, for example) is obviously different from introducing a new system where a policy decision has deemed that the old system (which users liked and were familiar with) is withdrawn. The latter has to be perfect.
Another consideration is the ultimate use of the system; those used frequently each day should have a different interface from those used irregularly or infrequently.
A system should be designed so that training is NOT required. Training is expensive. Figures quoted at the seminar: 300 hrs preparation for 1 hour using Computer Based Training methods, and 200hrs for the more traditional teaching methods such as courses; this seems a bit high, but includes all secretarial work. Wherever possible, the system should stand alone without the need for extra information; where this is not possible, it should be provided in the following order of priority:
The interface should be given careful thought. A system which both novice and experienced users will be using should be designed to cater for both. Novice users are happier when the initiative comes from the computer (question and answer, and menu systems) but this will not suit experienced users, they prefer the initiative to be with the user (command mode).
Messages and the screen format of individual steps within the system should be consistent. This poses a question. On the one hand it is said that all commands on a system should have the same interface, but there is a strong lobby which says that some commands which involve communication with other systems, such as MAIL and file transfer, should have the same interface across a range of computers. Here there is obviously a case for two interfaces; the system which is consistent across a range of machines is more difficult to organise...
The provision of documentation was split into two: that REQUIRED for the use of the system, and that which describes the system, augmenting knowledge but which is not NEEDED.
Paper documentation is easier to read (25 per cent faster, probably due to the fact that terminal screens are at the wrong angle to be read easily -they are too upright) . It is not necessary to be at a terminal to read paper manuals, and it is possible to "personalise" them with comments.
However, a good on-line documentation system, which provides easy access using index and search features, is easier to keep up to date.
Many of these are out of our control, but are interesting, nevertheless. Format of messages should be useful and consistent. It should also be very clear when an error has occurred (in an on-line system, a serious error could be accompanied by a bleep, on colour systems "real" errors could be given in red).
Response times; users are happy for the system to take a long time if they know the machine is not dead. An acknowledgement should be given after 5 seconds, a status message every 10 seconds thereafter. Response times can also be too fast; a user can very quickly get dispirited if errors come back too quickly (especially if there are a large number of them).
Design of the keyboard is important. People have a good "location memory", this can be helped with sensible grouping (and spacing) of the keys, and particularly the Program Function (PF) keys. Keys should not be black, this colour causes problems with reflected light.
Design of the screen/keyboard - the screen should be positioned at an angle of 30 degrees from the vertical (with the top of the screen furthest from the user) . Keyboards should be positioned such that the elbow is at an angle of 90 degrees (ie the keyboard is very low) . We were shown a number of special terminal tables, which have a lower or adjustable area at the front for the keyboard.
Use icons (special images) where possible. This has already been done on the PERQ (the busy bee). Other suggestions included a face that smiles, and frowns when an error occurs, and even a system which used other senses: a "smell guide" - a nice smell of roses when things were going well - an obnoxious smell for an error!
The command format is very important; commands should be short and obvious and should avoid the need to type two special characters together. The use of double keying (case shifts and control characters) should be avoided.
Different Input/Output devices were considered. The relative merits of the joystick, mouse, touch panel, roller-ball, optical scanners, handwritten devices and voice as input devices were briefly discussed.
I hope that this has at least given all who design computer systems some food for thought; I am happy to pass on details of the seminar to those who want the whole story.
If you send letters to User Support at the Rutherford Appleton Laboratory, please ensure that these are correctly addressed. We get a number of letters addressed to simply 'User Support' and these frequently end up at the wrong place (the latest we received should have been sent to the Electron Beam Lithography group). These then have to be re-routed to the correct office.
We have five support offices within Computing Division: GEC User Support, Prime User Support, PAO (for IBM mainframe queries), PERQ (or Common Base) User Support and Network Support
.3 Nov GEC User Group Meeting at RAL
16-17 Nov Advanced CMS Course at RAL
21 - 22 Nov Prime New User Course at RAL
24 Nov Central Computer Reps. Meeting
For further information and enrolment, please contact either the Program Advisory Office on Abingdon (0235) 44 6111 or Garry Williams on Abingdon (0235) 21900 ext 6104.
