PNX is ICL's implementation of the UNIX multi tasking operating system developed by Bell Laboratories. PNX is based on UNIX System III, the latest version of UNIX. The first release implements the majority of the tools of version 7 UNIX, which is a subset of System III.
PNX involves:
ICL PNX is available to all PERQ users from March 1983. and will run on any PERQ system with a minimum 512 Kbytes of memory.
This implementation of UNIX on PERQ is one of the first results of the collaboration between ICL and SERC.
We have recently discovered that some users are still using the first edition of this manual, dated March 80, as their main source of information about CMS. This is now seriously out of date, and could mislead. Please destroy any copies of this edition that you still have available. The current recommended edition of this manual (Second Edition dated February 1981 : RL-80-008) will be revised shortly (we hope to release a new edition in June 83). As this edition does not contain references to some of the more recent additions to CMS a cover note is available which briefly lists those topics of which new users should be aware. A copy of this cover note is enclosed with FORUM and will be distributed to all new users of CMS. Additional copies can of course be obtained from the Documentation Officer (ext 5272).
Users are reminded that the Introduction Manual should only be used to gain familiarity with CMS. They should migrate to the RAL VM Reference Manual after initial use of CMS and not retain the Introductory Manual for long periods, since it is not our intention to issue updates to this document.
We have obtained the batch monitor system offered as an Installed User Product by IBM. This system provides a facility for scheduling and monitoring batch jobs in a VM/CMS environment. It is controlled by a supervising virtual machine, which dispatches and monitors other virtual machines to run the jobs. Commands are provided to submit or stop jobs and obtain status information.
The batch monitor can hold status information on many jobs at once including history records of previous jobs. A time window may be specified in which the job is to run, and one job can be submitted conditionally on the completion of another. This is done by making the job exec running in the batch machine submit the next one if it completes successfully. Job steps may be recorded by including the appropriate statements in the job exec - the job step reached will be reported in the reply to a status enquiry, and if the system were to restart the exec would continue from the step it had reached. Otherwise, on restart, jobs that were running at the time are restarted from the beginning.
The system allows for several classes of jobs to be defined by the installation depending on limits of cpu seconds, print and punch records and time windows. The batch server machines will be defined such that they can cope with jobs of one or more classes. Users specify the class required for their jobs when submitting them, and may change the limits for resource parameters by giving them on the command line. Other parameters that may be specified are a job name, the time window that a job may run in, the account number to be charged, and the priority, the current job has over other jobs submitted by the same person.
The charge factor applicable to jobs run in the batch machines has not been decided, but will certainly be less than the normal charge for CMS. It may also be possible at some point in the future to allow tape access from one of the job classes. The batch system should be available soon after Easter.
The Special Interest Group on Tools for Interactive Programs aims to provide standard software to the Engineering Research Community to reduce duplicated effort and improve the user interface. This software should be easy to understand and straightforward to use.
One of the areas that has been identified as requiring standard software is command input.
Three levels of facility were felt necessary:
Unfortunately inline editing is impracticable to offer over the multi-user mini network as it requires a character by character involvement from the operating systems. A simple decoder is being provided by DCODLEB; a library of subroutines that are used in a number of programs at RAL. The GILT Command Processor has been chosen to fulfil the role of table driven parser.
The GILT command processor is a software tool produced by CADC that enables the writer of FORTRAN application programs to provide a consistent user interface.
There are two distinct parts to the system:
The designer of the application program defines the structure of his command language in terms of a state transition graph (Figure 1) which is translated into tabular form by the GILT (Graphical Input Language Translator) program.
| ¦ | -LINE- | ¦¦ | ||||||||||||
| ¦ | -MOVE- | ¦¦ | -TO- | ¦¦ | ||||||||||
| ¦¦ | -BY- | ¦¦ | -X- | ¦¦ | -val- | ¦¦ | -Y- | ¦¦ | -val- | ¦¦ | ||||
| ¦¦ | ¦¦ | ---------- | ¦¦ | |||||||||||
| ¦¦ | ¦¦ | |||||||||||||
| ¦¦ | -Y- | ¦¦ | -val- | ¦¦ | -X- | ¦¦ | -val- | ¦¦ | ||||||
| ¦¦ | ---------- | ¦¦ | -n1- | ¦ | ||||||||||
In the application program (Figure 2), the tables produced by GILT are used by the Command Processor Subroutines to perform the lexical and syntactic analysis on the commands input by the user. The analysis is performed by identifying 'atoms' conforming to simple or complex lexical rules and fitting these atoms into the graph defined syntax. If the user command passes this analysis then the appropriate pieces of application code are called to execute it.
The command processor offers several application independent advantages to the user of the application program:
The command processor also enables the user to access any information, that has been provided by the application designer, to help him use the program.
The state transition graph representation is a flexible way in which to define the syntax of a command language. GILT allows loops, subgraphs and recursion in the language definition.
The designer is encouraged to use the top down approach using sensibly named subgraphs which may then be further subdivided and defined from the bottom up or recursively. The definition of the command language in this way is beneficial to the organisation of the application code, which should reflect the subgraph modular structure in its design .
The use of the command processor has two major benefits. It performs the lexical and syntactic checking, therefore freeing the application program from this task. Secondly, the separation of command processing and application code by a well defined interface allows different user interfaces to be tried without effecting the application code.
Trace facilities are provided which can be switched on and off through the command processor to simplify debugging of the application program.
A single manual contains the description of the GILT Command Processor from both the application designers and the end users standpoints. This manual will be available at each of the MUM sites where the software is mounted and additional copies will be available for grant holders. The transition graph itself is a useful aid to the inexperienced user of an application system. It provides him with a pictorial representation of the commands that are available and what information is necessary to execute them.
For example, an application might require the input of a pair of coordinates. This could be described by the following subgraph:
| coord | ¦ | - | ¦¦ | - X - | ¦¦ | - val - | ¦¦ | - Y - | ¦¦ | - val - | ¦ | |
| ¦¦ | ¦¦ | -------------- | ¦ | |||||||||
| ¦¦ | ||||||||||||
| ¦¦ | - Y - | ¦¦ | - val - | ¦¦ | - X - | ¦¦ | - val - | ¦ | ||||
| ¦¦ | -------------- | ¦ | ||||||||||
This can be read by the user as every time a coordinate pair is required he may type any of the following:
X 10.9 Y 13.2 Y 13.2 X 10.9 X 3.5 Y 22.4
in the last two cases the default values that will be used will be dependent on the application code.
If you would like further details about GILT or you feel you have a requirement for software that would be covered by the Special Interest Group, please contact Dave Porritt on EYIN11 (FLPB or RLGB).
One of the new standardised protocols to be produced has been the electronic MAIL protocol. Using this protocol text may be sent transparently between users of different machines. Normally it will only be available to machines connected to an X.25 network (eg SERCNET) and running a File Transfer Program. The MAIL protocol has been fully implemented on SERC GEC machines, and implementations are being worked on for a number of other types, eg PRIMES, IBM, VAX, DEC-10. The MAIL protocol will be replacing the older POST and LPOST systems which have been available in the past.
The MAIL protocol offers the user many advantages over the Post systems. MAIL may inherently have more than one destination. Copies may be sent to a third party or parties. Users are usually identified by their real name rather than the combination of characters which comprise the machine Userid. If a message is not delivered it is returned to the sender with the reason for failure. Finally, a very large community are implementing the MAIL protocols in the UK and further abroad. The protocols are very similar to the DARPA protocols in the USA and mail can be sent to the USA via the ARPAnet gateway at UCL, or to the British Wide Area Network via PSS where authorisation to use these facilities is approved. It is not yet clear how many IPSS hosts support MAIL.
The MAIL implementation for the GECs is written as a replacement for the POST and LPOST programs which will eventually be withdrawn from use. Under OS'4000 the MAIL command is used to send, receive and store messages. The implementation is based on the EMAS mail command and is a very flexible piece of software. The OS4000 Mail manual fully documents this command, but for simple use of MAIL the whole document need not be read.
The MAIL program is invoked by typing MAIL
The program will load any new messages into its files and then display a one line summary of each message on the terminal. The user can then list any message, reply to it, forward it, delete it or keep it. A new message is sent by first Composing a draft message and then Sending the draft. A copy of the message is normally filed when a message is sent. When Composing a message, MAIL has facilities to include files in the text, justify the text between margins and is also able to run an editor on the draft message should corrections be necessary.
Simple use of MAIL is made in the following example session. It consists of listing a message, replying to it and sending some mail. Text typed-in to the MAIL program is underlined.
MAIL
Mail Vn 2
3 messages, 1 unseen in folder DEFAULT
1 new message
n 3<= (7)11 Jun Ken May W.P.M.
<RETURN> to list message
Mail:<RETURN>
(Message number 3)
From: Ken May (on GEC 4090 at Bristol) %lt;KM@BRGA>
To: Peter Walker
Date: Friday, 11 June 1982 12:12-BST
Subject: W.P.M.
Message-id: <11 JUN 82 14:12:56 KM@BRGA>
The next Working Party Meeting is tomorrow, but Fred hasn't yet sent me the agenda.
He has promised to computer-mail them to me as soon aa they are ready.
Please inform your people.
Ken
Mail: REPLY
Replying to Ken May <KM@BRGA>
Text:
:Yes I'll certainly forward it. Thanks for keeping me in touch with developments.
?Z
Send now? YES
Message sent and filed
Mail:COMPOSE CC:
To: John Doe
Cc: Dave Glotz, Geoff Davey@SNGA
Subject: Working Partly Agenda
Text:
: Ken just sent me a missive saying that Fred is
: late with the agenda but will send it to me
: a.s.a.p and I will forward you a copy.
: Pete
::?Z
Send now? YES
Message sent and filed
Mail:END
Ready
MAIL has an extensive set of selection criteria for looking-up old messages stored in a folder (a folder is a file of messages) . These include searching by status (eg new, old or deleted messages), position (eg last, first ten, next six) or content (eg from="User Support", before="10/2/82").
OS4000 MAIL has facilities for supporting mail distribution lists and printing of incoming MAIL on a paper medium. Users may set up their own private directories for outgoing mail to provide mailing lists, aliases (nick-names) or to hold entries with their PSS password. If a PSS password is placed in this directory it does not appear on the message that is sent to the recipient. It is possible to specify that a PSS MAIL message is "reply-paid"; this is documented in the PSS gateway guide, written by A.S.Dunn and available from RAL.
It is planned to relocate the CRAY-1S currently at SERC Daresbury Laboratory at ULCC about Easter 1983. The exact date depends upon several factors, the most important of which are the completion date of the ULCC building extension (planned to be during March) and the successful linking and testing of the SERC network into the ULCC new telecommunications system.
The Amdahl 470/V8 computer at ULCC will be used to support the Cray. The operating system on the 470/V8 is MVS and the user interface is IBM JCL, TSO and a portable subset of the University of Cambridge PHOENIX. The disc space available for all user data sets (including ULCC supported data sets) will be approximately 10,000 Megabytes on the 470/V8, once the full configuration of discs have been installed (planned for Easter 1983), and approximately 1000 Megabytes on the Cray. It should be noted that the ULCC does not support private disc pack facilities. It is expected that an archiving facility will be available on the 470/V8 by early summer of this year.
The Amdahl 470/V8 was sized to support about 120 concurrent keyboard terminal sessions to be used principally for file editing and job submission, and intended for those user sites without interactive services and remote batch submission facilities of their own. In the initial months of the service based upon the new telecommunications protocols, it is expected that the number of concurrent keyboard terminal sessions will be limited to about 50. Users should as far as is possible use the remote job entry facilities available at their University to submit jobs to ULCC.
Users who have an allocation of disc space on the 470/V8 and/or Cray must not exceed their allocations. Although a disc space control system based upon that in use at the University of Cambridge will be installed on both systems in the near future, the initial control will be one of purging data sets if allocation is exceeded. Users are responsible for keeping backup copies of their disc data sets, (on magnetic tape) so that they can recreate their disc data sets if these are accidentally lost or corrupted. Although ULCC endeavours not to lose data sets, the Centre cannot and does not accept responsibility for the loss of data sets and gives no guarantees to reinstate data sets.
The user interface to the systems at ULCC will differ in some respects from that in use in the Daresbury Laboratory.
The user identifier or user registration number in use throughout the University of London computer services consists of seven alphanumeric characters. In general the identifier reflects the institutional and departmental affiliation of the user. The identifier is used on the JOB statement for mo/VS or Cray batch jobs, in logging into the system from a keyboard terminal, and as an identifier on disc data sets. Details will be made available in ULCC documentation on the services. When the Cray is moved to ULCC there will be about four weeks interruption in access to the Cray. This time is required to physically relocate the hardware, carry out tests to ensure that the system is satisfactory, and integrate the system with the 470/V8. The user data sets on the Cray discs will have been dumped to tape before the transfer and will be reinstated when the system is ready for use. Users should ensure that they can recreate their own data sets on the Cray discs if necessary. Users will be responsible for moving to ULCC those data sets currently kept on the NAS or on magnetic tape which they require to use on the Cray at ULCC. The ULCC tape drives will accept nine track tapes written at 1600 or 6250 bpi, either unlabelled or with standard IBM labels.
Telecommunication access to ULCC facilities is being based upon the X25 network protocol using the Job Transfer and Manipulation Protocol (JTMP) for remote job entry and 'triple-X' standards to handle interactive terminals. Protocol converters are being implemented to allow existing RJE and keyboard terminals to connect to the new facilities and so ensure a continuity of access to both old and new services.
MANAGERS' From March 28-29th at Bradford University.
SITE USERS' Monday April 11th at the Atlas Centre, RAL. Please contact Kevin Duffey, User Interface Group (ext. 6252) for details.
SERCnet is up and running. It has been for several years, and is still growing at a considerable rate. It is also evolving into a National Academic Network under the aegis of the Computer Board and the Research Councils.
SERC users have an interest in the management of SERCnet and its descendants. The right sort of basic services (interactive, file transfer, job submission, etc) and value added services (mail servers, name servers, print servers) must be provided. Quality of service must be maintained. Service levels must be acceptable.
This article shows how the SERCnet is managed and how it relates to the wider network which is evolving. We hope to publish further articles on other aspects of SERCnet.
The following figure shows the principle bodies involved in the management of SERCnet. The Computing Coordinator is Dr Manning, Director RAL.
The main committee is the SERC Network Management Committee. Its current list of members is shown below:
| P S Kummer | DL (Chairman) |
| P M Girard | RAL |
| D G House | RAL |
| P E Bryant | RAL |
| M R Jane | RAL |
| E Owen | DL |
| B J Charles | JNT |
Its terms of reference are as follows:
It will advise the Computing Coordinator on the management, operation and development of the SERC service computer network within the overall financial and policy guidelines established by Council and its Central Computing Committee. Specifically the SNMC will:-
The SERC service computer network is defined to consist of:
where these arrangements are intended to provide a service to users. Most users are likely to be familiar with some aspect of a but in the next few years b and c will be major growth areas.
The service network does not include any arrangements specifically intended for network research.
The subcommittees of SNMC are listed below together with their terms of reference.
| P M Girard | RAL |
| R T Braden | UCL |
| P E Bryant | RAL |
| B J Charles | JNT |
| A S Dunn | RAL |
| K Farvis | Edinburgh |
| P S Kummer | DL |
| V Pucknell | DL |
| J D Service | York |
| A Voss | NERC |
Terms of Reference
| P E Bryant | RAL |
| P J S Gladstone | RAL |
| C S Cooper | RAL |
| B V McNally | ROE |
| W P Sharpe | RAL-DCS |
| R Tasker | DL |
| N Parker | RGO |
| M W Johnstone | SNS |
| W Pulford | SNS |
| E Owen | DL |
Terms of Reference
| D G House | RAL (Chairman) |
| C Balderston | RAL (Joint Secretary) |
| P M Girard | RAL |
| R E Thomas | RAL |
| M R Jane | RAL |
| R Cooper | RAL |
| I L Smith | DL(Joint Secretary) |
| P S Kummer | DL |
| H Sherman | DL |
| J Hopkins | DL |
| G Petmezas | DL |
Terms of Reference
The current network manager is Cyril Balderson,. Computing Division, RAL. He and his team are responsible to the SNOSC for the management of the operation of the SERC service computer network according to the policy laid down by the SNMC. In particular, he should:-
The network quality assurance manager is Ian Smith, Computing and Electronics Division, DL. He and his team are responsible to the SNOSC for the maintenance of the quality of network components according to the policy laid down by the SNMC. In particular, he should :-
SERC/CREST-ITG Advanced Course, Corpus Christi College, Cambridge 11-22 July 1983
Course Director: Dr F Fallsade (Univ of Cambridge)
This residential course forms part of the SERC/CREST initiative in information engineering. It takes a broad, cross-disciplinary view of the subject, ranging from phonetics, psycholinguistics, computational linguistics and language processing for speech understanding to speech analysis, speech recognition and speech synthesis. A major item of the course is to form links between the first more abstract group and the second more applied group of topics.
It is aimed at research workers in speech science both in the academic and industrial sectors. This rapidly growing area has been picked out as a major component of advanced information technology by the Alvey and SERC initiatives in the UK, by ESPRIT in Europe and by the Japanese Fifth Generation Computer System programme.
The main lecture courses will be given by:
Single Lecture speakers will include:
There will also be a series of after-dinner speakers from government, industry and the academic sector.
Grants will be available for SERC and CREST supported research students to cover the whole cost of the course and for university research workers and younger academics to cover the course fee.
The course fee is £370 and the standard accommodation fee is £232 (excluding 16-17 July) or £275 (including 16-17 July). There is no VAT charge.
Further information and registration forms from Mrs M Barber, Cambridge University Engineering Department, Trumpington Street, Cambridge CB2 1PZ, Tel (0223) 66466.
The job turnround guidelines were last revised in 1977. Since then the 195s have been replaced by the 3081, we are running VM, and the short job time limit has been increased from 90 seconds to 5 minutes. We have therefore decided to review the guidelines and relate them to the changed store boundaries. Remember that the aim is to turn round 901 of jobs within the guidelines. The new guidelines are:
SHORT JOBS - NON-SETUP
| MEMORY SIZE | P12 | P10 | P8 | P6 | P4 |
|---|---|---|---|---|---|
| 0-210K | 15 min | 1 hr | 2 hr | overnight | weekend |
| 212K-560K | 15 min | 1 hr | 3 hr | overnight | weekend |
| 562K-1.5M | - | 1 hr | 3 hr | overnight | weekend |
| 1.5M-3.5M | - | overnight | overnight | weekend |
SHORT JOBS - SETUP
| MEMORY SIZE | P10 | P8 | P6 | P4 |
|---|---|---|---|---|
| 0-210K | 1 hr | 2 hr | overnight | weekend |
| 212K-560K | 2 hr | 3 hr | overnight | weekend |
| 562K-1.5M | 2 hr | 3 hr | overnight | weekend |
| 1.5M-3.5M | overnight | overnight | overnight | weekend |
LONG JOBS (>5 MINUTES CPU)
Priority ≥6 overnight
Priority = 4 weekend
There is no guideline for turnround of priority 1 jobs.
Turnround will be closely monitored and the guidelines reviewed if they are not being met. The guidelines will probably be reconsidered when the Atlas 10 is introduced.
The third stage in the rationalisation of routines common to RHELIB and CERNLIB has been implemented. The routines HZERO, UBLANK and UFILL in SYS1.CERNLIB arid KERNLIB TXTLIB have been modified so that they issue an error message and cause a user abend (code 333) if they are called with 2, 2 or 3 arguments respectively.
The Introduction to CMS Manual (Second Edition) is currently being revised. This note briefly guides new users to facilities that are at present not described in the manual but of which they should be aware.
You are recommended to skip Chapter 5 of the manual as a new facility called XPLANT is now available to provide very powerful generation and parameterisation facilities. This can be used to create files of JCL, Fortran, etc, with contents controllable by the user and is equivalent to the ELECTRIC edit system. Details of this facility can be found via HELP XPLANT MENU and by invoking the XPLANTDC EXEC which will provide a lineprinter copy of the current XPLANT documentation.
The EXECs VPRINT and VPUNCH should be used for printing/punching CMS files at either VNET or HASP controlled workstations (the direct use of NPRINT/NPUNCH is not required for this task).
The default PROFILE EXEC now invokes a file called STANPROF EXEC R which new users should examine to see what commands are invoked automatically for them.
Job output from MVT jobs submitted from CMS is routed by default to the virtual reader of your machine (see HELP ROUTING and HELP VROUTE to change the default).
A facility is available to generate utility jobs (like TPCOPY, XTAPE etc) and submit them to MVT (see HELP OSUTIL MENU).
The VS Fortran, VS Pascal and VS Cobol Compilers are available in CMS (HELP FORTVS, NEWS FORTRAN, HELP PASCALVS, HELP COBOL).
The Fortran H Extended Plus compiler has been replaced by the Fortran H Extended compiler.
A CMS equivalent of the MVT Freedisk facility is available (HELP FREEDA MENU).
CMS files can be archived (HELP ARCHIVE).
User supplied files (non-RAL CD supported) are available via the UDISK (HELP UDISK).
The WHOIS facility allows you to locate user identifiers/surnames.
Several XEDIT macros are available to help users, particularly those using ASCII terminals (HELP EDIT TP, HELP XEDIT TC, HELP XEDIT TL).
Other XEDIT Macros available include CAPPEND, TCURSLAST. DELWORD, AFTER, BEFORE, GROUP, PAR, SCL, DELETE, PARSE, SELECT, SPJ, UNDER, XX, YY (see relevant HELP XEDIT topic or HELP XEDIT HELP).
A set of EXECs is available to simulate the function of the ++H commands which keep track of batch jobs (HELP HCANC, HELP HLIST, HELP HRATI, HELP HRESE, HELP HROUT and HELP HSTAT).
Jobs producing graphical output may be run interactively in CMS. Graphics output can be sent to the FF80 without using an MVT batch job (HELP GRAPHICS and HELP GRAPHICS MENU). Fiche, microfilm and graphical hardcopy can be produced on the FR80 from CMS files (HELP NFLIST).
A new MAIL facility is available (see HELP NOTE, HELP NAMES, HELP NOTEBOOK, HELP NAMEFIND. HELP TELL and HELP SENDFILE).
CMSELEC can read Mugwump Graphics files (HELP CMSELEC).
The command RDRLIST will display what files are on your virtual reader.
RECEIVE will transfer these files onto your minidisks.
PEEK will display the contents of these reader files (as will BROWSE).
RDP will display the characteristics of the next file or, your virtual reader.
FILELIST will display information on a list of files.
EXECIO will execute CP commands and stack the results. It will also allow transfers between stack and file and file and stac
k.The CA/SYMBUG interactive debug package is available (HELP SYMBUG).
The CERN Libraries and Nag Library are available in CMS (HELP CERNLIB, HELP NAGLIB).
A file transfer scheme is available to send files from and to CMS (see HELP FTP and HELP FTPQ).
The RAL command SENDFILE has been renamed as GIVEFILE so that it does not clash with the IBM command SENDFILE.
A virtual machine called VNET now controls several of the IBM workstations and gradually the remaining HASP controlled workstations are being moved to VNET control (HELP VNET MENU for details of commands available to control VNET workstations).
The QBATCH command displays the jobs in CMSBATCH's queue.
Details of tapes in the TDMS database can be found via the command QVOL.
The command ABEND will provide information on MVT abend codes.
Remember that when you issue the HELP command you go into the XEDIT environment so you can make use of any XEDIT command to move around the helpfile as well as taking a copy of that file for subsequent printing.
Access to VM/CMS from the Network is now via the call !!RLIB.
From PACX the access is via CLASS CMS (which is the same as RLIB).
Files created by XEDIT and of filetype FORTRAN are serialised by default. The XEDIT command SET SERIAL OFF can be used to suppress the serialisation of Fortran files. This command can be included in a file called USERPROF XEDIT. XEDIT has its own profile file called PROFILE XEDIT and this will invoke a file called USERPROF XEDIT if present.
The current default virtual machine size is 512K and the maximum is 1Mb.
VM/SP with CMS in individual virtual machines is run on the 3081D computer; both FEM and CEM are currently on the 3081 running MVT, the BEM system runs native MVT on the 3032. The 360/195 computers have been removed from service.