Although the overall performance of the IBM/ATLAS10 system has been affected by a higher than usual number of hardware and software breaks user demands have generally been satisfied. Some turnaround guidelines have not been met but by Monday mornings the backlog has been cleared. GEC and PRIME performances have been good with no known difficulties for users of either systems.
This last issue of FORUM for 1983 contains a report of the recent IBM Central Representatives Meeting together with the considered replies to questions raised at the meeting which are of general interest. There are also summaries of a PNX User Forum, a DEC 10 User Meeting and a GEC User Meeting. The Joint Network Team have provided a status report which includes a list of host systems where packages are now available to support the recommended protocols. The replacement of the HASP Service to the SERC Primes is described in an article from the Systems Development Group.
Any IBM user who owns magnetic tapes which are stored at RAL must read the article describing the new policy agreed by the Division Heads Committee on Magnetic Tape Storage. The next issue of FORUM will contain a list of tape numbers currently in the tape archive which are affected by this policy.
It hardly seems possible that we have come to the end of 1983 already and that 1984 is just around the corner. I am old enough (just!!) to remember the other 1984 and at the time never expected the actual year to arrive so soon. The most significant event in the RAL Computing Division in 1983 was the removal of those remarkable old IBM 360/195 machines and the arrival of their equally remarkable replacements. The installation and early performance of the IBM 3081D and the ATLAS10 were better than we expected even though we have had good experiences in the past and therefore always have high hopes.
It only remains for me on behalf of the FORUM Team and RAL Computing Division to wish all our readers a Happy, Prosperous and Successful New Year.
A PERQ PNX User Forum was held on 22 September at RAL which was attended by over 50 people. The agenda was a mixture of progress reports, shared user experiences and discussions of future plans. The lunch interval featured several demonstrations of important pieces of software currently being prepared for release.
A presentation given by ICL was in two parts. Mr G Moggridge outlined the findings of a user survey and linked this with a description of the newly announced PERQ-2. As well as providing additional power more quietly, a number of improvements cover some items brought out in the user survey.
Mr A Montgomery described the contents of release 2.0 of the PNX operating system. This is based on Version 7 UNIX and provides the programming languages C, Fortran 77 and ISO PASCAL. There is a screen editor which makes extensive use of the puck and tablet. There are also font and cursor editors. User microcoding is possible on those machines which have a 16K Writeable Control Store. A symbolic debugger is available. There are changes to the window manager interface plus some performance improvements. (However, the display of input lines which has been heavily criticised is unchanged in this release.) There is support for a variety of printer attachments and facilities for external connections which include an X25 file transfer capability and UUCP (UNIX to UNIX copy). This installation of release 2 will be coincident with some hardware modifications.
This forthcoming release of the operating system incorporates the missing components (PASCAL, Screen Editor and Networking). Mr Montgomery discussed the general area of future work such as better paging, optimisation and additional functionality. He referred to the fact that POS PASCAL has many system dependent extensions. Users who have made heavy use of these extensions are likely to have much to do in order to implement them under PNX.
The Screen Editor, X25 networking and the GKS graphics package were all demonstrated during the lunch interval. These demonstrations made use of the new window manager developments.
Mr B F Colyer of RAL Instrumentation Division described the experience of converting a number of programs from POS to PNX. The work had been simplified by the preparation of an interface to the graphics used by PNX. (Copies are available from the CBP Support Office.) The user found PNX to be a more robust system than POS and its best features for him were piping, nroff and the window Tianager. At the present time, the performance of Fortran programs needs improving - the PERO's greatest strength being its graphical capability.
Other talks were given by Dr B Gay of Aston University discussing the development of Engineering Software under POS and PNX. This talk confirmed many of the findings given by Mr Colyer. Mr S P Guest described early experiences attempting to implement some software tools on a PERQ. Mr C Prosser of RAL Computing Division spoke about experiences of porting large utility programs and the need for reference testing systems.
Dr K Robinson outlined current support activity. The Support Office is continuing to build its experience and is examining the material available for use in Help systems, and the use of databases for query management. Documentation is one of a number of fields in which RAL will be collaborating with the group at Queen Mary College responsible for the support of PERQs purchased by the Computer Board.
The chairman, Professor C McGreavy of Leeds University, summarised the day by saying that PNX was beginning to all come together. There had been a useful exchange of information, and there were several requests for some of the software available for pre-release testing.
It is hoped to arrange the next Forum in the early Spring.
The Joint Network Team has been in existence for over 4 years and the networking programme which it established has now yielded substantial results. These have been achieved partly through the funds which have been directed towards achieving the goals of the programme but mostly through the willingness of the academic community to pool its efforts and work together.
The strategy adopted is based on the principles of Open System Interconnection and the corresponding non-proprietary protocols which are used to ensure interworking between computers from different vendors. The JNT has recommended the use of certain protocols throughout the community with the intention of ensuring that any terminal or computer can communicate with any other for the purposes of terminal access, file or mail transfer and job shipment. The strategy also proposes unifying communications arrangements so as to simplify topologies, improve flexibility, increase reliability and reduce costs.
The JNT has two main programmes. The development programme seeks to augment the efforts of the community and manufacturers by funding the production of host computer protocol packages or network components for widespread use throughout the community. The installation programme provides funds to university sites for the purchase of campus networks and host computer interfaces. In addition to this, the recently established Network Executive is seeking to integrate wide-area communications to provide a single X25 packet-switched network for the academic community (JANET). The table below shows the types of host systems where packages are now available to support the recommended protocols. The development programme is not complete and not all the systems listed support all the protocols. A system is included provided at least one of the user services (terminals, files, mail, jobs) is available.
Systems with JNT-recommended protocol packages
| Company | System | Facility | Supplier |
|---|---|---|---|
| CDL | CYBER/NOS | TF | M |
| DEC | DEC-10/TOPS 10 | TFM | JU |
| VAX/VMS | TFM | JMU | |
| VAX/UNIX | TFM | JU | |
| PDP-11 /UNIX | TFM | JU | |
| PDP-11 /RSX11M | TF | JMU | |
| PDP-11/RT-11 | TF | JU | |
| LSI-11/RT-11 | TF | JU | |
| GEC | 4000/OS4000 | TF | M |
| PRIME | PRIMOS | T | M |
| Honeywell | GCOS | TF | JU |
| MULTICS | TF | JM | |
| IBM | MVS | T | M |
| ICL | 1900/GEORGE3 | T | JM |
| 2900/VME | T | M | |
| PERQ/PNX | TFM | JU |
KEY:
| Facility: | T = Terminal access, |
| F = File Transfer, | |
| M = Mail; | |
| Supplier: | J = Developed for the JNT, |
| M = Manufacturer supplied and supported, | |
| U = University supplied and supported. |
The above list only covers packages which are available now as products with ongoing maintenance support (university suppliers are funded through the JNT to provide support). Further packages exist, for example for GEC, IBM and Prime systems, which are either not available as documented products or where there is no commitment to ongoing support for customers throughout the academic community. In many cases, these will be available soon from the manufacturer. The JNT believes in general that commercial rather than university supply and support is to be preferred and is pressing manufacturers to adopt products.
Development is continuing and other packages are in the pipeline. Job shipment can currently be achieved through an enhancement to the file transfer mechanism but will be available soon through a sophisticated Job Transfer and Manipulation Protocol.
Host computers are either connected to a wide- area network such as JANET or the public packet-switched network (PSS) or to a campus network. These networks are normally interconnected so that connection to one ensures communication with all other systems. The JNT installation programme provides funds to universities to implement campus network plans. Funds are provided to purchase components "off the shelf" rather than to enable local development.
Most existing campus networks use X25 packet-switching technology. This is primarily because work is more advanced than with the higher-speed Local Area Network technologies where a complete set of protocol standards or products are not yet available. About 35 university sites have now installed or have ordered networks based on GEC 4000 Campus Packet-Switching Exchanges and JNT Packet Assembler/Disassemblers (PADs or terminal concentrators). This means that over half of UK universities have a local medium-speed networking capability.
Higher-speed Cambridge Ring technology is also starting to come into use. The Computer Centres on 4 sites offer a Ring network service and a further 3 are planned. This is in addition to the large number of Rings installed for research purposes. Many sites are also considering plans for networks based on "Ethernet" technology.
Almost every university in the country now has some kind of access to the wide-area network. In some cases this may only be through a departmental machine provided for research purposes or may only be for terminal access. However, the population which can gain access is growing steadily and the quality of the connections is improving. The task of the Network Executive is to enhance the capacity of JANET, to provide general access to it by making connections available through university computer centres and to rationalise the network topology.
Much progress has been made in the last four years and a large part of the academic community now benefits from the facilities available for Open System communications. However, much work remains to be done particularly in the area of Job submission and in the high-speed Local Area Network technologies. The emphasis is likely to shift in the next few years with more development done by manufacturers rather than universities as the outside world catches up and international protocol standards become available.
Held at the Rutherford Appleton Laboratory on Thursday 3 November 1983 - chaired by Dr John Baldwin from Cardiff University. A well attended meeting with 24 attendees and most sites represented.
Development work on a form of archiving, using the new MASSTOR facility at RAL will commence early in 1984. Given that no major problems are encountered Andrew Dunn expects the project to be complete within 6 months.
Resource Management at RAL have been requested to produce more realistic statistical information on usage.
A small working group, comprising John Baldwin (Cardiff), Gareth Owen (Heriot Watt), Dave Lilley (Newcastle) and John Alcock (Bristol) is to formulate proposals for the future requirements of the GEC community. Any input from users on the subject should be directed to them.
Users consider that a full screen editor is urgently required.
A representative from GEC is to be invited to respond to questions tabled in advance of the next meeting. Any user may send questions either to the Chairman John Baldwin (Cardiff), or the Secretary Kevin Duffey (RAL).
A brief summary of developments since the last meeting was given: the M860 had arrived, the 3081 change had been made, the Atlas 10 was accepted, the 3032 had been dedicated to administrative computing, the solid state paging device had been installed, and an MVS internal service had begun.
The rest of the talk covered the Central Computing Committee discussion, reported in November FORUM.
This talk outlined the present plans for allocation and control of MVS facilities. These suggestions form the basis of work currently in hand on the MVS systems. In MVS we shall be controlling facility use by means of the Account Unit (AU) and disk space will be controlled by the space-time integral.
The Account Unit will be calculated as :-
AU = A (Computer Resource Unit)
where A is a multiplication factor based on the priority at which the job was last set by the user. Thus the resource unit should reflect the effects on the system of the job and should be reproducible for each job. The resource unit includes CPU, region size and I/O from disk tape and VIO, as its major contributing factors and overhead charges for each step, job and unsocial requirements.
We intend to provide suitable usage figures in the Job-log to enable each user to assess the impact of his job. At the end of each step the total resource units used by the step and the make-up of these units from their constituent parts expressed as percentages will be presented.
At the end of the job the total AU's, the total CRU's, the last priority set by the user and the system's estimate of AU's will be printed.
The structure will be similar to the present one of Board, Category and Account but a Sub-account level will be added below the account level to facilitate disk-space accounting.
Each entity to which resources are allocated, i.e. Boards, Categories, Projects, and Subprojects will have a record in the database to record those resources. There will be a manager for each record who will be responsible for all aspects of managing the resources. He will, for example, be responsible for creating the records of the next layer down in the hierarchy and allocating resources to them. Managers of Subprojects will be responsible for defining who may access datasets belonging to the subproject, and who may run jobs which are charged to it. In general the managers will be users not members of Computing Division.
We will attempt to provide a flexible policing system which allow users to transfer resources forward and backwards in time within defined limits. The system will also automatically transfer resources unused by one subproject to other subprojects within the same project. To do this accounting will be done on a yearly basis. Users will be allowed to overspend in any week, but will be kept within allocations in the long term by a weekly adjustment of allocations.
Four different resources will be recorded, MVS AUs, MVS disk space, M860 space, and CMS AUs. At present we do not intend to charge for M860 space.
When the Electron Beam Lithography Facility was established at RAL it was decided that its users, mainly university students and research workers, should all use the same Computer Aided Design language, GAELIC, on the PRTMEs at Atlas. Both the GAELIC language and the programs within the GAELIC suite contain many features intended specifically for integrated circuit design so the only extra facility required was to add one extra program to the suite; namely a GAELIC post-processor which would translate from GAELIC into the input language of EBLF's Electron Beam Mask Fabricator (EBMF2).
With the provision of the post-processor and a 9600 baud File Transfer Protocol (FTP) link between the PRIME and EBLF's PDF 11/34 we were able to start production. Early experience soon highlighted a major operational difficulty; FTP at 9600 baud. The EBMF2 hardware can expose only one basic shape; a trapezium parallel to the x-axis with sides at one of only four particular angles. Thus, since users are free to specify perfectly general polygons in their GAELIC designs, it may take very many EBMF2 shapes to represent one GAELIC shape. This data explosion takes place on the PRIME at post-processor time. In extreme cases a few lines of GAELIC can produce several hundred thousand lines of EBMF2 input. A file of this size can take days to FTP at 9600 baud! Fortunately most of our work is for integrated circuits which are mainly rectilinear. In such cases there is a one-to-one relationship between most of the designer's GAELIC and EBMF2 input and thus there is only a small increase in the amount of data to be transferred. Also, once the problem had been recognised it was also realised that the solution was already in hand; namely a l0Mbit Cambridge Ring between the PRIME and PDF 11/34. With the solution confidently expected within a reasonable timescale no further action seemed necessary. Oh well, a nice idea, but we seem to have survived without it!
Thus as originally envisaged EBLF made little direct use of the PRIME, it was mainly GAELIC and our users who hogged the system. Our use was confined to running the post-processor and FTP. However the next problem to arise soon changed that. It became apparent that there is a seemingly harmless habit of some designers to overlap touching shapes. Unfortunately this leads directly to a double-exposure on EBMF2 and a potential failure of the final product. Within the GAELIC suite there is a program called MERGE which can solve this problem. At the end of a MERGE run all touching or overlapping shapes have been merged into individual polygons leaving you with a design in which all shapes are isolated from each other. A little thought will show you that this process is analogous to sorting in terms of computing time taken and is liable to increase dramatically as the number of shapes in a design increases. In fact large designs have to be submitted as weekend jobs on the PRIME and even then may not complete before the next scheduled downtime. Initially EBLF had to run MERGE on all designs received but now it is the user's responsibility to ensure that he submits a non-overlapping design.
Having removed the necessity for EBLF to run MERGE it soon returned. MERGE has the ability to perform another very useful function which is to inflate or deflate all shapes by a specified amount. The ideal world where the designer specifies the exact size of each shape, EBLF produces exactly that sized shape in the mask and then finally it is produced in silicon does not always exist. In practice the silicon production unit may require that all dimensions on the mask are plus or minus the required size by some fixed amount. This is achieved by running MERGE with the appropriate amounts specified. Currently we have to do this for some jobs but not for others, depending upon to which silicon production unit a job is going.
If anyone requires further details, contact me at RAL, telephone 0235-21900 Ext. 5650.
Dear Sir,
As a user of the GEC and DEC 10 facilities of SERC, my eye was naturally caught by the comments about them in the October FORUM.
The problems with GEC use may have more to do with the hardware and software limitations of the machines rather than lack of interest in MUM use. A GEC user who lacks any screen editor at all can only feel green with envy at the PRIME users getting EMACS (and why are the available DEC 10 EMACS emulations so poor when better ones exist): a machine designed for interactive graphics with no screen editor is nonsense. What I fear, and this may be a fear shared by other GEC users, is that the built-in handicaps of these MUMs may lead to simple removal , or removal of vital parts of their capabilities, rather than their replacement by machines suitable for the late 1980s.
As for the suggestion that the high DEC 10 use represents an effort to finish projects, I suspect that as far as AI users and those using AI type languages are concerned, it may rather represent a steady increase in activity on continuing projects which at present have no other facility to use. It should be seen as a demand for a suitable replacement for the DEC 10, not as a symptom of the end of activity.
I was also rather upset by the reference to the attendance at DEC 10 User meetings. Surely it is inevitable that attendance from a community scattered over the country using one machine is worse than that of groups (eg PRIME users) using many machines. It must be easier to find one person in a group of, say, 20 or 30 PRIME users at a site than for each user of the DEC 10 to be able to take a day off normal duties to attend a meeting. Yet your report suggests that this implies that users do not care: my own impression, especially of those meetings which took place when there was some attempt to save, not the DEC 10, but the general facilities it provided, was that people do care, in many cases desperately so, because their research would become essentially impossible if the DEC 10 closed before its replacements became fully operational.
Yours faithfully,
Dr M A H MacCallumn
Sir,
Article 12 in the October FORUM explains why I never seem to have any time. Jacky Hutchinson reports that a 1 hour lecture takes 200 hours to prepare. My modest new lecture load of 20 hours must take 4000 hours, i.e. an 80 hour week. No wonder colleagues with heavier loads make their lectures last 20 years as Geoff Lambert confirmed recently.
G.C. Barney
Tired of UMIST
Sir,
I, too, was surprised at the figure quoted at the seminar, and questioned it at the time. I was told that this figure included all secretarial and managerial work involved in organising a course.
Perhaps the fact that the seminar was given by an American is significant.
Jacky Hutchinson
The FR80 microfilm recorder was installed in 1975 and is now nearing the end of its useful life. In order to preserve a record of the many different types of research which were done with it, a member of Computing Division is hoping to write a review article. If you have any FR80 output which you would like to be considered for inclusion, please send a few lines describing the research project, together with the plot to me at RAL.
The Computing Division currently holds approximately 30,000 archived tapes which have not been used for at least 5 years and some date back to 1970. A large proportion are 1600 bpi. A sample test has recently been carried out and although readability of the tapes was better than expected great difficulty was encountered when attempting to trace the ownership.
As a consequence the following rules have been laid down by the Division Heads Committee :-
Users will be requested to make positive identification of tapes and state which should be kept and which may be released. Users must assist Computing Division to convert all wanted tapes to 6250 bpi.
Tapes not identified after a second trawl will be removed from the archive and scrapped.
The MVS External Trial Service will start on Monday 6th February 1984. A copy of the MVS Trial Service User Guide can be obtained from John Gordon in User Support Group (Ext 6574 or JCG @ RLIB) The service will be available from 14.00-18.00 Monday to Friday and we would encourage everyone to use it in order to familiarise themselves with the differences between MVT/HASP and MVS/JES3 and to overcome any technical problems in transferring before the production service starts. The good news is that the Trial Service will be free - the bad news is that there can be no guarantee of turnround as this will depend on the quantity of work submitted and the availability of Operations staff to support the service.
The replacement of MVT by MVS on the Rutherford IBM complex during 1981 means that the HASP system for submitting jobs from the Primes and retrieving the output will no longer work. Our planned replacement for this service will provide all the existing facilities with one exception: the keywords JCL= and RESULTS= on the *FILE card will no longer be available. At present, these keywords allow the JCL and RESULTS listings from a job to be routed to separate files or lineprinter listings. Under the new system all output from a job would have to go to a single file or lineprinter listing (equivalent to the OUTPUT= keyword).
Before committing ourselves (and our users!) to this system, we would like to know whether the JCL= and RESULTS= keywords are indispensable to anyone. If you have strong views on the subject please contact Prime User Support as soon as possible.
The new system will include a replacement for the HASP command. This will be easier to use under Rev 19. We intend to run the new system in parallel with the existing HASP service for as long as possible, to allow everyone enough time to convert their CPL packages etc.
The following points of interest arose:-
23 - 26 January IBM New Users' Course
22 - 23 February Advanced CMS Course
For further information and enrolment, please contact either PAO on (0235) 44 6111 or Garry Williams on (0235) 21900 ext 6104.
Q I would like to automate the receiving of mail into my virtual machine. I would therefore be grateful for any advice you may have to offer.
A First of all we suggest that you make a decision as to the action you wish to take on incoming mail.Choosing "a" you need only place the command EXEC QMAIL REVIEW in your PROFILE EXEC file, then at logon this command is processed and will prompt you to use one or more of the following subcommands:
REVIEW stores new mail in a previously defined Notebook (default ALL NOTEBOOK). The default Notebook may be changed using the DEFAULTS command. Choosing "b" you need to place the command EXEC QMAIL RECEIVE into your PROFILE EXEC file. The command will copy any new mail file into the previously defined Notebook (default ALL NOTEBOOK). The REVIEW command may then be used to view unseen mail files. The default ALL NOTEBOOK is normally changed when using the QMAIL RECEIVE command, generally speaking people prefer to use specific Notebooks. This can easily be set by setting the DEFAULTS command.
DEFAULTS SET RECEIVE LOG OLDDATE NOTEBOOK *
Each time a mail file is RECEIVEd it will be stored into filename NOTEBOOK, where filename is normally user origin id.
The following CMS Helpfiles will give full details on above information.
HELP QMAIL HELP RECEIVE HELP REVIEW HELP DEFAULTS
Q What is the difference between -NO_VERIFY and -NO_QUERY.
A The -NO_VERIFY option is a wildcard option, applicable to any PRIMOS command which has been invoked with a wildcarded filename. For example:
DELETE @@.BIN -NO_VERIFY
suppresses the PRIMOS request to the user, verifying every filename which matches the wildcarding (@@.BIN in this case) is to be deleted.
-NO_QUERY is an option which applies to specific commands (for example DELETE and COPY). By default, the user is asked to resolve any conflicts. For instance, DELETE with -NO_QUERY does not ask the user whether they intended to delete a directory, or in the case of COPY overwrite an existing file. In these cases PRIMOS resolves to delete the directory and overwrite the file.
Q I have a program which behaves rather oddly. It is compiled with FORTV, linked with LINK2 and calls the NAG routine S01AAF. The program fails in the NAG routine; though with the removal of the preceding WRITE statement or an additional and unrelated type declaration, the program completes without error. The following is an extract from the program:
REAL*8 GAM1.S1
INTEGER ITERC(500),IFAIL,N,X1,Y1,Y2
C
IFAIL=0
X1=0
Y1=0
...........
DO 20 N = 1,21
X1=N+Y1-1
...........
WRITE(2,120)S2
GAM1=S14AAF((X1+1.),IFAIL)
120 FORMAT(1X,'S2 = 'E14.7)
ITERC(X1)=Y2
20 .........
A The GEC implementation of the NAG library is in double precision. Since S14AAF is a function subroutine which returns a value of type REAL, it should be declared as a double precision variable together with all real parameter variables.
Mixed-mode arithmetic should be avoided, unless the machine's mode of operation is known for a given mix of real and integer variables. It is wiser to use the compiler functions DINT and DFLOAT to convert from real to integer and vice versa.
This particular program generates an array-bound violation when it assigns the value of Y2 to ITERC(O), almost certainly outside the data area but within the code area. This would cause the overwriting of part of the code, and explain the strange effects induced by trivial changes to the program.
If the program had been compiled with option Q, additional code would have been generated to perform a run-time check on array indices. The array-bound violation would have been flagged as a consequence
.The present system of financing Central Computing, whereby each board pays for part of the budget in proportion to its usage, seems lunatic.
Reply: We agree that the current system of financing is quite unsatisfactory and we hope that the Central Computing working party, which is considering the long term policy issues of SERC computing, will propose something better.
The various quantum chemistry projects are seeking very large allocations of time on the IBM system in compensation for the loss of Cray time.
Reply: There is capacity on the IBM systems to accept much more batch work. With the agreement of a given funding authority, this may be freely allocated in FY83/84. In future financial years such allocations may be made as part of the board's allocation. The capacity is there but the boards must agree allocations through the normal channels for future financial years.
When will the space-time integral for a dataset for MVS disk space be done?
Reply: The accounts will not be updated when the dataset is accessed. Each time the size of a dataset is changed, i.e. a dataset is created, extended or deleted, the amount of space used by the sub-project is updated and the space time integral can be calculated. Accounting is best done continuously since it gives less opportunity for people to manipulate the system. We will have to see if the overheads are excessive.
I have used MVS at Argonne, where they charged for the region size in MVS. We found that we were charged less if we heavily overlayed the program, which is bad for the system.
Reply: The theory behind an elaborate charging system such as the one we are using is that antisocial behaviour, or activity which is bad for the system, can be prevented by charging heavily for it. We will attempt to choose the constants in the charging formula to prevent the sort of problem you have pointed out.
Will MVS provide an estimate of the cost of a job in pounds? This has a much bigger impact on the user.
Reply: No the 'cost' of a job is assessed as its impact on the system in resource units, the conversion to account units allows the user's requirements for turnaround to be assessed in the same allocation unit. This does not relate to a cost in pounds effectively and so no such conversion will be performed.
Since you are not charging for tape mounts in MVS, surely you cannot complain about excessive use of tapes?
Reply: The charging formula has been determined partially by three conditions we have to meet: we can only use information which is readily available; we want to print the cost of a job on its output; we want to adjust the rations as soon as possible after the end of execution. The first condition is because we don't have the manpower to go burrowing into the operating system to find hidden data in the time available. If the second two conditions are unnecessary please say so. This may affect what we do.
We do intend to charge for tape drives and demountable disk drives used. We would like to charge for disk and tape mounts but we don't know how to get the information and we don't have enough effort to find out. It will be on the list of possible improvements after MVS is introduced.
Is the MVS disk space accounting in terms of a space-time integral really a good idea? If you run out of AUs before the end of the year, you may have to delete all of your datasets.
Reply: I think space time integral is the best way of charging for disk space. It isn't clear what is the best way of policing disk space. It may be better to use space occupied for that purpose. It is clear that waiting until some one exceeds his space limit and then stopping him submitting jobs, or creating new datasets is no good. The charge will still continue to mount. What is needed is some form of pre-emptive migration which will prevent sub-projects from reaching their maximum. If anyone has good ideas we would like to hear from them.
Will we have to specify a number of AUs or resource units for a job in MVS?
Reply: No, the job will be terminated on a maximum time specification as at present. The AUs used will be deducted from the total allocation which may go negative in any period.
Given that a dataset is allocated to a subaccount, can it only be used by that subaccount.
Reply: A sub-project manager can give access to any individual by including his USERID in the rules set for that dataset. You can give different types of access (READ, WRITE, etc) to each individual. There is also a universal access code in the rules set which defines the type of access which applies to anyone whose USERID is not included in the rules-set.
Can you lose some of your MVS allocation if you underspend early on in the year.
Reply: Computers actually deliver a fixed amount of resource each week (to a first approximation). Therefore you can only allow a user to move his activity forwards or backwards in time if there is another user who wants to move an equal amount of resource in the other direction. With a large population you hope that if everyone does what they want the net result will be a zero movement of demand . If there is a net movement of demand in one direction this may result in the machine being overloaded. Therefore we have to limit the amounts of resource that can be moved. If you underspend too much early in the year you may not be able to recover it all.
TDMS uses the MVT identifier at present. Do you intend to change this in MVS?
Reply: Under MVS the format of the user's identifier will change from that used under MVT. The MVS identifier will be the same as the CMS userid where one exists, or will be allocated by the same mechanism. TDMS will use the MVS identifier to maintain a record of ownership of a volume. Ownership of existing volumes will be altered, where possible, from the MVT identifier to the corresponding MVS identifier.
How can you get a list of MVS datasets belonging to a particular identifier.
Reply: The ASM2 package which will be used for data management has powerful facilities for managing datasets and listing information about them. Datasets are selected by specifying strings to match against part or parts of the dataset name, in much the same way as you can select groups of files with the LISTFILE command in CMS
.With reference to job failures, how do we know if a job has run on the Atlas 10? What other information should be sent to PAO?
Reply: The HASP log at the start of the job output tells you which initiator the job ran on. This with the date and time at which the job ran can identify which machine was used. Another example of where users can help PAO to help them is a job with tape problems. The drive on which the tape was mounted is recorded in the HASP log. This information should be reported.
Can the VM reference manual be updated?
Reply: We are working on this. The reference manual is largely a listing of HELP files. It is necessary to get many RAL produced HELP files into a standard format to make them suitable for inclusion. This is going ahead with the assistance of several users who have volunteered to help out with what is a very labour intensive task.
What can users do in MVT that makes use of privileged instructions and hence slows down programs on the Atlas 10?
Reply: The Atlas 10 is a 15 MIP processor and has been benchmarked as such with an average workload. Program which use mainly floating point instructions will run faster than the average and those which use mainly privileged instructions will run slower. The latter are programs which make a lot of supervisor call and in particular, programs which do a lot of input or output to peripheral devices such as disks and tapes.
Is there any convention for what goes after the node name for datasets on UNIT=STORAGE?
Reply: No, the node name in MVT, and sub-project in MVS will identify the dataset well enough to enable it to be related to a project manager who has direct responsibility for the datasets created by that project. However if the project manager wishes to identify users within a project he may find it helpful if the userid is included in the dataset name. This will not however be enforced.
How will the new FTP workstation system cope with multiple printers.
Reply: When NIFTP looks up the destination in its table, the look-up is based on a primary and a secondary name. We have thus built in the possibility of routing output to specific secondary devices. We have not as yet had time to establish whether this is a fully viable scheme. Re-routing of output to a secondary device will for instance probably not be possible.
We can issue HASP commands from RLIA at present. Will this facility disappear with Electric?
Reply: No. This facility depends on MAST and will only disappear when MVT goes.
Is there a FAST way of printing a RDR file without RECEiving it and then VPRINTing the received file?
Reply: There is nothing easily available at present though we are planning to extend VPRINT to do this. You can do it by hand if you retag the reader file (if it is to go via VNET) and CP TRANSFER it to VNET's reader (or the system printer if not a VNET workstation).
Will there be an equivalent of JOBSTAT for MVS?
Reply: Details have yet to be established. Status facilities are likely to be provided as far as possible using IBM-provided hooks. In the long term, JTMP should provide a satisfactory built-in status-modify system. The strong desire of a number of users to have a 'history' file was noted, but to produce new facilities of this kind would require a lot of manpower, so it is difficult to see how this could be done. The only existing facility fulfilling this kind of function is of course JOBSTAT, but we are unwilling to devote further major effort in that direction.