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.
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.
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.
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.
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.
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.
This Group's function is to support the activities of the SERC initiatives in the Information Technology area which are coordinated by the Division.
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.
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.
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.
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.
Any new system should conform to the following general statements of policy.
The following facilities have been noted as ones where the RAL service could be improved:
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.
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:
This list has (deliberately) omitted all film recorders (like the Dunn) that are configured as terminal hardcopy devices.
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 |
|---|---|---|---|---|---|
| IBM | 3800-3 | 167 | 240 | Yes | No |
| ICL | 3051A | 70 | 240 | (Yes) | No |
| ICL | M3052A | 210 | 240 | (Yes) | No |
| Xerox | 8700 | 70 | 300 | Yes | Yes |
| Xerox | 9700 | 120 | 300 | Yes | Yes |
| Hewlett-Packard | 2680A | 45 | 180 | Yes | No |
| Datapoint | 9660 | 15-20 | 240+ | Yes | Yes |
[Duplex means printing on both sides of the paper.]
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.
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:
and in the colour area
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.
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).
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.
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.
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
OSRUN ABC
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
OSRUN ABC
In both cases any Input/Output streams needed by the modules should be defined by FILEDEF commands prior to the OSRUN command.
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
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,
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 non-re-entrant versions from SYS1.XFORTLIB.
The module can then be executed like any other MVT module as described above.
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.
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.
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.
FI RHELIB DISK RHELIB TXTLIB *
Next add the card
LIBRARY RHELIB(CPULFT)
to the end of ABC TEXT.
The Linkage editor may now be run as in (b) to produce a CMS load module.
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).
