Jump Over Left Menu
- DR BRIAN DAVIES
- Charging For Central Computer Usage
- UTS: Unix on the Atlas 10
- VAX (VMS) USER GROUP MEETING REPORT
So there is life beyond 1984 after all; may we wish our readers a happy and successful new year. What did Father Christmas bring you? He brought us Council approval of the direct charging scheme for the RAL mainframe computers. Full details appear in this issue. To lighten any gloom the prospect of charging induces in our readers we include a picture feature and a Special Offer.
The New Year is a time for looking back as we do in our FORUM84 summary and forward as we do in articles on UTS and MVS.
This issue is dominated by articles on mainframe computing. This does not imply a period of inactivity on other fronts. We carry a short report of the SERC VAX (VMS) User Group Meeting highlighting its interest over problems in the area of "coloured-book" network software. The meeting it requested with the JNT and other interested parties has now been set up. This group is proving a very effective voice for VAX users.
The Needs of Engineering Computing Working Party is now beginning to formulate its views and, although the final report is not due until early Autumn, the new Engineering Board Five Year Forward Look is hopefully to be adjusted to include funds to allow the recommendations to take effect in the 1986/87 Financial Year assuming they are approved.
The Prime upgrades reported earlier have all been delivered and will be installed by the time this Newsletter is published. The GEC upgrades are still on schedule for early February.
The ICF machines have performed well during this period apart from the Prime 9950 at UMIST which has suffered a spell of unexplained crashes. The central mainframes have also performed well with the backlog being cleared each weekend. Some problems have been experienced with network connections and this situation is being investigated.
Paul Thompson, Head of User Support and Marketing Central Computing Division
DR BRIAN DAVIES
One of the recommendations of the Computer Review Working Party was that SERC should have a full time Director of Computing. The duties of the Director would be to run the Council's computing infrastructure and networking activities, to run the RAL mainframe service, to advise on the coordination of the provision and replacement of the various Boards' computing resources, to advise Council on computing matters and to liaise with the Computer Board and other bodies involved in the provision of research computing.
This recommendation was accepted by Council and I was appointed to do the job with effect from October 1st last year.
There were two major tasks to be tackled immediately. One was to get agreement at Board and Council level on what items of the existing portfolio of computing activities should be included in infrastructure and to secure appropriate funding. The other was take up another of the Working Party's recommendations - that the RAL mainframes be run on a direct charging basis and to propose to Boards and Council how this might be done. Both these tasks have now been done and Council accepted my specific proposals at its meeting just before Christmas. More detailed information on the charging arrangements is given elsewhere in this issue.
The general position in SERC computing at the moment is one of considerable change. The devolution of some facilities from central funding to funding directly by Boards, together with the introduction of new charging arrangements for the mainframes at RAL are big enough changes in themselves. Since they also coincide with a period of severe financial restraint in the Council as a whole, it is clear that Boards and their users will be ever more concerned to see that the computing facilities they fund are relevant to their needs and are provided efficiently. The providers of the facilities are well aware of this and I am sure they will respond accordingly.
At this stage I do not propose to make any further specific comments, but from time to time I will contribute an article to Forum as appropriate.
Brian Davies - Director, Computing
Charging For Central Computer Usage
As reported in previous issues, the Computer Review Working Party proposed that the central computers at RAL should be run on a direct charging basis. On 19 December Council accepted this recommendation and approved the detailed proposals put forward by RAL. It also decided that the new arrangements should operate from 1 April 1985.
Staff in Central Computing Division have for some time been studying ways of operating the computing service on a direct charging basis and have arrived at the scheme approved by Council. This is a major change from the way in which computing has been accounted and funded in the past. It comes at a time when the batch system changes from MVT to MVS. Because we have been forced to make assumptions about MVS demand, I suspect that we will need to introduce changes to our first attempt at the charging scheme. Both the charging rates and algorithms will be subject to periodic review. There will be two components of the charging scheme - basic charges and resource usage charges.
An annual charge of £150 will be levied for being registered to use any of the RAL mainframe systems. In other words it will cost £150 per year to have a personal identifier but this identifier may then be used for MVS, CMS, PROFS etc. A charge of £3 per year will be levied for storage, maintenance and handling of each magnetic tape in the RAL Tape Library. From 1986/7 there will be a charge for disk space in both the MVS (batch) and CMS(interactive) systems. In MVS the charge will be for space occupied integrated over time. The charge for CMS disk space will be levied on each cylinder of minidisk owned. A charge for space in the Masstor cartridge store will, be introduced when appropriate.
Charges for Use of Computing Resources
The basis of charging for both MVS and CMS will be the Allocation Unit (AU). An Allocation Unit has been devised for the MVS batch system which takes into account job priority, processor time, number of I/O instructions, size of job and other factors. As a guide we expect 100 MVS AU's to be equivalent to a 360/195 CPU hour for average jobs. For many short jobs usage of MVS AU's is likely to be higher than this comparison suggests. Users are already familiar with the CMS AU but details of both algorithms are given at the end of this article. The cost of an MVS AU will be £2.75 and a CMS AU will cost £24, These rates apply to SERC-supported users and will be introduced on 1 April 1985. External users will be notified of the rate appropriate for their use of RAL facilities.
A review of the way in which we charge for other aspects of the service (eg laser printing, manuals, printed graphical output) is in progress. For the moment, however, we intend to continue the present arrangements for charging for manuals and for magnetic tapes.
HOW WILL IT WORK
The average user will not be involved in the charging procedure. Your allocation will be in AU's and your usage reported in AU's. At SERC Board level, however, the situation will be different. Each Board will be asked to decide annually to what extent it wishes to finance its central computing requirements and whether the sum of bids received matches the funds available. It will then bid for the requisite amount of computing from RAL. Resources may be requested at any time of the year but bids will normally be made for the forthcoming financial year. Bids received in this way will be treated as firm commitments and will attract a bonus of 20% extra resource at no additional charge. Bids received for resources in the current financial year will be accommodated if capacity is available and will be charged for as used but will not attract the bonus.
These arrangements are intended to make the provision of central computing more responsive to the needs of the Council's scientific programme and to this end sufficient margin has been built in to the charge rates to allow hardware to be replaced before it becomes obsolete and expensive to run. We are keen to find out what sort of computing you will require in the future. We shall be starting a programme of consultation with users, particularly those making the heaviest use of the resources. We are interested in the needs of every user. If you have views on the way the central computing service can meet your requirements please write to Forum or contact me or one of my Group directly. If Central Computing is necessary to your work it is important, too, that you make this known to those who represent you on the various SERC Boards and Committees. They are the people who control the funds and will decide what sort of Central Computing Service SERC has in years to come. The introduction of charging and the necessary control and accounting software will mean a period of learning for both users and central computing staff. I hope you will be patient with us while we are learning and we certainly aim to be fairly flexible during the initial period of working under these new conditions.
THE MVS AMD CMS CHARGING ALGORITHM
Resource usage charges for MVS will be calculated using the following formula:
AU usage = 0.0571 * P * (CPU + 0.00136 * (DIO + VIO + 2 * TIO) + 0.48 * (0.01 * SIZE + NS + 1 + NU))
P = Factor based on user priority - 3 for 1 for medium, 0.6 for low CPU = CPU time used in Atlas 10 seconds DIO = number of disk I/O instructions (EXCP's) issued TIO = number of tape I/O instructions (EXCP's) issued VIO = number of virtual I/O instructions (EXCP's) issued SIZE = a measure of the job size in megabyte-seconds NS = number of steps NU = number of anti-social requirements
NU will eventually include items such as tape mounts but will initially be zero.
As a guide we expect that 100 MVS AU's will be the approximate equivalent of a 360/195 hour used on the MVT system by average jobs. The MVS algorithm takes into account use of CPU and other factors and for many short jobs their use of MVS AU's is likely to be significantly higher than this comparison suggests.
The CMS algorithm used in the new scheme is identical to that currently in use. It is included here for completeness.
AU usage = 0.0041 * B * CH(t) * (A * CPU + 0.0006 * CON + 0.00035 * SPIO + 0.008 * NSPIO)
A = CPU time factor (1.6 on the 3081, 4.5 on the Atlas 10) B = factor for CMS BATCH work (0.8 for batch, 1 otherwise) CPU = CPU time in seconds CON = terminal connect time in seconds SPIO = number of spooled I/O's NSPIO = number of non-spooled I/0's CH(t) = a time of day factor given by CH(t) time of day CH(t) time of day 0.10 00.00-08.00 weekends 0.40 08.00-10.00 0.10 00.00-24.00 1.00 10.00-12.00 0.60 12.00-14.00 1.00 14.00-17.00 0.40 17.00-22.00 0.10 22.00-24.00
Paul Thompson - Head of User Support & Marketing, Central Computing Division
UTS: Unix on the Atlas 10
What is UTS
UTS is a version of the Unix Operating System which runs under VM. It offers most of the features of Unix Version 7, together with some additions. A general overview is given below.
Interest in a 'large' Unix system has come from a number of places: notably from the Alvey Programme. UTS has now reached the stage where it is ready for use. It has been placed on the Atlas 10 to avoid any performance conflict with CMS. However, as yet there is little indication of how UTS will interact with MVS. Therefore, before setting up a full service, we want to try UTS with a few early users.
Anyone interested should contact R E Thomas, H K F Yeung or PC Thompson at RAL. Pump priming facilities will be made available for this pilot service. Although UTS can be accessed from ASCII terminals, it is really designed for use with 3270-type full-screen devices. If necessary, a modified Cifer can be provided on loan for the period of the trial.
What is available
The features of UTS are summarised below:
UTS and UNIX
- a hierarchical file system. This allows users to divide their directories into subdirectories which in turn can be divided further into sub-subdirectories etc.
- a flexible, easy to use command language (shell) that may be tailored to specific user needs.
- a context editor (ed).
- a flexible text processing system (nroff, troff) .
- a system for controlling and tracking changes in computer programs and arbitrary documents (make, sees). Make provides a simple mechanism for maintaining up-to-date versions of programs that result from many operations on several files. Sees is a source code control system which enables the user to keep track of different versions of a system.
- high level languages: C, Fortran 77 and Pascal.
- a symbolic debugger (dcon). Although it is not directly tied to the C programming language, some 'dcon' features can only be used when debugging a C program.
- a desk calculator (be).
- an assembler (as). The language accepted is a hybrid of 370 Assembler language and the Unix assembler language for the PDP-11. It does not support all the features of the 370 Assembler.
- a pattern scanning and processing language (awk). The basic operation of awk is to scan a set of input lines in order, searching for specific patterns. For each pattern, an action can be defined.
- a computer-aided learning system for beginners (learn). At present it supports scripts for basic file handling, the text editor, advanced file handling, and the C programming language. Students receive immediate feedback and confirmation of progress.
- a lexical analyser generator (lex). Lex is a program generator designed for lexical processing of character input streams.
- a C program checker (lint). Lint examines C source programs, detecting a number of bugs and obscurities. It enforces the type rules of C more strictly than the C compilers.
- on-line documentation (man).
- a compiler-compiler system (yacc). Yacc provides a general tool for describing the input to a computer program (eg. a compiler).
UTS and VM/CMS
Many of the additional features reflect the fact that UTS runs under VM:
- 16 M bytes user virtual storage.
- 3270 full screen support. A C preprocessor (qs) is available which provides a set of screen manipulation routines to assist the implementation of full-screen applications.
- a full screen editor (ned). It incorporates all the features of the line editor and takes advantage of the full screen capabilities of the 3270-type terminals. It also provides language dependent program editing features.
- CMS interfaces. The communication between UTS and CMS is accomplished mainly via the virtual reader and punch.
- VNET interfaces. Files can be routed to VNET for transmission to a remote VM or workstation.
UTS and RAL
At RAL, other features are added to the UTS system to meet our local requirements:
- file/mail transfers. This allows users to transfer files and mail to/from UTS and other machines. The implementation uses the service provided by NIFTP.
- more data formats. The standard UTS system supports only the 'card' data format. We have extended this to include 'disk dump' (used by ftp) and 'net data' (used by mail) formats.
- interface to laser printers. Interface programs are provided to allow users to send their output to the 8700 and 6700 laser printers. Work is in progress to provide a similar interface to the 4250 printer.
- other languages. Work is in progress to mount Franzlisp and Prolog. The former comes from Amdahl and the latter from Edinburgh.
Given the success of the pilot service, it should be possible to offer a full service. UTS is due to be upgraded to UNIX System V shortly also. Further information will be provided in later editions of Forum.
Eric Thomas - Head of UNIX Section Informatics Division
VAX (VMS) USER GROUP MEETING REPORT
The SERC VAX Users Group met in London on November 22nd. 17 users representing 15 sites attended. The meeting discussed the possibility of establishing closer ties with Computer Board Meetings concerned with VAX computers. The present position is that there is cross-representation between the VUG and three Computer Board meetings (Systems, Communications and Applications). One major area of common interest is networking and the consensus was that a meeting organised by the JNT with representatives from the Computer Board, the SERC VAX User Group, UWIST and Digital would be the best way to proceed. This would leave the VUG meeting free to expand its discussions into other areas.
For the future the VUG will establish its agenda well in advance so that appropriate action can be taken for items of wider interest.
A representative from Digital was present for part of the meeting. He clarified the position on problems or suggestions relating to FTP; all communications should be to Digital. The implications of VMS 4, PSI 3 and FTP 4 were discussed. It was clear that individual sites would prefer to make the complete transition to these releases over a short time interval. The variation from site to site will be quite large but this should not lead to any serious communication problems.