[comp.software-eng] Soft-Eng-Dig-v5n7

nigam@MITRE.ARPA (05/31/88)

Soft-Eng Digest             Mon, 30 Apr 88       V: Issue   7

Today's Topics:
                  Announcement of Leif Distribution
             Boswell and the Project Chronicles (2 msgs)
                Control flow and common sense (4 msgs)
                                  CP
               Minutes of ECMA TC33 PCTE Second Meeting
                New ECMA TC33 PCTE Terms of Reference
                      number-string conversions
                   Programming Environments Survey
   Request for information on DAVE and other dataflow tracing tools
                      requirement specification
----------------------------------------------------------------------

Date: Thu, 19 May 88 18:28:05 cdt
From: wsmith@m.cs.uiuc.edu (William Smith)
Subject: Announcement of Leif Distribution

We have just released Leif, a language oriented editor that is based on
a recognition paradigm.  In a recognition paradigm the programmer enters
text and the editor incrementally analyzes this text to determine structure.
Many other language oriented editors are based on templates.  In these
editors, the program is constructed by expanding templates.  Template
editors prevent the creation of syntax errors by restricting the possible
edits.  In Leif, the programmer may use all of the text editing commands
of a host editor (GNU Emacs) to create a program.  The programmer may also
use language oriented commands.  At any point, the syntax analysis may be
consulted to locate syntax errors or display the structure of the program.

By using a standard text editor as the front end, Leif offers several benefits.
First, there is very little overhead in learning to use Leif.  By learning
only one new command, the "move to syntax error" command, Leif can be useful.
Other commands allow a programmer to see the structure of the program or
examine a syntax error.  A second benefit is that the user can edit the
program as text or as syntax simultaneously.

Leif has respectable performance.  It uses an incremental parsing algorithm
to analyze changes to the text and to maintain a parse tree.  If a change is
made that affects only a local part of the parse tree, only that part is
Analysis does not occur on every key stroke.  Instead, Leif allows any
number of consecutive changes to be processed as a unit. The programmer may
use Leif transparently and request information from the parser when it is
needed.  Once started, Leif does not require any actions by the programmer
for it to follow an editing session.  Until a Leif command is activated,
the user does not notice any change in the editor.  This translates into an
efficiency benefit and further enhances the ease of use.

A language for Leif is specified as a lexical analyzer and LALR(1) grammar.
Standard tools, Lex and Bison (similar to Yacc), are used to process the
specification.  Once the tables produced by these tools have been converted
into an appropriate parse table format, Leif use the tables and edit text
in the language.  Prototyping the syntax of a language is easy and a
designer of a language may specify a language and experiment with it quickly.
The language need not be a programming language, but could instead be a
specification, design or text processing language as long as a language
fits in the lexical analyzer and parser paradigm.

Leif is available via anonymous ftp from a.cs.uiuc.edu.  The files are
located in the subdirectory pub/Leif.  Consult the file README.DIST that
is in that directory to decide which files to retrieve.  Documentation
is available in the file leif-doc.tar.Z.  (If you are unable to retrieve
the files via ftp, please contact us.)

Please send Leif related queries to ihnp4!uiucdcs!leif or leif@a.cs.uiuc.edu

Bill Smith,     Dan LaLiberte,  Roy Campbell

------------------------------

Date: 12 May 88 03:24:16 GMT
From: pixar!unicom!jonson@bloom-beacon.MIT.EDU  (Mary D Johnson)
Subject: Boswell and the Project Chronicles

In article <41891UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
. . . to paraphrase
the guru, boswell, expert (chose one) might be more valuable than the project
leader

at least that seems to be Lee's message (in my words)
It also seems to be the hardest thing to convince management that the
department or project manager might not be too upset to pay more than they
make themselves to get the services of someone who is really good.

How many coaches make more than their star pitchers, centers, or quarter
backs?

------------------------------

Date: 13 May 88 17:42:56 GMT
From: uh2%psuvm.BITNET@CUNYVM.CUNY.EDU  (Lee Sailer)
Subject: Boswell and the Project Chronicles

>How many coaches make more than their star pitchers, centers, or quarter
>backs?

You make our point for us.  The Coach is the Chief Programmer.  The
star pitcher is his assistant.

------------------------------

Date: 7 May 88 14:14:54 GMT
From: defun.utah.edu!shebs@cs.utah.edu  (Stanley T. Shebs)
Subject: Control flow and common sense

In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes:

>One fellow I know documented a particularly complex and obscure code with the
>comment "This procudure implements the <something or other> algorithm given
>on page <xyz> of <some book> by <some author>".  (The angle bracketed items
>are mine.)

Sounds perfectly fine to me.  Why waste all kinds of space repeating other
people's words?  Or worse, not mentioning at all that the algorithm derives
from somewhere else?

In all fairness, the bald citation is insufficient - there should also be
one or two lines like "the algorithm is based on the use of multi-colored
pointers cycling around in something resembling a butterfly FFT".  This will
jog the memory of the informed reader, and strongly suggest to the ignorant
reader that there are a lot of prerequisites to understanding this code.

------------------------------

Date: 9 May 88 16:49:11 GMT
From: ihnp4!ihlpf!jtkrist@bloom-beacon.MIT.EDU
Subject: Control flow and common sense

In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes:
>One fellow I know documented a particularly complex and obscure code with the
>comment "This procudure implements the <something or other> algorithm given
>on page <xyz> of <some book> by <some author>".  (The angle bracketed items
>are mine.)
>
golly, this could be me! whenever i need to implement an algorithm, i
look first in knuth and if i find what i need, i transliterate the
algorithm, as closely as possible, in the language i'm using - yes i
know it's not structured and there are lots of labels and gotos, but
it works - who was it who said that scientists stand on each other's
shoulders, while programmers stand on each other's toes?

------------------------------

Date: 7 May 88 13:27:32 GMT
From: uh2%psuvm.BITNET@jade.berkeley.edu.user%host.BITNET@CUNYVM.CUNY.EDU  (Lee Sailer)
Subject: Control flow and common sense

Tastes differ, and gentlefolk can disagree.  I am usually delighted when
this type of comment appears in the code.  The book nearly always makes
much better reading than some guys half-literate comments.

Real Soon Now, we'll all be using Xanadu, and the comments in the code will
actually point at the reference on a disk somewhere, and you'll be able
to access it online. :-)

------------------------------

Date: 9 May 88 12:57:44 GMT
From: attcan!lsuc!spectrix!yunexus!geac!daveb@uunet.uu.net  (David Collier-Brown)
Subject: Control flow and common sense

In article <1122@daisy.UUCP> david@daisy.UUCP (David Schachter) writes:
| One fellow I know documented a particularly complex and obscure code with the
| comment "This procudure implements the <something or other> algorithm given
| on page <xyz> of <some book> by <some author>".  (The angle bracketed items
| are mine.)

| Real helpful.  If I want to understand his code, I have to get the book from
| a speciality bookstore or get my company to purchase library access at Stanford
| University.  Then, hoping the edition I get is the same as his (so the page
| numbers match), I read some author's description of the algorithm and hope
| the programmer implemented the algorithm exactly.  Great, just great.

That was probably me.  You'll find the photocopies of the pages in
the book in the file with the master man pages and design notes for
the program.

| It is folks like him who justify, in my mind, the existence of nuclear weapons.

That's odd, I don't **remember** working for a nuclear weapons
company...

------------------------------

Date: Wed, 18 May 88 10:04 BST
From: Colin M Thomson <mcvax!gm.rl.ac.uk!CMTA@uunet.UU.NET>
Subject: CP

In digest V issue 1 fad@balder.think.com.uucp suggests the main problem with
the Brooks's CPT organisation is that you can't find the superprogrammer to
lead. That isn't the problem at all [as someone already pointed out, you don't
need one. However there a few problems:-
   (a) managements sometimes think you need a superprogrammer: this either
       stops them using the technique, or (much worse) leads to them putting
       someone totally inappropriate in the post. [Such managements are
       subject to natural selection, so this may be a rare problem!]
   (b) many projects are TOO SMALL for the technique to be applicable. A
       fairly isolated project of less than 5 man years with a natural
       timescale of about 10 months is a common enough occurrence.
   (c) some projects are just too big; it's unreasonable to expect one person
       to understand the design at a fairly detailed level for the whole of a
       5000 man year job. Splitting into subprojects of the right size for
       attack by cpts can always be done, I guess, but the natural split that
       comes out of a top level structural design may not deliver chunks of
       the right size, and imposing a different design split to get the chunks
       to fit may (will?) introduce precisely the sort of incoherence and
       structural decay the technique was intended to avoid. [This is not a
       very serious problem: the task size range that fits the CPT concept
       well is quite large - say about 25 my to about 125 my, and one can
       choose to do some tasks within the overall big project with CPT
       organisation and some with other organisations, ie use it where it
       fits.]
   (d) related to (b) above, I saw one bunch of people group together lots of
       smallish and totally unrelated tasks into a hunk of work to make
       something big enough to fit CPT style organisation. Needless to say,
       it didn't work [no design coherence was needed between the individual
       hunks, in fact radically differing desing styles were appropriate]. So
       there's a problem of misuse of the technique as well as problems in
       using it.

------------------------------

Date: 17 May 88 04:23:00 GMT
From: casee.dec.com!wyman@decwrl.dec.com  (Bob Wyman)
Subject: Minutes of ECMA TC33 PCTE Second Meeting

Folks,
        Attached, you will find a copy of the minutes of the second meeting of
the ECMA (European Computer Manufacturer's Association) Technical Committee
33 on PCTE (Portable Common Tools Environment). As stated when I posted the
minutes for the first meeting, I receive these minutes from the ECMA
secretariat on floppy disk and make no editorial changes to them prior to
posting them to the network. Thus, I cannot be held in any way responsible for
their contents. The only changes I make to the text are those necessary to
remove the more bizarre control characters introduced by the word processing
software used by the secretariat...

        For those not familiar with PCTE, it is probably best to say that many
consider it the "European CAIS." In fact, significant effort has recently been
expended by members of the PCTE community and the CAIS-A team to try to plan a
strategy by which PCTE and CAIS can be converged or at least made to interwork.
This PCTE/CAIS cooperation is being primarily driven by a number of NATO
nations within the IEPG/TA13 sponsored "PCTE+" program. It is expected that
PCTE will soon become a standard, at least in Europe, and that this standard
will be forwarded to the ISO for broader review. Further, it is expected that
either PCTE or an amalgam between PCTE and CAIS will become a requirement for
NATO business after 1990. Thus, although PCTE is of European origin, it is
likely to have impact on the US market as well.

        Happy reading.

==============================================================================

                            ECMA / TC33 / 88 / 23
                                   -    -
                                  E  C  M  A
                European  Computer  Manufacturers  Association
                         Minutes of TC33 2nd Meeting
                           Cannes, 28-29 March 1988

Chairman        : Mr. Morron (ICL)
Secretary       : Mr. Brockway (ECMA)
In attendance   : Dr. Crispin (HP),  Messrs. Davis (ICL),  Frost (BT),
                  Hayselden (SSL),  Jeanrond (Nixdorf),
                  Kelter (Universitat Dortmund),  Mittermaier (Siemens),
                  Moreau (BIM),  Myren (TeleLogic),  Smedema (Philips),
                  Thomas (Bull),  Wyman (DEC)
Excused :       Messrs. Harvey (Alcatel),  MacDonald (Unisys),  Nielsen (DDC),
                Prof. Dr. Weber (Universitat Dortmund)
Absent  :       Dr. Bologna

1.      Adoption of Agenda

The Agenda was adopted as proposed (88/12); items were re-sequenced, as
reflected by these Minutes. Newly-available papers were noted: X Toolkit
Widgets - C Language X Interface  (MIT, DEC, 88/18 A),  Using the X Toolkit or
How to Write a Widget  (DEC, 88/18 B), and  Conformance to a PCTE standard,
issue 1  (ICL, 88/19).

2.      Approval of Minutes of TC33 1st Meeting

It was felt that the Minutes as written (88/11) do not explicitly reflect an
unstated, but nonetheless underlying, agreement of the Meeting that both C and
Ada specifications should be included, with equal emphasis, within the initial
proposed ECMA standard.

On page 3, item 8, the 4th sentence was revised to achieve greater clarity as
follows:

Mr. Kelter indicated that 1.5 is intended to remove internal inconsistencies in
each language-bound specification, and for which a commentary procedure
operates within the PICG (88/4 refers), whereas 1.6 is intended to remove
mutual inconsistencies between the two language-bound specifications.

With these clarifications, the Minutes were approved as written.

3.      Matters arising from the Minutes not covered elsewhere

An early version of the VDM specification, kindly made available to TC33
through the Office of Mr. Elmore (CEC/XIII/A/4), was received with interest
(88/16). Mr. Brockway emphasized that the document is an initial draft and
directed particular attention to the cautionary covering letter from ESPRIT VIP
Project Manager Mr. Jackson, and to the envisaged availability dates for
revised and final versions of the specification as indicated by Mr. Elmore
(covering letters to 88/16).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


For readability, TC33 document references are abbreviated from ECMA/TC33/88/n
to the form 88/n.



Mr. Brockway was asked to request from Mr. Elmore a copy of the Ada Functional
Specification (First Edition), and also, with regard to copyright aspects of
the PCTE Interface Specifications, to request approval for ECMA TC33 to base
its work both on the current versions of the C and the Ada specifications and
on future versions as they become available.

It was also agreed to request copies of the current PCTE+ C and Ada Functional
Specifications, as well as the PCTE+ Interface Specifications Comparison
between PCTE and PCTE+. Accordingly Mr. Morron will approach the appropriate
authority within IEPG TA13 to seek clarification as to how TC33 can best base
its work on the PCTE+ documents; Mr. Brockway will request the current
documents from Mr. Fikkert (International Review Manager, TNO) for circulation
within TC33. In his contacts with TA13, Mr. Morron will also explore the
possibility of using text as recorded on tapes.

With regard to the envisaged future launch of ECMA PCTE standards into ISO by
means of the  fast-track  procedure, Mr. Brockway indicated that it is neither
required nor desirable for ECMA to pre-submit a proposal to ISO for the
creation of a new work item on PCTE (Minutes of 1st Meeting, 87/11, page 3,
item 7, refer). Mr. Wyman introduced portions of the ISO  fast-track  working
procedures. It was suggested that a 5-year rule may apply, under which once a
standard has been accepted through the  fast-track  procedure it cannot then be
revised within 5 years, a suggestion which, if true, would necessitate a
strategic timing of submissions of ECMA standards into ISO.

Secretariat Note:

Documents describing the ISO  fast-track  procedure are not being circulated
within TC33. Instead, ECMA Secretary General Mr. Hekimi will present the
relevant aspects of this procedure at the next Meeting of TC33 (Geneva, 24-25
May 1988), and respond to questions or concerns of TC33 members. In particular,
ISO international standards may be revised, in principle, at any time; there is
no requirement to  wait  5 years before revisions. The 5-year  rule  (which is
not specific to the  fast-track  procedure) stipulates essentially that every
ISO international standard shall be reviewed not less frequently than at 5-year
intervals, to ensure compatibility is maintained with regard to other
standards and that considerations of areas of overlap are adequately covered.

The essential point, in accord with a basic premise of standardization, is that
ISO international standards (whether arrived at through  fast-track  or
otherwise) may be revised as often as required provided that the revisions are
upward-compatible; revisions that are unable to maintain upward-compatibility
should ideally be avoided and, in any event, not applied frequently.

4.      Report from PIMB

Mr. Morron reported from the 9 March PIMB Meeting. With regard to the briefing
given by the TC33 1st Meeting Mr. Morron indicated that:

(i)     the Ada specification is in the public domain; however the C
specification is seen as  definitive ;

(ii)    the proposal (for addressing to the CEC) indicating the desirability of
rewriting the C specifications in the style and quality of the Ada
specifications, and requesting allocation of the necessary resources, was
raised and noted; a considered and definitive response was not however given.

Mr. Morron was actioned to raise point (ii) again at the next PIMB Meeting (6
May).



Among topics discussed by the PIMB Mr. Morron highlighted
language-independency, the possibility of future production of a promotional
videoclip for PCTE, and the recommendation that TC33 base its work on the C
specifications.

Mr. Davis felt it is critical that the issue and funding of specifications of
Ada bindings for the User Interface (U-I) be resolved. Mr. Morron agreed to
raise this at the PIMB. Mr. Thomas agreed to make available a U-I document for
TC33 circulation.

5.      Report from PICG

Mr. Kelter reported. The overall schedule of PICG work (88/5) has not changed
since the previous TC33 Meeting. Few comments have been received on 88/4. A
PICG U-I panel has been created as a full-time working group, and has led to a
division of tasks. Work on PCTE 1.5 will proceed in an April-May timeframe,
geared to the July PIMB Meeting; the timing is recognizably tight. PICG
resources are limited and stretched, especially if a large number of change
requests are received. Work on C is being given priority. The C specifications
are on-line, those of Ada will be brought on-line soon.

Some TC33 members questioned the prioritization being given by the PICG to 1.5
C work, and considered it preferable to raise the priorities on Ada.

Mr. Wyman suggested that work would proceed more efficiently if the total
workload is subdivided into isolated functional areas and addressed by
different experts on a per-topic basis. Mr. Wyman indicated that his Company
would be prepared to address the topics of  date and time  and  memory
allocation management. Considerable support was expressed for this viewpoint.

With regard to the relationship of management and technical work in both the
PICG and TC33 environments, the possibility of parts of the necessary technical
work being carried out within TC33 was noted. TC33 agreed to focus on a
November 1988 target for a pre-final draft initial ECMA PCTE standard rather
than placing emphasis on the July 1988 PICG target for 1.5. It was agreed that
PICG work would be supplemented by TC33 work if seen as necessary.

6.      Interface and division of responsibilities between PIMB and TC33

This agenda item was not addressed explicitly, the subject being covered by
other items. Messrs. Morron and Wyman agreed to provide the ECMA Secretariat
with lists of the memberships of the PIMB and PICG.

7.      Review of scope and PoW

With regard to the TC33 scope and PoW (88/8) as proposed at the previous
Meeting, it was agreed to delete references to 1.4 and the Fourth Edition; the
text thus revised was agreed upon (88/20), and will be put forward to the CC
Meeting of 26-27 May.

8.      Conformance requirements

Mr. Davis introduced his paper Conformance to a PCTE standard, issue 1
(88/19). With regard to section 4  Conformance of what? , some participants
considered this to be simply conformance of a PCTE; others felt the point to be
more complex. The text of 4.1 received particular attention; it was felt that
conformance of tools and of implementations are both important. In conclusion,
Mr. Davis agreed to prepare draft text for a Conformance Clause for the initial
ECMA PCTE standard, for consideration at the next-but-one TC33 Meeting (7-8
July). Mr. Brockway will forward to Mr. Davis further ECMA standards including
a selection dealing with programming languages. Discussion of conformance
testing was held over until a future Meeting.

9.      Report from TC33 Ad-hoc Group on the Reference Model

Mr. Wyman reported from the 3-4 March Meeting of the ad-hoc group on the
reference model, also attended by Dr. Crispin and Mr. Davis. Terms of reference
(ToR) for a new TC33 Task Group on the reference model, accompanied by a
schedule of events, as prepared and proposed by the ad-hoc group, were
presented by Mr. Wyman.

It was agreed to establish a TC33 Task Group on the reference model. The ToR
for the Task Group were agreed as follows:

                          Terms of Reference for the
                TC33 Task Group on the Reference Model (TGRM)
                       (agreed by TC33, 29 March 1988)

SCOPE:  To define and maintain a reference model for computer assisted systems
engineering environments in order to provide a suitable framework within which
evolving standards can be defined.

PROGRAMME OF WORK:

1.      To define the requirements for the reference model with particular
        focus on the requirements for portability and interoperability within
        a distributed heterogeneous environment.

2.      To solicit input from the systems engineering community on models
        which can assist in meeting the requirements.

3.      To identify international standards that must be referenced by the
        model.

4.      To develop and present to TC33 a proposed ECMA Technical Report
        defining the model and its rationale.

5.      To maintain and enhance the model.

Regarding point 3, Mr. Wyman indicated that there are about 150 relevant
standards; a list will be circulated within TC33 in due course.

Participation in TGRM is open. Dr. Crispin and Messrs. Davis and Wyman
indicated their commitment to the work of TGRM; Messrs. Frost and Jeanrond also
expressed high interest. With at least 3-5 companies intending to participate
in the work, the minimum requirement for a TG was seen to be met, and TGRM
formally established.

Turning to the proposed schedule for the TG, it was agreed to include a target
of September 1988 for a 1st draft Technical Report on the reference model, with
a 2nd draft in November 1988 and final draft in February 1989. With this
refinement, the schedule for TC33 TGRM was agreed (88/22).

Mr. Wyman focused on the workshop on reference models for systems engineering
environments, proposed for sometime during October or November. Questions with
regard to organization, structure, participation, invitation, papers, and
funding were briefly addressed; Mr. Wyman agreed to prepare a proposal covering
these and other relevant aspects of the workshop, for consideration at the next
Meeting.

Requirements for the reference model were given initial attention; some of the
points addressed summarily are noted below (contributions and commentary are
invited and should be sent to Dr. Crispin):

-       the single workstation environment,
-       the non-connected multi-equipment environment,
-       the connected equipment environment,
        -       with the same PCTE implementation,
        -       with different PCTE implementations,
        -       with equipment all of the same manufacturer,
        -       with equipment of different manufacturers,
-       the distributed environment,
-       language bindings, including the possibility (or impossibility) of 1:1
        mapping between various bindings,
-       common services in C and Ada implementations,
-       the resolution of  cultural  differences between C and Ada, inherent in
        the essences of the two languages,
-       considerations regarding end-users, including end-users as writers of
        tools and end-users as final users of tools,
-       interoperability of tools written in different languages.

One of the major objectives of the reference model is to provide a framework
for a smooth and coordinated evolution of future ECMA standards, in particular
to ensure that the first standard is developed in such a way that further
standards may easily achieve alignment in the sense of upward compatibility.

Mr. Wyman reported on the list of existing studies (88/10). It was noted that
documents are now available on ISTAR, PACT, VIP (see 88/16), ESF (for which
Mr. Jeanrond agreed to send documents to Mr. Davis), and will soon be
available for ATHERTON. Mr. Wyman agreed to follow up with Mr. Bourguignon on
EAST.

10.     Review of roadmap and timeframe

The extract from the Report of a Meeting of the CC held 25-26 February was
noted (88/17). Mr. Brockway reported on concerns expressed by the Secretary
General to ECMA Management and the CC with regard to changes to the timeframe
and planning being proposed by TC33.

It was considered by all present that publishing 1.4 as an ECMA standard would
serve no purpose and would infact be counter-productive. The initial goal was
recalled and confirmed, i.e an initial ECMA standard for adoption by the ECMA
GA of June 1989, implying completion of a final draft by TC33 in February 1989.

Alternative routes to June 1989 were considered, including an  additive  path
based on 1.4-1.5-1.6 and a  subtractive  path based on PCTE+.

It was agreed that the production of future versions of the draft PCTE standard
can best be begun by selective editing of the latest PCTE+ specifications (C
and Ada). The differences between 1.4 and future versions of the draft PCTE
standard will reflect PCTE+ extensions and other proposed modifications
accepted by TC33.



TC33 recommend that PICG agree this approach to their achievement of the PIMB
directive within three weeks, and inform the TC33 Chairman by telex.

It was further agreed that each TC33 participant will brief his Company
representatives to the CC and the GA with regard to this situation.

Mr. Thomas agreed to prepare a list of the extension areas of PCTE+, and a
proposed prioritization, for circulation in advance of the next Meeting, the
objective being to examine which of these are suitable for inclusion in the
initial ECMA standard.

The roadmap and timeframe for TC33 as elaborated at the 1st Meeting (88/9) was
then reviewed and updated to reflect the above agreements (88/21).

11.     Roles and liaisons

It was recalled that internal liaison is envisaged with TC22 (Database) and
with TC32-TG2 (Communication, Networks and Systems Interconnection -
Distributed Interactive Processing), whose scopes and ToRs are given in
document 88/7.

Liaison with TC32-TG2 was considered particularly relevant with regard to the
recently adopted Standard ECMA-127  Basic Remote Procedure Call (RPC) using OSI
Remote Operations.

Dr. Crispin accepted nomination to liaise from TC33; Mr. Rutherford
(contactable through Mr. Morron at ICL) and he will prepare a brief paper on
liaison requirements regarding PCTE and Standard ECMA-127 for review at the
next Meeting.

The revised TC33 ToR (88/20), these Minutes (88/23) and the Agenda for the next
Meeting (88/24) will be sent to the Chairmen of TC22 (Dr. Lamersdorf, IBM) and
TC32 (Mr. von Studnitz, Philips) and to the TC32-TG2 Convenor (Mr. Brenner,
ICL).

12.     Document handling issues

This item was not addressed explicitly; the subject was covered under other
items. The guidelines offered by the ECMA GA for editing, recording and
exchanging drafts of ECMA standards and TRs were noted as circulated
(GA/86/21).

13.     Chairman's Report to Coordinating Committee

Mr. Morron agreed to prepare his report for review by TC33 at the next Meeting
(24-25 May), immediately prior to the next CC Meeting (26-27 May).

14.     Next Meetings of TC33 and TC33-TGRM

The next, 3rd Meeting of TC33 will be held 24-25 May 1988, in Geneva, from
14:00 hours on 24 May until 17:00 hours on 25 May. An Agenda and htel
accommodation arrangements are given in document 88/24. Contributions for
circulation to TC33 in advance should be sent to the Secretariat to arrive no
later than 29 April.

The 4th Meeting of TC33 will be held 7-8 July 1988, in Brussels, kindly
arranged by Philips, from 10:00 hours on 7 July until 13:00 hours on 8 July
(the early start on 7 July is intended to enable participants to reach home by
nightfall the following day).

The 1st Meeting of TC33-TGRM will be held on 26 April 1988, in The Hague;
details will be available directly from Mr. Wyman.


15.     Other business

(i)     Publicity

The degree to which TC33 should publicize its work was briefly considered.
Since the revised scope and ToR have yet to be reviewed and approved by the CC,
it was agreed not to formally activate any ECMA publicity machinery until after
the CC review of 26-27 May. It was recalled that all ECMA documents are in the
public domain.

(ii)    Member Company representation in TC33

Mr. Brockway reported that, as noted at the 1st Meeting, despite early
indications of interest in the work of TC33, neither IBM nor GEC had announced
representatives to this committee. Documents 88/1 through 88/12 had been sent
to Apollo Computer, but no indication has yet been received regarding interest
in participating in TC33.

Secretariat Note: IBM has subsequently announced its membership of TC33.

With all business concluded, Mr. Morron guided discussion to a close and
adjourned the Meeting, thanking all present for their participation in the
progress achieved. Thanks were extended to Mr. Wyman and Digital for organizing
and hosting this Meeting.

------------------------------

Date: 17 May 88 04:45:00 GMT
From: casee.dec.com!wyman@decwrl.dec.com  (Bob Wyman)
Subject: New ECMA TC33 PCTE Terms of Reference

Dear Readers,
        Attached you will find the new Proposed Revised Terms of Reference
for ECMA (European Computer Manufacturer's Association) Technical Committee
33 on PCTE (Portable Common Tools Environments). These are referred to in the
minutes of the 2nd TC33 meeting, previously posted.

===============================================================================
                            ECMA / TC33 / 88 / 20
                                  E  C  M  A
                European  Computer  Manufacturers  Association
                 Proposed Revised Terms of Reference of TC33
           As revised by TC33 2nd Meeting, Cannes, 28-29 March 1988
                     (supersedes document TC33 / 88 / 8)

The Scope and Programme of Work of TC33 as they appear in document
TC33/88/1 and in the 1988 Edition of the ECMA Memento were reassessed by
TC33 at its 1st Meeting, held 1-2 February 1988 in Geneva.

A proposed revised text was then circulated as document TC33/88/8,
incorporating clarifications and editorial changes, and also reflecting shifts
in importance attached by TC33-represented Member Companies to the various
aspects of the work in which TC33 intends to engage.

The text was further amended at the TC33 2nd Meeting by replacing the
references PCTE 1.4 and Fourth edition by PCTE. Pending approval by the
Coordinating Committee, TC33 is proceeding on the basis of the terms of
reference thus revised and shown overpage.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
overpage

TITLE:  PORTABLE COMMON TOOL ENVIRONMENT (PCTE)

SCOPE:  To standardize a common tool interface, implementable on a wide range
        of operating environments, to ensure a suitable foundation for
        portable, interoperable computer assisted systems engineering tools
        and tool sets.

PROGRAMME OF WORK:

1.      To define a layered reference model for computer assisted systems
        engineering environments that will support the incremental definition
        and evolution of interface standards.

2.      To position PCTE (see Note) within that reference model.

3.      To develop interface standards for the layers of the reference model,
        taking PCTE (see Note) as a starting point.

4.      To maintain liaison with TC22 and with TC32-TG2.

5.      To maintain liaison with the PCTE Interface Management Board (PIMB)
        and its technical group - the PCTE Interface Control Group (PICG),
        with DG XIII of the Commission of the European Communities, with the
        PCTE+ programme of Technical Area 13 (TA13) of the Independent
        European Programme Group (IEPG), and with the German PCTE Initiative.

6.      To identify and position complementary standards and standards
        activities relevant to the reference model, and to maintain liaison
        with those standards organizations responsible for their maintenance.

7.      To develop interface standards for the lowest layer of the reference
        model first and in the shortest possible time, while taking into
        account the requirements and specification efforts already underway
        as noted in item 5.

8.      To prepare standards in a form acceptable for submission via ECMA to
        ISO.

9.      To present the standards ultimately as an abstract specification with
        separate language bindings.

Note: PCTE: the Portable Common Tool Environment Functional Specifications,
        currently managed by the PCTE Interface Management Board (PIMB).

------------------------------

Date: 19 May 88 14:37:34 GMT
From: jfjr@mitre-bedford.arpa  (Jerome Freedman)
Subject: number-string conversions

  I am not sure if this is the correct group so forgive me if I
am wrong. A few days ago Robert Firth criticized (Boy did he)
some Pascal code that translated integers and floats to strings
and back again. Its an issue I never gave much thought to but
it interested me. How is this done when done well?? any
pointers to relevant literature??

------------------------------

Date: 20 May 88 23:00:11 GMT
From: beta!dph@hc.dspo.gov  (David P Huelsbeck)
Subject: Programming Environments Survey

        I'm interested in finding information about who is doing
        research in the areas of programming environments, software
        tools, CASE etc.  I'm also interested in finding out
        generally what these folks are doing.

        My interest is two fold.  First, I may be working on a
        programming environments related project at work some time
        this fall.  Second, I plan to graduate with my BSCS some time
        in the not too distant future and I'd like to pursue a
        graduate degree with programming environments as my emphasis.

        I've looked a fair amount of literature but I haven't turned
        up a lot of leads.  So any and all help would be appreciated.

------------------------------

Date: 18 May 88 18:04:16 GMT
From: attcan!utzoo!dciem!array!len@uunet.uu.net  (Leonard Vanek)
Subject: Request for information on DAVE and other dataflow tracing tools

Does anyone know the complete address of NAG on Banbury Rd., Oxford UK?

I am interested in NAG as the source for TOOLPAK, specifically
a component called "DAVE", which performs dataflow tracing of Fortran
programs. If anyone has information on either DAVE or NAG's TOOLPAK I
would also like to hear from you. This would include references to work
on DAVE by Osterweil and Fosdick.

I would also like to hear about any other interactive dataflow tracing
tools that anyone knows about.

------------------------------

Date: 17 May 88 22:42:23 GMT
From: uhccux!cs661s02@humu.nosc.mil  (Cs661s02)
Subject: requirement specification

I looking for references in generating requirement specification
document.

Thanks in advancs

------------------------------

End of Soft-Eng Digest
******************************