It seems we are becoming ever more like the daily newspaper. First we had pictures on page 3, now we are reporting births and deaths. This issue features two deaths and one birth.
The IBM operating system MVT was in use at RAL for many years. Its reliability and lack of frequent major changes did much to promote extensive use of the RAL Central Mainframes. The user population owes a great debt of gratitude to the experienced systems staff who incorporated many extremely useful features and continued to support the system long after IBM had pronounced it dead.
This issue also marks the closure of the ERCC DEC-10 service. This machine, too, represented a major SERC investment and provided sterling service over many years. It is nice to see that the machine is now doing a useful job elsewhere.
But time moves on and computing is an area which changes more rapidly than most. Emphasis is now on more power at the user's place of work and while setting the seal on the DEC-10 and MVT we mark the rise of the SERC SUN User Group and the UK SUN User Group. I feel sure that we have an increasing role to play in coordinating groups of this sort.
This issue contains details of the introduction of the Masstor cartridge store on the Central Mainframes. Hopefully this will enable us to cope with the ever rising tide of data. Perhaps 110 gigabytes seems a large amount of data to collect but I am sure you are more than equal to the challenge.
Consideration of the Forty Report on Future Facilities for Advanced Research Computing and the Needs of Engineering Computing grind on and we hope for good news next year.
Owing to staff shortages we have had to delay publication of the Network Supplement until a later issue. I hope this does not spoil your Christmas.
May I on behalf of the FORUM editorial staff and all the support staff at RAL wish you a peaceful Christmas and a happy New Year and hope that you will return to your work with your AUs replenished.
I would like to take this opportunity to send all readers my best wishes for Christmas and the New Year. Like most of its predecessors 1985 has been a busy year, with substantial changes for computer users and for the providers of the service. The introduction of the MVS operating system and associated facilities on the IBM mainframes has been a particular landmark, reached after a great deal of effort by our support staff and also by users in adapting to the new environment. May I thank the former for all the work they have put in and the latter for their tolerance and tenacity during the transitional period. We hope to reap the benefits of this investment during 1986.
Compliments of the season!
At the end of September 1985, we finally laid to rest a venerable servant of computing at the lab, namely the IBM MVT operating system, which had been running without interruption, if with some competition from VM, and latterly from MVS, since 1971.
When the 360/75 was installed in December 1966, it had at first run OS/PCP - Primary Control Program: a Uniprogramming system (and before we scoff at this, perhaps we ought to remember that vestiges of PCP still exist in the as environment of CMS!).
PCP was soon replaced in early 67, by MFT I Multiprogramming with a fixed number of Tasks. Each Task, or program ran in a fixed sized partition of core storage. The partition sizes had to be worked out by hand by the operator and typed in with a fiendishly long command, all of which was rejected if it was out by a few "K"! (And no pocket calculators to help in those days.) It had no disk spooling, but optional tape spooling, which by all accounts was pretty awful.
Various IBM teams around the world were competing, trying to write a better spooling system. At SHARE, Harry Hurst had met one Tom Simpson, who had developed a new system which seemed to be just the thing. He came over to give a demonstration - an affair which even now seems to be shrouded in some secrecy! This system turned out to be HASP - Houston Automatic Spooling Priority.
HASP Version I was actually installed in mid 1967.
In mid 1968 MFT II (release 15/16) came along. This had a somewhat improved spooling system, compared to MFT I, so HASP was dropped.
In late 1970, it was decided to buy the 360/195. This was only supported by MVT, so a migration path to MVT was initiated. Increasing remote use lead to a requirement for a spool package which would support RJE; HASP and ASP were evaluated and HASP selected. MFT R17 was installed in the third quarter of 1970 and re-installed with HASP II Release 2 in Dee 70. HASP II release 3 was installed in April 1971. In May 1971, MVT was first installed at Rutherford: release 19, which contained support for LCS (Large Core Store). R20, the first release to support the 195, was generated in July 1971, and taken to Poughkeepsie to test in early August, on an IBM 195 before Rutherford's was delivered. Release 20.1 with support for RPS devices became available 1 week before the trip and, remarkably, was generated and also taken! (George Adamson, and Roger Harrington of IBM were principally responsible for this.) Back home, Release 20.1 was installed later the same month, the 195 itself being delivered in October. By November 1971, the workload was switched over.
MVT stood for Multiprogramming with a Variable number of tasks. As well as a variable number of tasks, it also had the subtask concept, where programs could attach other programs as subtasks, which then competed with the main task, and all other programs, for the CPU. It also brought in the concept of variable sized REGIONS rather than the fixed partitions of MFT. (An early internal name for the system, which crept onto some of the microfiche, was Variable Memory System - VMS!) This was much more flexible for users and operators, but it did have the problem of core fragmentation, as regions were set up and broken down all over the place. For some Rutherford applications, it was essential that they should never wait for storage, so a sort of hybrid system was developed, known as FENCE, whereby one end of core was divided into fixed FENCES, or partitions, and the rest was true MVT dynamic storage.
Although HASP had many nice features. it also lent itself to modification very easily, and many new features were put in by customers. Rutherford HASP was heavily modified. Perhaps one of the most dramatic was Alan Mayhook's SETUP system. This was an answer to the large and growing number of tapes. Jobs which required tapes were put into mini-queues. separate from the main HASP job queue, and competed with each other for tape drives. Operators got advance warning of tape requirements, could have the tapes out by the drives when they were required. and jobs were not allowed to start until there tapes were mounted. Thus jobs never had to wait for their tapes once in execution. This was later enhanced by TOMS - Tape and Disk Management System which took the process a stage further, by maintaining a database of all the tapes in the system, with last use dates etc. which has survived into MVS. (Alan, Steve Tunstall. Charles Wilkins).
Another major area of HASP activity was in COPPER - Control of Peripherals with Policing Enquiry & Reporting - written by Margaret Curtis. This was the means by which jobs were only allowed to enter the system at certain priority levels, which the users had to pay for from their ration accounts. Unused rations were credited at the end of the job. COPPER ran as a semi-independent subtask of HASP, but with several points of intersection with the main task, SETUP, and also MAST, to provide an online ration enquiry/job status system.
One cannot talk about MVT without bringing in MAST. Originally written by Bob Taylor, et al, as MAST, it became MOST for a while, was re-written by Margaret Curtis, Alan Mayhook and Peter Hemmings and became MAST again. It was designed for 1 satellite computer (the DDP224 - supported by Sylvia Norris - and the HPD); it was extended to "n" satellites and 2741 type terminals. Peter Girard then put modified HASP to allow workstation users access to the online system. In the meanwhile, John Burren's group were writing ELECTRIC, also a MAST "customer". So although MAST was originally a data-switching system with a few messages, it evolved into a message switching system, with finally (after the demise of the satellites) no data!
An interesting development in MVT occurred when it was decided to buy the second 195. By this time, official support for MVT by IBM was drawing to a close. Undaunted by this, Rutherford C and A Division decided to "do their own thing" and write a system to couple the 195s together. They were somewhat encouraged and helped by the University of Gothenburg, Sweden (SEAS contacts) who had done a very similar thing, albeit with different CPUs and with MFT not MVT. The main areas of modification were ENQ/DEQ and getting the HASPs on either side to talk to each other. IBM provided help by giving time under VM at a customer test centre, where it was possible to have two or more operating systems running at the same time and to test the interconnections via "virtual" CTCAs (Channel to Channel Adapters). As well as George, Alan and Margaret, Chris Osland and I participated in that exercise.
When, a few years later, it was decided to buy a 3032 and couple that in, as well as the 195s, it was relatively simple to extend the coupled system to a multiple system. This time, however, the 3032 ran VM as its primary operating system and MVT as a "guest" operating system. (We had become rather fond of VM the first time round!).
The basic pattern of a Front-End Machine, with two back-end machines (BEM and CEM), survived across the transition from 195s + 3032 to 3081 + 3032, then to 3081 + Atlas 10.
After the final release of MVT - 21.8F (mid 1977) there were a couple of other IBM features installed: the 3350 PRPQ, to support the new disks (late 1977), and also the 3032 PRPQ, to support the new CPU (1979). The most recent piece of IBM code in MVT (1984) was support for 4K protect keys, provided on a "one-off' basis, because of an upgrade to the 3081! Interestingly, the 3350 PRPQ depended on some 370 type instructions, and a 370 instruction simulator package was installed. (1 think this came from another customer, via SHARE). So for the last few years of their lives, the 195s under MVT were actually capable of "running" 370 instructions, even though they were 360 architecture machines.
Another interesting fact is that the net result of the coupled HASP system at Rutherford looked rather more like JES3 than JES2, although JES2 was the natural successor to HASP in IBM terms.
There is much more that could be written about the early days, but time and space press. I apologise if I have missed out any important names or facts. I would like to thank and acknowledge the following for filling the gaps in my memory: Harry Hurst, George Adamson, Margaret Curtis, Chris Osland, Ann Cox, Adrian Webber, Keith Benn and Sylvia Norris.
If MVT wasn't always user friendly, it certainly won some friends among systems programmers, operators and, I hope, among some users, over the years!
MVT was finally laid to rest at the end of September after a long and successful life.
Meanwhile. MVS marches on and a recent addition was the migration of datasets to the M860 mass storage device. This works on the basis of datasets being migrated if they have not been accessed for a certain period. Initially this period has been set to be fairly long but will be reduced gradually to around 20 days. Don't forget that access from CMS does not count and will not prevent a dataset from being migrated. Apart from this it should be transparent since datasets are restored automatically within a few seconds when referenced by the JCL in an MVS job.
The hypervisor has been removed from the Atlas 10 and the code to replace it installed in CP. First indications are that about 30% more work is being processed as a result. An initial attempt to adjust the CPU charge factor so that on average a job would use the same CPU time was incorrect and a further adjustment has been made since.
The control mechanism which required you to change your password at least once if you had not done so since April 10 was switched on. If you had not made the change by November 5 you will have been locked out of the system and will have to ask User Support for a new password.
This second general meeting, held at Cosener's House, Abingdon on 9 October, was attended by 38 people made up of an independent Chairman Mr G Dixon, 11 members of the ICF team from either RAL or UMIST, 13 site managers or their representatives, and 13 users. When taken into consideration that, on the day before, the ICF team and the managers had had their own meeting, the attendance at this meeting, primarily for users, must be considered disappointing. Main points from the meeting were :-
A user group has been established for users of SUN computers purchased by SERC. The initial convenor is Jane Hesketh of Edinburgh University and its first meeting was held on Friday 30 September 1985 in Edinburgh attended by 23 people.
A wide range of subjects was discussed. Issues of current interest were hardware maintenance, the distribution of software and levels of support to be offered by RAL. Preliminary details of the role to be played by the Common Base Support Office when it expands its scope in the near future (on the completion of some building alterations and office moves) to include SUNs, were presented. Peter Kent of RAL gave a short presentation on the SUN3 workstation and some experiences of using it were reported.
Minutes of the meeting will be circulated to SERC Sun holders and further information can be obtained from the convenor or the secretary (Lynton Jones-Ng at RAL).
The activity of the SERC SUN User Group is seen as complementary to the SUN UK User Group which met on the following day. About 50 people attended and the theme of the meeting was Communications. There were talks given on networking in inter network environments, and in an integrated multi-vendor system. There were also some technical presentations on products and plans. The day ended with a short period of open discussion (which will be allowed more time in future meetings). Each of the two groups has been recently formed and both judged their meetings as successful. The intentions are to meet at six monthly intervals and to continue scheduling them on adjacent days. It is hoped to stage the next meetings at UCL in March 1986.
The official title of SGML is ISO/DIS 8879 "Information Processing Systems - Text and Office Systems - Standard Generalised Markup Language (SGML)" - a mouthful of words to describe a practical solution to one of our text processing problems.
Many of us write reports and prepare documentation of one sort or another, and we are increasingly turning to computers to assist us in this work. Ideally, text should be prepared locally, using our friendly word processor or minicomputer, with local printing for proof-reading. When the text is complete, it ought to be possible to send it through the network for better quality printing from the central mainframe. Unfortunately, this is not possible at the moment because the input format used by text layout programs on the minis, e.g. RUNOFF on the PRIME, is not that used by the IBM layout program, formerly SCRIPT, now DCF (Document Composition Facility).
SGML is an attempt to solve the problem by defining a standard document description. The description will be interpreted by each manufacturer's layout program with output to whatever printers they support. So we should then be able to move our documents easily for printing on whichever printer we choose, even if it is miles away across the JANET network.
Another advantage is that because the document is described in a structured way, it can be converted to retrieval programs such as STAIRS, and a database created easily. Our current version of DCF has this option now for use with texts created using the GML subset of SCRIPT commands.
The SGML standard has been drafted by an international group of information scientists, authors and publishers. During the next 6 months you have a chance to improve it by sending your comments to the British Standards Institution, who will supply copies of the draft to members of the public. Work is also in progress to describe technical text and mathematics in a general way. Further information on SGML can be obtained from the president of the SGML User Group, Joan M Smith, Senior Consultant, National Computer Centre, Manchester.
Although there are as yet few implementations of SGML, several large organisations are actively planning their future documentation around it, and I recommend all users to seriously consider it themselves.
British Aerospace maintain technical documentation, including engineering drawings, for all their aircraft. Their problems are complicated by several different aircraft types, and having to send manuals to over 40 different countries, not all of whom read English. The latest product, the Tornado, has over 15,000 pages in the complete set of manuals.
SGML is also an essential tool for the Office for Official Publications of the European Communities. In 1983 they were responsible for 35,000 pages in each of the 7 official languages. They have recently published a 240 page book describing their methods, FORMEX, formalised exchange of electronic publications obtainable from them in Luxembourg.
After nearly nine years service to SERC Grant Holders as ICFs most powerful machine, the DEC-10 computer at ERCC was closed down on 30 September 1985 at a brief ceremony attended by ERCC and RAL representatives.
However, this was not the end to the life of this machine. since it has been moved to Essex University where it is now installed beside their existing DEC-10 computer.
It is hoped to publish a detailed history of the life of ICFs ERCC DEC-10 in the next issue of FORUM.
