Jump Over Left Menu
No 35 May 1983
Forum 21-41 Banner
- 1. CONTENTS
- 2. ICL ATLAS 10 INSTALLED
- 3. NEW DIVISIONAL STRUCTURE
- 4. FR80 REPLACEMENT PROGRAMME
- 5. REMINDER TO ALL ELECTRIC USERS
- 6. EMACS SCREEN EDITOR ON PRIME
- 7. QUESTIONS RAISED AT CCR MEETING 22/3/83
- 8. OSRUN
- 9. DIARY
2. ICL ATLAS 10 INSTALLED
The Atlas 10 was delivered on schedule on Tuesday 26 April 1983- The machine was powered on for the first time the next day and by Friday 29 April the installation tests had been completed and the first operating tests begun.
ICL/Fujitsu Atlas 10 Acceptance, Doug House Accepts Frank Walker (ICL) looks on
ICL/Fujitsu Atlas 10 Acceptance, Tim Pett (nearest)
ICL/Fujitsu Atlas 10 Acceptance, Bob Hopgood
ICL/Fujitsu Atlas 10 Acceptance
The Atlas 10 was formally accepted on Saturday 30 April and the first part of the performance acceptance tests was run the following day. This involved running the RAL benchmark suite of jobs under MVS and was completed successfully. Since then software validation has been taking place, mainly testing MVT and MVS under a VM system. Production work was run on the Atlas 10 for the first time on Thursday 12 May when the back-end MVT BEM system was run under VM from 13.00-17.30 hrs. No major problems were encountered but severe I/O contention was seen on the BEM system disk. Because of this it was difficult to keep the CPU busy! This problem will be tackled before the Atlas 10 goes fully into production.
Time on the Atlas 10 is shared between RAL and ICL until the handover on 1 September. It is intended that a limited production service will be started by 1 June. Further details will appear in the next issue.
T G Pett - Computer Services Group
3. NEW DIVISIONAL STRUCTURE
The Computing Division will be increasing in size to 190 in the next year (the in post figure is 170 at the moment) , The current four-Group structure would be difficult to manage with a Division that size and consequently a new six-Group structure came into force on 1 May 1983.
Computer Services Group - D G House
This Group will be responsible for all aspects of running and maintaining the production services on all mature and established mainframe and mini systems including peripherals and offline production devices.
User Support Group - MR Jane
This Group will be responsible for providing help to the users of the systems supported by the Computer Services Group and making the Division aware of users' requirements and problems. It is responsible for public relations, general and user education in the Division. It is also responsible for the contractual dealings with remote sites.
Applied Programming Group - R Taylor
This Group's aim will be to enable the problem-solving programmer to work at a higher level than the systems provided by the Computer Services Group. This includes the provision of machine independent libraries and packages particularly in the database and graphics area. Contract work at the application level is the responsibility of this Group.
Informatics Coordination Group - R W Witty
This Group's function is to support the activities of the SERC initiatives in the Information Technology area which are coordinated by the Division.
Systems Development Group - C J Pavelin
This Group will be responsible for the longer term developments of standard computer services offered by the Division. In particular, it is responsible for the Division's strategy in the Computer Services area.
Office Automation and Unix Group - RE Thomas
This Group will be responsible for the promotion end support of Office Automation activities in the Division and developing a Unix service on suitable systems with the emphasis on supporting applications software in the text processing and automated documentation areas.
Common Base Project - K Robinson
This project will run outside the Group structure for the time being. The project is to develop a stable service on single user systems according to SERC's Common Base Policy.
F R A Hopgood - Division Head
4. FR80 REPLACEMENT PROGRAMME
The current FR80 film recorder is coming to the end of its economic operational life: this document indicates some general policy statements about how it should be replaced and outlines the types of device that are seen as suitable.
In particular, we think that it would be sensible to separate production of hardcopy and microfiche from the production of film, since film will always require operator effort whereas hardcopy and microfiche can be produced unattended.
We therefore anticipate that our requirement will be satisfied by two or three independent devices, and each of these should be online to the SERC computer system. We consider it desirable that the complete graphics output subsystem is handled by a controlling computer. This should connect to the main network with an adequately fast connection and should be the only repository for control and accounting of the actual output devices.
General Policy Statements
Any new system should conform to the following general statements of policy.
- The complete system should continue to provide the same range of functions as is available at present and to deal with the projected workload.
- Any new peripherals should normally be operated online to avoid special procedures on the main system and to reduce operator intervention.
- Appropriate technologies should be used that allow operator involvement in film processing to be reduced.
- Replacement systems that reduce turnaround times will be preferred.
- Reduction of recurrent costs - both those incurred as maintenance charges and those of consumables - will be a major consideration.
- Facilities, other than those currently provided, should, if possible, address those listed in the section on Additional Facilities below.
- Reduction of the effort RAL has to provide to support manufacturers' software will be a major consideration - preference will therefore be given to devices running manufacturer supplied and supported software.
The following facilities have been noted as ones where the RAL service could be improved:
- facilities for output of raster images to film, hardcopy and microfiche;
- access to facilities for high quality text output;
- greatly reduced turnaround times;
- support of full-frame 35mm output.
The quantity of film and microfiche is expected to increase steadily as a result of the additional CPU power being installed at RAL; improved turnaround and added functions could cause a further increase in load. We estimate that, after about two years, the workload would be between 2 and 3 times the current rate. Given the difficulty of making this estimate, systems that can be extended to provide greater capacity are attractive.
The quantity of hardcopy output is difficult to estimate but it is likely that the majority of the output currently sent to three IBM 1403 (1200 1pm) printers would be diverted to any non-impact system, as well as the current FR80 hardcopy load. We anticipate that the dramatic improvement in turnaround of such a printer compared with an offline film recorder would also attract users wanting multiple copies of documents.
The range of hardware available now is vastly greater than when the FR80 was bought; however, the number of comparable film recorders is still very low. In this section, we present a restricted list of the hardware that is available in the UK. The lists are split into four categories: film recorders, laser printers, fiche systems and others.
1. Film Recorders
There are now two classes of device in this area: the full facility, expensive ones and the single facility, cheaper ones. We should look at whether a battery of cheaper ones could provide a better service: with each having a dedicated camera, no camera changes would be needed and so turnaround and reliability could be improved; however, in general the cheaper devices are much slower. The devices known are:
- FR80 A - successor to FR80
- Dicomed - a range of recorders, including FR80 simulator
- Celco - a similar device to FR80
- QCR - a range of cheaper, online recorders
This list has (deliberately) omitted all film recorders (like the Dunn) that are configured as terminal hardcopy devices.
2. Laser Printers
There is now a large range of laser printers on the market: the ones that match our main requirements of connectivity, graphics and resolution are as follows:
|Make||Model||Speed (pg/min)||Resolution (per in)||Graphics||Duplex|
[Duplex means printing on both sides of the paper.]
3. Fiche Systems
The number of suppliers of online fiche systems is rather small; most of the large film recorders noted above are capable of driving lOStim fiche cameras; in addition we have discussed our requirements with:
Of these, only NCR produce a system that can be plugged into an IBM system and which will produce finished, distributable fiche without further operator action. The other suppliers produce milky master fiche which are intended for diazo copying before distribution.
As yet there is no device announced (or due to be announced) in the UK that produces graphics fiche and does its film processing inboard.
4. Other Devices
The above lists cover the main components of an FR80 that would be located centrally. In addition, we have looked at devices that would allow us to distribute some of the output production to MUMs and PERQs. In the monochrome area, this has included:
- Electrostatic printer/plotters
- Rasterizing adaptors for these
- Honeywell hardcopy devices
- Epson, Prism, Integrex dot-matrix printer/plotters
and in the colour area
- Prism and Integrex dot-matrix printer/plotters
Having completed an extensive survey of the available devices and having considered a structure for future output systems, the authors are now in the progress of producing a draft operational requirement for all aspects of the FR80 replacement programme. This leaves it up to the supplier to decide how many of the requirements are matched singly or in combination.
In parallel with this, a survey will be conducted by Computing Division of user requirements to ensure that the complete system will meet not just the projected workload but also forms of output which are not addressed by the current output facilities.
C D Osland - Applied Systems Group and P C Thompson - Computer Services Group
5. REMINDER TO ALL ELECTRIC USERS
Users are reminded that the ELECTRIC service will be closed at the end of this year. No more archiving of ELECTRIC files will be allowed after the end of June, although it will still be possible to restore files. No Account Units will be issued to users after the end of September, except by special request. The online filestore will continue to be available from CMS via CMSELEC in read-only mode. It is our aim to try to restore any files remaining on the two archive packs, so that only one ELECTRIC pack will be needed. To this end users are asked to start deleting any unwanted ELECTRIC files NOW.
ELECTRIC users who are currently not registered to use CMS (and who do not plan to transfer their activities to any of the other available interactive systems) should register as soon as possible - contact Mrs V A Walker, extension 5273. All users who still have files on ELECTRIC are asked to transfer them and delete the ELECTRIC version as soon as they can. In cases where all files below the main directory may be deleted this can be done by Computing Division staff (contact David Trew, extension 6554 or Sue Ward, extension 6553).
6. EMACS SCREEN EDITOR ON PRIME
Bowing to intense pressure from some PRIME users for a screen editor, we are ordering the PRIME EMACS editor for the RAL machines (subject to a demonstration of satisfactory support of our screen terminals). This is partly funded directly by the community supported by RAL Technology Division as the central funds available for ICF systems are very limited.
EMACS is a powerful, flexible screen editor, yet it is also easy to learn how to use. The basic commands to move the cursor or perform editing functions are sensibly named and therefore easy to remember, and a comprehensive help facility is provided. Multiple editing windows are catered for, and sophisticated language environments are available to simplify entry of FORTRAN or PL 1 programs, for example. A full programming language is supplied as part of EMACS and it is possible to write customised editing commands to perform very complicated editing tasks.
C J Pavelin - Head of Systems Development Group
7. QUESTIONS RAISED AT CCR MEETING 22/3/83
- Q1 Is there a reason why no guidelines have been given for Priority 1?
- A1 Priority 1 time is issued to enable the machine to accept work from users who have exhausted their weekly ration. Such work is only run when there is time available and therefore no guaranteed turnround can be offered. From time to time, when job queues become too long, Priority 1 rations are withdrawn. This is to prevent submission of work with little prospect of being run. (P J Hemmings)
- Q2 There is going to be a continuing need for short jobs to, say, delete MVT jobs. Would a class for very small jobs be a good idea?
- A2 We think the requirement for short jobs should be covered by the Priority 12 / 210K class. We do not wish to encourage very small jobs on such powerful processors. (P C Thompson)
- Q3 a) Has any thought been given to CMS Batch replacing MVT/MVS?
- b) Are there any figures for the relative efficiencies?
- A3 a) No. MVS will be our standard batch operating system for large scale scientific data processing. This is because it is compatible with CERN and Daresbury, it is IBM's strategic product for big systems and it is compatible with our MVT workload. However, this does not mean that the batch processes associated with our timesharing systems, including CMS, will not continue to be developed and improved. As resources become available we hope to remove many of the restrictions currently on the CMS service.
- b) No, the CMS batch service runs at low priority and is fairly limited. We will investigate when we have more experience of it. (C J Pavelin)
- Q4 Would it take more effort to develop MVS or to improve CMS?
- A4 The effort is committed to MVS, in line with the policy of remaining compatible with CERN, Daresbury, etc. and of running unmodified manufacturers' software. The amount of effort needed for each is probably comparable. (P C Thompson)
- Q5 Sometimes the need arises to move a data set from disk to tape and back again when it is needed. There is no convenient way of doing this.
- A5 The DSCOPY and VSCOPY utilities available with the OSUTIL oonmand in CMS provide a fairly simple way of transferring sequential and partitioned datasets between disk and tape. (C P Wood)
- Q6 If there were a single class, say 0-560K, then there would be a clear distinction between small core and large core jobs. Why is the distinction made between jobs of 212-560K and 560-1.5Mb when guidelines are identical? Is the division of 560K real?
- A6 The distinction is real, and is made to allow operators to fit as many jobs as posssible into our non-virtual MVT storage. (P C Thompson)
- Q7 If there were to be a Laser Printer accepting files from other points on the network, what impact would there be on Network response?
- A7 It is not known. A laser printer would only be used over the network for a special reason. It would not be offered as a general facility. (D G House)
- Q8 When considering the laser printer as a replacement for FR80 hardcopy, would both graphical and text be provided?
- A8 Most definitely: 'text only' printers are not being considered in this role. (CD Osland)
- Q9 When considering a replacement for the FR80, would any offline tape facilities be provided for external users?
- A9 Yes - although it is hoped that network access and bandwidth will have improved sufficiently by the time replacements are installed so that offline input will only rarely be necessary. (C D Osland)
- Q10 Will the Atlas 10 mean more Batch power or CMS power?
- A10 Initially, the Atlas 10 will be used to run an MVT batch system and therefore will provide more OS batch power. However, it should be possible to remove the CEM from the front-end 3081 which will provide more CPU power for CMS. The possibility of running the Atlas 10 as the front-end and 3081 as back-end will be considered in the longer term. Whether this Is done will depend on the relative demands for the use of CMS and OS batch. (T G Pett)
- Q11 Network congestion is sometimes caused by users transferring an existing file back and forth across the Network to make minor alterations to their files. Will users be trained to use the Network more efficiently?
- A11 The courses provided for new users attempt to teach good habits, and general management of data and files is one of the subjects covered. Unnecessary traffic is difficult to detect especially as there is no such thing as a network AU. Too often users are unaware that there might be easier ways of doing things and deny themselves the advice available through the Program Advisory service. (P J Hemmings)
- Q12 Are there any plans to get users to use the Network more responsibly? A great number of users transfer >20,000 lines during mid afternoon, causing excessive traffic over the network.
- A12 There are at present no plans to try to control the size of file transfers at particular times of day, as there has so far been no hard evidence that this is necessary. If users are experiencing problems, a useful first step would be to supply us with appropriate details, for instance which network routes are affected and the frequency of the problem. One possible remedy (on some routes where this is technically possible) is to allow more file transfers to proceed in parallel. (P M Girard)
- Q13 If it became necessary to choose between regulated IPLs of the ATLAS 10 or a minor disruption in the accounting, would it not be better to IPL, as timings and turnround would improve?
- A13 The intention is to run MVT under AVM on the Atlas 10 during the period in which RAL is sharing time with ICL. The BEM will be run in a virtual machine under AVM for most of the time. The only period during which ICL will have dedicated access to the Atlas 10 will be front system development on Wednesday morning to system development on Thursday evening. During this period the BEM will be run on the 3032. Consequently there should normally be only 2 IPLa per week at the system development times. (T G Pett)
- Q14 Who would prefer Computing Division to scrap the conversion from MVT to MVS altogether?
- A14 No one! (Assembled Users)
- Q15 Will there be tape access on CMS?
- A15 Yes, only for the import of data. It will be available through PAO. (P C Thompson)
- Q16 Will CPULFT have to be changed for the new Batch system in CMS?
- A16 Yes. We hope to provide a new version of CPULFT when the new Batch system goes into service. (C P Wood)
- Q17 Will ELECTRIC files be accessible after its demise?
- A17 It has been stated previously that level zero files will be accessible (in a read only mode) via CMS using the CMSELEC facility. Work is currently in hand to dispose of as many unwanted files as possible with a view to restoring archived files to level zero. (P J Hemmings)
- Q18 Were network speed measurements averaged on various days?
- A18 Yes, but not in an organised way. Measurements were taken at convenient intervals between other activities. (C Balderson)
- Q19 There seems to be a mismatch between intended facilities for networking and the amount of money being provided. Is there any need to be worried about possible lack of funding?
- A19 Certainly it is a worry: the SERC Network was never properly funded in as much as there were never earmarked funds. Finance for the unified National Network will come from the Computer Board and there will be earmarked funds with estimates and forward looks. This should bring some stability and allow more planning. (B J Charles)
- Q20 a) How is SERCNET related to the Academic Network?
- b) When will it happen?
- A20 An evolutionary approach has been adopted for the Academic Network. This means that SERCNet will evolve into providing a more general academic community service and there will be no sudden noticable change. The funding and management structures will also evolve to match the new situation. I see this taking place over the next 12 months. (B J Charles)
- Q21 Is it correct that GKS will not be implemented on the older GEC (ICF) machines, i.e. those without Fortran 77?
- A21 Yes. The decision to use Fortran 77 was taken when Unix and Vax had good compilers. Prime had a compiler that was improving, there was a good compiler for the IBM and a working compiler on GEC 4090 (March 1982). It now appears that GEC will not provide F77 on their older machines; all other F77 compilers have improved. We will be looking at the possibility of providing an F66 implementation of GKS on the GEC machines only. (C D Osland)
- Q22 I do not feel that the turnround is fast enough. Many users in HEP Division feel the same way. We would like to see most figures reduced by a factor of 3 on short jobs.
- A22 With the Atlas 10 in service and the disk system balanced you should see some improvement. (P C Thompson)
- Q23 It appears that 3.5Mb is the maximum core size available as there are no guidelines for jobs larger than this.
- A23 3.5Mb is the largest job that we can run on a 4Mb real storage MVT system. This will change with an MVS system. (P C Thompson)
- Q24 Will there be notification when disks are about to be tidied up?
- A24 No. We shall have a published policy for disk management and we shall adhere to it. (P C Thompson)
The CMS command OSRUN enables users to execute members of load module libraries. These libraries may be in CMS or MVT.
Note If an MVT load module has been linked using the re-entrant FORTRAN library (which is the default) or makes calls to certain RHELIB and CERNLIB routines then it will be necessary to use the CMS Linkage Editor to replace the relevant routines by the CMS versions.
Load Library in CMS
To execute the member ABC from XYZ LOADLIB the user should first define the LOADLIB by
GLOBAL LOADLIB XYZ
and then load and execute the member by
Load Library in MVT
To execute member ABC from ULIB.ATLAS on ULIB03, first link to the disk.
MVTDISK ULIB03 E
(Mode E is used for the purpose of these examples. Any available mode would do.)
Next define the library to CMS.
FILEDEF $SYSLIB DISK ATLAS LOADLIB E DSN ULIB.ATLAS
Then, as before, define the library as a LOADLIB
GLOBAL LOADLIB ATLAS
and then load and execute the member by
In both cases any Input/Output streams needed by the modules should be defined by FILEDEF commands prior to the OSRUN command.
ULIBS with generation datasets
Some of the larger ULIBs on the system have more than one generation dataset. CMS treats these as discrete datasets. For example, ULIB.USG consists of ULIB.USG.G0001V00 and ULIB.USG.G0002V00. If the library of interest is one of these then, unless it is known which generation dataset contains the volume, both should be defined as LOADLIBs.
FI $SYSLIB DISK A LOADLIB E DSN ULIB.USG.G0001V00 FI $SYSLIB DISK B LOADLIB E DSN ULIB.USG.G0002V00(CONCAT GLOBAL LOADLIB A B
Load modules of FORTRAN programs
By default load modules created on MVT from FORTRAN programs contain references to re-entrant versions of the FORTRAN library routines. The re-entrant code is not stored in the load module and these routines are not supported in CMS.
Such modules can be run in CMS by replacing the re-entrant Fortran Library routines by the standard Fortran Library routines. This can be done in either MVT or CMS. To help in this task a file is stored on the P-disk called FORTRAN REPLACE. This file contains the Linkage Editor control cards needed to remove all of these routines. They may be removed by,
(a) In MVT
Relinking and recreating the module with the following JCL.
//JOB //EXEC FHL,SYSLIB='SYS1.XFORTLIB', //LIBRARY='ULIB.XYZ' ,MEMBER=ABC //L.SYSIN DD * ..... cards from FORTRAN REPLACE ..... INCLUDE LIBRARY(ABC) ENTRY MAIN /*
This will replace the re-entrant routines in ULIB.XYZ(ABC) with the nonre-entrant versions from SYS1.XFORTLIB.
The module can then be executed like any other MVT module as described above.
(b) In CMS
The Linkage Editor LKED may be used to produce the same effect.
First define the MVT library and the file containing the REPLACE cards.
FI ATLAS DISK ATLAS LOADLIB E DSN ULIB.ATLAS FI REPLACE DISK FORTRAN REPLACE R
Next, define the autocall library for the replacement routines.
FI SYSLIB DISK FORTLIB TXTLIB *
Then create a TEXT file (eg ABC TEXT) for input to the linkage editor. This should contain the following cards:
INCLUDE REPLACE INCLUDE ATLAS(ABC) ENTRY MAIN
Finally run the linkage editor using the command,
LKED ABC (LIBE NEWLOAD LET
This will create a file called NEWLOAD LOADLIB which will contain a module called ABC. The LET option is to stop the load module being marked non-executable. This may be run by
GLOBAL LOADLIB NEWLOAD OSRUN ABC
as described at the beginning of this article.
Partially-resolved Load Modules
A load module created in MVT with linkage editor option NCAL will not contain routines from any of the system libraries. To run such a module in CMS, follow the instructions above for using the linkage editor in CMS but omit the INCLUDE REPLACE card in the TEXT file. Information on all of the CMS commands mentioned here is available from the CMS HELP system.
Modules containing MVT-dependent routines
Certain routines in the MVT versions of RHELIB and CERNLIB will not run in CMS (or vice versa) . Generally these are routines like CPULFT, GETDD, SERLAE and TIMEX which access system control blocks. If any of this type of routine is present in an MVT module then they should be removed and replaced by either the CMS versions or dummy routines. To remove these routines follow the instructions for the use of the Linkage Editor in (b) above with the following additions.
- In the TEXT file (eg ABC TEXT) add the relevant REPLACE statements at the beginning. (eg REPLACE CPULFT)
- replace the routines by dummy versions, compile the dummy routines and add the resultant TEXT files to ABC TEXT.
- To replace the routines by CMS versions, first. declare the relevant library to CMS.
FI RHELIB DISK RHELIB TXTLIB *
Next add the card
to the end of ABC TEXT.
The Linkage editor may now be run as in (b) to produce a CMS load module.
J C Gordon - User Support Group
From 21-22 June 1983 there will be a course at UMIST for new users of the Prime. This is only for beginners. Anyone who is interested in attending should contact Dave Lomas, Control Systems Centre, UMIST, PO Box 88, Manchester, (061-236-3311 ext 2161/2162) by 10 June.
The following courses will be held at RAL.
|IBM New Users Course||4-7 July|
|ELECTRIC/CMS Conversion Courses||29/30 June|
|Advanced CMS Course||20/21 July|
|Prime New User Course||21/22 November *|
* Please note that the course scheduled for 23/21 May will not take place.
For further information and enrolment, please contact the Program Advisory Office (0235 116111 or ext 6111) or R C G Williams (ext 6104).