RL-77-008/a
The purpose of this document is to give a general survey of the computing facilities associated with the IBM 360 model 195 computers at the Rutherford Laboratory. It has been prepared from lecture material usually presented to new and prospective users of the 195. It is assumed that such users have some familiarity with at least one other computing system. The reader will find no formal presentation in these pages. For such he should refer to CIGAR and other manuals.
From the spring of 1977 there will be two machines sharing common peripherals. Except in a very few special cases, the system will appear to the user as a single machine and the remainder of this survey adopts this viewpoint.
The 195 is owned by the Science Research Council. At the end of 1976 it was averaging 15000 jobs per week for about 1000 users working mostly in Universities and Research Laboratories throughout the United Kingdom.
Well over half the jobs on the 195 are submitted remotely, mostly from workstations. The map shows their distribution as at the end of 1976.
It is also true that over half of the jobs on the 195 are submitted from keyboard terminals using a file handling system known as ELECTRIC. ELECTRIC may also be used for output retrieval.
The 195 is operated 24 hours a day 7 days a week and is normally available to users at all times except for scheduled maintenance and system development periods. During 1976 the 195 was available 160 hours per average week. The CPU utilisation was over 90%. After deducting system overheads, about 120 CPU hours were accounted to users each week.
The 195 is a very large and powerful computer with a Central Processing Unit (CPU) which is especially suited for number crunching. Its special hardware performs floating point operations very efficiently. It also gains speed by performing several operations concurrently.
The main memory is 2 Megabytes for each CPU. Allowing for space needed by the operation of the machine the size of the largest job that may be run is about 1.4 Mbytes. The 195 is not a paging machine. A machine word is 32 bits consisting of four 8 bit bytes. Integers require one word or half a word. Real variables generally use a single word or a double word giving precision to six and fourteen significant figures respectively. Quadruple precision is also available.
A machine of the power of the 195 needs very fast peripheral devices to keep the CPU busy. For the general user there are twelve magnetic tape units which may be used to read data at speeds up to 1.2 Mbytes/second and twenty four large capacity disks which transmit data at speeds up to 0.8 Mbytes/second .
Users may access the 195 either from keyboard terminals or in the traditional manner using punched cards. The card readers connected directly to the 195 accept 1000 cards per minute.
Those connected via workstations generally accept about 300 cards per minute. At most places users are allowed to use the card readers personally, though work may be submitted at Rutherford over the computer reception counter or via the post.
Printed output will normally be produced at the place from which the job was submitted. The central line printers have speeds of 1100 lines per minute with 88 lines to a page. One printer has lower case characters but its printing rate is slower. Remote printers operate at 200, 300 or 600 lines per minute but the speed of the transmission links can affect the nominal speed depending on the traffic to and from other devices on the workstation.
It is possible for output to be routed to any workstation. In particular work submitted remotely may be printed at Rutherford either to await collection or to be posted to the user. Some sites are served by a courier service and output may be directed to that service.
Users may direct their line printer output to ELECTRIC where it may be examined from a terminal. When that is done hardcopy may also be requested.
Except for those few workstations possessing a card punch, all punched output is produced at Rutherford.
Good quality output may be produced on the FR80 Film Recorder, both for printed and graphic work. Users may produce hardcopy, 16 mm or 35 mm film (colour or black and white), or microfiche. A single microfiche may accommodate 192 pages of output.
Paper tape may be used by special arrangement through one of the small computers linked to the 195.
There is a variety of magnetic tape drives. Four accept 6250 bpi 9 track tapes only. Another four accept 9 track tapes at either 6250 bpi or 1600 bpi. Two accept 9 track tapes at either 1600 bpi or 800 bpi, and two accept 7 track tapes at either 800 bpi or 556 bpi. Tapes at 800 bpi or less are NRZI, 1600 bpi and above are phase encoded.
Users are recommended to use 6250 bpi 9-track tapes. These hold the most data, transmit more quickly, and according to experience since mid-1974 are the most reliable. The other tape varieties are available principally for exchanging data with other computing systems.
Users are also recommended to use IBM standard labels. This means that among other things the name of the tape is written as part of the data on the tape so that the operating system may check that the correct tape has been mounted. When tapes carry no magnetic label there is always a danger of data being confused or even destroyed.
The facilities to protect users' tapes have until early 1977 been elementary. Users may arrange with the tape library for a tape to carry a visible warning that under no circumstances should it be rewritten. Also users wishing to rewrite a tape must provide that information when submitting a job to run on the 195 otherwise the system will reject any attempt to rewrite the tape.
Magnetic Tapes
9 TRACK 800 bpi two units
9 TRACK 1600 bpi six units
9 TRACK 6250 bpi eight units
7 TRACK 556 bpi two units
7 TRACK 800 bpi two units
Magnetic Labels - IBM Standard
- Unlabelled
- Others
Protection Measures
- Read Only Tapes
- File Protection via SETUP
- Label checking
- Expiry date Protection
- Authorisation of Use
From the summer of 1977 the system will also check that the intended use of a tape is authorised. For example an owner may limit read access to a collaborator while reserving for himself the right to rewrite it. This protection may be extended by the use of key words.
Over 30000 magnetic tapes are kept at the Rutherford Laboratory under the supervision of the Tape Librarians. The majority of these tapes are issued at Rutherford for which IBM standard labels are mandatory. Tapes originating elsewhere are termed "foreign" and must be registered with the tape library before use. Foreign tapes will be returned to their registered owner after six weeks disuse or earlier by request.
Only a subset of the tape library (about 5000 tapes based on recent activity) is available for immediate use. The remainder are stored away from the computer area and generally require 24 hours notice of use. This notice may be given in advance by informing the system, or merely by submitting a job to use the tape, which will be queued until the tape is ready.
Users should consider what arrangements are necessary to backup their data. Tapes designated as backup tapes will be kept in a different building from the main tape library. Only in the case of permanently mounted disks do operations staff maintain backup copies of data. In all other cases the provision of adequate backup is the responsibility of the user.
Magnetic Tape Library Active Tape Library Main Tape Library Backup Tape Library Foreign Tape Library Tape Librarian may be contacted from a terminal using ++T followed by a message Or phone 0235-21900 extn 333
The other major facility for storing data and programs is that of magnetic disk. The system has 24 spindles for IBM model 3330 disks or equivalent. 8 spindles accept the 100 Mbyte model 1 . The remaining 16 spindles accept the 200 Mbyte model 11 known as double density disks. Certain spindles are reserved for disks which are permanently mounted. When the quantity of data (too much) or frequency of use (not often enough) do not justify the use of permanently mounted space, demountable disk packs are used. A substantial amount of disk space, 1800 Mbytes, is permanently available. By storing compiled programs on disk and keeping reasonable amounts of data on the permanent disks, users are able to gain substantial benefits in turnround for development work. For example if a test needs to read part of a magnetic tape, a user would be fortunate to complete four or five tests per day, but if that same data were on permanently available disk it is quite possible to complete a dozen or more short tests during a normal working day.
The permanent disk space is used in a number of ways. Firstly, the system occupies 200 Mbytes and uses another 200 Mbytes for spooling the job queue and output. Secondly, 300 Mbytes are used to accommodate ELECTRIC files which are described more fully later. It would be useful at this point to note that ELECTRIC files are not accessible from User programs in the same way that user data sets are.
DISKS
Model 3330 (100 Mbytes)
3300-11 (200 Mbytes)
PERMANENTLY MOUNTED
- System Work Areas
- ELECTRIC files
- Public Libraries
- Group Libraries
- User Data Sets
- Long lived
- Short lived
- Temporary Data
DEMOUNTABLE
- Private Packs
- Shared Packs
- Low use Data Sets
Part of the system mentioned above consists of public Libraries containing programs available to the general user. Some of these are listed below.
In addition to the public libraries which form part of the system there are a number of private libraries used by different groups. These group libraries, commonly known as user libraries, are used for storing compiled programs or parts of programs. Therefore it is not necessary to compile the whole source of a program each time it is run. When developing a program, a user need only compile those routines under test. Since express turnround is rationed, this is an important consideration. Production programs normally require no compilation at all. These Libraries are for compiled forms of programs only. It would be an error to try to store a program source in a group library.
400 Mbytes are used for the group libraries. The space is managed by a feature of the system which records the use of each program. Programs unused for 100 days will normally be archived to tape in order to conserve free space in the Libraries. Retrieval of programs archived in this way is not difficult.
PROGRAM LIBRARIES - Fortran - Rutherford - Harwell - CERN - SSP - NAG - CPC - Graphics
As mentioned earlier, users may create files which are accessible to programs. These may be divided into three categories. Files required during the execution of a single job are termed temporary data sets. Provided their size is not excessive such files may be created on permanent disks. The system deletes them at the end of the job. There is a public demountable disk available for very large or very numerous temporary data sets.
Files required for longer may be stored in what are known as user data sets. 200 Mbytes are reserved for user data sets which are to be short lived. Such data sets will be deleted after 15 days disuse or at the end of the month following their creation. January data sets, for example, are deleted at the end of February. No formal registration is required for such data sets. However, ownership must be attributable in the event of problems!
500 Mbytes are available for longer lived data sets which must first be registered. When such data sets are registered you will be advised which disk to use and asked for a date when the data set should be reviewed. While such space is very suitable for control indexes of data management schemes, there can be no question of long term storage of bulk production data - that is best done on tape; nor of large data bases - that is better done on private or shared demountable disk packs.
Use of the 195 has to be authorised. This is done through a number of committees, each committee authorising a single category of users having at its disposal a share of the 195. The accounting unit is CPU time used. A user is authorised to use an account which receives a weekly allocation of computing time at different levels of priority. The responsibility of day to day running of the 195 rests with the Computing and Automation Division of Rutherford Laboratory. Except for various nuclear physics users, prospective users should negotiate with the Grant Support Group of C & A Division. (In general nuclear physics users are allocated computing time when experiments are approved).
The 195 is run by Operations Group. A Program Advisory Service is provided by User Support Group to whom programming problems should be addressed. As explained above, the allocation of computing lies outside the province of the computing service. Any special requirements must be negotiated with a representative of the appropriate category appointed for that purpose.
There are facilities provided via the terminal system to answer questions such as "what has happened to my job?". It is therefore not normally necessary to approach operations group except when dealing with the tape library or in cases of equipment malfunction. You may also contact the program advisory office and the tape library from terminals.
SRC Facilities Committee - shares computing between CATEGORIES OF USERS - who authorise and allocate projects to USER GROUPS - who coordinate activities and authorise work on projects by SINGLE USERS PROGRAM ADVISORY OFFICE Abingdon 0235 21900 extn 6111 09.30-12.00 13.30-16.00 Monday 09.30-12.00 13.30-16.00 Tuesday 10.30-12.00 13.30-16.00 Wednesday 09.30-12.00 13.30-16.00 Thursday 09.30-12.00 13.30-16.00 Friday ++U Terminal Message for PAO
The operating system is known as OS/360 MVT. The M standing for multiprogramming, ie. several jobs are processed concurrently. A subsystem known as HASP 1s used to control selection of work from the job-queues and to communicate with the remote workstations. A number of local modifications have been made to improve operational efficiency and provide extra facilities to the user. Generally the user does not need to distinguish between the components of "the system". However, this is the explanation of the slight difference in the form of some of the control cards to be met later.
The nature of the user population has been such that the programming language used almost to the exclusion of all others is Fortran. Whilst certain other languages are available on the system there is nothing like the level of support that is available to the Fortran user. In particular the experience of the program advisory service with other languages is limited.
Two Fortran compilers are available. One is best suited for development work, compiling faster and having a Debug facility but performing no optimisation. The other takes longer to compile, but using special optimisation techniques taking advantage of 195 hardware produces code typically twice as fast in execution.
PROGRAMMING LANGUAGES FORTRAN (G and H) ASSEMBLER (F) PL/1 (F) COBOL (ANS) BCPL PASCAL not ALGOL
Below is an example of a job that would run on the 195. A four line Fortran program is enclosed in the necessary Job Control Language.
Most Job Control statements begin with //. There are only eight types of Job Control Statements. Many users will only ever need to use the JOB, EXEC and DD statements shown here. DD stands for data definition and in this case the * which follows indicates a card deck following immediately, which is terminated by the control statement /*.
The user must provide an account and identifier which are given here in brackets. XZJOB1 is an example of a job name. Users are required to follow a certain convention in choosing names for jobs, and in other places, so that ownership may be established when necessary.
In addition to the Job Control statements, the user will meet statements beginning /* which are used by HASP and local extensions to the system. Those for assigning priority and selecting postal output are shown below.
JOB SUBMISSION
//XZJOB1 JOB (43DM,1E).DEMO
// EXEC FORTG
//C.SYSIN DD *
PRINT 100
100 FORMAT(' SUCCESS')
STOP
END
/*
PRIORITY AND ROUTING
/*PRIORITY 12
//XZJOB2 JOB (43DM.1E).DEMO
/*ROUTE PRINT POST
// EXEC FORTG and so on
In the example given above neither tapes nor disks were required. The job was non-setup. In the example 100 records are copied from a 1600 bpi 9-track tape to a short lived data set on a 3330 disk. The disk is permanently mounted but a /*SETUP card 1s required for the tape giving both its serial number and the type of tape.
Data definition cards are required for both the tape and the disk. Note the systematic names FT01F001 and FT02F001 which are derived from the stream numbers 1 and 2 respectively. Because the tape has standard labels the file must be referred to by a data set name, but being an existing data set its internal characteristics are not given since the system will obtain them from the magnetic label.
Disk data sets do not have the option of being unlabelled. Therefore the data set must be named. Note its compound systematic form. Because it is to be created, a space limit is required and its internal organisation described by the DCB parameter - a standard pattern is used here.
After running this job the user could perform his tests from the short lived data set as non-setup jobs thus qualifying for express turnround provided some other conditions are also met.
USING TAPE AND DISK
/*PRIORITY 6
//XZJOB3 JOB (43DM.1E).DEMO
/*SETUP 900000.DENI600
// EXEC FORTG
//C.SYSIN DD *
INTEGER AREA(500)
DO 99 I=1,100
READ(1) AREA
WRITE(2) AREA
99 CONTINUE
STOP
END
//G.FT01F001 DD UNIT=DEN1600,
// DISP=OLD,LABEL=(1.SL),
// VOL=SER=900000,DSN=RUN543
//G.FT02F001 DD DSN=JAN.Xz1E,
// VOL=REF=FREEDISK,
// SPACE=(TRK,20,RLSE),
// DISP=(NEW,KEEP),DCB=TRACK30
The examples given previously were simple 1n terms of core (memory) required. Programs that are too large to run with the default value of 72K will only run if the system is told to reserve sufficient core. This is done using the Region parameter in the manner shown opposite. The region must be large enough not only to accommodate the program, whose size may be obtained from the linkage editor, but also any buffers for input and output. If you fail to request sufficient core your program will abend, that is, end abnormally. If you overestimate the core required, the system is unable to use any free core for other work.
The system classifies each job it receives according to the maximum core required for any single step. See below for the classification scheme. Work is selected from the job queue according to its class. Typically at any one time the batch may be executing six jobs of Class A and one of Class E. The recipe for job selection is varied by operations staff according to the work load and the need to meet certain turnround requirements.
REGION SIZES //XZ1E JOB (43DM.1E),DEMO // EXEC FORTG, REGION.G=160K The Region must Accommodate (i) the compiler Program (ii) Buffers needed for I/O (Computed) CLASSES OF JOBS A Up to 210K E Up to 500K F Up to 960K G Over 960K
The system also distinguishes between Long running and short jobs, the boundary being ninety seconds CPU time. Obviously analysis programs vary, but many can process an entire tape in 90 seconds. Few programs are so large that they cannot be compiled in that time. Monte Carlo programs typically generate tens of thousand events in short jobs. Other programs can do about a hundred inversions of 50-row matrices.
Certain jobs with modest core and time requirements qualify for express turnround provided no tape or disk needs to be mounted. Express jobs may be submitted at priority 12 provided one's ration is not exhausted.
As with the core requirement, jobs exceeding their time or estimate of printed or punched output will be terminated. The default time limit is 30 seconds, 5000 lines for printed output, and 500 cards for punched output.
The classification scheme mentioned on the previous page is modified for long jobs as indicated opposite. During prime shift the batch normally only processes short jobs of priority 6 and above.
SHORT, LONG and EXPRESS JOBS
SHORT jobs are up to 90 seconds
LONG jobs exceed 90 seconds
Priority 12 runs EXPRESS Jobs up to 10 seconds
not more than 210K and NON-SETUP
Time and Lines are extra parameters on the JOB card.
Long Class A jobs become Class 1
Long E and F become 5 and 6
Long Jobs default to Priority 4
Short Jobs default to Priority 6
Computing time is issued at different Levels of priority which is normally associated with turnround. The table below lists the target turnround for work submitted at each priority level. For the priority levels 8 and above these turnrounds are applicable to short Class A jobs only. During the prime shift for example the system does not start long jobs, hence it is not meaningful to expect 30 minute turnround in that case.
Only if there is sufficient ration will the system accept a job at the priority tendered. Otherwise the job will cascade to the next lower priority, and so on until a large enough ration is reached.
Users are able to interrogate the system from terminals, asking the status of any job. The reply gives the position in the job queue and its priority, or else reports that the time the job ran indicating how the job terminated, normally or abnormally.
The owner may cancel, reroute, or change the priority of a job.
Turnround means the completion of printed output. Output from the FR80 usually requires 24 hours processing time.
PRIORITY and TURNROUND P12 --> 15 mins non-setup etc P10 --> 30 mins P8 --> 2 hours P6 --> overnight P4 --> weekend P3 --> when other work is exhausted P1 --> when other work is exhausted CPU time is allocated at different priority levels.
Almost 200 terminals are connected to the 195 in one way or another. Most of them may communicate with parts of the system and with other terminals. In particular they talk to ELECTRIC.
ELECTRIC Terminals
Talk to ELECTRIC by default but may talk to MAST,
HASP or any other TERMINAL.
++M JOBS
++H STATUS JOB=XZDEMO
++27 HERE IS A MESSAGE FOR 27
++U FOR PROGRAM ADVISORY OFFICE
++T TO TAPE LIBRARIAN
++S TO YOURSELF
++E IS ELECTRIC
++A IS ARPA
ELECTRIC is the name of a file handling system used mainly from terminals for file handling, job submission and output retrieval. The files of ELECTRIC are separate from system data sets. Internally there are two types of ELECTRIC file: text files which users may edit and submit as jobs; and, output or graphics files. Graphics files, known collectively as MUGWUMP, are of two kinds - Lineprinter output obtained by routing to ELECTRIC, and Pictures.
Picture files may be produced using standard software to define a frame, draw curves, caption and so on. Such files may only be examined at graphics terminals for example in the Tektronix 4000 series. Picture files are not designed for long term storage, but essentially for quick look purposes. Pictures which are required for longer may be sent to one of the FR80 cameras if desired, although generally better quality is obtained when the picture is sent to the FR80 directly.
In addition to standard Editor features including parametric editing, ELECTRIC has a layout facility which is suitable for the preparation of documents.
ELECTRIC AND MUGWUMP TEXT FILES - used for Job Submission - extensive editing facilities - documentation (via TN Printer or the FR80) GRAPHICS FILES - line printer output by using /*ROUTE PRINT ELECTRIC - Picture files created by MUGWUMP software visible on Graphics Terminals
The output below feature an ELECTRIC session in which a file is created, edited, executed. The output is examined and both output and text files are removed. Command names may in fact be abbreviated. In general the remaining ELECTRIC commands provide more powerful editing features and a flexible file organisation. This example represents a minimum command subset.
NB In order to distinguish replies from inputs, all inputs here are preceded by a blank line except the examples of entering and modifying a file.
login id=1e,acct=43dm,key=demo USER 34 0184 BL 19/ 20 11.55.13 31/ 1/77 V 13/12 enter f1=xyz //xzdemo job (acct,1d),demonstration // exec r1dem1 $$ OK type f1=xyz FL=1EMAINDR.XYZ NENT= 2, NBLK= 1 1://XZDEMO JOB (ACCT,ID),DEMONSTRATION 2:// EXEC RLDEM1 EOP modify f1=xyz $replace ln =2 // exec r1demo1 $insert ln*1 /*route print electric $1 1n=0:/*priority 12 $$ OK type 1:/*PRIORITY 12 2://XZDEMO JOB (ACCT,ID),DEMONSTRATION 3:/*ROUTE PRINT ELECTRIC 4:// EXEC RLDEMO1 EOP execute f1=xyz WAITING FOR COPY Q=S OK H** XZDEMO (1205) IN SHORT NONSETUP QUEUE POSN 009 PRI 012 'XZDEMO ' STARTED /XZDEMO ' ENDED list id=le 1EDEMO . 1 FT = 3 SIZE = 1 (TX) 31/ 1/77 END OF FILE find f1=ledemo 1IDEMO . 1 FT=3 SIZE = 1 (TX) 31/ 1/77 index NAME FRAME ER HASPLOG 2 JCL 2 ENJOB 3 END OF INDEX 2 ln=65 65: 66: THIS IS A SHORT FILE OF DATA WHICH IS LISTED BY 67: THE DEMONSTRATION PROCEDURE R1DEMO1. 68: 69: 70: EOP FRAME 2 scratch OK delete f1=xyz OK logout OK 1E 0184 BL 19/ 20 12.08.13 31/ 1/77 status job=xzdemo H** XZDEMO (1203)ENDED ON 31 AT 12.06;TIME=00001 SECS;C-CODES ZERO
The dialect of Fortran used on the 195 is IBM 360 Fortran IV which includes ANSI 1966 Fortran as a subset. Listed below are some features which are not in ANSI Fortran. The H-extended-plus optimising compiler has some further language extensions. In particular it has an option allowing all single precision variables, constants and subroutine names to be replaced by double precision equivalents. This may be particularly relevant when importing programs from machines with a longer word length. Single precision variables are only stored to six significant figures. Double precision stores fourteen.
SOME FEATURES OF IBM FORTRAN
1. REAL*4 - REAL*8 (Precision)
COMPLEX*8 - COMPLEX*16
2. INTEGER*2, LOGICAL*1 (Economy)
3. IMPLICIT INTEGER (A-Z)
4. END= and ERR=
5. NAMELIST eg READ (1,X)
6. Direct access I/O
DEFINE FILE 8(10.4.8,U,K8)
READ (8' I) LIST
7. FORMAT(T61,I5)
8. RETURN 3
9. ENTRY XYZ (A,B)
10. SUBROUTINE ABC(/A/)
11. READ (5,*) X, Y, Z
12. More Mathematical Functions
13. STOP 8 causing condition code 8
In addition to the dialect of Fortran there are certain other matters that anyone coming to the 195 from another system should be aware or reminded of. The character code for punched cards is EBCDIC. The internal representation of characters on tape is also EBCDIC. Cards and tapes in other codes require translation except in the case of tapes written to ASCII for which the system will perform conversions.
Word length was discussed previously. In general wherever possible try to avoid bringing to the 195 tapes containing binary data. Numbers are stored on such tapes according to the internal representation used by the original computer and require conversion to that used by the 195. This problem is avoided when the tapes are formatted and the numbers are represented by character strings which may be processed by the system.
Some features of formatted and unformatted input/output are listed which are generally applicable to both tape and disk. In short, the advice is use unformatted internally and formatted externally.
FORMATTED v UNFORMATTED I/O
FORMATTED
(1) SLOWER (except for A-Format because of
Data Conversion to or from EBCDIC
(2) Usually less data per inch
(3) It is more suited to tapes which are transported
(4) No control information is written on the tape
when using RECFM=FB
UNFORMATTED
(1) FASTER because no data conversion takes place
(2) Awkward to transport because of machine dependence
(3) Control Information is added to the tape
The efficiency of reading or writing to tape or disk can be affected in two ways. The first is the speed with which the operation takes place, locating as well as transmitting the data, and the second is the amount of work the system has to perform before declaring the data available to the user. Poor choices in the organisation of data degrade performance significantly. If you keep to standard methods you will avoid making a poor choice.
Do not be misled into believing that the size of blocks of data written to tape or to disk must correspond to the records processed by single Read and Write statements. Only in the case of Fortran Direct Access data sets is this so. Both space and time are saved by blocking as many logical records as possible into a physical record or block. There is an upper limit to the size of a block. Larger records have to span more than one block. When the size of records is variable both blocking and spanning may take place.
If your program is heavily I/O bound it may be necessary to consider isolating your data from public disk space.
Within a Fortran program, input to an entire array rather than an implied DO is very much more efficient than to a list of distributed locations. Therefore wherever possible keep the items in input/output lists in consecutive locations equivalent to an array.
When you become an authorised user of the 195, you will be required to complete a registration form countersigned by an approved project holder. You will be issued with a personal identifier (possibly to share). Normally this is done by the computer receptionist, though a few groups issue identifiers independently. A second part of the registration form is used to authorise computing with particular project account numbers. If you intend to use ELECTRIC, you should request to do so when you register or later. You will be unable to use the 195 until the registration process has been completed.
Certain programs, having restricted copyright, may only be used according to the licensing arrangements. Each user of the 195 is required to sign an agreement to honour these.
When you begin to use the 195 you will need certain documents. CIGAR (RL-75-032) is a more formal description of the system issued in a Loose Leaf binder. As well as a manual describing ELECTRIC (RL-77-043) there is a pocket size card summarising the commands. A comprehensive description of JCL is given in the IBM manual GC28-67Q4 entitled Job Control Language Reference. However most Fortran programmers will find all they need in the IBM manual GC28-6817 entitled FORTRAN IV (G and H) Programmer's Guide, or in SC28-6852, IBM OS FORTRAN IV (H Extended) Compiler Programmer's Guide. If these documents are not available to you, then apply to the computer receptionist at the address given on the title page.
BASIC DOCUMENTATION
CIGAR
ELECTRIC MANUAL
ELECTRIC CARD
(IBM) FORTRAN LANGUAGE MANUAL
JCL is covered adequately in
(IBM) FORTRAN (G and H) PROGRAMMER's GUIDE