Since the VM System Product (VM/SP) was installed earlier in the year, XEDIT has been the standard editor for use with CMS at RAL. The Waterloo editor developed by the Perkin-Elmer Corporation is not supported and XEDIT should be used in preference.
Some advantages of XEDIT are:-
a PROFILE XEDIT file, similar to PROFILE EXEC is executed at the start of every editing session if it exists and can be used to set various editor options. There is a standard XEDIT profile on the R-disk which will be invoked by default if you do not have your own.
a macro facility which utilises the EXEC2 language allows you to write your own editor sub-commands.
much improved character manipulation, including the concept of a current column pointer analogous to the current line pointer, allows easier manipulation of character strings.
XEDIT can operate on files in packed format and this allows savings in disk space.
update files can be produced and extended automatically from XEDIT. This only partially solves the stored edit problem but is a big improvement compared with the Waterloo editor.
The above features are standard but a very useful additional feature
provided at RAL is XHELP. This is an XEDIT macro which gives a very brief description of the syntax and
use of all XEDIT sub-commands and macros. It is intended as a supplement to the standard XEDIT help
facility. It is invoked by typing:
XHELP name or
XHELP SET/QUERY name
where name is the sub-command or SET/QUERY option for which help is required.
XHELP understands abbreviations and synonyms and will tell you what a synonym stands for as well as giving the help information.
If XHELP cannot find the 'name' it replies with a list of all the sub-commands and macros which have the same first two letters as 'name'. It then tries for 'SET name' and if still unsuccessful gives a list of all SET options with the same first two letters.
The following example gives an indication of the sort of information given by XHELP:-
.XH AL AL is a synonym for ALTER
ALter char1 char2 <TARGET!1<N!*!1<p!1>>>
Change a single character to another (char or hex) on one or more lines for one or more
occurrences (starting with the pth occurrence (default 1))
In the above syntax the options in angle brackets can be omitted and their defaults are always given as the last item in the group, that is, all ones in this case.
2. QUESTIONS AT CCR MEETING
Q1. What is the capacity of the computer to be attached to the central filestore? Bottlenecks
must be avoided.
Q2. What element of security will there be In the central filestore?
A2. A filestore will not be introduced unless we are convinced that the data stored in it is adequately
protected. (A R Mayhook)
Q3.Users of enhanced workstations would like to stress the importance of connection through X25.
A3. It is certainly our intention to connect X25 to the filestore. (A R Mayhook)
Q4. Will the bottleneck be in the m/c controlling the central filestore?
A1/4. The MASSTOR system we are looking at consists of data storage attached to (generally) a pair of
loosely coupled IBM compatible processors running MVS. Any size computer can be used. The smallest systems generally
used are 4341 power machines. 3031 power and 3032 power machines are available. The hyperchannel can handle up to
3 Mbytes/sec on a data path and you can have multiple data paths. You can connect several channels to the same
hyperchannel data paths. Therefore if you spend enough money there should be sufficient capacity both in data paths
and in computer power to cope with a very large data store. (A R Mayhook)
Q5. Is there any documentation on XEDIT and EXEC2?
A5. Introductory documentation on XEDIT and EXEC2 is provided in the RAL
Publication "An Introduction to CMS on the RAL Coupled System", RL-80-008. Further documentation on both programs
is provided in the RAL VM/370 User Reference Manual. Both these publications are undergoing revision to bring
them into line with the current software in use. Reference Documentation for each product is provided in the
appropriate IBM Manual. The distribution policy with regard to RAL and manufacturer produced documentation is
set out in CIGAR Part A, Section 4, last updated 1 June 1981 and distributed with FORUM 11. (J Brown)
Q6. Regarding policy of userids on CMS, there is high changeover of personnel in quite a lot of groups.
How will you handle this? Can a user change his own id?
A6. It is quite easy for the management to change a user id or to delete a user and put in a new one.
A user cannot change his own id. (T G Pett)
Q7.Where did the definition of 'trivial' command come from?
A7.The definition of 'trivial' command as given in the VMAP manual is a command which completes before the
Q1 time-slice ends. The actual calculation of response time is more complex because an attempt is made to calculate
the response time as perceived by the user. (T G Pett)
Q8. To whom do we give the CMS registration information?
A8. Please give the information to the Program Advisory Office. (P J Hemmings)
Q9. Is it possible to have more than 100 blocks per user on the U-disk?
A9. 100 blocks is considered sufficient as a maximum for each user on the U-disk. The U-disk should
only be used for programs which are likely to be of value to a large section of users. It should not be
used for file-sharing amongst a group of users. For this it would be better to have a special minidisk
belonging to one of the users set aside for this purpose and for each member of the group to link to it. (T G Pett)
Q10.I have on occasion waited some time for a copy command to be completed. This is awkward with automatic
logout after 8 mins in a dormant state.
A10.We will make sure that people in the copy queue are not logged out. (T G Pett)
Q11. Could there be a copy Q position message when waiting for copy?
Q12. Will there be a facility to allow you to catalogue datasets with COPY TODSN from ELECTRIC?
A11/12. The possibility of doing these will be investigated and they will be implemented if only trivial
changes to the ELECTRIC program are needed. (T G Pett)
Q14. How do you manage IEHMOVE commands which have to refer to a specific volume?
A14. The IBM utility IEHMOVE should only be used where load modules are to be loaded/unloaded to magnetic
tape for export/import to other IBM installations. The Program Advisory Office should be consulted in this case.
The utility VSCOPY (Program Library Manual UT/34) should be used to copy load modules to/from tapes that are used for
backup purposes - specific volume information for catalogued disk datasets is not required with this
utility. (D F Parker)
Q16. What is the default priority during the short job experiment?
A16. Short jobs are submitted by default at priority 6.
Long jobs are submitted by default at priority 4.
This will continue to apply during the experimental change of definition.(P J Hemmings)
Q17. Will the catalogue be a distributed catalogue?
A17. Yes. Most of the 3350s accessed by the MVT system will contain a portion of the catalogue. (P J Hemmings)
Q18. When will the new rules for FREEDISK etc come
into operation?
A18. No date is available yet. Further details will be announced later. (P J Hemmings)
Q19. Is it possible to see the registration details in CMS?
A19. The command DIRM REV will cause the Directory Maintenance machine to send a copy of the directory entry
for the userid who submitted the command to that userid's virtual reader. The user will be prompted for the current
logon password to authorise the action. Details of commands that the user can send to DIRMAINT can be found with
the command DIRM ?. (D F Parker)
Q20. Does the Fortran H Ext+ Compiler have the same problems with MVT and CMS?
A20. The current problems with the test version of the Fortran H Ext+ compiler apply to both CMS and MVT.
The test version is at a later release level than the production version and will replace the production version
when these problems have been fixed and a thorough test period has been undertaken. (D F Parker)
Q21. What plans have RAL for enabling someone to read data from floppy disks produced by a micro?
A21. RAL has no plans to provide a floppy disk service by post. Instead it is assumed that the network will take
care of all the necessary data transfer. An asynchronous protocol has been designed to allow very small
minis (and micros) to transfer data to Prime or GEC Multi-user Minis. From there it is possible to transfer
files to the IBM system. Software is available for the following set of machines: DEC PDP11, RT11
and RSX/11M, MOTOROLA M6800 (under FLEX), INTEL 8080 and Z80 (under CP/M) and ALPHA 16. (R E Thomas)
Q22/23. Is it possible to improve the NETSTAT message when the machine is down? Can the network status machine
contain messages like 'unusable until 10.30'? Could the ELECTRIC login information also go in to the status machine?
A22/23. We are currently providing the operators with a terminal connected to PACX and making some small software
changes to make it easy for operators to update NETSTAT. We will then ensure that the type of information provided is
improved and that a review time is quoted in each message. (P C Thompson)
Q24. Are 1600 bpi tape drives to be phased out?
A24. It is not our intention to phase out 1600 bpi tapes. The reason we encourage the use of 6250 bpi
is that that they will store 4x1600 bpi tapes worth. Therefore our physical storage space can be reduced. Will
every user examine his/her tape holding and return to the Magnetic Tape Librarian any tapes no longer
required. Please be hard on yourselves! (D G House)
Q32. Why did you run the benchmark on a single processor 3081?
A32. The IBM 3081 on which trial runs have been made had only recently been installed. These runs had no formal
status. (J Brown)
Q33. Did you say a manufacturer only offered 20 minutes for a benchmark run? Why not 12 hours?
A33. At least one manufacturer has indicated that a representative benchmark such as we are supplying
should be run at least 3 times consecutively to overcome end effects when measuring throughput. It would not be
reasonable to ask manufacturers to run a very long benchmark (say 12 hours) in this way. A total CPU
time of 20 - 60 minutes will probably be sufficiently long to test throughput. (J Brown)
Q34. Your largest program in testbatch is 400k. What is the impact of running larger jobs on a virtual machine?
A34. We have made changes to some of the benchmark programs to increase their size up to 1 Mbyte.
It should be noted that less than 3% of jobs use more than 560k. (J Brown)
Q36. Will old-fashioned workstations be able to connect to VNET?
A36. Yes. All systems which operate a standard HASP multileaving communications protocol will be able to communicate
with VNET with no change to their system. Operators will need to issue different commands sometimes to achieve
similar results but this is a matter of training and documentation which will be supplied at the time of
conversion. (C Balderson)
Q37. Will there be access to ELECTRIC from a VNET workstation?
A37. Initially this will only be possible for networked workstations where the terminals are handled as discrete
logical calls, independent of the HASP connection. In the near future it will be possible to support ELECTRIC calls
from the additional consoles on the VNET workstations which are not networked. Workstations which are not networked
will therefore not be put on VNET until this is possible. (C Balderson)
Q38. Can the Network be made to recognise names like CMS?
A38. Yes, this is possible but we are reluctant to do so. While ELECTRIC has remained an unique service name,
it is likely that CMS will not be. We prefer to use a network name for a service based on the Host machine.
The official name for access to RAL's CMS service is RLIBI indicating Rutherford Lab IBMB
machine Interactive communication, when access is via the VMNCP machine. Access via DKNCP in the MVT front
end is on service RLIAC. (C Balderson)
Q39. Will there be access to CMS from CERN?
A39.There is access to CMS from CERN on !!RLIAC.
(C Balderson)
3. INDEX
List of articles in FORUM 10,11,12,13,14
10.1 Introduction
10.2 Central Computing Hardware
10.3 Central Computing Software
10.4 VNET
10.5 ELECTRIC/CMS Status
10.6 Turnaround guidelines
10.7 Meetings and courses
11.1 Meeting notes of CCR meeting, Jan 81
11.2 Questions raised at CCR meeting
11.3 Attendance at CCR meeting
11.4 Report of the CRWP
11.5 The Mark 8 Fortran Library
11.6 Central Computer Scheduled Downtime
11.7 INDEX of articles in FORUM 6, 7, 8, 9
12.1 Introduction
12.2 Graphics under VM/CMS
12.3 Introduction of CMS service
12.4 Use of subroutine arguments in Fortran programs
12.5 Allocation and control of ELECTRIC
12.6 VLSI Conference
12.7 SIGCE report
12.8 Guidelines for quality of service CMS and ELECTRIC
12.9 Date of CCR meeting, 13/7/81
13.1 The 'SERC-NERC' networks
13.2 GENSTAT newsletter
13.3 CAD 82
13.4 Compeda's DRAGON
13.5 Jiffy bags
13.6 Upgraded sites meeting, 4/6/81
13.7 CMS-UDISK, Users command list
13.8 Hitch hiker's guide to SRCNET
13.9 Interactive computer graphics course, Sept 81
13.10 IBM computer usage
14.1 Meeting notes of CCR meeting, 13/7/81
14.3 Computer statistics
4. CORRECTION TO RAL COMPUTER NEWSLETTER 9/81
There was an omission in the CMS section 1.2 of the newsletter. This section should read as follows:
The CMS command AUS, which is available now, gives allocation details.
AUS usage of AUs during the current session
since the last time boundary
AUS RATION monthly allocation, AUs left and
grant-end date (grant holders only)
AUS CF current charge factor
AUS ALL current usage, charge factor and monthly allocation
6. NETWORK HELP
The information in the paragraph under this heading on page 3 of FORUM 14 was slightly misleading and a clarification is now offered.
There is a process called STATUS which is accessible over the network. It contains information on many machines linked to the network. On receiving a call from the user the STATUS process requests an option. There are several options available but the most useful may be:
STATE gives the state of all machines
polled by the STATUS process
(up, down etc)
STATE site mnemonic gives details of an individual site
HELP NETWORK gives details of computers and facilities on the SERC network
HELP MUMS gives information on all GEC sites
INFO gives general information about
forthcoming events which will
affect the Network. This is
not updated by an automatic
process but by operations staff
To access the STATUS machine login as follows:
from SERC DECnetwork SET HOST GRETNA CALL STAT2
from Prime (attached to SERC network) LOGIN -ON STATUS
from Networked Workstations !11.333
from GEC MUMs !!STATUS
on RAL site PACX services 70,71,72 go to Primes, PACX service 67 goes to GEC
7. CMS COURSES
Courses to assist users in converting to CMS (Conversational Monitor System) are held regularly at the Rutherford and Appleton Laboratories and occasionally (where demand warrants it) at external sites. These courses are of one days duration. They should enable a user to gain an insight into the Virtual Machine concept and make use of CMS for editing and running of jobs etc.
Any existing ELECTRIC user who has access to CMS (see FORUM 12.3) and who would like to attend such a course should contact Dave Parker of User Interface Group (ELECTRIC id=AT or Tel. ext 6456).
