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
officers.
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
DML.
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.
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
word.
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.
LAWRENCE BERKELEY LABORATORY
UNIVERSITY OF CALIFORNIA
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
ENGLAND
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
M E M O R A N D U M
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.
Honeywell
September 25, l975
Alan Clarke
c/o Rothamsted Experimental Station
Computer Department
Harpenden, Hertfordshire
England
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
owner!
Example
FIND(NEXT, SET="DEPT1", ERROR=999)
NOTE: IF DBSTAT NOT EQUAL TO ZERO GO TO STATEMENT 999.
FIND(NEXT, SET="DEPT1", ERROR=CKSTAT)
A = B+C
FIND(NEXT, SET="VENDOR", ERROR=CKSTAT)
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.
EXAMPLE
FlND(PRIOR, RECORD="XYZ", SET=DEPT, ERROR=999)
Note: Record XYZ is a record named XYZ in the Subschema. DEPT is a
character variable,
FIND(PRIOR, RECORD=XYZ,SET=DEPT, ERROR=SETA)
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
obtain a copy of NBS HANDBOOK 113 CODASYL DATA DESCRIPTION LANGUAGE JOURNAL OF
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.
Sincerely,
(signed)
Robert W. Drake
CODASYL FDBMLC
Vice Chairman
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
SHELTRAN and SHELBOL.
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.