British Computer Society Fortran Specialist Group

Minutes of a meeting held on Monday 7th February 1977 in the

Geology Lecture Theatre, Royal School of Mines, Imperial College

Computer Centre, Prince Consort Road, London S.W.7.

Present:   Mr.D.T.Muxworthy (Chairman)   University of Edinburgh

Mr.M.Lewis (Vice Chairman)    Imperial College Computer Centre

Mr.P.D.Bond                   Philips Industries

Mr.M.Dolbear                  B.P.

Mr.C.M.Evans                  D.O.A.E.

Dr.B.Ford                     N.A.G.

Mr.R.Grosvenor                Honeywell I.S.Ltd.

Mr.S.Hague                    N.A.G.

Mr.D.Hill                     C.C.A.

Mr.D.J.Holmes                 Rolls Royce (1971) Ltd., Bristol

Mr.K.Y.Lee                    Kingston Polytechnic

Dr.J.Murch1and                University College London

Mr.K.Normington               Lanchester Polytechnic

Mr.H.Pitcher                  N.C.C.

Mr.J.Roberts-Jones            Liverpool City Council

Dr.D.A.Rutherford             U.M.I.S.T.

Dr.A.Sambles                  Philips Industries

Dr.L.Schonfelder              Birmingham University

Mr.J.D.Wilson                 Leicester University

Mr.R.Woollett                 U.L.C.C.

Mr.P.A.Clarke (Secretary)     Rothamsted Experimental Station

1.   Approval of Minutes of Previous Meeting

The minutes of the meeting of 6th December 1976 were approved

subject to the following corrections: In section 1, The first

occurrence of "recommending" should have read "recommedning".

In 3.1 paragraph 1 ':*' should read ';*'. In 3.1 paragraph 2

'it's' should read 'its'. In 5. 'Mr.Muxworthy had had no reply etc.'

should read 'Mr.Muxworthy had had a reply, but it was not satisfactory'.

2.   Matters Arising from the Minutes

In 3.1 of the minutes of the December 1976 minutes it was

stated that X3J3 had received over 600 public comments on dpANS

(March 76). Mr.Muxworthy had revised information that 289 letters

consisting of 1225 pages consisting of 2388 comments had now been

received.

3.   Activities of Other Fortran Groups

3.1  ANSI X3J3 Committee Activities

The minutes of the November meeting of X3J3 had been received

and the decisions taken were reviewed. Mr.Muxworthy noted some

discrepancies in the revised draft (X3J3/76.5, Nov.1976) and

these were sent to X3J3. The minutes of the January meeting

had not been received but a summary document

had been received from Dr.Meissner (Appendix A). It was known

that Mr.D.Maisey (ICL) had attended the January meeting and it

was regretted that he was unable to attend this meeting to

elaborate on some of the decisions.

From the summary, it was not clear if the new syntax for

CHARACTER declarations was an alternative or a replacement.

3.2  International Purdue Workshop (IPW) Activities

The Minutes of the joint meeting of the Fortran Committee

of the IPW and the ISA SP61 Committee on Industrial Fortran,

8-11th November 1976, had been received. Enclosed were working

papers entitled "Management of Parallel Activities in Real-Time

Fortran" by D.Pettersen, "Initiation Key Words" by M.Gordon-

Clark , "Notes on Tasking"by Mrs. M.Hands, "A Rationale and

Proposal for Fortran Extension for Task Management" by R.Curtis

and a "Proposal to Improve the Fortran SUBROUTINE and FUNCTION

statements and their reference" by R.Caro.

The latter proposes keyword parameters. Circulation copy

of these is available from the Secretary.

Mr.Clarke said that real-time facilities in Fortran had become

topical because our Group had been asked to supply a representative

for a working group on programming languages of the BSI DPS 13,

by its chairman Mr.K.Thomson (N.C.C.). Dr.D.A.Rutherford of

the Control Systems Centre, UMIST had volunteered and attended

a meeting (see 3.3.1 below).

Mr.Clarke said that now was an appropriate time to consider

the ISA standards, and with slides (see Appendix C) he

described the main features of ISA S61.1.

3.3  Other Fortran Groups

3.3.1 Working Group 2 (programming languages for industrial

Control, systems and communication) of the BSI DPS 13

Committee

Dr.Rutherford had attended a meeting on 1st February

1977 and said that the languages being considered

included Coral, RTL2, Real-time BASIC and Fortran with

ISA routines. The objective of the Group was to be

able to provide information from which the various

submissions for standardisation could be assessed, in

order to be able to present a British recommendation at

the next ISO TC97/SC5/WG1 meeting in November 1977.

Meetings of the Working Group are to be held at 2

monthly intervals. The Chairman is Mr.K.Thomson (N.C.C.)

and other members were from IEE, ICL, RAE. the "Coral

Group", GEC and the PO.

Dr.Rutherford reported the impression that the

activities were mainly 'non-technical'.

The meeting considered the proposal submitted to

ISU by an American group - which consisted of "Real-time"

Fortran i.e. the ISA standards, and would be interested

in the UK reaction. The working group appeared to be

trying to standardise the functional requirements for

real-time languages. In particular, the "Coral 66"

proposal which contains no real-time functions is being

considered because of certain characteristics which lend

themselves to real-time usage e.g. pointer and address

processing and partword fields.

To help Dr.Rutherford with this work, a survey form

(enclosed) has been prepared and any returns would be

valuable.

3.3.2 Canadian Standards Association Fortran W.G.

We had received the minutes of the December 76 meeting

of the CSA Fortran Working Group. Included in their

list of possible future work projects are: sending

comments to X3J3 on ANS Fortran, giving publicity to

the "substantial ongoing standardisation activity" related

to Fortran, Clarifying its interest in database standards

with respect to Fortran. The group appears to consist

of about seven people, and some recruitment activity is

reported.

3.3.3 Fortran Development Committee

No FOR-WORD newsletter was received since our last

meeting. Dr.Meissner had forwarded draft details of a

Fortran loop construct proposed for discussion purposes

by Mr.W.Brainerd. Mr.Lewis described the proposals in

detail. Mr.Normington said that they were unnecessarily

complicated, but he thought the "times-clause" was a

convenient structure when used on its own. No-one seemed

impressed by the fact that "program-proving" was assisted

because the loop could be shown to terminate. There was

discussion as to whether all the logical conditions in

the 'until-clause' should be set .TRUE. on exit from the

loop. The examples described were:

DO 17 TIMES

DO FOR I = 1,N

DO UNTIL (NO DATA)

DO UNTIL (SIGNAL,ERROR) N+2 TIMES

DO UNTIL (TIRED)FOR BOTTLES=99,1,-1

A LEAVE statement is proposed, which causes the loop to

be terminated and a logical variable to be set .TRUE.

It might be used as follows:

DO UNTIL(CNVRGD,DATA ER) 1000 TIMES

-

IF (DATA.LT.0.)LEAVE(DATA ER)

-

IF (X.LT.EPS)LEAVE(CNVRGD)

-

REPEAT

IF(CNVRGD)THEN

-

ELSEIF(DATA ER)THEN

-

ELSE

-

ENDIF

Several people said that it would be easy to simulate

this type of loop using standard Fortran.

3.3.4 Dutch Fortran Study Group

Mr.Muxworthy said that he had been contacted by

Mr.Heyns and that the Dutch Group were in favour of

supporting an international Fortran development group.

4.   Progress Reports

4.1   Preprocessor W.P

Dr.Murchland said that there was little to report since the

last meeting. A document entitled 'A Review of Program

Portability and Fortran Conventions' by Mr.Muxworthy had been

studied and found to contain much valuable information including

ten pages of references. Mr.Muxworthy said that copies could

be obtained from EUROCOPI, Ispra, Italy (as Technical Report No.1 -

Sspt.1976) and cost 2500 Lira (£1.60).

4.2  Group Promotion/Information W.P

Mr.Clarke said that a draft of the revised document 'Some

activities of the Fortran Specialist Group of the BCS' was

available to those present and comments for improvement would

be welcome.

A draft of the revised contact list (version 1.1, Jan. 1977)

was available for inspection. Many more changes would be made

before the next release (version 2).

4.3  W.P. to review the CODASYL FDBMLC JOD

Mr.Clarke reported that the review had not progressed very far -

a list of section headings was being circulated to form a frame

work for the text. Pauline Walters of the BCS Technical/Branches

division had been contacted to see if the BCS would be prepared

to (re) publish the JOD in the UK. It appeared that this could

be done provided at least 200 copies could be sold (to avoid

making a loss of revenue). It is doubtful if this number of

copies could be sold in the U.K.

5.   BCS Business

5.1  Datafair 1977

Mr.Muxworthy said that our Group had been allocated a room

at Datafair, at the Cunard Hotel, from 4.15-4.45 p.m. on

Wednesday 5th October. There would be seating for 50 people.

He asked for volunteers to talk on the revised ANS Fortran.

6.   Any Other Business

Mr.Muxworthy said that the next meeting was the A.G.M. and that

himself and Mr.Clarke would be retiring as Chairman and Secretary,

and he invited proposals for replacements. Mr.H.D.(Dave) Ellison

of University of Manchester had also resigned from the steering

committee as he was about to move to the University of Salford and

new work.

Mr.Lewis drew attention to the revised CDC draft specification

for Fortran and a conversion program providing 42 points of change

for existing CDC Fortran programs.

Mr.Hi1l said that he had had informal contacts with ICL 2900 staff

involved with Fortran and who would be interested to know informally

what facilities users thought ICL should be providing. He asked for

comments to be referred to him after the meeting.

Mr.Clarke asked if members thought there was a case for Fortran

'supersets' i.e. optional alternative extensions. This had been

prompted by the CODASYL FDBML specifications, the ISA standards, and

the CADC proposal to 'standardise' plotter software. These are all

rather large and specialised.

One comment was that these constituted "application extensions"

rather than "language enhancements".

Dr.Schonfelder suggested that Fortran follow a proposal made about

Pascal; that extensions only be standardised, when the extension

has been "written in" standard Pascal.

7.   Date of Next Meeting

The next meeting will be held on Monday 4th April 1977.

Afternoon

Dr.A.Sambles (Philips Industries) gave a talk on his experiences

developing a large program (see Appendix D) and Dr.B.Ford and Mr.S.Hague

talked about the organisation and software tools used to develop,

maintain and distribute a large subroutine package. (Details to be

included with minutes of next meeting). Statistics relating to the

transportability of the Fortran were presented. A document describing

these entitled "On the enhancement of portability within the Nag project"

is available, on circulation, from the secretary.

APPENDIX A

SUMMARY OF ACTIONS TAKEN AT JANUARY 1977 MEETING OF X3J3

The draft describes certain "properties of a file", including the access

method (sequential or direct), the form (formatted or unformatted), the record

length, and the maximum record number (if any); it seems to imply that these are

inherent attributes that become attached to the file at the time it is created

and must remain unchanged thereafter. The terminology has now been modified

to clarify that the properties of a file are a set of allowed access methods, a

set of allowed forms, etc., while the particular choices currently in effect are

properties of the connection rather than of the file. Specifiers for access,

form, etc. in the OPEN and INQUIRE statements therefore relate to the present

connection. New specifiers have been added to the INQUIRE statement to improve

information concerning the set of allowed access methods and the set of allowed

forms.

Use of the FORM attribute in OPEN and INQUIRE statements is no longer

prohibited if a file is connected for sequential access. When this specifier is

omitted  from the OPEN statement, the default for a direct access connection is

UNFORMATTED and for a sequential connection is FORMATTED.

Either part of a complex constant may be a real constant or an integer

constant.

An integer, real, or complex expression may be raised to

a real or complex power. The interpretation of x_l ** x₂ is defined to be the

same as that of EXP (x₂ * LOG (x_l)), where the principal values of EXP and LOG

are those of the Fortran intrinsic functions. (Use of the processor-implemented

EXP and LOG intrinsics is not necessarily recommended; they merely define the

principal value of the result.)

If a function subprogram contains one or more ENTRY statements, a reference

to one of these functions must not cause the definition of an associated function

name (as a variable) that is not of the same type as the referenced function.

Change the syntax of the FUNCTION statement so that the parentheses are

mandatory even if there is no argument list.

The formula for unformatted record length in section l2.l.2 is eliminated.

The length of an unformatted record is "measured in processor-dependent units".

If the list of an unformatted WRITE does not fill the record on a direct access

file, the remainder of the record is undefined.

For list-directed data, a complex constant may have blanks before or after

either the real or the imaginary part.

Negative zero is prohibited in the exponent field for E and D output.

The precedence of .XOR. is changed to the same as .EQV., and the name is

changed to .NEQV.

In a CHARACTER declaration, when a length specification applies to more

than one of the entities being declared, those entities are enclosed in paren-

theses and the length specification is written at the end. Thus, according to

the draft, a declaration might appear as

CHARACTER *7 A*6, B, C, D, E*8, F(3)*8, G*l

this would now become

CHARACTER A*6, (B, C, D)*7, (E, F(3))*8, G

Also the IMPLICIT CHARACTER and CHARACTER FUNCTION statements are changed as

shown in the following examples:

IMPLICIT CHARACTER (B - D) * 7

CHARACTER FUNCTION CF (X, Y) * (*)

An integer, real, double precision, or complex entity in an nlist of a

DATA statement may correspond to an integer, real, double precision, or complex

entity in a clist. Type conversion takes place as with assignment.

The length specified for a statement function dummy argument of type

character must be an integer constant expression.

L. P. Meissner

27 January 1977

APPENDIX B

To: X3J3

From: British Computer Society Fortran Specialist Group

Date: l6th February, 1977.

Subject: Comments on Fortran 77 Full language X3J3/76.5 (76-11-30)

The following editorial points were noted at our meeting of

7th February, 1977.

1. The Group repeats its objection to the use of the

word 'redundant', applied to type specifications

in section 19.2 item (9). It is clear from

section 8.4 that 'duplicate' is intended.

2. The decisions taken on 'extended range of Do loops'

at the November l976 meeting of X3J3 have not been

incorporated consistently in X3J3/76.5. In section

11.10.2, lines 35O - 351 contradict lines 361 - 364.

Appendix C

      SUMMARY OF THE WORK OF THE JOINT INTERNATIONAL PURDUE WORKSHOP

(IPW) FORTRAN COMMITTEE AND THE INSTRUMENT SOCIETY OF AMERICA

   (ISA) COMMITTEE ON INDUSTRIAL FORTRAN

Standard ISA S61.2 (1976)

Fortran Procedures for

* Executive Interface,

* Process Input/output,

* Bit String Manipulatlon And

* Date And Time lnformatlon.

The procedures are expected to be executing both in a solitary and in a

multiprogramming environment under the control of a real time executive

routine.

EXECUTIVE INTERFACE

Procedures to start, stop or delay execution of a program.

Start a Program Immediately Or After A Specified Time Delay.

CALL START ( PROG, DELAY, UNITS, STATUS)

where        PROG specifies the program to be executed (either an integer

expression, array or procedure name)

DELAY is the time delay (in UNITS units) before executing the

program

UNITS is units of time (either real-time-clock units,

milliseconds, seconds or minutes)

STATUS returns status (1 = accepted, 2 or more = rejected)

Start A Program At A Specified Time Of Day

CALL TRNON ( PROG, GOTIME, STATUS)

where        PROG and STATUS are as for START

GOTIME is an integer array whose first three elements contain

Hours,  Minutes, and Seconds

Delay Continuation Of A Program

CALL WAIT ( DELAY, UNITS, STATUS)

where        DELAY, UNITS and STATUS are as for START.  WAIT returns after the

specified time delay

Terminate A Program - use STOP

PROCESS INPUT/OUTPUT INTERFACE

Control Of Analog And Digital Sensors And Output.  Each Procedure

Performs An Unformatted Input/Output Transfer.

Analog Inputs In A Sequential Order

CALL AISQW ( NDATA, TRANS, BUFFER, STATUS)

where        NDATA is the number of analog points to be read.

TRANS provides transmission information.  i.e. (processor

dependent) hardware or software acquisition and conversion

inform atom, (as an integer expression of array).  It specifies

the first point to be read and the form of all the data placed

in BUFFER.

BUFFER is an array to receive the data

STATUS returns status (all data collected =1, operation

incomplete = 2.  error = 3 or more)

Analog Inputs In Any Sequence

CALL AIRDW ( NDATA, TRANS, BUFFER, STATUS)

where        NDATA and STATUS are as for AISQW

TRANS is as for AISQW and also controls the input sequence

BUFFER is an array to receive the data.  the order of the

elements in BUFFER will correspond to the order in TRANS

Analog Output In Any Sequence

CALL AOW ( NDATA, TRANS, BUFFER, STATUS)

where        NDATA, TRANS, STATUS are as for AIRDW

Digital Input

CALL DIW ( NWORDS, TRANS, BUFFER, STATUS)

where        NWORDS is the number of external digital words to be read.

TRANS, BUFFER and STATUS are as before

Momentary Digital Output

CALL DOMW ( NWORDS, TRANS, BUFFER, PERIOD, STATUS)

where        NWORDS, TRANS, BUFFER and STATUS are as as before

PERIOD is the duration in basic system clock counts that the

outputs are to remain set.  ( PEROID may be ignored but must be

present.)

Latching Digital Output

CALL DOLW ( NWORDS, TRANS, BUFFER, LATCH, STATUS)

where        NWORDS, TRANS, BUFFER and STATUS are as as before

LATCH is a masking array defining digital outputs which can be

changed by DOLW

Causes the output of digital signals which can be latched in either the

set or reset state.  These signals consist of sets of bits typically

organised as an external digital word.

Appendix D

Summary of a talk on 'A Large Scale Fortran Project' by Mr.A.Sambles

(Philips Industries)

The project was to write a comprehensive electronic circuit analysis

program. This was to be undertaken at two sites and use two different

computers during development. Fortran was chosen because it was

available and was reasonably efficient at run-time. Programming

considerations to co-ordinate the groups determined a strict set of

rules for coding subroutines. Data structure documentation and COMMON

allocation was made the responsibility of the Project Leader. Test

versions were run at both development centres at frequent intervals to

help clear non-standard features at the earliest opportunity. A

comprehensive benchmark was run before new versions were released.

Coding Rules enforced included: beginning subroutines with

descriptions of arguments, inputs/outputs, list of called and calling

subprograms; code should contain about hO% comments; No local variables

were to be used; No assumptions of variables being initially defined

(e.g. as zero).

Naming conventions were as follows: names starting with I-N are

integer, B are boolean, C are complex, D are double precision and the

remainder are real.

COMMONs are organised so that arrays and variables are not in the same

COMMON. Nested DO loops do not end on the same labelled statement,

statements are labelled in order. Formats are labelled n+1000 where n

is related to the adjacent statements. Subroutines contain less than

150 statements. All errors are processed by a CALL EROR procedure.

All machine dependent constants are held in COMMON. All array dimensions

are held in one COMMON. Use of assembler is kept to a minimum.

A diagnostic built-in debug which is controlled by flags which can be

set in the input stream has proved worthwhile.

The conclusions are that the system works, it is transportable,

there are numerous cases of code extension by programmers other than the

originator. The programmers initial reaction that some of the

conventions were bureaucratic soon subsided and it was found acceptable

for a one person to be responsible for COMMON organisation.

British Computer Society Fortran Specialist Group

Survey of Fortran usage in real-time and process control applications

This survey is to assist the working Group 2 (Programming Languages for

industrial control, systems and communications) of the BSI DPS13 in obtaining

information for the purpose of formulating recommendations for standardisation.

If you can answer any of the questions below this would be much appreciated.

Questions

1.   What is your interest in real time facilities for Fortran?

e.g. Process Control? Scientific experimentation?____________________

2.   Are you aware of the Instrument Society of America (ISA) Standards,

ISA S61.1 and S61.2? ________________________________________________

3.   Please indicate which facilities listed overleaf, or near equivalents,

which are available to a Fortran program on your processor. Indicate

in the 'specification'column, the standard used e.g. ISA, Computer

Manufacturers standard, CAMAC, Company/Department or 'local' specific-

ation. The procedures in brackets (e.g. CALL START) are those defined in

the ISA specifications. Some of the functions such as OPEN file and

Direct Access I/O are currently included in the draft proposed ANS

Fortran.

4.   Please give number of processors to which your answer applies:

        Mainframe_____  Mini_____  Micro _____ Other _____

5.   Please tick estimated (rough) usage.

rarely -- Yearly -- Monthly __ weekly __ daily__ hourly __ continuous __

6.   Any comments on the ISA specifications e.g. have you found it necessary

to modify them?

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

7.   Suggest any other persons to whom this survey should be sent _________

Name and address:_____________________________________________________

______________________________________________________________________

______________________________________________________________________

8.   Completed survey forms should - either be sent to:

Dr D.A. Rutherford, Control Systems Centre, UMIST,

P.O. Box 88, Manchester M50 1QD.

- or may be handed in at the next BCS FSG meeting.

D. A. Rutherford

21.1.77