British Computer Society Fortran Specialist Group

Minutes of a meeting held on 2nd October 1975

at Datafair 75, Cunard International Hotel,

Hammersmith, London W.6.

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

Mr. G. A. Croes                  Shell International Petroleum

Mr. M. R. Dolbear                B.P., London

Mr. J. L. Dyke                   Huntingdon Research Centre

Mr. G. Erwin                     L.U.C.S. Ltd, London

Mr. J. B. Haseler                G.C.H.Q. Cheltenham

Mr. D. J. Hide                   Shell International Petroleum

Mr. D. Hill                      Micro Computer Systems Ltd.

Dr. J. Murchland                 U.C.L.

Mr. P. Partington                Management Dynamics Software Services

Mr. T. Patel                     Compulogic Ltd.

Mr. R. W. S. Rodwell             I.C.L.

Mr. J. Tidmarsh                  B.R. Technical Design Branch

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

Apologies for Absence

Dr. A. C. Day                    U.C.L.

Mr. F. A. Perris                 I.C.I.

1.      Approval of Minutes

        The minutes of the meeting of 1st September, 1975 were approved subject to

the following corrections. Throughout 'Mr. Morice' should read 'Dr. Morice'. In

section 4-2, 'systax' should read 'syntax' and the paragraph: 'Some comments were

sent to the CODASYL FDBMLC group'should be added. In section 4.3 'Acitvities'

should read 'Activities'. In Appendix B 'preformed' should read 'performed'.

2.    Matters Arising

(a)   Section 4.2, the comments sent to the CODASYL FDBMLC had not been included in

the minutes, and have been attached to these minutes (see Appendix C).

(b)   Section 6, Mr. Patel described a program for relabelling Fortran programs and

producing cross references, distributed documents relating to this. The

program is called COMFORT and is obtainable from Compulogic Ltd., 119 Oxford

Street, London W.1. It is currently implemented on IBM, ICL, UNIVAC, CDC,

Honeywell, Burroughs and Xerox Data Systems machines and requires

approximately 55K Bytes or 19K words. There is a leasing charge.

Some members present knew of relabelling programs available free of charge.

Most of these were specific to a single manufactures Fortran.

3.    Future Activities

Mr. Muxworthy informed those present that a series of speakers was being

arranged. And that to facilitate this, the steering committee suggested that

meetings be planned for the first Monday in alternate months. There were no

objections to this.

The question of when the ANSI draft standard would become available and what

arrangements for publication were being made was raised. The latest information

we have is that the draft standard will be subject to a letter ballot in December.

If it is approved, then publication for public comment would follow. Publication

details are not clear yet. The minutes of the July ANSI meeting indicate that

there is an arrangement to publish dpANS X 3.9 in the ACM SIGPLAN journal.

Persons wishing to obtain a copy of the document should contact the

secretary.  The secretary holds a list of names of persons who have already

requested a copy and those persons need not re-apply.

Prior to the meeting, Dr. A. C. Day (U.C.L.} had expressed the view that the

group should form a working party to review the new ANSI draft standard in a

similar manner to that adopted by the original working party. chaired by

Mr. B. H. Shearing on extensions to the American National Standard Fortran.

The terms of reference of this new working party have yet to be defined but

it is expected that the review would cover constructive criticisms, details of

where the revisions differed from our views and expectations (as expressed in our

original proposals and our correspondences) and the implications for existing users

and implementors.

Members wishing to join this working party should inform one of the group's


4.    Fortran Group and Committee Activities

4.1   ANSI X3J3 activities.

Mr. Muxworthy conveyed the reply by Frank Engel (see Appendix A) to our last

set of comments on the ANSI X3J3 Fortran Revisions.

The revisions made at the July 1975 meeting of X3J3 were read and discussed.

Mr. D. Hill (MCSL) noted that the syntax of the proposed CHARACTER*len

FUNCTION name (--) was not CHARACTER FUNCTION*1en name (--) which might be a more

simple syntax - also conforming to IBM length attributes.

Those present saw no difficulties with the X3J3 proposed syntax.

It appeared that there was little more that we could contribute to the

current X3J3 proceedings until Fortrev becomes (we hope) a draft standard after the

December ballot, when we could make public comment.

4.2   CODASYL FDBMLC activities

Mr. Clarke reported on the reply by Mr. R. Drake (H.I.S.) (see Appendix D)

which had been received from the CODASYL FDBMLC in response to the comments (see

Appendix C) we had made at our last meeting.

The CODASYL committee have now reached an advanced state of development of

the form of a Fortran Data Manipulation Language for accessing databases and are

expected to publish their proposals. It is believed that their publication will be

forwarded to ANSI X3J3 for consideration as one of documents which will be the

basis of discussions for the next round of standards revisions, in five years time.

A copy of the Aberdeen University Database Programming Manual had been

received from Mr. J.S. Knowles. This was probably one of the first British

implementations with a Fortran DML interface - with a syntax based on the COBOL


Mr. Dolbear (B.P.) said that he believed the Central Statistical Office

(Cabinet Office) had a Fortran interface to a Database management system,

but did not know the details of this.

4.3   Fortran Development Committee

Correspondence has been received from Dr. L. Meissner. This included a

letter (see Appendix B) which indicates that our views on future Fortran revisions

will be gladly received. Also copies of the Questionnaire relating to the survey

of structured Fortran pre-processors were received and members who are involved

in the development of structured Fortran pre-processors and wish to contribute

may obtain a copy of the forms from the secretary.

The purpose of the survey is to study as many existing implementations as

possible in order to formulate a good method of introducing structured programming

ideas into Fortran. There will be a discussion of these implementations on

9th February, 1976 at Fortran Forum West to be held at the Disneyland Hotel,

Anaheim, California.

Currently the survey covers more than 50 such pre-processors.

A summary document of a 'Workshop on Fortran Pre-processors for Numerical

Software', held at the Jet Propulsion Laboratory in November 1974 has been received

from Mr. C. L. Lawson (J.P.L.). The document contains one page summaries of about

30 pre-processors including a British contribution by B. Ford and S. Hague on

'NAG Numerical Software Maintenance - The Predictor Corrector Approach'. The

document is currently being circulated to members, and any member who wishes to be

included on the circulation list should contact the secretary.

5.    Any Other Business

Mr. Dolbear asked if anyone knew of a facility for monitoring the execution

of Fortran Programs similar to that recommended by D. Knuth in a paper 'An

empirical study of FORTRAN programs' published in Software Practice and Experience,

Vol 1, pg 105-133 (1971).

The monitor produces a dynamic profile of instructions executed.

Mr. Muxworthy replied that he knew that Dr. Day had such a program which was

written in SNOBOL. Mr. Clarke replied that he had a similar program written in

Fortran, known as EFFORT (Eficient FORTran) and had found it useful for indicating

areas of programs that had not been tested, as well as indicating heavily used

instructions. The program was freely available.

6.    Presentation by Mr. G. A. Croes

Mr. G. A. Croes described the main features of the SHELTRAN pre-processor

(see Appendix E) and outline some future developments. He distributed copies of

his paper entitled 'Aspects of Structured Programming in Fortran' published in

Informatic jaargang 17 nr. 3 pag 109 t/m 163 Amsterdam maart 1975 together with a

sample SHELTRAN program to solve the 8-Queens problem.

The presentation was followed by questions and discussion.

7.    Date of Next Meeting

The next meeting will be held on 1st December 1975.

Appendix A

Alan Clarke, Sec'y, BCS/FSG                                                September 11, 1975

Rothamsted Experimental Station

Harpenden, Hertfordshire, England

Dear Sir,

Thank you for your note of Sept. 8 and your past communications keeping us informed of

the opinions of your group. While I/we may not have responded in writing on each occas-

ion, I assure you that they have been duly noted and considered by the members of X3J3

in our deliberations. We appreciate your valued assistance, and hope that our product

will be the better for it. At this late stage (it seems that I have been saying that for the

last four years), we might be unable to take your suggestion because of our inability to

find appropriate wording to repair the document within the available time frame. This

comes to mind particularly with reference to your item 1. You are quite right, we should

have done something about the blank character, but what? We did not even address the

question, to the best of my recollection. Do we throw it in with the alphabetic characters,

for the purpose of assigning it a position, and at which end? You seem to indicate that it

should be in a third class, separate from the letters and the digits, which it now is, but

that it should be assigned a position in the collating sequence. That is where we fear to

tread! My own inclination is that the blank is close to a null in character data, and should

precede the letters, so that appending blanks would not change the sorting position of a


On item 3, I personally agree with you, and I strongly opposed the X3J3 action. The vote

was close, and could be rescinded, but I doubt that it will happen. My reasons are mainly

concerned with the political implications with respect to the acceptance of our efforts. It

is probably true that every implementation will provide the Hollerith feature for reasons

of compatibility with previous processors, which I think the market place will demand,

and that whether or not it is in the standard language will not affect the cost of implement-

ation or the availability of the feature. However, we have removed a feature from the

standard language that is widely used in existing programs, (although it is not certain

how many of them are standard conforming programs) and we lay ourselves open to cri-

ticism on a matter that will bring out strong emotions. It hardly seems worth the jeopar-

dy of the whole effort on such a point. Again, what do you suggest as the definition of

the proposed standard HASH function? It seems to me that this is analogous to specifying

a collating sequence, and we don't know how to solve that problem. My own preference is

for us to take the bull by the horns and declare that the FORTRAN character set has a

sequence which we specify, and provide the leadership necessary to effect some order in

this chaotic situation. My associates in X3J3 tell me I am dreaming, if I think that FOR-

TRAN could take independent action here. The only course we could take would be to a-

dopt the ASCII set, and there is a significant part of X3J3 that is opposed to that course

of action.

On item 4, I believe that you have misunderstood the action of X3J3. The motion changed

only the syntax of the substring reference , and the part of /62 Appendix X relating to the

length specifier was not adopted, according to the minutes and my notes of the meeting.

The type statement syntax was not changed. Again, I personally was opposed to this

action by X3J3. From the standpoint of a user, this is awkward and less intelligible in

reading statements. It also suffers from a lack of regularity when an extension to deal

with subsets of arrays is provided. The old view of an array element reference was

that it was a function reference, i.e. a reference to the array successor function. To

me, the substring reference was not a separate function that was added as implied by

the new syntax, but rather an extension to the old function that provided a means

of identifying several elements in succession. I maintain that this is desirable for array

elements as well as for characters, and that the former syntax was preferable. I think

we should avoid the connotation of the SUBSTR function, but I lost on this one too. I con-

clude that your example is not in accord with X3J3 actions, or /69 FORTREV.

As you probably know by this time, we are proceeding with our letter ballot to accept

the next version of our working draft as the dpANS X3.9 revised FORTRAN Language.

The closing date is to be Dec. l, to allow us more time to consider the full language

document, and to have at least thirty days on the subset document letter ballot terminat-

ing on the same date. We hope to be able to ask X3 to approve the document for further

processing as the dpANS in December-January, so that the public review and comment

period will be February through June (1976?) .

I have proposed at this time to appoint a new. subcommittee to begin consideration of the

next revision. Of course the first question is whether or not it should be expected that

another revision will he attempted. If so, then next should be developed appropriate cri-

teria to guide its development. Then there are so many items that we are already aware

of that we have not been able to include in this revision, and there will undoubtedly be

many more suggestions arising out of the comments from the review of this revision that

cannot be incorporated in the document now. The committee could begin to collect these

items and classify them preparatory to further work. I would hope to secure a wider

participation in this subcommittee, including the Purdue Workshop/lSA Industrial Con-

trol Languages group; the FORTRAN Data Base Management,Language Com. of CODASYL

the Structured FORTRAN Committee, and others. Perhaps your FORTRAN Specialist

Group may also want to throw in the towel, so to speak, with respect to the present re-

vision and begin to consider what can be done afterwards to effect further improvement.

My thought is that by getting started now, we may be able to meet the ANSI requirement

that the standard he reaffirmed, revised or rejected within five years of its approval! If

there is to be another revision of the language, and these other diverse features are to

be include, there should be some provision for subdividing the language other

than the proper subsets now postulated. Thanks again for your help.

(signed) Frank Engel Jr.

Appendix B



     BERKELEY, CALIFORNIA 94720  TEL, (415) 843-2740

50-B 3239

22 Sep 1975

P. A. Clarke

Computer Department

Rothamsted Experimental Station

Harpenden, Hertfordshire AL5 2JQ


Dear Alan,

I was glad to receive your letter of l7 Sep, including the recent

minutes of meetings of the BCS Fortran Specialist Group. I assume that

BCS and your Group will not object if I find items of interest in your

Minutes that seem to he worth reprinting in For-Word.

I will also print in For-Word your invitation to attend meetings of

the BCS Fortran group, and future schedules insofar as they reach me in

time to be of current interest. I will be happy to hear your further

ideas on the subject of Fortran development. Walt Brainerd who is on the

X3J3 committee, has been writing to me, and he has proposed a general de-

bate on the question: "Fortran is ready for a major revision (not just

adding more bells and whistles)." This of course means revision beyond

what the committee is working on currently. Any thoughts that you or

your friends may have on this question will he gladly received.

Sincerely ,

(signed) Loren

Loren P. Meissner

Appendix C


To: CODASYL FORTRAN DBMLC                 From:   B.C.S. Fortran

Specialist Group

cc:                                       Date:   16th September, 1975

Subject: Comments on Items Under Discussion

The following points arose at our meeting of 1st September,

1975, The comments relate to the minutes of meetings #5, #6, #7.

1.   Members of the group did not see from the evidence presented

in the minutes of meeting #6 the necessity to introduce a

'procedure call' of the form: ERR=SETA(...). The new

form seems to require an unnecessary syntactic extension

to Fortran. It also introduces a complication with the

flow of control. Which instruction is executed when

control returns from SETA?

The same action could be achieved by : ERR=1abel - where

label is the statement number of a statement:

label CALL SETA (...)

Note that the form: ERR=label has been widely implemen-

ted and is under consideration for standardisation by

ANSI X3J3. It is also provided in your syntax definitions

included in minutes of meeting #5.

2.   From details given in minutes for meeting #6, it appears

that the meaning of RECORD=XYZ may be determined at exe-

cution time. It is not clear what effect this would

have on implementations which "host" the DML statements

by means of a Fortran preprocessor.

3.   Members would be interested to see a draft of the pro-

posed Appendix A - sample programs with all details, as

soon as possible, in the hope that this will clarify

the purposes and method of use of the DML statements.

Despite reading the relevant documents, we have difficulty

in understanding information provided in your minutes.

This means that we are not able to contribute to the pro-

ceedings as we would like. We hope that the final docu-

ment produced by the committee will be 'comprehensible to

any Fortran programmer' without having to make extensive

cross-references to other documents and without having to

become intimately knowledgeable about COBOL.

Appendix D


September 25, l975

Alan Clarke

c/o Rothamsted Experimental Station

Computer Department

Harpenden, Hertfordshire


Dear Sir:

I was most happy to receive your memo of September 16, 1975 and at the request

of Dr. Chester Smith our chairman, I will try to answer it from my viewpoint.

I appreciated your input so much that I real1y wanted to respond as an in-

dication of that appreciation.

Your point #1.

The ERROR phrase allows dynamic selection of the action to be taken when the

DBCS (Data Base Control System) returns a non-zero status at the completion

of a DML (Data Manipulation Language) statement. The ERROR phrase specifics,

for the statement attempted, the statement number or the subroutine name to

receive control as the user "processes" the non-zero status. The status of

any DML statement is returned to the user by the DBCS in a field generated

by the Fortran data base compiler (probably in common) named "DBSTAT" whose

Fortran Data Type is integer. It is up to the Fortran programmer to check

this field to make sure that his DML statement executed correctly against the

data base. Regarding error conditions, there are two requirements that exist

on sites that I am aware of:

l.   The programmer handles his own error conditions.

2.   There is a common suh-routine written by the techniques

group at a site that must be executed where all error

conditions are encountered, This is a site edict.

Regarding point number l, there will be a number of times that a Fortran

programmer will want to execute the same error procedure and return control

to the next statement following the statement containing the error test. Note

here, that DBSTAT is a status set by the DBCS and can be set to non-zero on

other than error conditions, i.e., "0502100" is a status return for "end

of set occurrence", i,e., you have "walked" around a set occurrence from its

owner, "finding" all members in the set occurrence and are now back at the






A = B+C


X = W*Y

NOTE: CKSTAT is a subroutine that could check DBSTAT for "0502100", Depending

on logic either return control to the next statement depending on where it

came from i.e. A = B+C or X=W*Y or do its own thing. The error phrase

takes the form of ERROR = <statement number>

                          <subroutine name>

I hope this has answered your question #1 and/or generated other questions.

Your point #2.

Since Fortran, in general, has many features and capabilities that COBOL

does not have, the committee has tried (only time will tell how successfully)

not to limit these capabilities. Fortran, on many computers with communication

capabilities, is interactive and thus Fortran programmers are usually very

interactive time-sharing oriented. This might draw many arguments from the

COBOL programmers, but being an old hand at data bases (since l96l) and COBOL I

believe I could prove my point, and you probably more successfully than I! In

keeping with this theme, a general rule adopted by the committee has been to

not limit the FORTRAN DML to a batch oriented, non interactive system. This

does not limit you from implementing either a batch or interactive DML. We have

adopted the following form, if a name is enclosed in quotes it is a name

defined in the Subschema. If it is not enclosed in quotes it is a character

variable, the contents of which contain the name defined in the Subschema.



Note: Record XYZ is a record named XYZ in the Subschema. DEPT is a

character variable,


Note: Both XYZ and DEPT are character variables as defined in 6.2b of FORTREV.

Your point #3.

I believe Dr. Chester Smith, our chairman, is sending you a copy of our working

document. I personally would point out that, at this time, it is still under

heavy modification. As to your participation, our committee certainly welcomes

and encourages it! I would recommend that you obtain a copy of the DBLTG

Proposal 73001.03 which has now been approved. I would also recommend that you


DEVELOPMENT JUNE 1973. This document defines the Schema and its concepts. The

other document defines the COBOL Subschema and gives you an idea of what is in

a Subschema.

The committee's final document will be as comprehensive as we can make it,

within due bounds of course. There is no way that we can make it into a data

base management course or teach a programmer data base management thru our

documentation. My own personal belief, after a number of years of experience in

data base management, is that the FORTRAN programmer - just like the COBOL

programmer - cannot just pick up a manual and start writing data base

management system programs, he will need to have training in the data base

environment and its interaction in the computer system he is working on.

If I or the committee can be of any further help, please write us.



Robert W. Drake


Vice Chairman

Appendix E

The ideas presented by Mr. G. A. Croes in his talk on SHELTRAN related the phil-

osophical discipline of structured programming to practical implementations in


The goal of his approach was the production of good programs with {he correct

structure which would be adaptable and self documenting. This was to be attained

by the use of simplified logic control structures and data structures.

The logic control structures would replace GO TO statements and the concept

of labels (or addresses) which machines can manage, but which lead to 'logical

spaghetti' in human thinking, would be abolished.

The framework for the improved control structures in SHELTRAN are the

statements for selection:

1.    IF condition THEN statements {ELSEIF condition} ELSE statements CIF

2.    SELECT expression CASE ni {nistatements}... OTHER statements CSELECT

The statements for iteration:

1.    LOOP ['NAME'] [[DOWN] variable = expr,expr[,expr]]

2.    WHILE condition statements XWHILE{[WHEN condition]} statements CWHILE

3.    REPEAT statements {XREPEAT [WHEN condition]} statements UNTIL condition

In the future it was planned to implement internal data structuring (possibly

along the lines of that provided by the CLASS construct of SIMULA) and external

data structuring (possibly in the form of CODASYL database ideas).

Further in the future, the idea of an integrated support system consisting

of a multitude of utilities to facilitate the programming and design functions

was being considered.

In practice SHELTRAN had proved valuable on a variety of machines. Versions

for these machines could be generated by supplying the machines characteristics

together with those of its Fortran compiler. Unlike many other pre-processors,

the (120) error messages produced by SHELTRAN are such that as many errors as

possible are trapped as early as possible and there is no need to see the Fortran

code generated.