This document describes the HARTRAN System introduced on the S.R.C. Atlas on the 1st March, 1965. Hartran System Notes 2 and 3 are now superseded. System Note No. 1 - Routine Linkage Conventions within HARTRAN - may be of interest to specialist machine code programmers.
At SRC Chilton, the full HARTRAN system was introduced on the Atlas computer on 1st March 1965. This note describes the facilities. It incorporates those sections, of Hartran System Note 3 which are still relevant, and in all other respects this note supersedes that note. This note describes the facilities available in Version 003 of Hartran.
The full system provides for the compiling of Fortran routines, the assembly of ASP routines, the loading of binary routines in the target language BAS and subsequent execution of the object program. The job may consist of a mixture of these individual activities in the proper order. Thus, execution may be omitted if the programmer wishes. Alternatively he may compile routines for subsequent execution without presenting a single binary card. The note which follows describes the principal features of the system and the method of requesting them.
Experience with the system is still limited, and the interaction of it with the Supervisor program on Atlas may still give rise to some difficulties. For this reason, users are asked to show some forbearance whenever these difficulties affect their own programs. Some indications are given later of the most likely diagnostics produced by the Supervisor and the recommended course of action is specified.
We believe that existing programs will continue to run under the new system even though the system output may be slightly different. However, we cannot guarantee that multichapter jobs will necessarily continue to work, because there are more changes to the system concerned with them and also because such jobs could only work on the previous versions of HARTRAN with modifications.
We cannot stress too strongly that an alteration to the make up of the source deck whether it be addition of extra cards or the removal of old library routines may result in a working program card deck becoming inoperative. This is particularly true of those jobs using the precompiled Hartran library from the magnetic tape titled at SRC.
N0010 HARTRAN LIBRARY
A program using this tape will continue to run if the cards are left in the same order as on a previous run.
Likewise jobs for Fortran compilation and ASP assembly which make use at SRC of the magnetic tape
NIRNS COMPILERS
will continue to work as before. However, users will notice that the pseudo ASP listing will no longer be produced.
Warning is now given that neither of these magnetic tapes will be maintained and that in the near future both will be withdrawn from use altogether. From now onwards any corrections to the Fortran Compiler will only be applied to the Hartran System and the tape NIRNS COMPILERS is liable to become increasingly out of date.
Those programmers who made use of COMPILER HAR2 to obtain automatic inclusion of Hartran library routines will find that their programs will continue to run although some slight changes to the library routines have been made. From now onwards the Atlas Supervisor will understand COMPILER HAR2 to mean COMPILER HARTRAN. However users are asked to request HARTRAN in their own interests because the other name will eventually not be recognised. The phrase
COMPILER HARTRAN
may now be shortened to the phrase
USE HARTRAN
in a job description.
The user who wishes to obtain compilation and execution in the same run must now take account of the output generated by the Fortran compiler and ASP assembler in addition to his own program output. Unless the user expresses a request to the contrary, binary cards will normally be produced and the job description must contain a specification for two streams of output namely
OUTPUT 0 LINEPRINTER x LINES OUTPUT 15 CARDS y LINES
where x must be a number to take account of the compiler output (about twice the number of source cards) in lines plus an allowance for the expected execution output. The number of binary cards y will usually be about a quarter of the number of source cards. Once again due allowance should be made for output generated for the card punch by PUNCH statements in the program in execution, if any.
It is also advisable that some allowance be made for the time spent in compiling Fortran routines and in ASP assemblies whenever execution is to follow. Users should notice that the request for COMPUTING time includes the time spent in compiling and loading the program. The Fortran compiler at present takes about a quarter of a second per line to compile a routine. A line corresponds to a source language statement.
The various activities of the system are indicated by control cards, all of which must have an asterisk in column 1. The contents of the other columns 2 to 8 are used to specify the particular action the system must take.
All users of HARTRAN in the past will be aware that the loading of program from binary cards is initiated by the card bearing *BAS in columns 1 to 4. This control card is produced by the Fortran compiler or ASP assembler and the user does not usually have to prepare such cards himself. Equally the user will be aware that the finish of his binary card deck and the termination of the loading phase for his program is indicated by a card punched in columns 1 to 6 *ENTER. This card is also responsible for the initiation of the execution phase of the program loaded.
All control cards have an asterisk in column 1 and the remaining part of the directive follows immediately in column 2 packed in adjacent columns. The control cards or directives which the new Compile and Go version of Hartran recognises are
*FORTRAN *BAS *READGLO *ASP *ENTER *CHAPTER *COMPILE *DEFINE *END *SUMMARY *RENAME *GLOBAL *LIBR *CHAIN *ALTER
and on each of them no other information may be punched before column 9 or after column 72. Columns 73-80 may be used conventionally for labelling and serial numbering. Of the directives listed above those in the left hand column have been introduced for the first time and will be described first.
This directive is used to indicate that a routine written in the Fortran language follows and is to be compiled by the Atlas Fortran Compiler. Before the compiler is entered columns 9 to 72 of the card are scanned to determine what options the user wants. If columns 9 to 72 contain no recognisable option, the standard options are taken. The relevant options are indicated by words on the *FORTRAN card and they are:-
Standard Non-Standard
NOLIST LIST
CARDS NOCARDS
COMMENTS CODEONLY
FAILED NOFAILED
To obtain both cards and listing without comments, the user would prepare the control card reading
*FORTRAN LIST,CARDS,CODEONLY
Notice that each option is separated from the next by a comma, and standard options need not be stated. The standard options may be changed in the light of experience with HARTRAN. The details of the options are:-
The other words NOLIST, CARDS, COMMENTS, FAILED have opposite effects and need not be described.
Each Fortran language routine should be preceded by *FORTRAN. The options are reset for each routine to the standard settings and, if the user requires a non-standard option for each of his Fortran routines, he must state it afresh on each *FORTRAN card.
If the compiler cannot compile a routine which is too large, processing of the deck is resumed by the system at the next control card. It is thus in the user's interest to ensure that *FORTRAN cards precede each Fortran routine, otherwise the search made for the next control card may be responsible for routines being overlooked.
Unless listings are taken, the Fortran compiler now breaks the output for the printer after ten routines. For this purpose the count includes ASP routines.
The version of the Fortran compiler incorporated with HARTRAN does not process the statements
INITIAL PARAMETER DOUBLE LENGTH DOUBLE PRECISION COMPLEX
Most of the restrictions due to table sizes have been relaxed and we give a list of the principal tables and the maximum number of permitted entries:
Table Maximum Overflow Key
Name No. of on Error Purpose
entries 1011
LOOM 511 6144 PUBLIC and COMMON names
LAID 511 7168 Arithmetic Identifiers
LCOI 511 1264 Constants(Real,Integer & Boolean)
LCOH 511 1776 Hollerith constants: Formats
LEQU 50 4750 Equivalence Statements
LERR 40 4928 Error table
LABS 511 2288 Absolute addends for addresses
LFID 100 4536 Flow identifiers
LOOP 256 9728 Loops: DO,FOR, implied I/O
LOOK 40 4336 Nesting of loops
LFSN 256 2800 Format statement numbers
LDUM 40 4456 Dummy arguments
LCOT 128 4800 Transfer table keys
LIRN 511 3312 Local referencing
LISB 384 0496 Statement numbers and blocks
LINK 511 8704 Linkage of blocks
LERT 511 1536 External references
LDIM 509 1946 Dimensions
CCOR 250 6123 Constants (Real & Integer)
While the tables and sizes above are those which have given rise to overflow errors in the past, there are other tables which may overflow when the compiler is capable of processing PARAMETER declarations. A consequence of the present table sizes is that routines with more than 255 DO loops will fail to compile, and routines with more than 170 FOR loops are liable not to compile. Routines of about 500 Fortran source language statements should compile satisfactorily, but there is a distinct possibility that routines with 300 or more Fortran statements will cause the Supervisor diagnostic
ILLEGAL FUNCTION EXCESS BLOCKS
resulting in termination of the job. See section 20.
This directive will precede any routine written in the Atlas Symbolic Programming language (ASP). As in the case of *FORTRAN, the contents of columns 9 to 72 are scanned for the setting of options. However, only two options are meaningful and these are:-
Standard Non-standard CARDS NOCARDS FAILED NOFAILED
Their effects are exactly as described for *FORTRAN. Users who use the LIST option on *ASP cards will find that execution of their program is deleted even though the option has no bearing on the output from the ASP assembler.
This directive is used to indicate that a job consists only of compilation of Fortran routines and assembly of ASP routines. There will be no execution phase in the job. The directive must come first and is illegal once any other directive is read. After *COMPILE, the only legal directives are *FORTRAN and *ASP preceding routines in the appropriate language. The end of the set of routines is indicated by the directive *END. A typical deck for compilation might be:
JOB (user's job number and title card) OUTPUT 0 LINEPRINTER x LINES 15 CARDS y LINES COMPUTING z SECONDS USE HARTRAN *COMPILE The set of routines to be compiled *END file card
The file card is punched with both 7 and 8 in column 1 and C in column 80. The quantities x y and z have been discussed earlier in section 4.
By means of this directive a user may obtain the printing of all the following system control cards in the order in which they are processed. Normally such printing is suppressed.
This directive is used primarily to indicate that the following routine need only be loaded if there is a call for it from the program so far loaded The chief use occurs in presenting libraries of routines to the system. Users will, in general, not need the facilities provided by this directive, but details are given for those wishing to build up libraries of routines.
The directive is used to provide a list of symbols which will be define if the following routine is loaded. The symbols are those defined through ENTRY or DEFINE pseudo-operations in ASP and, in the case of Fortran, there is only one symbol, the name of the routine. The routine will be loaded into store if there is a call for one of the symbols listed, and the call must be from the program already loaded into store.
The format of the *LIBR card is rigid and the symbols are listed in fields of eight columns starting from column 9. The first symbol occupies columns 9 to 16, the second columns 17 to 24 and so on up to column 72. If more than eight symbols need to be listed, successive *LIBR cards are used for the purpose and each *LIBR card must precede the routine to which it applies.
Should at least one of the symbols on the *LIBR cards be found to be the name of a routine still unsupplied called from the already loaded program, then the following routine is loaded. However care is taken to ensure that the routine is loaded in the appropriate region of store in a multichapter job. Only those symbols which are names of wanted and unsupplied routines are defined. Thereby clashes in the use of names are avoided.
This directive provides facilities for the correction of program once it is loaded. The address of the first of a series of corrections - the series can consist of just one correction - is specified by an expression starting in column 9 of the *ALTER card. The expression usually takes one of three forms
Absolute constants may be decimal integers or octal constants preceded by a decimal point as in ASP or even a combination just as in ASP. The symbol used must previously have been defined.
The corrections themselves are given on succeeding cards and apply to successive addresses. As many corrections as desired may be planted in this way. The process ceases at the next system control card which may, of course be another *ALTER card.
There are three types of correction possible, and they are indicated by the format of the card containing the correction itself. In each case a correction applies to a 48 bit word, and the types of correction are instructions, halfwords or text.
Instructions must be punched in a rigid format.
Such address expressions can be more general than those defining the addresses of a correction on *ALTER cards. The symbol need not have been previously defined and it may be signed. The address of the current location in which the correction is to be planted may be referred to by the special symbol *. Thus we have the possibility of expressions of the following forms which will be the most usual:
Halfwords are introduced by H punched in column 1. The remainder of the card up to column 72 may be used to specify two instruction address type expressions separated by a comma.
Text is introduced by T punched in column 1. The eight characters of the text word are punched in columns 5 to 12 inclusive. The contents of columns 2 to 4 are not examined.
As a check on the alterations introduced, Hartran prints under headings the location, the old contents and new contents of the word altered. The format used for printing the old contents corresponds to the type of correction inserted. The previous contents of instruction address and halfword fields are printed in octal.
As an example suppose we wish to change a format specification from (7E12.3) to (10G10) and we know that this is contained at location 496 of routine WROUT whose entry point is 379. Then we put
*ALTER WROUT + 117 T (10G10)
Notice that the figure 117 is derived from the location 496 less the entry point of routine WROUT.
The cards containing this directive are usually produced by the Fortran compiler and ASP assembler and the user is not normally concerned with preparing them. Such cards signal the presence of a routine in the binary target language (BAS), and their normal purpose is to initiate the loading of a binary program.
The format of *BAS cards is rigid, and the information recorded on the card is shown below:
Columns 9-16 Name of routine. 17-24 Entry point relative to beginning. 25-32 Position of Routine symbol tables. 33-40 Number of symbols defined in routine. 41-48 Length of COMMON required.
The contents of columns 9 to 16 will be blank in the case of a Main Program. Each of the other fields will contain an octal constant and usually the first and last columns will be zero and left blank. Although the columns from 49 to 80 are produced with punching by the Fortran compiler and ASP assembler there is no significance in the information for the loading process. The columns contain the version of the system, the time and date of compilation with the label of the routine in columns 73 to 80.
Following the *BAS card will be one or more binary cards. These cards all have punchings in rows 7 and 9 of column 1 and all but the last have additionally a punch in the + row of column 1. They will have been serially numbered in columns 79 and 80. Each binary card carries a checksum of all internal information. The use of this checksum may be suppressed by punching row 0 in column 1.
The binary cards contain information which can be loaded into any part of memory in such a way that the routine may operate there. The information found in rows 2 to 6 of column 1. This is a binary count with the units position in row 6, and is a count of the number of words of information on the card. The other columns of binary cards are used as follows:
The directive which indicates the end of the source language and binary routines is *ENTER. For single chapter jobs nothing else need be punched on this card, but for multichapter jobs the chapter to be entered first must be punched as an expression (with rules similar to *ALTER expression rules) starting in column 9.
It is at this point that the Hartran library routines are supplied and if after scanning all the library there are still routines missing execution will be deleted.
The deck will start with a job description. The first card of this will be punched JOB in columns 1 to 3 and after a space the job number and title will follow. The cards following this and up to that punched USE HARTRAN (or COMPILER HARTRAN if preferred) will specify the particular properties of the job. If routines are to be compiled and binary cards are to be produced then as mentioned earlier the two cards
OUTPUT 0 LINEPRINTER x LINES OUTPUT 15 CARDS y LINES
must be present. Some hints on the choice of numbers for x and y was given earlier in Section 4.
Similarly the user should ask himself about the amount of store his program will need. This is requested in the job description by
STORE n BLOCKS
where a block indicates 512 words. A program needing 10K of store in total will need the request
STORE 20 BLOCKS
The user needs also to mention in his job description his estimate of computing time, the logical numbers of all magnetic tapes needed by the job together with their titles, and the stream numbers and titles of any input documents.
An example then of a simple deck for Hartran might be:
JOB I0493 FOSSEY EXAMPLE DECK
OUTPUT 0 LINEPRINTER 100 LINES
COMPUTING 1 MINUTE
STORE 6 BLOCKS
USE HARTRAN
*FORTRAN NOCARDS
1 READ 100,X
IF(X)EXIT,EXIT,2
2 Y = EXPF(0.813*LOGF(X))
PRINT 101,X,Y
GO TO 1
100 FORMAT (F8.1)
101 FORMAT (2X,2HX=,F10.3,2X,2HY=,F10.3)
END
*ENTER
207.4
8176.1
-30.0
File card
The file card is punched with both 7 and 8 in column 1 and with C in column 80.
Although this program is trivial, we have had to make an allowance for the library routines. Thus the store request is STORE 6 BLOCKS. Because the option to suppress binary card output is taken, there will be no card output during the compiling phase and the program produces none in execution. It is safe, therefore, to omit the description of OUTPUT 15 CARDS from the job description.
This example of the very simple job can be extended by replacing the one compilation by several and by introducing binary cards preceded by their *BAS cards either in place of the symbolic routines or in addition to them. For operational convenience, users are recommended to put their symbolic routines first followed by their binary routines. In those cases where the routines must be presented in a definite order the user can present his job with his routines in the necessary order.
The principal purpose of the *DEFINE directive is to allow the values of PARAMETERS to be set. However the directive has another very convenient effect. During development of a program a testing run may be held up while the programmer completes the coding and preparation of a routine which is not likely to be called in the initial stages. This directive enables a user to make two routines formally equivalent for a particular run.
Let us suppose that a job requires a routine UNBORN which has yet to be written and that another routine GOING could be used in its stead. Then by inserting in the deck before the *ENTER card a card punched
*DEFINE UNBORN = GOING
any Fortran statement CALL UNBORN is effectively turned into CALL GOING. If either routine has any dummy arguments, then for safety they should agree in number and type but the routine GOING may have fewer than UNBORN. Here we have assumed that the routine UNBORN will actually be called.
If the programmer is fairly certain that the routine UNBORN will not be called he may if he prefers use
*DEFINE UNBORN = -1
This has the effect of setting the address of the entry point of the routine UNBORN to an illegal address. If the routine is then called the Atlas Supervisor Program will produce the diagnostic
SV INSTRUCTION
indicating that control has gone to an illegal address and the job will be terminated.
If A,B,C,D represent symbols and E,F represent expressions, then the format of *DEFINE cards is
*DEFINE A,B, ... = E,C,D, ... =F, ...
The expressions E,F etc are address type expressions and are similar to those mentioned in Section 11 on *ALTER. However, since the values of E,F etc must be known, all symbols used in the expressions must be defined.
The effect of this *DEFINE is that the symbols A,B, ... etc take the value of the expression E, while the symbols C,D etc take that of the expression F. Only columns 9 to 72 may be used for the definitions, but any number of *DEFINE cards are permissible in a job. No symbol may have its value defined twice.
The use of this directive is twofold. The first enables a particular program to have the same name used for two different entities, e.g. two routines having the same name could be loaded. The second usage which is the more common allows all the calls of one routine to be turned into calls of another and is particularly useful where both routines are library routines.
For instance, it is thus possible on Atlas to turn all READ INPUT TAPE statements in Fortran into READ statements without changing the original source language.
Let AX,BX,CX .... AY,BY,CY denote symbols , then the general form of the *RENAME card is
*RENAME AX=AY, BX=BY, CX=CY, ...
The symbols AY,BY,CY, .... are the original names which are lost and AX,BX,CX, ..... are the corresponding new names. If the new name is that of an already defined symbol, the renaming is not allowed. The original name may have been defined or not, and the new name may have been used in a call from a routine already loaded. None of the uses of either name will be lost in the process of renaming.
As a result it is possible to change by renaming all READ INPUT TAPE statements into READ statements even though there are genuine READ statements already present in the program. This particular feature is accomplished by the card
*RENAME /RSI = /RIS
A job needing several chapters is called a CHAIN job and it will require a magnetic tape. On this tape will be recorded the various chapters and sufficient information to enable the job to be extended or entered fairly easily without the whole loading process being repeated.
The identity of the magnetic tape is specified by the directive *CHAIN p,q,r where p is the logical tape number, q is the starting block number and r is the highest chapter number. These numbers start in column 9. If r is omitted it is taken equal to 8 and, if q is also omitted, the starting block number is set to unity. Tape p then becomes the chain tape.
Each chapter is introduced by the directive
*CHAPTER n
where n is the chapter number. Routines will be loaded into the chapter region unless the chapter number is zero, when they will be loaded into the Global region. The chapter region starts with the logical address .10000000 octal and the Global region starts from the logical address zero. As each *CHAPTER directive is met the library routines necessary to complete the previous chapter are supplied and the chapter is written to the Chain tape. Hartran prints out
TAPE p STARTING AT BLOCK b FOR m BLOCKS
to indicate where the chapter is on tape. The chapter region is cleared and all chapter region symbols are removed before the next chapter is loaded.
Each chapter may consist of a mixture of BAS routines introduced by *BAS cards, Fortran routines preceded by *FORTRAN cards and ASP routines preceded by *ASP cards. Symbolic routines must be placed in the chapter to which they belong, and so symbolic routines and binary routines can be presented in any order.
Routines can be loaded into the global region if the names of the relevant routines are declared through the directive
*GLOBAL
The names may also include any public scalars and arrays which the user wishes to force into the global region. The list of names starts in column 9 and each name is separated from the next by a comma. Notice that this directive should come before the first use of scalars and arrays and before the routines affected.
Entry to the program is achieved by means of the directive
*ENTER n
where n is the chapter to be entered and this must not be punched before column 9. If n is zero, it may be left blank.
Chapters may be presented in any order. If no *CHAPTER directive is present at the beginning of the deck, any routines occurring before the first *CHAPTER card will be treated as part of the material to be loaded into the global region. Each chapter other than zero should contain a main program, a routine with a blank name.
If chapter 0 requires a main program, then the main program must be preceded by *CHAPTER 0 and come immediately before the *ENTER card. It will be possible to enter chapter 0 without the various corrections at present necessary in the near future.
If the sole purpose of running the job was to get the chain tape written, then the *ENTER card may be replaced by *END and this causes execution to be deleted after the chain tape has been written.
Once the chain tape has been written, Hartran has reported on the printer the positions of each chapter on the tape. In order to read the program from the tape it is necessary to use the figures recorded for the position of GLOBAL on the chain tape. A message will state
TAPE p STARTING AT BLOCK q FOR r BLOCKS
and the user will need the directive
*READGLO p,q,r
to specify the tape and the position of global on the tape. To read information from tape 5 and enter chapter 2 assuming global is at block 25 for 11 blocks, we need just the two directives:
*READGLO 5,25,11 *ENTER 2
The chain tape must have been written as logical tape 5. The tape number of the chain tape is recorded in the global information and cannot be changed easily once that information is itself recorded on the magnetic tape.
The appendix gives a list of all the routines in the library with some brief notes on calling sequences and effects. We want to draw attention to one.
If a large volume of output is expected for any output peripheral, whether lineprinter, card punch or paper tape punch, the user should consider seriously whether it could be produced in sections. Output which is broken into sections while the program is in execution can generally be produced more quickly and efficiently than can one huge amount after the program has finished. For Hartran users the library routine OUTBRK may be called by the Fortran statement
CALL OUTBRK (N)
where N is the stream number of the output produced by WRITE (N, format) or WRITE OUTPUT TAPE N statements. PRINT statements produce stream 0 and PUNCH statements stream 15. This facility cannot be too strongly recommended and should be used whenever the output exceeds 80000 characters, about 15 densely printed pages.
This facility is used by the FORTRAN compiler so that routines with listings are printed as soon as they have been compiled and those without are treated in groups of ten.
Practical experience with the Hartran system has led to recognition of the more common difficulties in its interaction with the Supervisor and also in machine operating. Since magnetic tapes are used for intermediate storage by jobs requiring both compilation and execution, the operational convenience spoken of earlier in ordering routines in job decks is concerned with making the requisite tapes available for the job.
In discussing possible remedies for the diagnostics mentioned below, we assume that the job which has failed has not reached the execution phase. If the job is in the execution phaser the function of HARTRAN has been accomplished and errors are probably due to the program and its own interaction with the Supervisor which is much more restricted.
(i) Three diagnostics are concerned with magnetic tape:
WRONG TAPE MODE TAPE NOT DEFINED TAPE FAIL
In each case the job should be re-run without any modification.
(ii) Other common diagnostics will undoubtedly be:
OUTPUT NOT DEFINED OUTPUT EXCEEDED C TIME EXCEEDED
In each case some part of the job description is lacking or, if present, inadequate. For the first check that OUTPUT 15 CARDS so many LINES is present. The others indicate inadequacy of the allowances made for the OUTPUT streams and for the COMPUTING- request. The job can be re-run with larger requests, replacing any completely compiled symbolic routines with their binary equivalents.
(iii) Some more serious troubles can arise in the running of a compile go job:
(a) ILLEGAL FUNCTION EXCESS BLOCKS
The jobs in the machine are fighting each other for space. This job has lost the battle. Re-run the job.
(b) EXCESS BLOCKS
This can arise in two situations
The first case is one of sheer conflict between jobs in the machine. Try the job again. The second case will be accompanied by a print of the three instruction cells immediately before the executor (routine /). Check that the store request exceeds the value given in B11, plus one for each input on output stream, plus two for each magnetic tape used.
In the case of persistent failure in classes (i) and (iii), or if any other unexplained errors occur, the faulty output should be sent to E. B. Fossey or Miss B. Stokoe at the Atlas Laboratory, if the job was run on the SRC Atlas at Chilton.
Label Entry Points CHAP21 / CHAPTR NEXTCH CHAIN /EXE31 / /EXE /ERC13 /EREC /ERR24 /ERR /TOV /IOI14 /IOI IOI /MSG27 /MSG /TRK09 /TRK TRACE /TRP26 /TRP /IER /END /ERROR DUMP30 DUMP EXIT46 EXIT EEXIT /EXIT
Label Entry Points /IXP22 /IXP /RXP32 /RXP
Label Entry Points /IOH34 /IOH /IOHI /IOHO /IOX14 /IOX IOX /IOX1 /IOY14 /IOY IOY /IOY1 /ITM11 /ITM IAWD30 /IAWD INPAWD IBWD16 /IBWD INPBWD IHWD12 /IHWD INPHWD IEFG13 /IEWD INPEWD /IIWD INPIWD /IFWD INPFWD /IGWD INPGWD IKWD14 /IKWD INPKWD ILWD11 /ILWD INPLWD IOWD14 /IOWD INPOWD IREC31 /IREC INPREC /IGNCH /NLRC ISEL26 /RIS INPSEL /RSI READ OAWD12 /OAWD OUTAWD OBWD15 /OBWD OUTBWD OEFG27 /OEWD OUTEWD /OIWD OUTIWD /OFWD OUTFWD /OGWD OUTGWD OHWD12 /OHWD OUTHWD OKWD13 /OKWD OUTKWD OLWD12 /OLWD OUTLWD OOWD25 /OOWD OUTOWD OREC33 /OREC OUTREC OSEL24 /WOS OUTSEL /PSO PRINT /WSO
In addition we have the following routines
Label Entry Points INPSL1 INPSEL OUTSL1 OUTSEL IOBUFF IOBUFF IOQ IOQ IOR IOR IOS IOS IOZ IOZ ODELO1 OUTDEL
Label Entry Points TAPES2 /WAT /RAT /BTAP /BREC SETBFR BREC22 /BREC BAKRSC BTAP20 /BTAP REWIND RREC2 /RAT WREC22 /WAT /EFIL ENDFIL BFIL21 BAKFIL UTAP11 UNLOAD
Label Entry Points AERR11 AFTERR ALRM10 ALARM MRALA BRCH11 BRANCH MAXBR KILL CLOK13 CLOCK CNST23 PI RECIPI DEG RAD E LOGEPI LOGE10 LOG10E LOGE2 LOG2E GAMMA GAUSS CNTR03 CNTR /CNTR CONDFN COMDFN DATE21 DATE TODAY ICONV1 /ICONV LOG LOC LOCF XLOCF NULST1 NULSET OVFL12 /OVFL OVFLOW PAGE21 PAGE PAUS23 PAUSE /PSE /STP STOP RDTPNM RDTPNM RMCTR1 RMCTR SENSE SENSE SKPCH1 SKIPCH SUBSC1 SUBSCR TANHF2 TANHF TANH TESTAO TESTA0 TESTFN TESTFN TIME21 TIME ELAPSE TXDTM4 TXCLOK TXDATE TXTIME /TIME /DATE XPECT10 EXPECT TAPE14 TAPE TAPE7 TAPE86 TAPE8 TAPE6
Label Entry Points ABS ABS ACOS ACOS AMAX12 AMAX AMAXO AMAXO AMAXI AMIN12 AMIN AMINO AMINO AMINI AMOD21 AMOD ARG ARG ASIN ASIN ATAN ATAN COS COS DIM DIM EXP EXP FLOAT FLOAT IABS IABS ISIGN1 ISIGN LOG LOG MODIM MOD IDIM NINT1 NINT AINT INT IFIX FIX SIGN11 SIGN SIN SIN SQRT SQRT TAN TAN
There follows a brief description of some of those routines which may be called by a Fortran program.
CALL CHAPTR(N)
CALL CHAIN(N,K)
These both have the effect of calling the link N of a program down into store from the relevant chain tape.
CALL NEXTCH(N)
This positions the relevant chain tape in the optimum position for reading down link N from the tape.
CALL IOI
This may be called to initialise the input/output buffer to spaces at any time.
CALL TRACE
This will invoke the tracing routines.
CALL DUMP(X,Y)
This will dump from location X to location Y.
CALL EXIT
Causes normal exit, printing 'END OF JOB'.
CALL EEXIT
Causes error exit, printing 'JOB TERMINATED'.
CALL IOX(N)
Space the input/output buffer pointer over N places (the same effect as NX in a format statement).
CALL IOY(N)
Set the input/output buffer pointer to N.
CALL INPAWD(A,IW)
Input a word, A-format from the buffer into a word A, with a field-width IW. The input field is left-adjusted, with a natural width of 8. It may contain any characters, spaces being significant. The internal representation of characters is in Atlas Internal Code, left-adjusted in the word, filled out with spaces if necessary.
CALL INPBWD(A,IW)
Input a word, B-format, into a word A, with a field-width IW. The input field is left-adjusted with a natural width of 16. Leading spaces are treated as zeros; otherwise only octal digits are permitted. The internal representation has 3 bits for each octal digit, left-adjusted in the word, filled out if necessary with zeros.
CALL INPHWD(A,IW)
Input IW characters of Hollerith text into store starting at location A, packed eight to a word, any remaining part-word being left-adjusted. Blanks are significant.
CALL INPEWD(X,IW,ID)
Input a word, E-format, into the word X, with field-width IW, and assuming ID places after the decimal point unless one is specified in the number input. The input field is right-adjusted: after leading spaces (ignored) may be a + or - sign (optional), spaces (ignored), followed by decimal digits, possibly including a decimal point, then an exponent, which either consists of a letter E followed by optional spaces then an optional + or -sign or else a + or - sign; in both cases followed by decimal digits.
CALL INPIWD(J,IW)
Input an integer, I-format, into the word J, with field-width IW. The integer must be right-adjusted in the field, and only decimal digits should be present.
CALL INPFWD(X,IW,ID)
Input a word, F-format, into the word X, with field width IW, assuming ID places after the decimal point unless one is specified in the number input. The specification is the same as for INPEWD but there must be no exponent present.
CALL INPGWD(X,IW)
Input a word G-format, into the word X, with field width W. The specification is the same as for INPEWD, but it is optional whether or not the exponent appears.
CALL INPKWD(J,IW)
Input a word, K-format, into J. The input field is right-adjusted; it may contain any characters (spaces are significant). Characters are read in AIC, accmulated base 64, and the result given in INTEGER form. This is particularly useful with IW=1.
CALL INPLWD(A,IW)
Logical input; the input field is left-adjusted, with a natural width of 5. It should contain the appropriate number of characters of either
TRUE or FALSE
The result is represented internally by a word of all 1s or all 0s respectively.
CALL INPOWD(J,IW)
Input a word, O-format. The input field is right-adjusted; after optional leading spaces (ignored), there may be a + or - (optional) spaces (ignored) followed by octal digits (0 to 7). The octal digits are accumulated base 8 and the result given in INTEGER form, after negation if there was a - sign.
CALL INPREC
Input a record to the buffer.
CALL OUTAWD(A,IW)
Output a word, A-format, from A into the buffer, with a field-width IW. The output word will be interpreted as 8 AIC characters, which are left-adjusted in the output field. The supervisor interprets the output information, and may take special action on meeting control characters which might accidentally arise, such as tabulate, backspace or shift. If an unavailable character is met, a dot is printed.
CALL OUTBWD(A,IW)
Output a word, B-format, from A. Any output word will be interpreted and represented by 16 octal digits. These are left-adjusted in the output field, and leading zeros are suppressed, up to a maximum of min(IW, 16)-Z, where Z is the minimum number of integer places to be printed (see IOZ).
CALL OUTEWD(X,IW,ID)
Output a word, E-format. The output word is expected to be in REAL form. It is converted to floating-point decimal form, in a field, right-adjusted in the actual field IW, with a natural width of
6 + ID + max(Z,Q) (see IOQ)
made up of
sign : 1 character integral part : max (Z, q) characters point : 1 character fractional part : ID characters decimal exponent : 4 characters
the decimal exponent, e being in the form:
E sign digit digit if |e| ≤ 99
or E digit digit digit if e > 99
or - digit digit digit if e < -99
CALL OUTIWD(J,IW)
Output a word, I-format. The word is expected to be in INTEGER form, It is converted to a decimal integer with a natural width of 1 + max(Z,n) where 10n-1 ≤ value < 10n made up of
sign : 1 character integral part : max(Z,n) characters
and this is right-adjusted in the actual field IW.
CALL OUTFWD(X,IW,ID)
Output a word, F-format. The word is expected to be in REAL form. It is converted to fixed-point decimal form (i.e. without explicit exponent) in a field with a natural width of 2 + ID + max(Z,n) where 10n-1 ≤ internal value * 10R < 10n made up of
sign : 1 character integral part : max(Z,n) characters point : 1 character fractional part : ID characters
CALL OUTGWD(X,IW)
Output a word, G-format. The output word is expected to be in REAL form. This is converted to a floating-point decimal form, in which the exponent is omitted if either the value can be expressed without it, or the field width is insufficient. The presumptive number of decimal places is d = IW - b - max(Z,Q) provided that 0 ≤ d < 12.
If the formula gives d > 12, then the left-most d-12 positions of the field are spaced over, and the G-conversion carried out for the remainder with d = 12. If the formula gives d < 0, then F-conversion is used with no scale factor.
The output word is converted as though by E IW. d. Then, if the decimal exponent lies in the range 0 < e < d the decimal point is moved right the appropriate number of places, and the exponent deleted.
Thus for those items whose values are in the range 10 Q-1 ≤ value ≤ 10Q+d the output is as though by F(IW-4).(d-e),4H.
CALL OUTHWD(A,IW)
Output IW characters of Hollerith text from store location A onwards, taking 8 characters from each word.
CALL OUTKWD(J,IW)
Output a word, K-format. The output word is expected to be in INTEGER form. The output field is formed with a natural width of 6, containing characters in AIC as the base 64 representation of the output word. This is most useful with a field width of 1.
CALL OUTLWD(A,IW)
Any word will be interpreted, and represented by TRUE if there are any 1 bits, FALSE if all bits are 0. The result is left-adjusted in the output field, with natural width 5.
CALL OUTOWD(J,IW)
Output a word, O-format. The output word is expected to be in INTFGER form, It is converted to an octal integer with a natural width of 1 + max(Z,n) where 8n-1 ≤ value < 8n made up of
sign : 1 character integral part : max(Z,n) ) characters
CALL OUTREC
Publish the output buffer.
CALL INPSEL(N)
Select input stream N (Note that the entry point obtained is in INPSL, not ISEL)
CALL OUTSEL(N)
Select output stream N
CALL IOBUFF(A)
Initialise the input/output buffer to contain the character given in the leading position of A. (The standard setting of the buffer is to blanks).
CALL IOQ(Q)
Set the scale factor for E conversion to Q. The mantissa is then normalised to the range 10Q-1 ≤ mantissa < 10Q so that there are Q integer places. The standard setting is 1.
CALL IOR(R)
Set the scale factor for F conversion to R. For output the number has the value 10R times the value of the corresponding list item. The standard-setting is 0.
CALL IOS(A)
Reset the sign characters for + and - to be the two most significant characters of A. The standard setting is blank and -. If it were required to change this to + and -, for example, A would have the value 2H+-.
CALL IOZ(Z) - Z is integer
Set the minimum number of integer places to be printed to be Z, leading zeros to be supplied if necessary. The standard setting is 1.
CALL OUTBRK(N)
Cause a break of output to appear on stream N. This should be used to subdivide large amounts of output into manageable segments.
CALL SETBFR(N)
This causes a special set of fixed block length transfer routines to be used instead of variable length transfers when writing tape. It is only useful when a known maximum number of words is being transferred at any one time, and can be inefficient if there is a wide variation in the number of words transferred at any one time. SETBFR has the effect of setting the buffer length to N. Fuller details may be obtained from E.B. Fossey.
CALL BAKREC (N)
Backspace tape N by one logical record.
CALL REWIND (N)
Rewind tape N
CALL ENDFIL(N)
Write an end-of-file marker to tape N
CALL BAKFIL(N)
Rewind tape N to the last end-of-file marker.
CALL UNLOAD(N)
Unload tape N.
CALL AFTERR(N, RESCUE)
This should normally be preceded by
EXTERNAL RESCUE
On error N (where 1 ≤ N ≤ 9), control will pass to the programmer's routine RESCUE, instead of to the standard trapping position.
CNST
A routine containing
PUBLIC PI(0)
and using PI will obtain a value of π from the library to full machine precision. Similarly for the other entry points of CNST.
M = LOC(N) or LOCF(N) or XLOC(N)
This has the effect of placing the location of N into M.
CALL NULSET(N)
If N is zero, null records are ignored in paper tape input (i.e. extra new lines have no effect). If N is non-zero, they are not ignored.
X = OVFLOW(O)
This can "be used as a logical function to test the overflow indicator, and set it to FALSE.
CALL PAGE
Throw a new page on the currently selected output stream.
CALL PAUSE(N)
Prints PAUSE N, then continues with program.
CALL RDTPNM(N,A)
This reads the name of tape N to location A onwards.
CALL RMCTR(A)
This places in A the remaining number of instruction interrupts left for this program, in floating point form.
CALL SKIPCH(A)
This sets the character which will cause a record to be ignored for paper tape input. Its standard setting is ?
CALL TESTAO
This may be used to test whether accumulator overflow has taken place.
CALL TIME (A)
This places the time since the start of program in A. The time is calculated from the location counter, multiplied by a suitable factor. The result is a floating point number.
CALL ELAPSE (A)
Gives the time (in the sense of TIME) since the last call of ELAPSE, or the start of the program as a floating point number.
CALL TXCLOK(A); CALL TXDATE(A)
These give a text version of the clock time and date suitable for output by an A8 format. TXTIME is exactly the same as TXCLOK. The output would be, of the form:
11/07/65 for TXDATE and 09.47.33 for TXCLOK
CALL TAPE (I); CALL TAPE7 (I) ; CALL TAPE8 (I) ; CALL TAPE6 (I)
These set I to next character on currently selected input stream. Fuller details may be obtained from E.B. Fossey.
The system routines all have the same effect as the use of the names with a terminal F as Functions in a Fortran statement.
These errors are produced at compilation stage, before the system prints 'EXECUTION'.
The errors diagnosed are of various types, characterised by the range of the key number, k. Not all key numbers are used, as the list was built up during development of the compiler, and some "errors" became obsolete.
These 'errors' are mainly comments: anything looking a little strange is flagged just in case it is an error. If necessary an assumption is made about the intended meaning. In the compile and go system, execution is not deleted for this class of error.
Example:-
I=9K
POSSIBLE ERROR -1 (5) FOUND AT POSITION 10 OP THE ABOVE LINE
There are adjacent elements in the expression on the right-hand side, i.e. there is no operator between the 9 and the K. The error is detected when the K appears when an operator is expected: i.e. at position 10 of the line, assuming that I=9K occupies columns 7 to 10 of the card. The number in parentheses in this case is a function of what characters are legal at this point. The intended meaning is presumed to have been
I=9*K
although the error could have arisen through some other mistake, e.g. a missing zone punch on the card.
These errors are of a more serious nature, and cause execution to be deleted, as indeed will any of the subsequent errors. They also cause the suppression of binary cards, a lace 'FAILED' being produced in addition to the program card.
Example:-
ANGLE=SINF(((ALPHA+BETA) *GAMMA-THETA)
GRAMMATICAL ERROR 8 (4) FOUND AT POSITION 72 OF THE ABOVE LINE.
There are too many left parentheses in the expression. The error is not detected until the whole of the card has been scanned, hence the pointer to position 72. For further processing, the statement is amended by adding a further ) at the end.
The precise meanings of some of these list overflow errors are too technical to be included here. Instead, comments are made which will, it is hoped, be sufficient to enable the routine or statement to be modified so that it can be successfully recompiled. However, error number 1011 can occur in many ways. The second argument does provide a more precise key, and a list of these has been given in section 6.
These are not listed here because, again, their meanings are too technical to be intelligible to anyone who is not familiar with the internal workings of the compiler. In the event of repeated occurrence E.B. Fossey or Miss B. Stokoe should be contacted at the Atlas Laboratory, S.R.C.
This class of errors was introduced to cover situations which were outside the scope of the Mark 1 compiler, but were within the projected scope of the Mark 2 compiler. At the time of writing only 9008, 9012 or 9013 are liable to occur, and then only if an attempt is made to use complex or double precision variables, INITIAL statements, or COMPLEX or DOUBLE PRECISION functions.
- 1 Adjacent elements in an expression. Assume *, or, in I/O lists. - 3 Too few subscripts. Assume later subscripts 1. - 4 Constant too long. Ignore later characters. - 6 Superfluous number in DIMENSION statement. Ignore. - 7 Incorrect or missing punctuation. Ignore character, or interpolate. - 8 Inconsistent mode declarations. Ignore later declarations. - 9 Incorrect separator after an identifier. - 12 Numerical element in logical segment. - 14 Parameter previously defined as integer scalar. - 15 FUNCTION or SUBROUTINE not first statement. - 16 FUNCTION with no dummy arguments. - 17 Statement obviously inaccessible (unnumbered). - 23 Multiplication by zero. - 24 Only one successor in a computed GO TO. - 25 Missing comma in assigned G0 TO. - 26 No successor after GO TO. Treat as CONTINUE. - 27 Incomplete ASSIGN statement. Ignore. - 28 TO omitted from ASSIGN statement. - 29 Assigned GO TO with zero or blank successor. - 30 Dimensions multiply defined, but consistent. - 31 ATANF with two arguments. Assume ARGF. - 32 MODF or AMODF with one argument. Assume IABSF, ABSF. - 33 MAXF etc., with one argument. - 34 Exponentiation segment with more than two operands. - 35 COMMON block length specified. Ignore. - 38 FORMAT statement number multiply defined. - 39 FORMAT statement with no specification. - 40 Insufficient successors after IF. - 41 All successors after IF the same. - 42 Logical or Text element in numerical segment. - 44 Possible path of control to END statement. Insert RETURN. - 45 FORMAT statement number is same as one on executable statement. - 47 Text constant nH extends beyond end of statement. Reduce n. - 48 Last statement of loop contains a jump to its immediate successor. - 49 DO,FOR: integer occurs when index expected. - 50 Extra argument given in library operation (e.g. REWIND 2,3). - 52 TRUNCATION: unrecognised or superfluous name. - 53 TRUNCATION statement incomplete. - 54 ASSIGN contains extra successor. - 55 EQUIVALENCE: missing group parenthesis. - 56 EQUIVALENCE: missing subscript. - 57 Boolean constant too long. - 58 Boolean field too big. - 59 AFTER ERROR: extra routine name specified. - 60 Identifier used both as label and calculation variable. - 61 PUBLIC contains a dummy argument. - 62 COMMON contains a dummy argument. - 63 EQUIVALENCE contains a reference to a parametric array. - 64 TRUNCATION statement recurs. - 65 Subroutine name used inside routine. Treat as function. - 66 Function name was not used in routine. - 67 No path of control to this basic block. - 68 (Follows error 54 and gives positions of references). - 69 ASSIGN successor undefined. - 70 Confused input/output statement. - 71 Strange statement READ DRUM WRITE DRUM. Ignore. - 72 Hollerith constant or format spec, prematurely terminated. - 73 Strange statement WRITE. Treat as PRINT. - 74 Input/Output statement: unit or format identifier subscripted. - 75 Format identifier is not a TEXT array. - 76 Input/output statement; unit identifier is an array. - 77 Jump statement mentions itself as a successor. - 79 CALL subroutine name has been used otherwise. - 81 FORMAT statement unnumbered. - 82 Implied truncation. - 83 Integer constant in an expression is out of range. - 84 EQUIVALENCE: only one or no term in parenthesis. - 85 Incompatible modes: LHS logical or text, RHS numerical, - 86 Incompatible modes: LHS numerical, RHS logical or text. - 87 Only two successors given for an arithmetic IF. - 88 Name appears in COMMON or PUBLIC more than once. - 89 Incompatible modes RHS complex, double length, text or logical. - 90 Last statement in a loop is a jump. - 91 FUNCTION or SUBROUTINE statement improperly terminated. - 92 Zero statement number to terminate loop. - 93 Missing comma in Input/Output statement. - 94 Array name used as scalar variable. - 95 Block name incorrectly used. - 96 Equivalence before beginning of COMMON or PUBLIC.
1 Too many subscripts. 2 IF: parentheses do not match. 3 Too many right parentheses in a statement. 4 IF: too many successors. 5 Adjacent operators in an expression. 6 DIMENSION: array name already used as a function or declared parameter, 7 Illegal character. 8 Too many left parentheses in a statement. 9 DIMENSION: array name has numeric first character. 10 DIMENSION: dimension real or missing. 12 Illegal character in column 1. 14 Identifier in an expression too long. 15 Letter or punctuation in definition of statement number. 16 Multiple definition of statement number on executable statements. 18 Illegal nest structure for loops. 21 Wrong number of arguments in call of a macro (open standard function). 27 Unrecognised .CODE. 28 Expression ends in wrong phase. 29 No dot terminating .CODE. 30 Illegal combination of operators in one segment. 31 DO or FOR: wrong number of control parameters. 32 DO or FOR: control parameters not integer. 33 Statement contains, at level zero after = at level zero, but is not a DO or FOR. 35 Routine already named. 36 SUBROUTINE, FUNCTION: dummy arguments duplicated in argument list. 37 Parameter name previously defined. 38 Expression on left-hand side of a calculation statement. 41 Division by zero, 42 ASSIGN: zero successor. 43 Identifier in a declaration already used as a function. 44 Dimensions multiply defined and inconsistent. 45 COMMON: dimension not constant. 46 PUBLIC: variable dimension not declared parametric. 47 COMMON, PUBLIC: identifier already used in other sense. 48 IF: no successors or possibly parentheses not matching. 49 EXTERNAL: identifier already used otherwise. 50 Function or array name previously used as a scalar. 52 Loops incomplete. 54 Undefined successor. 55 Undefined FORMAT. 56 DO, FOR: loop ends on a transfer statement. 57 Unmatched REPEAT. 58 DO: FOR: index used in another current loop. 59 IF: comma segment. 60 Constant on left-hand side of a calculation statement. 61 DO: FOR finishes a loop. 62 DO: FOR: statement number has already appeared. 63 COMMON, PUBLIC, identifier is a function. 64 Unrecognised statement. 65 COMMON, PUBLIC, identifier is a parameter. 66 EQUIVALENCE: variable in subscript. 67 Statement number used was defined within a loop. 68 Statement number defined has a jump to it from outside this loop. 69 EQUIVALENCE: subscripted name not declared an array. 70 EQUIVALENCE: identifier is a function. 71 EQUIVALENCE: too many subscripts in subscripted variable. 72 EQUIVALENCE: array has a variable dimension. 73 EQUIVALENCE: inconsistent specification. 74 EQUIVALENCE: two items in COMMON. 75 DO, FOR: wrong separators. 76 BLOCK name used as a variable. 77 Dummy argument is a local function. 78 Dummy argument is macro. 79 Dummy argument is common block name. 80 Dummy argument repeated. 82 Local function contains a subscript. 83 Local function used before definition or multiply defined. 86 Routine name used as array, function or parameter. 87 Input/output: index of loop is not a variable. 88 Input/output: unit number not an integer scalar. 89 EQUIVALENCE: variable not local, common, public or block. 90 DO, FOR: index not a scalar variable. 91 Input/output: left parenthesis probably introducing a subscript. 92 CALL: routine name has been declared or used in another mode. 93 Relation segment: explicit comma appears. 95 Function name used as scalar variable. 96 Expression in an input list. 97 GO TO: more than one successor. 98 GO TO: illegal punctuation. 99 GO TO: missing expression in computed GO TO. 100 ASSIGN: illegal punctuation. 101 EQUIVALENCE: illegal punctuation. 102 Local function name previously used as a scalar, array, or local function, 103 Local function: mixed complex double length, logical or text in assignment. 104 Local function dummy argument is not a scalar. 105 CALL: illegal name on punctuation. 106 Boolean constant contains the digit 8 or 9. 107 INITIAL statements have come before EQUIVALENCE. 108 Two Dummy Arguments equivalenced. 109 COMMON equivalenced to Dummy Argument. 110 Array with dummy dimensions is in local or common storage. 111 Number of B-registers exceeds 80. 112 Common blocked common or public variables equivalenced to each other. 113 Equivalence of a block name.
1004 Expression too long. 1005 Expression too long. 1006 Expression too long. 1007 Expression too long. 1009 Expression too long. 1011 Too many entries for list. 1015 List of Hollerith text full 1016 Expression too long. 1017 Expression too long. 1018 Routine too long. 1019 Input/output list too long. 1020 Segment too long. 1021 Input/output list too long. 1022 Expression too long. 1023 Too many equivalences. 1024 Routine too large.
The system is designed to give the programmer as much scope as possible, whilst at the same time providing a comprehensive standard action. It is based to a large extent on the facilities provided by the Atlas Supervisor system for trapping upon the detection of certain errors.
If any errors of certain classes occur, e.g. exponent overflow or square root of a negative number, then the Supervisor consults a trapping vector, one full word in which corresponds to each possible error. This word indicates whether or not the particular error is to be trapped, and if so gives the address of the section of program to deal with it, and also the number of the B-register into which main control is to be stored. The base address of the trapping vector is set in Hartran by the executor, the routine which initialises the execution phase of a job, using extracode 1132. For all trapped errors, B90 is used to hold the original value of main control. Some error traps are grouped together, whilst a few are not trapped, since it is felt that they will not be relevant to the pure Fortran programmer. For fuller details consult ICT document CS.348 (The Atlas Provisional Programming Manual).
The trapping vector is in fact only one of four ways in which the error routines can be entered. The Hartran library input/output package contains many checks on the validity of characters in both format specifications and data. Similarly other library routines contain checks whose failure results in an error call. The third way is a call after the Supervisor has printed a diagnostic message. The Supervisor descriptions refer to this as a private monitor sequence. The entry point is set by the executor using extracode 1112. The fourth and last way is by a direct call of the routine TRACE from a Fortran program. The program will subsequently continue execution.
This routine acts as the funnel through which all errors are channelled. The physically first part of this routine is the trapping vector. After a trap, /TRP puts the available information into a Fortran compatible form, and then calls /ERR. A library input error enters at /IER to print the input buffer before calling /ERR. Other library routines cause entry to be made at /ERROR, which just calls /ERR.
The standard action is to print an error identification and the current position of control using subroutine /TRK to give a backward flow trace. TRACE is a subsidiary entry point of /TRK, which uses standard Fortran calling conventions, so may be invoked by the programmer. The overflow indicator /OVTND will be set if appropriate. Finally it either returns (via the link in B90) or exits (via EEXIT which terminates the job, printing JOB TERMINATED) dependent upon the error numbers.
Error First Second Standard Action
Argument Argument (may be changed)
Infinite result 1 AC Return
Overflow result 2 AC Return
Complex result 3 AC Return
Illegal Format 4 Illegal Character Return
Illegal Data 5 (see below) Return
End of Data 6 Stream Number Exit
End of Tape 7 Tape Number Exit
Illegal Chapter Number 8 Chapter Number Exit
Supervisor Detected Error 9 Exit
Improper Job Description 10 (see below) Return
Second argument for Illegal Data:
1 More than one . or non-digit in mantissa. 2 Non digit in exponent part 3 Exponent found when I specified 4 Exponent found when F specified 5 No exponent found when E specified 6 Non-octal digit in B or O field
Second argument for improper Job Description:
1 Same stream number used for both external (input or output) and internal (magnetic tape) stream.
Suppose, for example, we have a program as follows
READ 1, X
1 FORMAT(O16)
etc.
which is used to read in a card
12496
Then we would obtain as output something of the form
ERROR 5 OCCURRED IN THE ROUTINE ..... AT LOCATION 0002265 CALLED FROM THE ROUTINE /IOH AT LINE 0000001 CALLED FROM THE ROUTINE AT LINE 0000001 0003472.0 0300000.0 0000006.0
This implies error 5 - an input error, and the last line printed implies that it was of type 6, that is a non-octal digit in an O-field. The trouble occurred in the main routine at line 1. In this case the first two lines of tracing are not necessarily helpful, as the library routines do not at the moment preserve all the necessary information.
This Fortran statement is written, for example,
AFTER ERROR RESCUE
At the beginning of a routine, say BESSEL, containing this statement the contents of the location /ERR are saved, and at the time of execution of the AFTER ERROR statement an instruction which is a jump to routine RESCUE is planted in /ERR. At the end of BESSEL the original contents of /ERR are restored. This means that should any errors occur after the AFTER ERROR statement, but before the end of BESSEL, the routine RESCUE will be called immediately after /TRP no matter whether the fault occurred in BESSEL or in any of its subsidiaries (unless over-ridden by a subsequent AFTER ERROR statement).
The nominated routine, in this case RESCUE, should expect two arguments. The first is an integer, the error number: the second depends on the error type. In fact the errors are exactly the same as given for /ERR. The nominated routine can if required request further execution of the object program from the position at which the error was detected by simply returning.
This library routine is used to give a more specific action than is possible with the AFTER ERROR statement and is generally to be preferred. It may be called at any time and as often as desired during execution. It has two arguments, the first an integer specifying a particular error number, and the second a routine name. After calling this routine, should an error of the specified type occur, then the named routine will be entered. The error numbers are as given for /ERR. Note that there is no saving and restoring in this case. Note also that it will usually be necessary to accompany each call of AFTERR by an EXTERNAL statement for the named routine.
We here give brief examples of how it is possible to interpret the trace information:
The execution of a program may have given
ERROR 7 OCCURRED IN THE ROUTINE /RAT AT LOCATION 0104105 CALLED FROM THE ROUTINE AT LINE 0000025
On inspecting the main program, we will see that there is a WRITE TAPE statement on line 25, which will cause the library routine /RAT to be invoked, and at this stage we have reached the end of the tape.
Similarly, we might have
ERROR 3 OCCURRED IN THE ROUTINE X AT LOCATION 0000160 CALLED FROM THE ROUTINE I AT LINE 0000005 CALLED FROM THE ROUTINE AT LINE 0000002
This tells us that we have a complex result (square root of negative number, negative number exponentiated to a real number, etc.) which occurred in routine X, called from Y at line 5.
To more accurately locate the error, we must consult the storage map. From this we may find that the routine X has its entry point at 0000171.0 (octal). Now from the compilation of X, we may find that it has as its relative entry point 0000165.0. This implies, therefore, that the origin of X is at location 171 - 165 = 4. So the error must have been detected at location 160 - 4 = 154 (octal) of X. This may help to locate the error more accurately. It may, in cases of extreme difficulty, be necessary to obtain a listing of the routine X by the use of *FORTRAN LIST in order to locate it exactly.
It does not always follow that the trace information is fully accurate; the named routine is determined in a different way from the location of the error. For example:
ERROR 9 OCCURRED IN THE ROUTINE CALL AT LOCATION 0000003 CALLED FROM THE ROUTINE CAFN AT LINE 0000018 CALLED FROM THE ROUTINE CAEC AT LINE 0000050 etc.
By looking at the storage map we may find that routine CALL has its entry point at 0074631.0. Let us suppose the routine CALL has 7053 as its relative entry point; then in this case, the first cell of CALL is 74631 -7053 = 65556 (octal). Hence control cannot be in the routine CALL. We may find that Hartran Error 9 is actually due to a Supervisor detected illegal function which suggests a jump out of control. These are usually caused by computed go to's with incorrect values or by overwriting when array bounds are exceeded.
A further example is:
ERROR 9 OCCURRED IN THE ROUTINE ..... AT LOCATION 0000003 CALLED FROM THE ROUTINE /IOH AT LINE 0000001 CALLED FROM THE ROUTINE PASD AT LINE 0000046
In this case we see that the routine /IOH is mentioned, yet we do not have an input type error (5). The error is most likely to have been caused by a statement in the routine PASD executed after that on line 46 (which will be some kind of Fortran input/output statement), but before the call of any other routine or input/output statement.