Welcome to what looks like an interesting and lively edition of FORUM. By the time this edition reaches you, we are likely to have made considerable progress on the mainframe replacement detailed on this page.
I was very pleased to see three letters from users in this issue. I sympathise with the two users who feel unable to attend users meetings. We are looking at ways of improving our liaison with users. One way is for you to keep sending in your comments to FORUM. The article on SLAC Batch is partly a result of the letter from Laurence Jones.
Note the hint in that article that we are reviewing our charging algorithms. We hope to come up with something which is simple and consistent. More on this next time.
First we had round computers - the CRAY - now we have square tapes. Whatever next? See John Gordon's article on 3480 cartridge tapes which we expect to become the main medium for data interchange.
For many years the use of magnetic tapes on mainframe computers has meant half-inch tape recorded with nine tracks at up to 6250 bytes/inch on reels of up to 2400 feet of tape. Over the last couple of years a new format has become available which looks set to replace these as an industry standard. The new tape looks the same (half inch) but the recording technique has changed to allow more data on less tape in a smaller package. These new tapes (known in IBM jargon as 3480 cartridges), contain about 600 feet of tape in a roughly square cartridge (123 x 108 x 24mm) holding up to 200 Megabytes. As reel tapes contained 2400 feet of tape on a 265mm diameter reel 2lmm thick holding up to 175 Megabytes it is easily seen that square tapes (or cartridges) give more Megabytes/cc than round (or standard) ones. As they also cost less per tape the advantages for cost, storage space and transport are obvious.
Just as the recording and track densities of old tapes increased over the years, it is expected (indeed announced) that they will both increase for cartridges too. Four-fold increases to almost 1 Gigabyte per cartridge are expected over the next few years so any project expecting to collect large amounts of data should consider using cartridges.
At RAL the IBM has two IBM 3480 drives attached to the CMS Batch service. Another two will be purchased soon and some of these may be attached to the MVS or Cray Services if there is demand.
Several firms also manufacture automatic cartridge loading systems which hold a large number of cartridges and mount them into the drives using some robotic device. RAL is looking at these devices as a means of handling the large numbers of cartridges that will be generated by the experiments on the LEP collider at CERN.
Although cartridges are so far only available on IBM and IBM-compatible computers, they look set to become an industry standard and will probably be supported by all manufacturers eventually. Even now there are sufficient of them around to make them a useful means of transferring data between sites: their small size making them much easier to post or carry.
If you have any queries about the usefulness of cartridges to your project or about RAL's plans for supporting them, give me a ring.
At its February meeting the Council approved the RAL proposal to replace its existing IBM 3081 and Atlas 10 mainframes by a single processor. The new processor will be more powerful than the Atlas 10 and 3081 combined and will bring with it a considerable increase in disk space. It will continue to run both CMS and MVS and will give CCD an opportunity to divert resources to where they are most required. It will also be cheaper to run in terms of both hardware maintenance and software licences.
Approval to purchase the new machine is being sought from DES and the Treasury and discussions are taking place on which items of hardware should be purchased. If these discussions are completed successfully, we hope to be installing the new machine within the next two to three months with production services being transferred as soon as the machine has been accepted into operation.
The amount of disruption to users will be kept to a minimum and will, where possible, be notified in advance. There will, inevitably, be some minor breaks in service for which we apologise in advance. When the installation is complete we shall have a very reliable, flexible computing engine on which to base future services.
This is the start of a regular series for users wishing to transfer work from MVS to SLAC Batch. SLAC Batch is a Batch system for CMS and we are encouraging users to move their MVS jobs to SLAC Batch, which offers many enhancements over MVS. We start with some of the arguments we've heard for NOT considering the move; future editions will contain more practical guidance.
For existing CMS users. the commands used to drive SLAC Batch are the same as those for interactive CMS. You simply send to SLAC Batch the command you want to be executed (eg a CMS command or one of your EXECs) in the same format as you would type it at the terminal in an interactive CMS session. Obviously there are other considerations, but the basic command syntax is that of CMS.
Our aim is that there should be no difference in the cost of production work between MVS and SLAC Batch. We are currently reviewing the charging algorithm to ensure that this is the case.
There is plenty of disk space available to CMS users. And, as users migrate from MVS to CMS, the empty MVS disks can be re-allocated to CMS. The smallest job class will allow a user up to 15 Mbytes of disk space on the Worker's minidisk, (the largest up to 30 Mbytes), and the user can decide which files are to be returned with the output and which are temporary and can be deleted. If required, extra disk space is available in the form of a temporary minidisk called TDISK.
You CAN. Four tape drives are currently available for SLAC Batch, and the current policy is to allocate a job up to 2 drives (these tapes need not be the same density). Please note that this is a number which can be varied according to demand; if users need more. then more can be supplied. As well as magnetic tape drives. a cartridge tape drive will be assigned to SLAC Batch too (and a further drive can be made available on request).
There's more than TWICE as much memory available in SLAC Batch. You can run a job requiring 16 Mbytes of memory in SLAC Batch; you can't get more than 7 Mbytes in MVS.
It's true that you will need to get a CMS account before you can run a job in SLAC Batch; this is used for accounting. However, JTMP and FTP can both be used to send jobs directly to SLAC Batch from other sites.
We do not underestimate the inconvenience of any change to our users. However. long term, we are aiming to simplify the system we run, to cut down on maintenance and overheads. If we can achieve this we feel that we can offer users a better service overall. Certain policy decisions have been made regarding SLAC Batch (eg, no more than 2 tape drives for any job) but this is something we can change. If users find this limit unacceptable, then they should send a note to PAO (using the CMS command ASKUS) or telephone Service Line (ext 6389). ALL comments/problems passed on will be considered and we hope to be able to provide the SLAC Batch system you are happy to use.
Many years ago, before the enlightenment of ISO, we installed a Cambridge ring of some magnitude as a prelude to a site wide service. It is still running sweetly with the same number of hosts as when it started -very few. The moral is - don't buy until it works.
With that moral in mind we have done nothing until about a year ago. By that time we were fairly certain that Ethernet was now well tried technology with a good bandwagon in our community. Our one reservation was the absence of Pink Book protocols without which no LAN would be complete. The mist cleared by seeing a possibility of Pink Book protocols on DEC VAX computers supported by DEC. The IBM mist was a bit more difficult to penetrate but after being convinced that IBM were unlikely to provide what we wanted we set to and developed a Pink Book implementation using an AUSCOM (a PDP11 with an IBM channel interface) and a modified version of our well tried wide area software.
With a small measure of confidence we, being N Gunadhi in particular, set up a site wide working party to decide if 'now' was the time and if so 'what'. 'Now' was decided to be the time and 'what' was inscribed in a heavyweight document which laid down in fine detail what to do.
Other things came to pass at this time. We entered into a co-operative project with ULCC, HEP, and DEC to investigate the emerging Pink Book systems over our experimental Ethernets which have been stirring, well hidden, in the basements. We wanted to see if the AUSCOM worked, we wanted to see if the IBM could talk to the VAX. At this point thanks should be recorded to James Hutton for driving the project.
The results were very slow coming but when they did they were encouraging - it worked. We extended the scope of the project to cover first the Spider PADs, then the PC, and now the Spider LAN/WAN gateway.
Meanwhile we had presented our report to our mandarins who accepted it and told us to get on and install. This we did.
What have we done? Nothing surprising. We have put in a fibre optic backbone Ethernet. We have defined 'villages'. A village is a set of closely related computers which tend to be in a single department. Each village is connected to the backbone via a bridge. The selected bridges are from DEC and not the cheapest. There are now eight villages. We decided that no equipment other than the bridges should be on the backbone. The idea is that most traffic will be on the village LANs and that only a small percentage will be between the villages. Thus the capacity of the LAN should last for some years. And here we keep our fingers crossed. The management of a village LAN is the responsibility of the village and as long as they do not adversely effect the backbone they do as they wish. Thus we expect villages to buy PADs, VAXes and so on. which they will install and operate as they see fit. If they ever need help then Central Computing Department (CCD) is always on hand to render first aid. In some cases the village may contract CCD to look after the village equipment.
The backbone is 'star' shaped with all the fibre connections terminating on a fibre optic multiport repeater from BICC. This allows operators to disconnect villages easily if problems arise. A monitor has been installed which is based on an IBM PC with an Ethernet card and software from EXCELAN. This monitors the overall performance of the LAN. The total traffic and error counts are collected.
The DEC bridges provide statistics which give us information on the type of traffic and how effective the bridges are in minimising the traffic on the backbone. So far the LAN has not been heavily loaded and there are no useful figures.
The LAN is managed by CCD under the direction of a committee with representatives from all the villages. The LAN manager is Andy Jessett and the committee is now chaired by Graham Robinson. They meet every six weeks or so to discuss progress.
So, how far have we got? It is there. First indications are that it works smoothly and does exactly what we want. Of course, it has still to carry heavy traffic. It is not yet a service as we are still accumulating operational experience and developing the monitoring and operational facilities. The traffic is still fairly low as confidence is still low and the current X.25 network still carries the bulk of the traffic. We have yet to start buying Spider PADs as we are waiting for some bugs to be fixed before advising some purchases. We also do not yet have a LAN/WAN gateway in place as the evaluation is not complete. A full service is expected towards the middle of the year when the operational aspects are understood and operator and user documentation is developed. It is also important to have the gateway and PADs working.
Further information can be obtained from Graham Robinson, Paul Bryant, or Andy Jessett.
