MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING HELD AT ROYAL

INSTITUTE OF PUBLIC HEALTH AND HYGIENE, PORTLAND PLACE, LONDON ON

8 JANUARY 1987



Present:        Stephen Brazier       - Prime

                David Burns           - NCC

                John Dyke             - Huntingdon Research Centre

                Miles Ellis           - Oxford University

                Anne Gooding          - Air Products Ltd

                David Hewitt          - Coventry Polytechnic

                Carol Hewlett         - LSE

                Peter Holland         - SS(E)L

                David Holmes          - Rolls Royce

                Chris Lazou           - ULCC

                Clive Massey          - SWURCC

                David Muxworthy       - University of Edinburgh

                Keith Normington      - Coventry Polytechnic

                Mike Nunn             - CCTA

                Kevin Pritchard       - UMIST

                T L van Raalte        - MOD (PE)

                Neil Smith            - RAE, Bedford

                Tony Webster          - Salford University

                Alan Wilson           - ICL

                John Wilson           - Leicester University

                John Young            - MOD (PE)



1.  APOLOGIES FOR ABSENCE


Apologies were received from David Griffiths, P Kraven and

Lawrie Schonfelder.


2.  MINUTES OF PREVIOUS MEETING  [16 October 1986]


Correction to page 5, paragraph 6 (iii). This should read:-


    "The Chairman said that FORCHECK (an F77 verifier/checker) was

     now available for PCs".


3.  MATTERS ARISING


    (i)  Membership renewal form.


         The Secretary had been drafting a membership renewal from

         which all Group members would in future be required to

         complete annually to indicate that they wished to stay on

         the Group's mailing list. It would also be used as a

         registration form for newcomers wishing to join the Group

         and to collect annual dues (£5) from non-BCS members.


    (ii) Fortran Forum


         The Group intended to hold a Fortran Forum later this year

         and there was some discussion on when this would be. It was

         decided that no date could be set until after the next X3J3

         meeting when it was hoped that the date for the release of

         the draft 8X standard for public comment would be known.

         All those registering for our Forum would be supplied with

         copies of the draft. It would be sent out well beforehand

         to give attendees sufficient time to digest it. Suggestions

         for attractive venues for the Forum from members would be

         most welcome - please contact the Secretary.


         A sub-committee was appointed to organise the event. Those

         offering to help included Chris Lazou, Miles Ellis and

         John Wilson. John Reid (Harwell) who organised the agenda

         and X3J3 speakers for the last Forum will be invited to help

         as well. Because BCS Conference Section is heavily loaded

         over the next eighteen months it was doubted whether they

         will be able to offer much assistance. Any Group member

         willing to help the sub-committee organise the Forum should

         contact our chairman (John Wilson).


4.   BCS BUSINESS


     (i) BCS has yet to decide on its funding allocation to the

         Fortran Group for the coming year. At present we have a

         surplus of about £1,200 which it is intended to use to set

         up the Forum. We would of course eventually hope to get the

         costs back from receipts.


         The Chairman suggested that some of the Group's funds might

         be allocated to fund the cost of himself attending X3J3

         meetings as an alternate for Miles Ellis when he was unable

         to be there. It would enable our Group to have a close link

         with X3J3 activity. However, after some debate it was

         agreed that it would be more appropriate to reserve any

         funds we possess to cover the costs of setting up the coming

         Forum. we might, for example, wish to assist with the costs

         of some key X3J3 committee member attending to give a

         definitive view of the philosophy of 8X.


    (ii) Members were asked to suggest subjects for talks at future

         meetings and came up with the following ideas:-


                Fortran compilers on PCs and micros;

                Fortran compilers on parallel computers eg FX/8,

                                  transputer, Meiko etc;

                Interaction of data processing systems with knowledge

                                  based systems ie expert systems/AI;

                Fortran 8X v Ada;

                Parallel algorithms in Fortran 8X;

                Fortran 8X toolpack (NAG/Salford project);

                SPAG structurizing tools (Polyhedron);

                Visit to SERC Rutherford.


         Any other suggestions for topics should be communicated to

         the Secretary.


(iii)   The Secretary mentioned that he had recently been talking

        with Active Memory Technology who are developing DAP-3

        as a successor product to the ICL PERQ DAP and they were

        willing to provide a speaker at a future meeting. It was

        agreed that they should be invited to give a talk at our

        April meeting. [This has now been arranged -Secretary.]


        It was also decided that the July meeting would take place

        at Coventry Polytechnic. Keith Normington would make the

        arrangements and confirm an exact date.


5.  PROGRESS ON FORTRAN 8X AT WG5


The ISO working group WG5 is conducting a vote on whether 8X is

ready for public review. So far few votes have come in and the

cut-off date has been extended; votes received up to now are 14-2

in favour of release. The next WG5 meeting is in Liverpool from

3-7 August. Names of attendees must be approved by BSI by June.

Anyone interested in attending should write to David Muxworthy at

Edinburgh University.


At a BSI meeting last December the UK voted in favour of releasing

the 8X draft for public comment (see appendix A). Other voting

alternatives would have been "Yes, with editorial changes" and "No,

with technical reasons for whatever changes would enable a change

to a 'Yes' vote".


6.   PROGRESS ON FORTRAN 8X AT X3J3


Miles Ellis had attended the latest X3J3 meeting in Albuquerque and

gave a summary of the main happenings as follows:-


The Albuquerque meeting, hoping to get the 8X draft out for

public review, had processed a huge number of documents. The

"obsolete" features category had now been renamed "deleted"

but this still seemed confusing. There had been some debate

about the procedure for releasing 8X; confusion existed within

X3J3 and the discussion got quite heated.


IBM and DEC felt the draft document was not suitable for

consideration as a standard. Peritus were also against it.

Two thirds of X3J3 have to be in favour of the draft before it

can be released. Those voting "No" must say what needs to be

changed for them to change their vote to "Yes". A straw vote

of voting intentions regarding releasing the draft for public

review resulted in 27 - Yes, 7 - No. Many of those against

believe that there have been too many late changes and some

stabilisation of the document is needed.


Eventually the draft must go to the X3 parent committee for

consideration. X3 does not actually meet but makes decisions

by correspondence. Alan Wilson says it is a vendor dominated

body. Miles Ellis understands that IBM's objections to the

draft standard have a basis that it fails to meet the market

needs for a language that can be learned easily and

implemented quickly. They also believe that the size and

complexity of 8X could lead to implementation errors and

confusion.


John Reid (Harwell) has provided a summary of the Albuquerque

meeting - see appendix B.


7.   ANY OTHER BUSINESS


One of our Group members, Chris Lazou, has just written a book

titled "Supercomputers and their use" published by Oxford

University Press at £22.50. It describes the state of the art in

supercomputers. A brochure and purchase form appears in

appendix E.


Polyhedron Software have kindly sponsored the cost of sending out

this newsletter. A brochure on their software products is enclosed

and they will be giving a talk on them at our Coventry meeting in

July.


8.   DATE OF NEXT MEETING


The next meeting will take place at 10.30 am on Thursday 2 April at

BCS HQ and will include the AGM. In the afternoon

Professor Denis Parkinson (QMC and Active Memory) will give a talk

on the new Active Memory Technology DAP-3. Both hardware and

software aspects will be covered.


A buffet lunch will be provided - but those wishing to participate

must complete the booking form and return it to the Secretary.


9.  AFTERNOON TALKS


In the afternoon there were talks on "The implementation of
Toolpack
" by David Hewitt (Coventry Polytechnic) and "Software
Tools
" by David Burns (NCC). Summaries appear in appendices C and D.


MIKE NUNN

Secretary, BCS Fortran

Specialist Group

17 February 1987


PS. A report from John Reid on the February X3J3 meeting in

Los Angeles has just been received and is included in the appendices.




                                                           Appendix A


WG5 INFORMAL LETTER BALLOT


    for Individual WG5 members



Subject: Revision of ISO 1539-1980        Date: Nov. 18. 1986

Reference Document: X3J3/58.103           Ballot Period: Dec. 1 - Jan. 5. 1987


Question: Do you approve the draft Fortran Revision (Fortran 8X) of ISO

1539-1980 (Fortran 77) enclosed with this ballot for submission to SC22 for

further processing as an International Standard?


                                        _____ Yes

                                        __X   Yes, with comments supplied

                                        _____ No, with comments supplied


Comments: (Additional pages of comments may be attached.)

                One page of comment is attached.


                                                Country

                                                  or

Mail to:                                        Name        United Kingdom

                        please print


Jeanne T. Martin                                Individual

L-300                              Signature:

Lawrence Livermore National Laboratory          D.T.Muxworthy (signed)

Livermore. CA 94550

USA                                             Date December 19, 1986


-------------------------------------new page----------------------------------


WG5 INFORMAL LETTER BALLOT. COMMENTS ACCOMPANYING THE U.K. VOTE.


The U.K. votes "yes" in the WGS informal letter ballot in order

that the document may be issued for public comment. The vote does

not indicate that the document is yet ready to be registered as a

draft proposed standard.


The U.K. commends X3J3 for responding favourably to several of the

WGS Halifax resolutions, but expresses regret that no action has

been taken on other resolutions, including numbers 10 (conformance) ,

13 (deprecated features) and 14 (significant blanks); moreover the

U.K. records its disapprobation that X3J3 took action directly

contrary to resolution 22 (name-directed I/O).


The U.K. reaffirms its support for the WG5 Halifax resolutions.

Further explanation of these points is to be found in responses

from individual U.K. WG5 members.


[The Halifax resolutions are available at

ftp://ftp.nag.co.uk/sc22wg5/N001-N1100/N205.pdf]





Appendix B


To: BCS, NAG, Fortran Forum, etc.

From: John Reid

Date: 4th December 1986

Subject: X3J3 meeting at Albuquerque


Note: This is a personal report of the meeting and in no sense does

it constitute an official record of it.


1. Summary


  This was a very active meeting, with over 150 working documents, most

of which were corrections and improvements to the draft standard, S8.

The plan is to retypeset it immediately after the meeting (the chairman,

vice-chairman, and editor are all staying behind to help) and send

out to members for a postal ballot over the period December 1st to

January 5th. Only three members (IBM, DEC and Peritus) opposed holding

such a vote. when asked how they anticipated voting in this ballot, two

members (IBM and DEC) said 'no' and 5 abstained, so there seems every

prospect for the required 2/3 majority. The February meeting will be

devoted to considering the reasons for any 'no' votes and any comments

that accompany 'yes' votes. Hopefully, we will forward the document to

our parent committee, X3, in February. He will also forward it to ISO.


2. Editorial matters


  A huge number of editorial changes to the draft standard were made. In

fact, to complete the consideration of all the changes proposed, the

editorial committee met until 11.30 p.m. on the last day. The major

changes involved the meanings of the terms 'object' (now includes

subobjects), 'program unit' (now has to be external), 'subprogram'

has to be a function or subroutine subprogram), 'real' (now includes

double precision as a special case), and 'deleted' (to replace

'obsolete', which is easy to confuse with 'obsolescent'), and changes to

the default bnf rules (there are now only three default rules and they

are never overridden).


3. Modules


  A proposal to extend the USE statement to permit renaming of operators

(requested by ISO WG5) failed (10-23). Given that operators for

different types can have the same name, it was not felt necessary to

have this extension.


  It was decided (29-0) not to allow the individual components of a

derived type in a module to be declared PRIVATE but to allow them all to

be so declared. This would be appropriate, for example, if it is desired

to retain the freedom to change the details of the type without having

to change code that uses it. A structure of such a type (or having a

component of such a type) would not be permissible in an i/o list except

in its own module.


  Range lists and name lists were added to the list of entities that may

be used from a module (it was an accident that they were not already

allowed). It was also decided that derived types, range lists, and name

lists should join the list of local entities that are required to have

distinct names.


4. Derived-type comparison and assignment


  It was decided (29-2) to remove the automatic definition of the

comparison operators .EQ. and .NE. for derived types because often a

simple comparison of the bit pattern is not wanted. For example, the

derived type

                        TYPE STRING

                          INTEGER LEN

                          CHARACTER(8O) CHARS

                        END TYPE


implements variable-length strings and the following function is

appropriate for comparison


        LOGICAL FUNCTION EQUAL(A,B) OPERATOR(.EQ.)

            TYPE(STRING) A,B

            L = A%LEN

            EQUAL = (B%LEN.EQ.L) .AND. &

                     ALL( A%CHARS(1:L).EQ.B%CHARS(1:L) )

        END


It was suggested that the automatic definition of assignment might

also be removed, but this was felt to be much more useful. No harm is

done if some bits that will never be used are set.


5. Component selection syntax


  Van Snyder, a guest from JPL, suggested that functional notation be

used for component selection. For example, the function EQUAL of section

4 would become


        LOGICAL FUNCTION EQUAL(A,B) OPERATOR(.EQ.)

            TYPE(STRING) A,B

            L = LEN(A)

            EQUAL = (LEN(B).EQ.L) .AND. &

                    ALL( CHARS(A,1:L).EQ.CHARS(B,1:L) )

        END


  This seems a rather natural notation and would incidentally avoid the need

to use the symbol % and would mean that arrays of arrays could be

associated with ordinary arrays without a confusing subscript

transformation caused by Fortran's use of column-wise storage order.

Arguments used against it were that it would make what is happening less

apparent, that it would lead to the over-use of parentheses, and that

care would be needed with the wording of the rules for overloading

function names. A straw vote (7-19-9) was unfavourable to the idea.


6. Generalized precision


  Changes were made to simplify the interactions between generalized

precision, derived data, and passed-on precision, principally to prevent

any possibility of a system needing to generate a large number of

versions of a subprogram. The main changes were


  (1)   to require a derived type with precision attributes to have a

        parameter called PRECISION and a parameter called EXPONENT_RANGE

        and generally to behave very like REAL and COMPLEX, which have such

        parameters, and


  (2)   to require passed-on precision always to take the form where both

        PRECISION and EXPONENT_RANGE are passed on (have effective values

        that match those of actual arguments).


7. Intrinsics


  An optional argument was added to each of the functions ISCAN, INDEX

and VERIFY to permit them to process strings backwards (requested by ISO

WG5), CLOCK was renamed SYSTEM_CLOCK, and ISCAN was renamed SCAN.


8. Transfer function


The committee accepted my suggestions to the TRANSFER function to

avoid any loss of information when the data does not fit into a whole

number of array elements.


9. Allocation and deallocation errors


  It was decided to add an optional flag to the ALLOCATE and DEALLOCATE

statements to allow error conditions to be indicated.


10. Interface blocks


  ISO WG5 resolved at Bonn (1985) and reaffirmed at Halifax (1986) that

it should be possible to use the procedure interface block both to

define a procedure and to describe a reference to the procedure.

Unfortunately, X3J3 has found no acceptable syntax to express this, and

therefore resolved not to pursue the matter. I actually voted against

this resolution because, as far as I could see, the purpose of the WG5

request can be met by placing the procedure in a module and using it.


11. ISO proposed standard for language extensions on micros


  X3J3 was asked to review a proposed ISO standard for extensions to

Basic, Fortran, and Pascal to include ways to access memory, I/O ports,

and arbitrary subroutines; to service interrupts; and to bind entities

to specific memory locations. The Committee was concerned about

incompatibilities with Standard Fortran and recommended that these be

resolved and the semantic descriptions be made much more complete and

rigorous before this is adopted as a standard.


12. Next meeting of X3J3


  The Committee meets next in Los Angeles, February 9-13, 1987. The

premeeting deadline is January 5th.



[the following report was written after the Fortran SG meeting of 8 January

1987 but was included with the minutes of that meeting.]



To: BCS, NAG, Fortran Forum, etc.

From: John Reid

Date: 19 February 1987

Subject: X3J3 meeting in Los Angeles


Note: This is a personal report of the meeting and in no sense

does it constitute an official record of it.


l.   Summary


     A letter ballot of all X3J3 members was conducted prior to this

meeting, asking the question 'Do you approve the draft Fortran

Revision...enclosed with this ballot for submission to X3 for further

processing as an American National Standard?" The result was Yes: 9;

Yes with comments, 20; No: 7. Since less than l/3 voted "no", the

ballot passed. Short summaries of the reasons given for each no vote

appear in Section 2. It looks of 2 or 3 of these may change to yes

votes once all the comments have been processed, but the rest are

asking for drastic changes that are quite unacceptable to a majority

of the Committee.


     The meeting was concerned with processing the huge number of

comments received with the ballots. A preliminary meeting (attended

by Jeanne Adams, Jeanne Martin, Walt Brainerd, Jerry Wagener, Brian

Smith and Dick Hendrickson) collated the comments and categorized them

(l for minor edits, 2a for editorial changes in style and taste, 2b

for editorial changes that might be controversial, 3 for substantive

changes, 4 for substantive changes requiring subgroup study, and 5 for

changes to the language that would be appropriate in the public

comment period). Most of them were labelled as recommended for

acceptance (**), covered by another recommended change (*), or

rejected (R).


     Each committee member in turn was given the opportunity to

introduce his or her ballot and discuss items other than those in

categories l and 2, which were considered by the Editorial Subgroup

and moved in blocks. The changes in categories 3 and 4, and the

outright rejections, were passed to the technical subgroups to be

studied and moved singly. The only technical change made (other than

corrections of errors) was over requirements for processor conformance

(see Section 3), Substantial rewriting of text for host association

(the term adopted for access by internal procedures to host entities),

array constructors, and the IDENTIFY statement were adopted. It was

decided that the glossary should be included as an appendix and that

there should be an index of the bnf terms. There was some sentiment

in favour of limiting the intrinsic functions permitted in

specification statements, but the proposal was withdrawn for further

work. It was confirmed that entry statements are not permitted in

interface blocks (each entry has its own interface).


2.   The no votes in the ballot


     The no votes were as follows:-


1.   Kevin Harris (DEC) wants


        (a) derived data types to be removed and new intrinsic types to

        be added for bit strings, general pointers, and varying length

        character strings;

        (b) to disallow modules to contain procedures or access other

        modules; to add an INCLUDE facility;


        (c) to remove generalized precision; to require minimal

        accuracy standards for operations and intrinsic functions; and


        (d) to reduce the obsolescent features list to noninteger DO

        variables, ASSIGN, assignedGOTO, and assigned FORMAT specifiers;

        to reduce the deprecated list to one item, the old source form.


2.   Dick Hendrickson (Cray) wishes to see the large number of

technical errors and holes that he has found corrected.


3.   Anil Lakwara (Peritus) believes that the document does not

conform with X3J3's Charter, that the language is too large and

complex, and that implementations will be too large and inefficient.


4.   Len Moss (SLAC) feels strongly that X3J3 should not publish the

document until the whole committee is convinced that it is

understandable, and is concerned about the large number of editorial

and technical errors that remain in the document.


5.   Ivor Philips (Boeing) wishes to change the Appendix F bit

facility to be based on bit strings and to add an OVERLOAD statement

that flags any overloading of procedures or defined operators.


6.   Larry Rolison (Unisys) has found virtually no new feature that

will enhance either compiler or run-time performance and is concerned

that the committee has created a negative incentive for the average

user to move to an 8x implementation.


7.   Dick Weaver (IBM) wants Fortran 8x to be reorganized into two

languages. One would be called Fortran and would consist of Fortran

77 plus data structures, array language as an option, bit string data

type, dynamic allocation, environmental inquiry functions, precision

specification, keyword and optional arguments on CALL statements,

IMPLICIT NONE, and the new form of DO. The rest would be processed as

a technical report, to allow implementation experience, testing and

evaluation.


8.   Processor conformance


     ISO Working Group 5 requested that processor conformance

requirements be extended, essentially to require static checking of

the syntax of a program for violations of the standard and for the use

of extensions. The committee accepted the spirit of the proposal, but

had some difficulty with the exact wording. After discussions in full

committee and ad hoc subgroups, the following was adopted (24-0):


1.   Add to the body of S8:


     A processor conforms to this standard if


     (l) It executes any standard conforming program in a manner that

     fulfils the interpretations herein, subject to any limits that

     the processor may impose on the size and complexity of the

     program.


     (2) It contains the capability to detect and report the use

     within a submitted program unit of a form designated herein as

     deleted, obsolescent, or deprecated, insofar as such use can be

     detected by reference to the numbered syntax rules herein and

     their associated constraints.


     (3) It contains the capability to detect and report the use

     within a submitted program unit of an additional form or

     relationship which is not permitted by the numbered syntax rules

     or their associated constraints.


     However, a processor is not required to detect or report the use

     of deleted, obsolescent, or deprecated features, nor the use of

     additional forms of relationships occurring in a format

     specification which is not part of a format statement (10.1.1).


2.   Add to Section Notes (Appendix C):


     The standard requires a standard-conforming processor to be

     capable of detecting and reporting the use within a program unit

     of forms designated as deleted, obsolescent, or deprecated, or of

     additional forms or relationships, where such use can be detected

     by reference to the numbered syntax rules and their associated

     constraints. It is recommended that the processor be accompanied

     by documentation which specifies the limits it imposes on the

     size and complexity of the program and the means of reporting

     when these limits are exceeded, which defines the additional

     forms and relationships it allows , and which defines the means of

     reporting the use of additional forms and relationships or of the

     deleted, obsolescent, or deprecated forms. Note that in this

     context, the use of a deleted form is the use of an additional

     form.


4.   Further meetings


     Because there is much work still to be done on the ballot

proposals, the Chairman has called for an extra meeting to be held at

Albuquerque, 23-27 March. This will be treated as a continuation of

the February meeting, without separate minutes. It should ensure that

processing of the ballots is completed at the meeting in Seattle,

11-l5 May. The premeeting deadline is April 6.





                          APPENDIX C


                 IMPLEMENTATION OF TOOLPACK

        TALK BY DAVID HEWITT (COVENTRY POLYTECHNIC)


David Hewitt works in Computing Services Department of Coventry

Polytechnic where there are 5,000 students. A great deal of time

is spent on porting software from other sites onto their Harris

systems. Most of this is written in Fortran so when they read

about Toolpack they decided to try it out. Computer systems at

Coventry consist of:-


                2 x Harris 800;

                1 x Harris 1000.


Each has 3MB memory and 24-bit word length. Largest programs that

can be handled are 1M words. Total disk space available amounts to

1.5 GB shared between 5,000 users. Presently a total of 175 on-

line terminals are supported but this could be increased to about

220 if more ports were available. The Harris operating system VOS

can only support a single level file structure, ie files are

referenced relative only to the directory in which they reside.


Coventry use a wide range of languages and about 60 application

packages. These vary between quite small ones for performing

simple calculations to large engineering packages and interactive

graphics.


In implementing Toolpack a user can choose a stand-alone regime in

which each tool is invoked separately or an embedded regime (more

difficult to implement) which gives more freedom in invoking tools.

Coventry started by trying the stand-alone regime. Toolpack is

supplied as a series of large files which have to be broken into

source files, macro definitions, block data and test areas. A

split program is supplied for this purpose. Source areas then have

to be converted to Fortran using the TIEMAC processor. Its main

actions are to include declared files and process define

statements. The next step is to hook in the libraries that contain

the host dependent routines for I/O, file handling, terminal

handling etc.


To implement Toolpack took one person a total of 104 days spread

over 9 months. It has to be noted that Toolpack is not only a

suite of about 40 tools but also an environment in which they

operate and consists of about 250,000 lines of Fortran source code.


General experiences were:-


(i)   Documentation provided although fairly detailed is not

  easy to understand or use.


(ii)  Conceptualisation of the different types of regimes and their

      relative implications are difficult to understand.


(iii) It is surprising how many tools have to be run to accomplish a

      single task.


(iv)  Because tools originated at different sites they do not present

      the user with a consistent interface.


(v)   The tools can provide useful functions like converting all single

      precision arithmetic to double.


Anyone interested in a very detailed set of notes that David has

produced on his experiences in implementing Toolpack should contact

him at Coventry Polytechnic.





APPENDIX D


"SOFTWARE TOOLS" - TALK BY DAVID BURNS (NCC)



The Software Tools Demonstration Centre (STDC) was set up via a

Department of Trade and Industry initiative in 1986 at the National

Computing Centre in Manchester. Its objectives are to:-


    1.  Promote the use of software engineering tools and methods.

    2.  Provide an independent demonstration centre for such tools.

    3.  Allow users to see and compare tools relevant to their needs.

    4.  Act as a focal point for exchange of expertise in software

        engineering.


The DTI contract valued at £3M was for three years; so far STDC is

one year into the project. Any revenues have to be ploughed back

into STDC which will eventually become a self-supporting company.

NCC itself was set up as an enterprise 20 years ago by the

government but is now self sufficient as a commercial company.


STDC activities include:-

        Demonstration of tools (in a highly professional manner);

        Advice on tool selection;

        Seminars/briefings/workshops;

        Producing a newsletter on "tools and methods".


STDC maintains an information base on 200 tools including abstracts

of Alvey projects.  STDC has 16 permanent staff and 3 temporaries. This
represents a doubling over the last year. The environment at the Centre
is very plush.


Hardware used includes:-

        2 x IBM PCs;

        IBM 4361;

        ICL 2953 with CAFS;

        VAX 8200 (under VMS);

        Microvax (under Ultrix);

        McDonnell Douglas 6830 (Pick);

        2 x Tandems;

        4 x Apricots;

        4 x Macintoshes.


STDC database of tools is kept on the VAX 8200 using ORACLE software.

Equipment is on free loan from suppliers.


Tools currently available exist in the areas of software estimating,

project support environments, 4th generator systems, IKBS, project

management, graphics, verification and validation, implementation

analysis and design, configuration management, quality management.


STDC expect to have a balanced portfolio of 40 tools by April 1987.

They also hope to run a school to give attendees hands-on

experience of using the tools. In the near future they will also

be able to offer a series of tool starter/sampler packs.


For further information on STDC contact:-

STDC Administrator, National Computing Centre Ltd, Oxford Road,

MANCHESTER Ml 7ED. Tel: 061-228-6333




APPENDIX E



Oxford University coat of arms


OXFORD SCIENCE PUBLICATIONS


SUPERCOMPUTERS AND THEIR USE


Christopher Lazou, Section Head, University of London

Computer Centre


Supercomputers are at the forefront of computer technology,

and are of immense practical importance in scientific research.

The speed at which they handle data makes them ideal

tools for researchers in such fields as aerospace, electronics,

and weaponry.

The first part of this book describes several different supercomputers,

discussing their architecture, the technologies used in building

them, and the constraints imposed by the available technology

on their design. The second part covers software, numerical

methods, and performance in terms of practical applications.

The book concludes with a discussion of future technological

possibilities and new hardware.


* Essential for all computer professionals and scientists

  using large-scale computation

* Written in an informal style

* Aimed at a general, computer literate audience

* Technical details kept to a minimum and are clearly explained

  whenever they are unavoidable


Contents: Introducing supercomputers; Organization of

building blocks; Supercomputer architecture in the 1970s;

Supercomputer technologies; Supercomputers of the 1980s

- made in the USA; Supercomputers of the 1980s - made

in Japan; Scientific computation; Software and scalar optimization;

Vectorization; Aspects of supercomputer performance;

Examples of practical applications; Future developments;

Appendix: Array features in FORTRAN 8x; Bibliography;

index.


0 19 853720 4, 240 pages, 57 line and 23 halftone illustrations,

Clarendon Press, November 1986 £22.50


    OXFORD UNIVERSITY PRESS

     WALTON STREET, OXFORD, OX2 6DP TEL (0865) 56767