Programmer's ROM - The Computer Language Library/programmersrom.iso/ada/news/asr011.doc

Text File | 1988-05-03 | 94.5 KB | 2,036 lines

.RR--!----!----!----!----!----!----!----!----!----!----!-------------------!-R
.po 5
..po 1
.he                        ASR Newsletter, Issue 11, Apr 87
.fo                                                              Page #
Ada (tm) Software Repository (ASR) Newsletter     Issue 11, Apr 87
Richard Conn, Newsletter Editor                   Published by Echelon, Inc.


                                  THIS ISSUE

    I. Ada, STANDARDS, and DoD DIRECTIVES                                  2
          A. Ada is Now an ISO Standard                                    2
          B. DoD Directive 3405.1, "Computer Programming Language Policy"  2
          C. DoD Directive 3405.2, "Use of Ada in Weapon Systems"          3

   II. ASR TAPE DISTRIBUTION CHANGE and ASR OVERVIEW                       4
          A. ASR ANSI Tape Distribution                                    4
          B. Snapshot of the ASR                                           4
          C. Most Popular Files in the ASR and Total Number of Accesses    6

  III. SOFTWARE REUSABILITY                                                7
          A. Ed Berard et al on Software Reusability (7 sections)          7
          B. A Reusability Proposal                                       13
          C. Software Component Engineers                                 14

   IV. Ada CONTRACTUAL ISSUES                                             15

    V. Ada EXPO and SIGAda CALLS FOR PAPERS                               19

   VI. Ada QUESTIONS AND TOPICS                                           22
          A. Software Components with Ada by Grady Booch                  22
          B. Hard Knocks Handbook                                         23
          C. Ada Sources                                                  24
          D. IEEE Ada as a Design Language                                24
          E. Attribute Grammar for Ada                                    25
          F. IEEE Articles of Interest                                    25
          G. Ada Generic Overhead Inquiry                                 26
          H. Verdix Ada and Code Size                                     27

  VII. NEW and PLANNED SUBMISSIONS to the ASR                             28
          A. CSET Updated                                                 28
          B. Comments to ALSP* (LISP Routines in Ada)                     28
          C. LART (Load ARchive Tape on ROLM)                             31
          D. PIWG Benchmark Suite                                         32
          E. ABSTRACT Problem                                             36
          F. PPLANNER Problem                                             37
          G. DoDD 3405.1 and 3405.2                                       38
          H. Screen Generators in Ada                                     38

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

          NOTE:  Statements  made  in  this  newsletter  should  generally  be
considered to be personal opinions of the individuals and not necessarily  the
opinions  of  the  U.S. government, any specific company,  or  any  particular
organization.

.pa
==============================================================================
  I. Ada, STANDARDS, and DoD DIRECTIVES

     This  section  contains  three announcements made  by  Mrs.  Virginia  L.
Castor,  Director  of  the  DoD  Ada  Joint  Program  Office  (AJPO).    These
announcements  are  on  the acceptance of Ada as  an  International  Standards
Organization  (ISO)  standard  and the signing of DoD  Directives  3405.1  and
3405.2.

------------------------------------------------------------------------------
     A. Ada is Now an ISO Standard
Date: 13 Mar 1987 13:42-PST
Subject: Ada* now an ISO standard!
From: [e-mail]

     I  am pleased to announce that Ada is now an international standard.   On
March  12,  1987,  the  Central Secretariat  of  the  International  Standards
Organization  (ISO)  announced unanimous approval of the  Draft  International
Standard (DIS) 8652 - Programming Language Ada.  The standard will be known as
ISO/8652-1987 Programming Languages - Ada, and will be published as a one page
endorsement of the American and French Ada standards, ANSI Standard 1815A-1983
and AFNOR Standard NF Z 65-700, respectively.

     I  would  like  to thank all of those who initially  contributed  to  the
development of ANSI/MIL-STD-1815A and to congratualate all those who helped to
make its endorsement as an international standard a reality.

------------------------------------------------------------------------------
     B. DoD Directive 3405.1, "Computer Programming Language Policy"
Date: 12 Apr 1987 10:49-PDT
Subject: Second DoD Directive
From: [e-mail]

     On  April 2, 1987 the Honorable William H. Taft, IV (Deputy Secretary  of
Defense) signed DoD Directive 3405.1, entitled "Computer Programming  Language
Policy".   This  directive,  which was prepared by  the  Comptroller's  Office
within OSD, supercedes DoD Instruction 5000.31, "Interim List of DoD  Approved
Higher Order Programming Languages (HOL)" dated November 24, 1976.

     Section D. POLICY directly addresses Ada via the following:

3.  Limit  the number of programming languages used within the  Department  of
Defense to facilitate achievement of the goal of transition to the use of  Ada
for DoD software development.

       a.  The Ada programming language shall be the single, common,  computer
programming  language  for  Defense computer resources  used  in  intelligence
systems,  for  the command and control of military forces, or as  an  integral
part  of  a  weapon system.  Programming languages other than  Ada  that  were
authorized  and being used in full-scale development may continue to  be  used
through  deployment and for software maintenance, but not for  major  software
upgrades.

       b. Ada shall be used for all other applications, except when the use of
another  approved  higher  order  language is  more  cost-effective  over  the
application's life-cycle, in keeping with the long-range goal of  establishing
Ada as the primary DoD higher order language (HOL).

       c.  When  Ada  is  not  used, only  the  other  standard  higher  order
programming  languages  shown  in enclosure 3 shall be used  to  meet  custom-
developed  procedural language programming requirements.  The use of  specific
HOL's  shall  be  based  on  capabilities  of  the  language  to  meet  system
requirements.  Guidance in selecting the appropriate HOL to use is provided in
NBS Special Publication 500-117.

(Note  -  The list of approved languages shown in enclosure 3  includes:  Ada,
C/ATLAS, COBOL, CMS-2M, CMS-2Y, FORTRAN, JOVIAL (J73), Minimal BASIC,  PASCAL,
SPL/1.)

------------------------------------------------------------------------------
     C. DoD Directive 3405.2, "Use of Ada in Weapon Systems"
Date: 2 Apr 1987 10:48-PST
Subject: Signed DoD Directive on Ada*
From: [e-mail]

     I  am  pleased to announce that on Monday, March 30, 1987  the  Honorable
William  H.  Taft  IV (Deputy Secretary of Defense)  signed  a  DoD  Directive
entitled "Use of Ada in Weapon Systems" (tentatively designated DoDD 3405.xx).

     This directive requires the use of Ada for computers integral to  weapons
systems,  effective immediately; requires the use of validated Ada  compilers;
and  requires  the  use of an Ada based Program  Design  Language  during  the
designing of the software.

.pa
==============================================================================
 II. ASR TAPE DISTRIBUTION CHANGE and ASR OVERVIEWS

     This  section  announces the availability of a new source  for  the  ANSI
tapes  of the Ada Software Repository and presents an overview of the  current
status of the Ada Software Repository.

------------------------------------------------------------------------------
     A. ASR ANSI Tape Distribution
Date: Fri 3 Apr 87 11:42:55-MST
From: Frank J. Wancho <[e-mail]>
Subject: Alternate source for ASR ANSI Tapes

     As  some of you may be aware, our turnaround for requests for  copies  of
the ASR in ANSI format has been very poor.  One reason is that we have had  to
stop processing to make a new set of master tape files.  The technique we have
been  using  to  make  those  master tape files takes  time  to  build  and  a
considerable amount of disk space.  Because we don't do that process but every
six  months  or  so, our requestors do not necessarily get  the  most  current
image,  except  for  those in the queue while we are making  new  master  tape
files.  And, that queue has recently grown, and the number of calls requesting
the status has likewise increased.

     Sometime  back,  I had asked for other organizations to volunteer  to  be
alternate  sources  for this format, perhaps charging a fee for  the  service.
One such organization ce for ASR ANSI Tapes

     As  some of you may be aware, our turnaround for requests for  copies  of
the ASR in ANSI format has been very poor.  One reason is that we have had  to
stop processing to make a new set of master tape files.  The technique we have
been  using  to  make  those  master tape files takes  time  to  build  and  a
considerable amount of disk space.  Because we don't do that process but every
six  months  or  so, our requestors do not necessarily get  the  most  current
image,  except  for  those in the queue while we are making  new  master  tape
files.  And, that queue has recently grown, and the number of calls requesting
the status has likewise increased.

     Sometime  back,  I had asked for other organizations to volunteer  to  be
alternate  sources  for this format, perhaps charging a fee for  the  service.
One such organization kEn)ouMk\{B?O}o;}wf'{Q7
db1%s
qy2zzG.yajw5)|owYAhas recently come forward, and others are encouraged  to
do  likewise.   Because there is now at least one such alternate  source,  and
because  of the resources consumed, in operator and clerical time, as well  as
disk  space we need to make available for other uses, we will no  longer  make
copies of the ASR in ANSI format once we clear the current backlog.

     For further information, contact Vincent Bia, 602-686-6391, at
          Navajo Technology Corporation
          Navajo Nation
          Box 100
          Leupp, AZ 86035

     Other  organizations  are  encouraged to provide  the  same  service  and
publicize  the  availability of that service (just name,  address,  and  phone
number, please) through this forum.

------------------------------------------------------------------------------
     B. Snapshot of the ASR
Date: Mon, 20 Apr 87 12:28:45 MDT
From: Rick Conn <[e-mail]>
Subject: Snapshot of ASR and update

     The  online documentation system has been updated to reflect the  current
status   of  the  ASR.   Attached  is  a  current  snapshot  (from  the   file
PD:<ADA>ADA.SNP):

.pa
                                ---- Source Code ---- | --- Documentation ---
Directory                       Byte Count Line Count | Byte Count Line Count
-----------------------         ---------- ---------- | ---------- ----------
PD:<ADA.ADA-SQL>                   1117750      30503 |     248404       6038
PD:<ADA.AI>                         250984       7326 |     326909      10503
PD:<ADA.ANSI-LRM>                        0          0 |    1201050      46091
PD:<ADA.BENCHMARKS>                1426971      49891 |      77692       1941
PD:<ADA.CAIS>                      1719047      50360 |      10742        216
PD:<ADA.CAIS-TOOLS>                 152675       4442 |       7140        132
PD:<ADA.COMPILATION-ORDER>          359990       8147 |      86428       2790
PD:<ADA.COMPONENTS>                2037853      63162 |     141569       2966
PD:<ADA.CROSS-REFERENCE>             23786        695 |       4457         99
PD:<ADA.DBMS>                        81285       2345 |       5314        116
PD:<ADA.DDN>                       1959099      52150 |     135474       3426
PD:<ADA.DEBUGGER>                   889057      23052 |     512159      15927
PD:<ADA.EDITORS>                   1615008      36463 |     219584       5802
PD:<ADA.EDUCATION>                       0          0 |     374209       8857
PD:<ADA.EXTERNAL-TOOLS>              92404       3396 |      47265       1301
PD:<ADA.FORMGEN>                    318402       9788 |     152458       7965
PD:<ADA.GENERAL>                     11904        333 |     362773       7995
PD:<ADA.GKS>                       1991575      55737 |     273777       9884
PD:<ADA.MANAGEMENT-TOOLS>          1347705      38114 |     643121      26054
PD:<ADA.MATH>                      1226925      38096 |    1595731      75515
PD:<ADA.MENU>                       453562      10861 |     297293       8046
PD:<ADA.MESSAGE-HANDLING>           977501      25714 |     222916       5983
PD:<ADA.METRICS>                   2940672      81611 |     419416      14150
PD:<ADA.NEWS>                            0          0 |     446465       9675
PD:<ADA.ONLINE-DOC>                  63360       2260 |     248168       7340
PD:<ADA.PAGER>                       98378       3566 |      28338       1267
PD:<ADA.PDL>                       1963068      51631 |    1120314      22759
PD:<ADA.PIWG>                       964045      30770 |     169146       5416
PD:<ADA.POINTERS>                        0          0 |     312098       6297
PD:<ADA.PRETTY-PRINTERS>           1037841      20866 |      99222       3063
PD:<ADA.SIMULATION>                 337803      10346 |     170261       6615
PD:<ADA.SPELLER>                    893957      60483 |     466092      46028
PD:<ADA.STARTER-KIT>                 31895       1071 |      13694        326
PD:<ADA.STUBBER>                     81309       1808 |       5754        131
PD:<ADA.STYLE>                     2021624      48628 |     212703       7262
PD:<ADA.TOOLS>                     1320403      41278 |     397188      33374
PD:<ADA.VIRTERM>                    312797       8887 |     642761      17479
PD:<ADA.WIS-ADA-TOOLS>                   0          0 |     350390       7016


                                ---- Source Code ---- | --- Documentation ---
Totals                          Byte Count Line Count | Byte Count Line Count
-----------------------         ---------- ---------- | ---------- ----------
Column Totals            -->      30120635     873780 |   12048475     435845
Grand Total (Col 1 Only) -->      42169110    1309625 |          0          0

.pa
------------------------------------------------------------------------------
     C. Most Popular Files in the ASR and Total Number of Accesses
Date: Tue, 21 Apr 87 05:50:27 MDT
From: Rick Conn <[e-mail]>
Subject: Most Popular Files

     The  following lists the files in the Ada Software Repository which  have
had 300 or more accesses (directly from the DDN).

   name                                     # refs,     rate/month,     size.
<ADA.COMPONENTS>LIST.ADA.2                  406              13       7 pgs
<ADA.GENERAL>KERMIT.DOC.1                   341              11       7 pgs
<ADA.COMPONENTS>SAFEIO.ADA.2                339              11       4 pgs
<ADA.EDUCATION>TITR.DOC.1                   338              14      28 pgs
<ADA.BENCHMARKS>BENCH.DOC.1                 337              16       3 pgs
<ADA.AI>EXPERT.ADA.1                        336              20      15 pgs
<ADA.COMPONENTS>LIST.PRO.2                  335              11       2 pgs
<ADA.COMPONENTS>ABSTRACT.SRC.1              331              15     224 pgs
<ADA.COMPONENTS>VDT100.SRC.1                330              11       6 pgs
<ADA.COMPONENTS>QSORT.SRC.1                 330              11       3 pgs
<ADA.AI>EXPERT.PRO.1                        328              19       2 pgs
<ADA.COMPONENTS>LIMPRIOR.ADA.2              325              11       3 pgs
<ADA.COMPONENTS>SAFEIO.PRO.2                324              11       2 pgs
<ADA.COMPONENTS>DSTR1.ADA.1                 320              13       4 pgs
<ADA.GKS>GKSUSER.DOC.1                      316              15      99 pgs
<ADA.COMPONENTS>VDT100.PRO.1                314              11       2 pgs
<ADA.COMPONENTS>PRIOR.ADA.2                 314              10       3 pgs
<ADA.PRETTY-PRINTERS>PRET.SRC.1             311              14     131 pgs
<ADA.COMPONENTS>LIMPRIOR.PRO.2              310              10       2 pgs
<ADA.COMPONENTS>PARSER.PRO.1                308              14       2 pgs
<ADA.COMPONENTS>PARSER.SRC.1                307              14       5 pgs
<ADA.PAGER>UNPAGE.ADA.1                     306              11       3 pgs
<ADA.GKS>GKS.PRO.1                          306              14       2 pgs
<ADA.EDUCATION>ADA1FOR.DOC.1                306              12       3 pgs
<ADA.AI>EXPERT.DAT.1                        305              18       1 pgs
<ADA.GENERAL>KERMICRO.DOC.1                 304              10      12 pgs
<ADA.COMPONENTS>PRIOR.PRO.2                 303              10       2 pgs
<ADA.EDUCATION>OBJECT.DOC.2                 302              11       4 pgs
<ADA.COMPONENTS>QSORT.PRO.1                 302              10       1 pgs
<ADA.COMPONENTS>DSTR1.PRO.1                 302              12       2 pgs
<ADA.COMPONENTS>CAS2.PRO.1                  300              11       1 pgs
<ADA.BENCHMARKS>BENCHABS.DOC.1              300              14       2 pgs


     For  your interest, as of the last online documentation update,  the  Ada
Software  Repository contained 994 files which have been accessed a  total  of
156,028 times since the ASR was set up on November 25, 1984.

.pa
==============================================================================
III. SOFTWARE REUSABILITY

     This section continues the discussion of software reusability issues.

------------------------------------------------------------------------------
     A. Ed Berard et al on Software Reusability
Date:     Tue, 10 Mar 87 15:16 CDT
From:     "SVDSD::PETCHER%ti-eg.csnet"@RELAY.CS.NET
Subject:  Ada reuseability

     Regarding Ed Berard's comments on software reuseability:

     There  are some additional roadblocks in the way of reuseability.   While
electronic  engineers  have  been able to freely  obtain  integrated  circuits
without  anybody worrying about who has the "rights" to the design,  the  same
has  not  been  true for software.  The government tends  to  demand  complete
rights  not  only  to embedded operational software, but  also  to  all  tools
required  to  maintain  it.  This tends to  prevent  software  designers  from
reusing  modules  from sources who believe they have a  vested  interested  in
their  software  design (as do chip makers in their chip  designs.)   This  is
worsened because distribution of source reveals 100% of the design information
on a software module, whereas corresponding information (schematic, electrical
characteristics,  etc)  for an integrated circuit  reveals  virtually  nothing
about the process technology required to make it.  Certainly no company  would
want  to invest money in development of generic reuseable software modules  if
it means the very first time they use a given module on a contract that module
is swept into the public domain.

-----------------------------------------------------------------------------
Date: 21 Mar 1987 09:02:34 PST
Subject: DoD and Software Reusability - Part 3
From: Edward V. Berard <[e-mail]> [phone]

     In  my  previous  two  communications,  I  questioned  whether  the  U.S.
Department  of Defense (DoD) was really committed to the reuse of software.  I
observed that a number of DoD policies and standards represented either direct
or indirect roadblocks to the reuse of software for DoD applications. Based on
the  responses  I have received, I am encouraged that several people  are  not
only  aware  of  the potential problems, but are also  investigating  ways  to
directly  address  the problem. (Many responses were directed directly  to  me
rather than to the mailing lists to which I originally posted the messages.)

     To  be completely honest, those who provide software to the DoD are,  for
the  most  part, ill-prepared to deal with reusable  software  technology.  In
effect,  if the DoD removed all roadblocks to the reuse of software  tomorrow,
it  would  still be a long time before DoD contractors could  adequately  deal
with the concept.

     Why do I say this? Consider the following:

          1. Few companies and organizations have anything that even  slightly
resembles  a  comprehensive  software reusability plan.  Yes,  many  of  these
companies  and organizations have someone somewhere who is  "researching"  the
idea. However, few have any intentions of implementing such a plan any time in
the near future. Let's face it: software reuse is hardly a "top priority item"
for many software firms.

          2.  Examine the commercial marketplace. How many vendors do you  see
who  are selling software reuse related products? I am not referring  just  to
reusable software modules. What about entire software reusability systems,  or
tools  specifically  designed to aid and foster the reuse of  software.  (Some
vendors have taken old products and placed the words "reuse" and "reusable" in
their marketing literature. While some of their claims may be true, the  reuse
of software is not quite business as usual.)

          3.  Look  at the software engineering training available.  How  many
courses  whose main focus is software reuse can you name? Compare that to  the
number  of "Ada(tm) courses" that are currently offered. For that matter,  how
much  emphasis  is placed on the reuse of software in  the  existing  courses?
Remember, it is not only the "technical staff" who must be trained in software
reuse. Management must also be trained in software reuse.

          4.  Examine  the attitudes of the  software  personnel  (programmers
*and*  managers) themselves. For some time now, I have been  participating  in
software reusability forums, and I have become aware of many "horror  stories"
relating to software reuse. For example, it is not uncommon to hear  technical
personnel  recite  long  lists of the  "disadvantages  of  reusing  software."
Managers  seem  equally  committed to maintaining the status  quo.  Even  when
managers  purchase the tools and training necessary for  rudimentary  software
reuse,  staff  resistance to the concept is still high.  (Skip  Carstensen  at
Magnavox in Ft. Wayne has some interesting insights into this problem.)

     Yes, the DoD seems to want to encourage the reuse of software. (Just this
past  week  I  heard more than one Army general use the  term  in  a  positive
manner.) And I am sure they are not completely aware of the full ramifications
of  their  commitment. (Many policies and standards will have to  be  changed,
personnel  will  have  to  be trained, and new initiatives  will  have  to  be
created, to name a few.) However, those of us who provide software services to
the DoD must get our own act together. If we are clever about it, we can get a
lot of work done before the DoD removes the last roadblock to software reuse.

-----------------------------------------------------------------------------
Date: 24 Mar 1987 02:33:02 PST
Subject: DoD and Reusability - Part 4
From: Edward V. Berard <[e-mail]>

     Those  of  us  who  pose problems to others  should  also  pose  possible
solutions  to those problems. In my previous three messages, I  observed  that
the  U.S.  Department of Defense (DoD) had (hopefully  unwittingly)  placed  a
number  of  roadblocks in the path of software reusability.  I  also  observed
that  those contractors who provide software services to the DoD need to  make
some changes to fully exploit the concept of software reusability. The purpose
of  this  message  is to offer a few suggestions to both  the  DoD  and  their
contractors on that same subject.

     First, to the DoD:

          1.  Current  and future software standards and  policies  should  be
explicitly  examined  for  their impact on software reusability.   THIS  IS  A
*TECHNICAL*  ITEM.  Merely placing such words as "software reusability"  in  a
standard  or policy will not guarantee sound reuse of software. Concepts  such
as  software  development  methodologies,  software  quality  assurance,   and
efficiency  have  a  direct impact on software reuse.  The  DoD  should  avoid
supporting  software  reuse  in  one  part  of  a  standard  or  policy  while
discouraging it in another part of that same standard or policy.

          2. A "Software Reusability Plan" (SRP) should be a required part  of
any  contractor's software proposal. This plan should include descriptions  of
the tools and libraries the contractor plans to use to exploit software reuse,
the level of software reuse training for both the software engineers and their
management,  estimates  of  the level of software  reuse  for  the  particular
project,  and  a  statement  on the impact of  software  reuse  (positive  and
negative) for this project.

          3.  Software contractors should also be required to produce a  short
post-project  assessment  of the impact of software reuse  on  their  project.
These assessments should be placed in the public domain whenever possible.

          4.  With  all due respect to the good work that Rick Conn  has  done
with  the Ada Software Repository (ASR), the mandate of the ASR should be  re-
examined.  One  of the original goals of the ASR was to provide  a  number  of
examples and tools to those just getting started in Ada technology. There were
few, if any, restrictions placed on the software which was placed in the  ASR.
We  need  to  recognize  that the repository might  be  made  more  useful  by
subjecting  (at  least  some)  of the Ada software to  some  kind  of  quality
assurance.

          5. The DoD should either establish, encourage the establishment,  or
recognize  the  equivalent  of  an  "Underwriters  Laboratory"  for   reusable
software.  This  entity  would  be charged  with  indicating  the  quality  of
potentially reusable software. This is no small task.

     Second, for the contractors:

          1. Establish an internal software reuse plan. Regardless of  whether
the  DoD  ever  requires  it  of its contractors, such  a  plan  can  help  an
organization control both the quality and costs associated with software.

          2.  Require  that software reusability be an integral  part  of  any
technical  and  managerial training. This should be especially true  for  Ada-
related training.

          3.  In  accordance  with your in-house  software  reusability  plan,
acquire  the tools and libraries you feel will most positively  contribute  to
the reuse of software within your organization.

          4.  Encourage  the use of methodologies and tools  which  have  been
demonstrated to enhance the reuse of software.

          5.  Track and measure both the reuse of software and the  impact  of
software  reuse.  Policy  decisions  should be made on  "hard  data,"  not  on
guesswork.

          6.  Management must let it be known that it actively encourages  the
reuse of software.

          7.  Recognize  that more than just "modules" can be  reused.  Tools,
test  data,  designs,  plans, environments, and other software  items  can  be
reused.

          8.  Above  all, recognize that software reuse is  not  "business  as
usual."  A  commitment  to software reuse will  require  some  changes.  These
changes should be introduced in an effective manner. Remember that the concept
of software reuse is alien to most technical and managerial personnel.

     The above suggestions are not the only ones that need to be considered. I
view them as a "starting point" for future discussions.

-----------------------------------------------------------------------------
Date: Tue, 24 Mar 87 18:13:11 PST
From: David Wolfe <[e-mail]>
Subject: Re:  DoD and Software Reusability - Part 3

     Indeed, almost all of the management types I know of throughout  industry
will pay lip service to the idea, but privately react to the idea with horror.
After  all, are YOU going to sell the Government on an idea that  will  reduce
the amount of labor on YOUR contract! Looking for industry to take the lead in
this matter is a forlorn hope -- people do not naturally put themselves off of
the gravy train.

     My  experiences indicate that while the "reactionary programmer"  problem
is  real,  that  they can be brought around after they see how  much  work  is
saved.   Bringing management around is another matter, as they don't  have  to
actually those nasty old coding jobs anymore.

     Software  reusability  will have to come from government  initiative,  by
putting  a  gun to everybody's head.  The principle problem is, what  kind  of
gun, and what kind of bullits?

-----------------------------------------------------------------------------
Date: 26 Mar 87 11:22:00 EST
From: "SI03::ZIEMBAM" <ziembam%si03.decnet@esdvax>
Subject: Reusability - Part 4 (comment)

Dear EVB,
     I  have  read,  with  interest,  your  (so  far)  four  declarations   on
establishing  a  lucid plan for exploiting reusability.  You raise  some  very
intersting  points, as well as controversial points that will probably  plague
the  issue  and, thus, prevent any clear thrust toward progress  in  the  near
term.

     I  published  an  ESD technical report in April of  1985  entitled,  "Ada
Reusability Guidelines".  Do you have a copy?  The TR number is ESD-TR-85-142.
The  work  was  done by SofTech, under sponsorship of  The  Computer  Resource
Management Technology Program (PE 64740F).

     Let me know if you need a copy.  I have a limited number of extras.

Mark V. Ziemba, 1Lt, USAF
Project Manager, Software Engineering Tools & Methods
The Computer Resource Management Technology Program (PE 64740F)
  ESD/XRSE
  Hanscom AFB, MA  01731
  [phone]

-----------------------------------------------------------------------------
Date: 25 Mar 87 19:23:26 GMT
From: pyrnj!mirror!cca![e-mail]  (Christopher Reedy)
Organization: Computer Corp. of America, Cambridge, MA
Subject: Re: DoD and Reusability - Part 4

In article <[e-mail]> Ed Berard writes:
>   1. Current and future software standards and policies should be
>      explicitly examined for their impact on software reusability.
>      THIS IS A *TECHNICAL* ITEM. Merely placing such words as
>      "software reusability" in a standard or policy will not
>      guarantee sound reuse of software.   . . .
Absolutely!!

>   2. A "Software Reusability Plan" (SRP) should be a required part of
>      any contractor's software proposal.   . . .
>
>   3. Software contractors should also be required to produce a short
>      post-project assessment of the impact of sofware resue on their
>      project.  These assessments should be placed in the public domain
>      whenever possible.

     I believe (for personal philosophical reasons) that software reuse is the
only  way that we can solve the crisis in software development.  Therefore,  I
agree with the concept here.  But ...

(FLAME ON)

     I  have  seen a large number of programs out of the DoD where  an  almost
infinite  variety  of  plans,  documents and  reviews  were  required  of  the
contractor.   A  number of these projects failed because they took  too  long,
were  too  costly, or failed to adequately address the  requirements.   In  my
personal  experience,  the  failure  probability  of  the  project  could   be
correlated  positively  to the number of documents, reviews,  etc.  that  were
called for.  I.e.  the more documents, etc. the more likely the project was to
fail.

     I believe that the primary cause for this phenomenon is that the DoD (and
the  government  in  general) does not take plans,  documents,  reviews,  etc.
seriously.   I have rarely seen the resources committed by the  government  to
adequately review, for example, the detailed design of the software as a  part
of a CDR (Critical Design Review).  In many of these cases, the reviews are  a
"dog and pony shows" that allow the government program manager to impress  his
peers  and  supervisors  with how well the program is  progressing.   In  this
environment, criticism of the program is discouraged.  Further, the contractor
usually knows that a real review will not be held.  This allows the contractor
to  do work he knows to be inadequate on the basis that he needs to  make  his
milestones (in order to get a good review from HIS supervisor) and can make up
the  work later.  Unfortunately, coding (or whatever) comes after  the  review
and  once  the government has approved the design, the contractor  MUST  start
coding, leaving no time to return to complete the design.  Finally, (and worst
of  all)  in some cases the contractor doesn't know better  and  assumes  that
because  he  has checked all the boxes and passed the review, that he  has  in
fact done an acceptable job.

     Those projects that I have seen that have been successful have tended  to
either:

          (a) have the government take their role as reviewers of the  project
seriously.   This  requires  a willingness (and budget) on  the  part  of  the
government  program  management  to commit the resources necessary  to  do  an
adequate  review, and to understand that if contractor's work  is  inadequate,
that  the  program will have to be delayed and/or replanned, but  that  it  is
better  to do that now than deal with the inevitable problems and delays  that
will arise later.  Or,

          (b) have the government trust the contractor, save contract funds by
holding minimal reviews and requiring minimal documentation and make sure that
everyone  understands  that  the contractor will be at fault  if  the  program
fails.

(FLAME OFF)

     Which is all to say ...

     Before proposing yet another document that must be produced by government
software contractors, I believe you should consider whether this document will
be treated by the government (and therefore the contractors) as another box of
paper  that  must  be provided by the contractor and will be  filed  away  and
forgotten  or whether it will be taken seriously by the  government's  project
management offices.

     I  offer  the proposal that government procurement offices  require  that
program  management offices provide (and make use of) resources and  a  budget
for adequately reviewing and critiquing the documents that are produced by the
contractors.   I personally believe that this would provide more  benefits  in
terms  of  the success of software projects than all  the  additional  ignored
documentation that one might require the contractor to produce.

-----------------------------------------------------------------------------
Date: 16 Mar 87 18:11:59 GMT
From: decvax!savax![e-mail]  (tom royer)
Subject: Re: reusability

In  article  <[e-mail]>,   [e-mail]
writes:
> Having just read the two dissertations on reusability
> submitted by Mr. Berard, I find myself wondering about a
> couple of things.
>
> First, it seems to me that the Cost-Plus-Fixed-Fee contract
> is not, in itself a barrier to the development and use of

     CPFF  contracts might, indeed, provide a vehicle for developing  reusable
software, provided that the acquisiton agency (the DoD) was willing to pay for
improved reusability and reduced cost for the next contract.

     The  tendency of government contractors to overrun  software  development
(and  other)  contracts has, however, inclined the DoD toward the  Firm  Fixed
Price contract (rightly or wrongly -- that's another discussion) in which  the
contractor  is locked to an estimated price which must be the lowest of  those
submitted  by  the bidders.  In this fixed cost environment, there  is  little
incentive on the part of a contractor program manager to invest the added cost
or  schedule necessary to produce truly reusable software since  the  benefits
will  be reaped by the guy with the next contract, not by  him.   Furthermore,
the  contractor itself has little to gain by encouraging its program  managers
to build such systems unless and until the DoD makes reusability and long-term
life cycle cost a part of the proposal selection criteria.

-----------------------------------------------------------------------------
     B. A Reusability Proposal
Subject: Re: DoD and Reusability - The Movie
Date: Wed, 01 Apr 87 11:01:10 EST
From: Bob Munck <[e-mail]>

     It  makes  me crazy to see proposals for DoD reuse of software  that  use
terms  like "standards and policies," "reusability plan," or "encourage."   It
is  the  case  that  program officers are MOTIVATED to  keep  the  project  on
schedule and within budget during their tour of duty.  Other things, like  the
quality of the product and future costs to maintain it are secondary.   (Note,
I'm  talking  about  the  motivation  of  these  people  by  the  system,  not
necessarily  their own predilections; I've seen many of them fight the  system
to be allowed to make the product better, at some cost to their own careers.)

     If  quality and life-cycle costs are secondary, the possibility of  reuse
of  the software on some later project is far down in the noise.  The  results
of  a program office's doing a good job on reusability on one project  doesn't
show  up until the next project is nearly finished. Given current  development
times, that's a half-dozen years or so; no way are those original people, long
re-assigned, promoted, or retired, going to be rewarded.  Please don't tell me
that they would have been rewarded at the time; that runs counter to the DoD's
general  policy  of  "don't make waves" and institutional  inability  to  make
judgments about quality.  They know that they can get the same result by  just
going  through the motions, publishing the policies and having the reviews  on
schedule.

     It's my opinion that the DoD will be unable to take advantage of software
reuse  without  significant  institutional  changes in  the  way  it  acquires
software.   An  idea like reuse has to be "owned" by someone, has to  be  some
person or group's major mission and goal.  Moreover, that someone has to  have
direct responsibility for acquiring the systems AND have the money  necessary.
We  can't continue to "tack on" reusability the way we impose minority  hiring
on  highway  construction, attempting to do two jobs with the same  bucks  and
doing neither well.

     My   proposal  is  that  software  acquisition  should  be  done  on   an
application-area  basis  instead of the current project basis.   For  example,
"avionics"  might be a suitable application area.  There would be an  Avionics
Software Office set up with the responsibility of acquiring the basic avionics
software  for all services for the next fifty years.  They would  analyze  the
field   of  avionics,  isolate  functions  that  are  basic  to  it  and   the
parameterization needed to make packages tailorable to fit most circumstances,
and  procure  the  packages.  They would then supply  software  to  particular
projects, customizing their standard packages where necessary by expanding the
parameterization to include the particular circumstances.  A project might get
software  from  several Software Offices and fit it together like  an  Erector
Set.   The  software  office personnel would be motivated to  save  money  and
shorten schedules on projects by doing a good job of software reuse.

     It's  a big change from the current way of doing business; I'm  not  sure
the bureaucracy is capable of such change.

-----------------------------------------------------------------------------
     C. Software Component Engineers
Date: Sun 29 Mar 87 11:02:40-PST
From: [e-mail] (Sam Harbaugh)
Subj:    Software Component Engineers

     Ed Berard's discourse on reusability has inspired me to share my  thought
that  there  is  a  need for Software  Component  Engineers,  a  job  function
analogous to the time honored profession of Hardware Component Engineer.
     A  friend of mine was head of component engineering at a  major  computer
company. He had about 15 engineers working for him. One engineer was in charge
of  crystal  oscillators  another in charge of  certain  types  of  integrated
circuits.
     I believe that as the software industry grows it will reach a level where
large  companies have a software components engineering group with  e.g.:  one
engineer  responsible  for DBMS's another for ARTE's, another  for  scientific
routines etc.

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

Date: 2 Apr 87 01:57:52 GMT
From: linus![e-mail]  (Steven D. Litvintchouk)
Organization: The MITRE Corp., Bedford, MA
Subject: Re: S/W Component Engineers (try2)

>     I believe that as the software industry grows it will reach
>  a level where large companies have a software components
>  engineering group with e.g.: one engineer responsible
>  for DBMS's another for ARTE's, another for scientific
>  routines etc.
     Japan's  "Software Factories" already do something analogous.  I  read  a
paper   about  the  Toshiba  Fuchu  Works.   They  have  a   "Software   Parts
Manufacturing Department" something like what you suggest.
.pa
==============================================================================
 IV. Ada CONTRACTUAL ISSUES

     This  section  contains  an  interesting  (and  probably  quite   useful)
discourse on contractual issues regarding the use of Ada.

Date: 2 Apr 87 13:51:00 EST
From: "Paul Byrley" <byrley@ntsc-74>
Subject: Contractual issues in Ada

     I would like some help in preparing RFPs for Ada projects. There are just
lots  of issues which keep coming up and I need some good ideas. A forum  such
as  these  bulletin  boards  should allow a free exchange  of  ideas  so  both
industry and government benefit.

     As  a start, I am providing what I call Issue 1. The format is  "off  the
top  of my head" and subject to change- any ideas?  I hope that  other,  maybe
many other, issues relating to the problems inherent in contracting for modern
software (i.e. Ada), using modern methodologies etc can be discussed.  Someone
out there (not me) can maybe write a book on contracting for Ada.

     Other issues I have trouble with are: reusable software; mixing  existing
equipment with new sw (do I require Ada when 40% ?, 70% of the software (maybe
C or Pascal) has been written and sold on another contract to Govt or  private
sector?);  Defining an APSE as part of a procurement;  DOD-STD-2167  tailoring
for  Ada (Wake up Don Firesmith!)....many more. Please feel free to  add  your
problems and/or help solve them. Please try to avoid the areas where your  and
my Congress has decreed a certain procurement rule. Out of scope!

     Is this of any interest to anyone?  My first try at it follows.

*****************************************************
Subject: Issue 1

Issue: Contractor Tools vs Government Needs

     The  Government  wishes to encourage contractors to develop  or  purchase
software  tools  to improve quality and improve productivity.  The  Govt  also
needs  to be sure that the delivery of software includes the  tools  necessary
for software support over the life cycle.  Often, Govt is not sure what  those
tools  are and, as a result, requires or tries to require the delivery of  any
and  all tools used in the software development effort. This Govt  action  has
had the effect of suppressing industry investment in quality and  productivity
enhancing software tools.

     What  kind of contractual language might allow industry to safely  invest
in in-house improvements and also would require the needed life cycle software
support tools needed by the Govt?  I don't have the answer, but I need it.

     As a strawman:

SOW Language-

1.3.7.1.1  The contractor shall reuse, develop or procure  automated  software
tools  and necessary equipment to develop software in a modern,  high  quality
and cost efficient manner.

...

1.4.2.3 The contractor shall provide as reusable, develop or procure automated
software tools and the data rights rquired by this contract, necessary for the
Government     to     maintain     the     delivered     software      product
(CSCI__________,CSCI___________and CSCI___________) over the life cycle. These
automated  software tools shall be part of the APSE and shall be  included  in
CSCI_________.


Specification Language-

3.6.9.2 APSE shall include integrated, automated software tools necessary  for
the  following  functions:  Compile,  ________,  _________,  _________,   ...,
Configuration Management.

3.6.9.2.1  Compile- A currently validated Ada compiler of  production  quality
which compiles at least 500 Ada statements ending in a semicolon and generates
no  more  than  12  machine instructions per Ada  statement,  on  average,  is
required.   [better  numbers  or  better  definitions  are  sought].   Project
validation  shall  be  provided  by the contractor  based  on  the  validation
certificate in effect at (PDR?), (CDR?)--(better words?)

...

3.6.9.2.n Configuration Management- Tools for automated software configuration
management shall be one or more commercial software products sold for software
configuration  management.  Software  tools  license  and  all   documentation
normally  provided  to a commercial purchaser of the tools  is  required.  The
configuration  management  tools  shall provide as a  minimum,  the  following
functions:
   a)
     ...
   f)


Technical Proposal Requirements (The Govt's instruction to the bidder
for required content of his proposal)

4.4 SOFTWARE TOOLS-

4.4.1 The offeror shall functionally describe the automated software tools  he
proposes  to use in development of software under this contract.  These  tools
need not be deliverable. Offeror shall provide enough detail of the tools  and
their  use  to  provide  the  Government  with  knowledge  of  the   potential
improvement in quality and productivity due to these tools.

4.4.2  The offeror shall describe, in detail, all deliverable  software  tools
which will allow the Government to perform life cycle support efficiently  and
with  high quality. The degree of integration with APSE hardware  and  between
tools shall be described. Each tool shall be identified as either  commercial,
developed  by  the  offeror or one of his  proposed  sub-contractors  with  or
without government money.  Data rights of each software tool shall be  clearly
identified  for all tools other than commercial. [note- commercial is  defined
by FAR or elsewhere in the rfp]

------------------------------------------------------------------------------
Date: Thu, 9 Apr 87 10:59:19 EST
From: [e-mail] (Dave Emery)
Subject: re: contractual issues in Ada

     Paul, you've raised some good issues.  Let me raise some more...

     re:   software tools...  It is not sufficient for the contractor  to  buy
tools,  he  must make them work together.  For instance,  we've  seen  several
contracts  where  the  contractor proposes Tool A  for  requirements  (i.e.  a
Yourdon tool), Tool B for high level design (maybe a PAMELA tool), Tool C  for
low level design (i.e. Ada PDL), and Tool D for implementation (i.e. SCCS  and
Make).  Most of the tools run on IBM PCs (standalone).  The problem is how  to
make  them  work together.  If Tool A keeps a database  of  requirements,  you
would  like  Tool  B  to somehow 'talk to'  this  list  of  requirements,  for
traceability, if nothing else.

     Another consideration is the tool environment.  If you have 10  designers
using PC based tools, how do they communicate?  Floppy Disk?  How is the  data
on  each PC kept consistent?  If you have 10 designers, how many PC's  do  you
have?  Hopefully, you have more than 1.

     I  believe  that it is important that the government have access  to  the
contractor's  tools.   Otherwise,  how can the  government  maintain  designs,
handle  changes in requirements during 'maintenance', etc?  The  legal  issues
surrounding   government  access  to  contractor-developed  (as   opposed   to
commercial) tools should be investigated.  The other problem with  contractor-
developed tools is maintenance (who does it, and who pays for it).

     However  you  approach it, it is important that the tools are  useful  in
producing   the  software,  rather  than  either  'proposal  boilerplate   and
motherhood' or the major focus of the development.

     One other note:  It is important that the contractor can show that he can
use the tool.  Besides specifying that he will use Tool X, he should show that
he has people who are trained in using Tool X, and that Tool X fits well  into
his general software development methodology.

     re:  Compilers...  You can't talk about compilation speed without knowing
the  host  system (computer and O.S.).  500 lines per minute on an IBM  PC  is
pretty  good, but is horrible for a Cray.  Furthermore, compilation  speed  is
often secondary to the speed and reliability of the surrounding toolset.   For
instance, what if the compiler runs 5000 lines per minute, and the  equivelant
link  speed is 1 line per minute.  My experience is that, particularly  during
unit test, when you have the edit, compile, link, execute cycle, link time  is
much  more  significant  than compile time.  If it takes  you  25  seconds  to
recompile  a  broken piece of code, and 15 minutes to link that same  code  to
test  your fix, you don't get very much done.  (p.s.  Those numbers  are  real
numbers from an Ada project I worked on...)

     Now,  onto  object  size... Ugh!!!  You don't want  to  specify  compiler
efficiency  that  way!  What about a generic instantiation  of  text_io?   One
semicolon  can  produce 10000 bytes of object code?  Right now, on  a  project
here  at  MITRE, we are looking at 253 bytes per semicolon, and  that's  using
Verdix,  which  shares generic bodies.  If we turn generic sharing  off,  that
number  will  probably  grow  to somewhere nearer  400  bytes  per  semicolon.
Instead,  you should look at some specific tests, and determine, for  a  given
program, the optimum (hand coded and globally optimized) size, and measure how
much a given compiler deviates from that theoretic minimum.  Furthermore,  how
about a compiler for a RISC machine, where the architecture expects  compilers
to  produce  lots  of  very fast instructions,  compared  to  a  compiler  for
something like the Intel 432 (or Rational), where there is a much closer match
of  op-codes to Ada statements?  Optimization/efficiency requirements must  be
addressed to specific host/target/runtime-operating system configurations.

     Another  issue regarding tools in general, but  particularly  development
tools  (i.e.  compilers) is sufficient 'horsepower'.  As a rule  of  thumb,  I
think  that  you should have no less than .5 MIPS of computer  power  PER  ADA
PROGRAMMER,  and  that 1.0 MIPS is necessary to get real  productivity.   I've
talked  to  several other people engaged in large scale Ada  development,  and
there  is  a fair amount of agreement that the amount of computing  power  per
programmer  should be in this .5 to 1.0 range.  It is very clear that one  VAX
11/780  (1 MIPS) will not support 50 Ada programmers.  The  contractor  should
show that he has enough computer resources to support the effective use of the
tools.   (p.s.  Making people work shifts because of hardware  constraints  is
evidence to me that the contractor cannot support the development.  Shift work
reduces  the  ability of programmers to communicate, and that causes  lots  of
integration problems, not to mention the personnel problems.)

     re:    configuration  management...   It  is  very  important  that   the
contractor integrate his configuration management system into the whole  APSE.
We  have heard horror stories of configuration management systems that  proved
to  be  completely  incompatable with the contractor's  Ada  compiler  program
library  system.   In other words, the contractor's CM system could  not  work
with  their  Ada compiler.  Like the front-end tools, many of  the  commercial
tools  do not integrate well with other tools, but integration is  what  makes
tools useful.

     One  thing  that has been tried on at least one procurement is  a  sample
project  (an  experiment), where the bidders are given a small  problem,  with
some  connection to the actual contract, and are asked to design  and  develop
software  using  their proposed methodology, tools, and people  who  would  be
working  on  the actual project.  Such an experiment brought out many  of  the
issues in tool use, tool integration, and overall contractor competency BEFORE
the  contract award.  (A note to contractors out there...don't be suprised  to
see more of these pre-award experiments...)

     I guess in summary the one single point I'd make is that the toolset must
be  integrated  with the contractor's ENTIRE software  development  framework.
The contractor must know where he is going, and how tools help him get  there.
He should show how the tools work with each other, and that he has  sufficient
(computer and personnel) resources to take advantage of the tool.

.pa
==============================================================================
  V. Ada EXPO and SIGAda CALLS FOR PAPERS

     This section contains calls for papers for the upcoming Ada Expo '87  and
SIGAda conferences to be concurrently in Boston in December.

Date:  Thu, 2 Apr 87 15:55 EST
From:  [e-mail]
Subject:  Call for Papers - SIGAda International Ada Conference


                               Call for Papers
                                Using Ada (R):
   1987 ACM SIGAda International Conference on the Ada Programming Language

                            December 9 - 11, 1987
                            Sheraton Boston Hotel
                              Boston, Mass.  USA

     The  theme   of the  conference will be the techniques of using  Ada  for
large systems.   Papers will  address the  practical side  of use  and  relate
to working examples  of the  use of  Ada  as  it  differs  from  and  provides
advantages over other languages.

     The conference will be held in conjunction with Ada Expo '87.

     Contributions are sought in areas including the following:

      *  Costing  and  estimating  with  systems  for  which  Ada  is
          markedly different
      *  Design with Ada-oriented PDL
      *  Configuration control and other life-cycle issues
      *  Techniques for reusability and operational taxonomies for finding
          code
      *  Unique Ada techniques for specific application areas
      *  Secondary standards  and interfaces  (graphics,  database,  etc.)
          and their use
      *  Maintenance of Ada systems
      *  Tools and environments that facilitate Ada project development
      *  Techniques for building real-time systems in Ada

     Extended abstracts  (5 pages  maximum length)  must be sent in 12  copies
to the program chair, W. Whitaker, by June 1, 1987.  Camera-ready copy will be
required  by  September 1, 1987,  with assurance that the paper  has  received
clearance for open publication.

    Deadlines:        Extended Abstracts Due       June 1, 1987
                    Notification of Acceptance    July 15, 1987
                    Camera Ready Copy Due        September 1, 1987

    Conference Chairman: Benjamin M. Brosgol
                     Alsys, Inc.
                     1432 Main Street
                     Waltham, MA 02154
                     Milnet: Brosgol @ MIT-Multics

    Program Chairman:    William A. Whitaker
                     Box 3036
                     McLean, VA 22103
                     Milnet: WWhitaker @ Ada20


-----------------------------------------------------------------------------
Date: 19 Apr 1987 09:49:25 PDT
Subject: Ada EXPO 1987
From: Edward V. Berard <[e-mail]>

     Ada(r) Expo 1987 will be held during the second week of December 1987  on
Boston,  Massachusetts. The major theme will be on the accomplishments of  Ada
technology  (as opposed to the "promises" of Ada technology). In  addition  to
presentations on the application of Ada technology for military systems, there
will  an effort to include presentations on the use of Ada technology in  non-
DoD  governmental  applications, commercial applications, and  foreign  (i.e.,
non-U.S.) applications.

     We,  on  the  executive committee, are looking for people  who  can  make
meaningful,  fact-filled  presentations on a number of topics related  to  Ada
technology.  We  are primarily interested in those who can speak  from  actual
experience. We would prefer people who can give balanced descriptions of their
experiences. Some of the topic areas include:

   - Conceptual Framework of Design Methodologies
   - Object Oriented Development and PAMELA
   - SAIS and MASCOT
   - Formal Design Methodologies
   - Life-Cycle Maintenance Issues
   - Case Studies
   - Ada and Software Engineering Technologies from a Management
     Perspective
   - Managing the Transition to Ada
   - Human Resource Requirements for Ada Projects
   - Specifying Ada Systems and Responding to RFPs
   - Lessons Learned from Real Projects
   - Near Future Directions in Ada Technology

     If you or someone you know might be able to give a presentation on  these
and other Ada technology-related topics, please feel free to contact Ed Berard
directly. DO NOT POST RESPONSES TO THIS MAILING LIST.

   Edward V. Berard
   EVB Software Engineering, Inc.
   5320 Spectrum Drive
   Frederick, MD  21701
   phone: [phone]

   ARPAnet [e-mail]

Suggestions and comments are always welcome.

.pa
------------------------------------------------------------------------------

Date: 21 Apr 1987 20:32:57 PDT
From: [e-mail]
Subject: DECEMBER SIGADA CONFERENCE

     JUST  SO NO ONE WILL BE TOO CONFUSED, THERE ARE TWO CONFERENCES GOING  ON
AT  ROUGHLY  THE  SAME PLACE AND TIME THIS DECEMBER IN  BOSTON.   ONE  IS  THE
BIANNUAL  SIGADA INTERNATIONAL CONFERENCE AND THE OTHER IS THE ADA  EXPO.   ED
BERARD  IS LOOKING FOR PAPERS FOR ADA EXPO AND I AM THE PROGRAM CHAIR FOR  THE
SIGADA  MEETING AND WOULD BE DELIGHTED TO HAVE PAPERS TO PUBLISH.  UNCONFUSED?
TELL A FRIEND.

.pa
============================================================================
 VI. Ada QUESTIONS and TOPICS

----------------------------------------------------------------------------
     A. Software Components with Ada by Grady Booch

     Grady's  latest  book,  Software Components with Ada,  is  out.   Another
announcement appeared in the last newsletter.

Date: 31 Mar 87 07:54:11 GMT
From: imagen!atari!portal!cup.portal.com![e-mail]
Organization: The Portal System (TM)
Subject: Software Reusability

Just released.  Grady Booch, Has just released his newest book entitled

        Software Components with ADA.

     This  is  Grady's  second book dealing with ADA, and it  deals  with  the
aspect  of software reusability.  In talking to Grady, the book will  soon  be
available in B. Dalton book stores throughout the country, but he did not know
when that exact date will be.

     If  you  can  not find it in you local bookstore, you may  get  the  book
through the following...

Benjamin/Cummings Publishing Company, Inc.
2727 Sand Hill Road
Menlo Park, Ca  94025

800-227-1936 (outside California)
800-982-6140 (inside California)

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

Date: 10 Apr 87 13:34:00 EST
From: "Barbara Pemberton" <pemberton@ntsc-74>
Subject: Grady's new book

Hello Ada and Grady Booch Fans!

     I  just received by copy of Grady's new book -- Software Components  with
Ada.  I haven't had time to evaluate.  The cost from the publisher 35.95  plus
shipping.  Publisher Benjamin/Cummings [phone].

Table of Contents
--------------------

Chapter 1  Reusable Software Components
Chapter 2  Ada and Object-Oriented Development
Chapter 3  Structures, Tools, and Subsystems
Chapter 4  Stacks
Chapter 5  Lists
Chapter 6  Strings
Chapter 7  Queues and Deques
Chapter 8  Rings
Chapter 9  Maps
Chapter 10 Sets and Bags
Chapter 11 Trees
Chapter 12 Graphs
Chapter 13 Utilities
Chapter 14 Filter and Pipes
Chapter 15 Sorting
Chapter 16 Searching and Pattern Matching
Chapter 17 The Architecture of Complex Systems
Chapter 18 Managerial, Legal, and Social Issues
Appendix A  Component Style Guide
Appendix B  Component Summary
Appendix C  Ada Overview
Notes
Glossary
Bibliography
Index

------------------------------------------------------------------------------
     B. Hard Knocks Handbook
Date: 17 Mar 1987 10:29-PST
Subject: Hard Knocks Handbook
Subject: real time programmers book of hard knocks
From: [e-mail]

     After  listening to Dr.  John Barnes at the  Washington  Ada
Symposium,  and attending numerous SIGAda and ADAJUG  conferences
about why Ada is failing (or not used well) in embedded  systems,
my  associates  and  I decided to perform  an  act  of  community
service.  We decided to take some of our experiences in  building
real  time  systems,  call for volunteers to  write  about  there
experiences and put together a "Hard Knocks Handbook" which  will
be a compendium of do's and don'ts geared for Ada programmers.

     To   make   it  fair,  we  decided  not  to   publish   this
commercially,  but  to  put the results on the  net  for  all  to
benifit.   That  way people who write their experiences  are  not
exploited.

     We will gather together what people write, edit spelling and
punctuation,  and  group similar topics.  We will not  change  in
anyway (other than above) what people are writing about.

     Soooo....

     If  you  have  implemented a real time  system,  or  written
embedded  code  (not necessary to write in Ada, but this  is  for
Ada)  here's your chance to become famous, but not rich,  and  to
share your pitfalls with the Ada world.

     You  may  write  as  long or as short  as  you  like.   Send
responses to me, at the address below.  If you would like to have
a  copy of what people have sent so that you may respond, I  will
keep  a  file  active  on my unix system so  to  send  you  these
reponses in a timely manner.

Eric Beser EBESER@ADA20 (ARPA) seismo!aplcen!cp1!sarin!eric
(usenet)
301-765-8008 (w) 301-356-4037 (h)

------------------------------------------------------------------------------
     C. Ada Sources
Subject: Re: ADA Sources Wanted
Date: Fri, 20 Mar 87 13:09:03 EST
From: Lt Col Francis L Falgiano III <[e-mail]>

Request for information:

     The description of records in Ada is pretty straight forward.  There is a
very  high correlation between the COBOL FD and associated 01  and  subsequent
lower   levels  of  detail,  ie  description  of  data  elements   and   their
characteristics.

     The methods in which records are organized should also be describable  in
Ada.   Has anyone done any work in standardizing the data  dictionary  entries
that  in fact lay out the structure and inter-relations.  Of  particular  note
would  be  those  that  are relational  structures,  indexed  sequential,  and
networked; ie existing older technology descriptions.

     New  structual  descriptions  would also be useful.   Comments  would  be
appreciated.

LtCol Frank Falgiano
Advanced Technology Division
WIS JPMO
AV 478-2930
[phone]
falgiano@mitre

------------------------------------------------------------------------------
     D. IEEE Ada as a Design Language
Date: 25 Mar 1987 17:41-PST
Subject: IEEE Recommended Practice on Ada PDL
From: [e-mail]

Colleagues -

     It  has  come  to  my attention  that  the  American  National  Standards
Instititute  (ANSI)  has made a call for comments on IEEE P  990  (Recommended
Practice for Ada as a Program Design Language), proposed as an ANSI  standard.
Comments must be received by April 14 and should be directed to:

Louise Germani
IEEE
345 East 47th Street
New York, New York  10017

re:  ANSI Standards Action Volme 18, No. 4, 1987-0273

     Given the somewhat controversial nature of the Recommended Practice  (and
Ada PDL in general), I am sure many of you will want to comment.  Please  feel
free to call me if you need additional inforwation.

     Please pich in!

Cammie Donaldson

------------------------------------------------------------------------------
     E. Attribute Grammar for Ada
Date:  Tue, 31 Mar 87 04:01 EST
From:  [e-mail]
Subject:  re: Attribute Grammer for Ada.

     An Attribute Grammer for the Semantic Analysis of Ada.

     It is Lecture Notes in Computer Science, Vol.  139.

     One of the co-authors, who has used an attribute grammer for implementing
an Ada compiler is

     Dr. G. Winterstein
     Am Rueppurrer Schloss 7
     D-7500 Karlsruhe 51
     West Germany

     Phone [phone]

     He also should know about grammers for Anna.

H.  Hummel, IABG Munich.

------------------------------------------------------------------------------
     F. IEEE Articles of Interest
Date: Wed 1 Apr 87 06:15:28-MST
From: Rick Conn <[e-mail]>
Subject: Ada article in IEEE Spectrum

    Article: "Ada: From Promise to Practice?"
    by John Voelcker, Associate Editor
    appearing in IEEE Spectrum magazine, April 1987, pp 44-49

     John  Voelcker has written what I feel is an excellent article about  the
Ada effort in the April 1987 issue of IEEE Spectrum.

     The  article  provides some details on the McDonnell Douglas  F-15  Eagle
fighter  plane, whose digital flight control system was coded in Ada, and  the
Air Force's Advanced Tactical Fighter project.  Topics include:

        Perceived shortcomings of Ada
        The ATF, a Flying Computer
        Efficiency for avionics
        Fixes for missing operations
        Hardware independence: plus or minus?
        Too few programmers
        The problem of validation
        The pro side of the coin
        Lack of development tools a problem
        The prospects
        To probe further

     Highlighted are inserts on:

        Selected Ada development tools for embedded systems
        Using Ada where eagles fly (F-15 Eagle details)
        From Jovial to Ada in the Fighting Falcon (ATF details)
        Evolution of the Ada standard

Date: Wed 1 Apr 87 06:16:54-MST
From: Rick Conn <[e-mail]>
Subject: Also from the IEEE ...

is  this  month's IEEE Proceedings, which provides much detail  on  the  Space
Shuttle  and  Space Station programs (note: Ada is to be used  for  the  Space
Station software).

------------------------------------------------------------------------------
     G. Ada Generic Overhead Inquiry
Subject: Re:  Ada Generic Overhead Inquiry
Date: Wed, 08 Apr 87 15:21:54 EST
From: CPT Jacques C. Choiniere <[e-mail]>

In reply to Joe Rubel, on run-time overhead associated with Ada Generics:

     Tim  Porter  of  SAIC  ((porter@nosc-tecr)) did some  work  for  us  that
explored  this  issue.  His team developed an automatic code  generator  that,
among  other  things,  uses  Ada generics.  This  work  was  done  for  WWMCCS
Information System, and is public domain software that will be sent to the Ada
Repository  on Simtel20 in the next several months.  A formal report  on  this
work  is  in  the  Proceedings  of the  Joint  Ada  Conference,  5th  National
Conference & Washington Ada Symposium pages 334 to 343.

     In  sum, he found that speed of the applications code was not  noticeably
different  from  "regular" code when running the compiled  code.   Compilation
speed was fairly slow with the large system his team worked with (see report).
The  PROBLEM  he  found was the size of the Ada code modules  created  by  the
automatic code generator and the generics it used.  The compiled code was big.
He told me that this was a function of current VAX Compiler technology and NOT
a  function of the Ada language.  The Compiler did not share any code at  all,
even  when the modules were identical.  THIS PROBLEM WAS SOLVED BY TIM.   With
careful  selections of implementation alternatives (see report or send  him  a
note)  he was able to shrink the generated code size and (I forgot to  mention
this  problem) handle the problem of in-line expansions of generics.   BY  ALL
MEANS READ THE REPORT OR TALK TO TIM TO GET THE DETAILS.

CPT CHOINIERE, USA
WIS JPMO/XPT
jcc@mitre

.pa
------------------------------------------------------------------------------
     H. Verdix Ada and Code Size
Date: 10 Apr 87 07:04:01 GMT
From: clyde!ima!mirror!xanth![e-mail]  (Kent Paul Dolan)
Subject: good news about code size under Verdix Ada

     Old Dominion has received its latest update of Verdix Ada, and the result
is  a  gold star for Verdix, and a general good news for  the  Ada  community,
about the progress of compiler technology.

     First, a couple of annoying bugs were fixed.  For a professor colleage of
mine,  an inability to freely mix tasks and generics in some  research  matrix
manipulation code was cleared up.  For me, some spurious dependency errors  in
linking compiled code, in my graph theory research support packages, that used
to  require lobotomizing the system's memory of previous compilations  of  the
code, to compile without errors, has gone away.

     Now  the big news.  My professor friend reports, that with no  change  in
source  code  or  execution results, the size of his  executable  code  module
decreased from 180K bytes to 80K bytes!  Progress indeed.

     The  moral,  if  there is one, is that, with  the  maturing  of  compiler
technology,  Ada seems to have a chance to compete in size and speed with  the
older languages.

.pa
=============================================================================
VIII. NEW and PLANNED SUBMISSIONS to the ASR

-----------------------------------------------------------------------------
     A. CSET Updated

     The  CHARACTER_SET component has been updated.  Thanks to Joe  Orost  for
his efforts.  Data:

     CHARACTER_SET  provides  a number of test routines which determine  if  a
given character falls into a particular class of characters.  See the  visible
section  for  details.   It also provides routines for  character  and  string
letter  case conversion (to lower case, to upper case) and for naming  control
characters.

Associated files:

   PD:<ADA.COMPONENTS>
          Bytes(SZ)

 CSET.PRO.3       3582(7)
   .SRC.3         16764(7)

 Total of 9 pages in 2 files

Notes from Compilation:
     I  compiled  the new CSET under DEC Ada, and  the  following  informative
diagnostics were generated:

$ ada character_set

   34      pragma BIT_PACK (BIT_ARRAY);  --Compiler dependent
..................1
(1) Replaced BIT_PACK with pragma PACK
...........2
(2) Pragma PACK is already given at line 33 for type BIT_ARRAY at line 32;
        pragma ignored
Ada compilation completed with 2 diagnostics

-----------------------------------------------------------------------------
     B. Comments on ALSP* (LISP Routines in Ada)
Date: Thu, 26 Mar 87 22:44:58 EST
From: [e-mail] (Mars J. Gralia)
Subject: Comment on pd:<ada.ai>alsp*

                              Comments On
                        C2 Support Modules (AI)
             by Software Architecture & Engineering, Inc.


by
Mars Gralia
The Johns Hopkins University
Applied Physics Laboratory
Laurel, Maryland
[phone]

March 26, 1987


SUMMARY
     We  have successfully compiled and executed the demonstration program  of
the  10  files  named PD:<ADA.AI>ALSP*.  We have thumbed  through  the  User's
Manual.   We  tried  several  of the examples; all  those  available  via  the
demonstration program worked.

     The  only problem encountered with this Ada/Lisp package is a minor  typo
in the Users Manual (file "alsp user.doc").


REVIEW SCOPE
     We  have  done  little more than mentioned above  in  the  summary.   Our
machine  is  a VAX-8650 Cluster, running Ada version 1.3-34, and  VMS  version
4.5.  We spent about a half hour examining the User's Manual (file name  "alsp
user.doc").  The "pager" file (name "alsp types.src") was readily fractionated
by  Pager,  and  compiled in the order specified  (in  file  "alsp  read.me").
Linking  was uneventful after we discovered its file name.  The  demonstration
program (file "ai types demo") behaved exactly as described.

     Even though the primary objective of this package is to provide Lisp-like
functions to a user's Ada program, we have not tried that.

     We  have  examined none of the source code.   The  demonstration  program
appears complete and robust; perhaps this is indication of high code quality?


BUG REPORT
     In   the  User's  Manual  (alsp  user.doc),  on  page  52,  it  gives   a
demonstration sequence as:
          -> assert1 ((loves ?x1, ?y1), (friends, ?x1, ?y1))
             (((loves ?x1, ?y1), (friends, ?x1, ?y1)))
          -> assert1 ((wife ?x2, ?y2), (loves, ?x2, ?y2))
             (((loves ?x1, ?y1), (friends, ?x1, ?y1))
              ((wife ?x2, ?y2), (loves, ?x2, ?y2)))
          -> assert1 ((), (wife, Mary, John))
             (((loves ?x1, ?y1), (friends, ?x1, ?y1))
              ((wife ?x2, ?y2), (loves, ?x2, ?y2))
              ((), (wife, Mary, John)))
and so on.

     The bug is a missing comma in the first two "assert1" lines.  They should
read:
          -> assert1 ((loves, ?x1, ?y1), (friends, ?x1, ?y1))
                ^
          -> assert1 ((wife, ?x2, ?y2), (loves, ?x2, ?y2))
               ^


AVAILABLE FILES and Reasonable Reading Order
     I found this to be the right order to read the files.  I have also  taken
the liberty to provide a tiny synopsis of each.

1.1  Alsp read . me
     A table of contents, with some annotation and the compilation order.   It
says there are generic packages and demonstration programs.

1.2  Alsp user . doc
     A  pretty  decent  manual  for the user.  It  explains  how  to  run  the
demonstration programs and the background.  Its formatted.  (The demo  program
info is given in section 7.1.  It also gives the compilation order.)

1.3  Alsp tech . doc
     The  "top  level  design  spec  and  final  report".   It  looks   pretty
reasonable.   It  explains  this was developed for Command  and  Control  (C2)
applications where LISP might be desired.

1.4  Alsp types . src
     The source code, in "Pager" archive format.

1.5  Alsp . abs
     This  is  the  full management information  ("abstract"):  developer  (in
full), scheduled completion of 30 Jun 85, and so on.

1.6  `Comment' Reports

1.6.1  Alsp . cmm
     A pro forma remark from the archivist: compilation not attempted.

1.6.2  Alsp . cm2
     Another  comment: "alsp design.doc.1 is a subset of alsp  tech.doc.1;  it
should be deleted."  They did not compile it either.

1.7  Garbage

1.7.1  Alsp ren . sub
     This  looks like a VMS command file the developers accidentally  sent  to
the archive.  Useless to me.

1.7.2  Alsp src . dis
     It  looks like a command file for collecting the pieces of  this  package
for submission; useless to me.


RECOMMENDED TESTS

     I  wish I had time to run additional tests.  (Instead, I'll assign it  to
my class!)

2.1  Memory Exhaustion
     A nasty characteristic of many Ada implementations is memory, obtained by
the  "new"  construct, is never reclaimed.  (And that's OK with  the  Language
Reference  Manual!)   This phenomenon has limited the  run-time  endurance  of
several of my programs.  Is it a limit here, too?

     A  test  program  might create and delete large  numbers  of  dynamic  s-
expressions,  probably  running  for several hours.  If  it  gets  a  "storage
exception", we know this package suffers the same limitation.   Unfortunately,
there is no way to know it does *not*, perhaps very slowly, erode memory until
there is nothing left.

2.2  Execution Speed
     It would be interesting to get a feel for the execution time of a program
which uses these packages.


OTHER COMMENTS

     It  would be much more convenient if the authors would also  provide  the
documentation  in "source" form.  That would allow me to re-format it  for  my
size pages; it would look like a real manual.  Furthermore, I don't care  what
the  formatting  language is; its fairly easy to convert from one  to  another
with  any  decent editor.  After all, I don't want a fancy  technical  report,
just one whose page boundaries match the paper.

     (I would provide the "source" of this file, but there is none.  Its  done
with a very primitive "what you see is what you get" formatter.  (Where's  old
runoff when you need it?))

-----------------------------------------------------------------------------
     C. LART (Load ARchive Tape on ROLM)
Date: Fri 27 Mar 87 05:49:47-MST
From: Rick Conn <RCONN@SIMTEL20>
Subject: New Submission: LART

     Thanks to A. F. Niessner of the Applied Research Lab at The  Pennsylvania
State  University  for  the  Load_AR_Tape submission.  I  have  placed  it  in
PD:<ADA.STARTER-KIT>.  Details follow:

Directory: PD:<ADA.STARTER-KIT>
  LART.DOC              10655
  LART.PRO               2517
  LART.SRC              31895
  ===============  ==========
    3 Files             45067

Machine/System Compiled/Run on : Data General MV10000,
                                 Rolm ADE

Keywords     : Ada Repository, ANSI Standard Tapes,
               Automated Loading
Abstract     : The program, Load_AR_Tape, and it's supporting
               packages, automate the process of loading the
               ANSI standard tape copies into a Data General
               MV10000.  The directory structure of the Ada
               repository is preserved.

Date: Wed, 22 Apr 87 10:04:20 MDT
From: Rick Conn <[e-mail]>
Subject: LART updated

    Data:

   PD:<ADA.STARTER-KIT>
          Bytes(SZ)

 LART.DOC.2       10936(7)
   .PRO.2         2694(7)
   .SRC.2         31860(7)

 Total of 20 pages in 3 files

-----------------------------------------------------------------------------
     D. PIWG Benchmark Suite
Date: Tue 31 Mar 87 03:42:44-MST
From: Rick Conn <[e-mail]>
Subject: PIWG Benchmark Suite Released

     The  Benchmark Suite of the ACM SIGAda Performance Issues  Working  Group
has been released to the Ada Software Repository.  Thanks to Jon Squire,  PIWG
Chairman, and the members of the PIWG for their efforts.  Data follows:

Unit name    : PIWG Benchmarks
Version      : TAPE_8_31_86
Author       : ACM SIGAda Performance Issues Working Group (PIWG)
Machine/System Compiled/Run on : Numerous

     PIWG  is a suite of tests/benchmarks prepared by the  Performance  Issues
Working Group of ACM SIGAda.  The purpose of PIWG is to develop the benchmarks
and  collect  and  disseminate  results.      The PIWG  tests  have  been  under
development for many years and have been run against many Ada compilers.   The
PIWG  test suite contains over 190 files which include Whetstone  (to  measure
processor  speed), Dhrystone (to measure statement execution per  unit  time),
and  other  benchmarks which test various attributes of the Ada  language  and
their  implementations  under  specific compilers.  The  PIWG  tests  must  be
customized  for  a particular compiler, and instructions are  included  to  do
this.
     Some of the items measured by PIWG include:
        * task creation-related timing
        * dynamic elaboration-related timing
        * exception-related timing
        * coding style-related timing
        * TEXT_IO-related timing
        * loop overhead-related timing
        * procedure call-related timing
        * task-related timing
        * compilation, link, and execution times

     NOTE:  the directory PD:<ADA.PIWG> contains each of the individual  files
of the PIWG Benchmark Suite, while the directory PD:<ADA.BENCHMARKS>  contains
the same files grouped as just a few large PAGER files.

    Files in PD:<ADA.BENCHMARKS> are:

Directory: PD:<ADA.BENCHMARKS>
  PIWG.DOC              14507
  PIWG.PRO               3350
  PIWG83186.CMM           424
  PIWGA831.INC            672
  PIWGA831.SRC         241273
  PIWGB831.INC            579
  PIWGB831.SRC         147989
  PIWGC831.INC            809
  PIWGC831.SRC         533807
  PIWGD831.INC            601
  PIWGD831.SRC         201739
  ===============  ==========
   11 Files           1145750

    Files in PD:<ADA.PIWG> are:
Directory: PD:<ADA.PIWG>
  A000001.ADA              84
  A000002.ADA               0
  A000011.ADA             375
  A000012.ADA             842
  A000013.ADA            2626
  A000014.ADA             725
  A000015.ADA             208
  A000016.ADA            2275
  A000021.ADA             869
  A000022.ADA             961
  A000031.ADA             981
  A000032.ADA            5719
  A000033.ADA            5271
  A000041.ADA            1414
  A000042.ADA            1379
  A000043.ADA            3011
  A000044.ADA             867
  A000049.ADA            5612
  A000051.ADA            1144
  A000052.ADA            1461
  A000053.ADA            1847
  A000054.ADA            1892
  A000055.ADA            4142
  A000091.ADA           14609
  A000092.ADA           13291
  A000093.ADA           19353
  A000094.ADA           28430
  A000098.ADA            2877
  A000099.ADA            2663
  A000100.ADA            1608
  A000101.ADA             766
  A000102.ADA             712
  A000103.ADA            1834
  A000104.ADA             289
  A000105.ADA             797
  A000106.ADA             323
  A000107.ADA             464
  ACOMPILE.CLI            993
  ACOMPILE.COM           1421
  ACOMPILE.LR1          47045
  C000001.ADA            2675
  C000002.ADA            2721
  C000003.ADA            2387
  COMPILE.CLI             815
  COMPILE.COM            1235
  COMPILE.L78           16102
  COMPILE.L86           23081
  COPY.COM               6450
  COPY.R10               2142
  D000001.ADA            2907
  D000002.ADA            2962
  D000003.ADA            3083
  D000004.ADA            3201
  E000001.ADA            2584
  E000002.ADA            3299
  E000004.ADA            3589
  F000001.ADA            2190
  F000002.ADA            2335
  G000001.ADA            2635
  G000002.ADA            2951
  G000003.ADA            2424
  G000004.ADA            2731
  G000005.ADA            2443
  G000006.ADA            2590
  G000007.ADA            2259
  GETPIWG.SUB            3714
  L000001.ADA            7801
  L000002.ADA            7858
  L000003.ADA            7893
  P000001.ADA            1916
  P000002.ADA            2267
  P000003.ADA            2408
  P000004.ADA            2505
  P000005.ADA            2446
  P000006.ADA            2482
  P000007.ADA            2478
  P000010.ADA            2919
  P000011.ADA            3585
  P000012.ADA            2952
  P000013.ADA            3278
  PIWG.DOC              14507
  PIWG.PRO               3350
  PIWG83186.CMM           424
  READ.ME                8987
  T000001.ADA            2322
  T000002.ADA            2425
  T000003.ADA            2993
  T000004.ADA            2864
  T000005.ADA            4661
  T000006.ADA            3866
  T000007.ADA            2507
  TAPE.LOG               6797
  TAPEDIST.LTR           5198
  WCOMPILE.COM           2535
  Z000001.ADA              74
  Z000002.ADA            3151
  Z000003.ADA            5288
  Z000004.ADA           12997
  Z000005.ADA           11752
  Z000006.ADA            6205
  Z000007.ADA            1523
  Z000008.ADA           13584
  Z000009.ADA           12980
  Z000010.ADA            6114
  Z000011.ADA           14769
  Z000012.ADA           21034
  Z000013.ADA            8106
  Z000014.ADA           11251
  Z000015.ADA            2349
  Z000016.ADA            7843
  Z000016A.ADA          13704
  Z000017.ADA            8012
  Z000017A.ADA          13305
  Z000018.ADA            2089
  Z000020.ADA            6307
  Z000021.ADA           12642
  Z000022.ADA            1603
  Z000023.ADA            2771
  Z000110.ADA             120
  Z000111.ADA            1312
  Z000111.COM            2536
  Z000111D.CLI           2170
  Z000111D.COM           4307
  Z000112.ADA            2652
  Z000113.ADA            6672
  Z000114.ADA           13373
  Z00011D.L86           10607
  Z000121.ADA            2943
  Z000122.ADA            6043
  Z000123.ADA           15343
  Z000124.ADA           30845
  Z000131.ADA            1137
  Z000132.ADA            2398
  Z000133.ADA            6178
  Z000134.ADA           12480
  Z000141.ADA            5032
  Z000142.ADA           10332
  Z000143.ADA           26232
  Z000151.ADA            6124
  Z000152.ADA           12524
  Z000153.ADA           31724
  Z000161.ADA            5839
  Z000162.ADA           11839
  Z000171.ADA            5083
  Z000172.ADA           10183
  Z000173.ADA           25483
  Z000181.ADA            1162
  Z000182.ADA            2322
  Z000183.ADA            5802
  Z000184.ADA           11606
  Z000191.ADA            4807
  Z000192.ADA            9707
  Z000193.ADA           24407
  Z000201.ADA            2151
  Z000202.ADA            4351
  Z000203.ADA           10951
  Z000211.ADA            3451
  Z000212.ADA            6951
  Z000213.ADA           17451
  Z000221.ADA             722
  Z000222.ADA            1742
  Z000223.ADA            3444
  Z000224.ADA            7044
  Z000231.ADA            1446
  Z000232.ADA            2886
  Z000233.ADA            7206
  Z000234.ADA           14412
  Z000241.ADA             740
  Z000242.ADA            1460
  Z000243.ADA            3620
  Z000244.ADA            7223
  Z000254.ADA            8666
  Z000264.ADA            6867
  Z000274.ADA           21964
  Z000281.ADA             241
  Z000282.ADA             491
  Z000283.ADA            1241
  Z000284.ADA            2492
  Z000291.ADA             542
  Z000292.ADA            1102
  Z000293.ADA            2782
  Z000294.ADA            5584
  Z000295.ADA           11384
  Z000301.ADA            1157
  Z000302.ADA            2367
  Z000303.ADA            5997
  Z000304.ADA           12050
  Z000311.ADA             321
  Z000312.ADA             651
  Z000313.ADA            1641
  Z000314.ADA            3292
  Z000315.ADA            6692
  ZCOMPILE.CLI            590
  ZCOMPILE.COM           1177
  ZCOMPILE.ICC            514
  ZCOMPILE.L86           2449
  ===============  ==========
  196 Files           1133191

-----------------------------------------------------------------------------
     E. ABSTRACT Problem
Date: 6 Apr 1987 2034-EST (Monday)
From: rutgers!petsd![e-mail] (Joe Orost)
Subject: Limitation/Bug in tools that Parse Ada code (like COMPORD)

I found/fixed a problem I had with COMPORD.  The problem is that a message:
        Compile_Order internal error
is  generated  when  I try to run compord on its  own  source  (including  the
abstractions).   The bug is with STATESTK.BDY, in procedure InitCopy there  is
no  check  for stack overflow, and if so, a CONSTRAINT_ERROR is  raised.   So,
insert the following code as the first lines of procedure InitCopy:

        if Index = StateParseStacksIndex'last then
           raise OverFlow;
        end if;

Now  for  the real bug.  The parse stack is too small!   In  file  PDECLS.SPC,
change:

        subtype StateParseStacksIndex is
            GC.ParserInteger range 0..200;

to
        subtype StateParseStacksIndex is
            GC.ParserInteger range 0..2_000;

With  this  fix,  COMPORD will now properly process  its  own  source!   (BTW,
PTBLS.BDY is the parser-killer.)

STATESTK.BDY and PDECLS.SPC can both be found in ABSTRACT.SRC.  Remember, this
bug  affects  all  repository  software  that  uses  the  parser  included  in
ABSTRACT.SRC.

--------------------------------------
Date: Thu, 23 Apr 87 05:49:07 MDT
From: Rick Conn <[e-mail]>
Subject: Problem with ABSTRACT noted

     Joe  Orost  has  noted  a problem  with  the  abstractions  component  in
PD:<ADA.COMPONENTS>ABSTRACT.SRC.    Joe's  comments  are  now  in   the   file
ABSTRACT.CMM under PD:<ADA.COMPONENTS>.  Thanks, Joe, for the inputs.

-----------------------------------------------------------------------------
     F.  PPLANNER Problem
Date: 17 Apr 1987 1254-EST (Friday)
From: vax135!petsd![e-mail] (Joe Orost)
Subject: PPLANNER tool doesn't compile

     Has  anybody fixed the Pplanner tool so that it compiles?   Currently  it
has errors because of assignment of objects of GRAPH_TYPE.  Is the correct fix
to  change GRAPHS.GRAPH_TYPE from "limited private" to "private"?  There  seem
to be other errors too, where private types are being looked into.

Date: Thu, 23 Apr 87 05:40:18 MDT
From: Rick Conn <[e-mail]>
Subject: PPLANNER.CMM file noted problem also

PPLANNER.CMM follows ...

                       Comments on Porting
                          Cost Estimators
                         by Ford Aerospace
                            to DEC Ada

                                                                Tool 17_2
                                                                January 3, 1986
COMPILATION
-----------
  A VMS command file was created from the ordered list of compilation
  units provided in the file PLANNERSR.DIS.  The files SIMUTIL.ADA,
  SCHEDULE.ADA, NEWFILE.ADA, and MODIFY.ADA were compiled with no
  errors.  Compiler errors in the file PERT.ADA occurred due to
  assignment on limited types.

EXECUTION
---------
  Execution of the Cost Estimators tool was not attempted.

---------------------------
Date: 23 Apr 1987 05:38-PDT
Subject: PPLANNER
From: [e-mail]

     I  am also trying to compile PLANNER on a VERDIX Ada compiler on  a  SUN.
Changing  LIMITED PRIVATE to PRIVATE is a start. There also seems to  be  some
strange problems with a call to pert_ops.create. I solved this by creating two
dummy  variables  of NODE_TYPE to use in the call. (This is  in  the  PERT.ADA
file)  I'm  still working on an "inappropriate prefix" problem.  If  you  need
more info, let me know.   Jim (JWOLFE@ADA20)


-----------------------------------------------------------------------------
     G. DoDD 3405.1 and 3405.2
Date: Mon, 20 Apr 87 05:23:48 MDT
From: Rick Conn <[e-mail]>
Subject: DoD Directive 3405.XX available

     These  files  contain messages on and the text of  DoD  Directive  3405.1
("Computer Programming Language Policy") and DoD Directive 3405.2 ("Use of Ada
in Weapon Systems").  DoDD 3405.1 supercedes DoDD 5000.31.

Directory: PD:<ADA.POINTERS>
  D34051.MSG             2660
  D34051.TXT            18550
  D34052.MSG             1149
  D34052.TXT             7494
  ===============  ==========
    4 Files             29853

-----------------------------------------------------------------------------
     H. Screen Generators in Ada
Subject: To answer Pat Emily's Request for Screen Generators in Ada
Date: Fri, 13 Mar 87 08:29:11 EST
From: CPT Jacques C. Choiniere <[e-mail]>

Pat and any other interested parties,
     The  WIS JPMO (a military organization) has placed two screen  generators
and  two  menu  managers into public domain at  Simtel20.   We  are  currently
preparing to send to Simtel20 a set of software that is an automatic Ada  Code
Generator  which  does what you want.  With the input of an  Ada  record  that
describes  the  form,  or  message, or table that you want  a  MMI  for;   the
generator  creates a full up formated editor of the type you asked for.   This
software was also used in a modified way to create an Ada/SQL interface for  a
relational  DBMS.  The software generated has been ported from VAX to IBM  PCs
which have the Alsys compiler.

                              **** WARNING ****

     This software is not well documented yet because it was developed on  the
fly  in support of another specific task.  I hope to have it documented  by  1
Oct.   YOU MUST KNOW Ada TO USE THIS TOOL!!!!!!!!!  The tool itself  has  been
developed  to  run  on the DEC VAX Ada compiler.  Rehost  should  not  be  too
difficult.

     The tool scans the Ada record to create the needed IO routines, etc.  And
then passes the routines and other information to a generic formated editor or
the "generic" Ada/SQL interface.

     If you have general questions please call [phone], or send a  note
on MILNET to [e-mail].





==============================================================================
Ada is a registered trademark, U.S. Government - Ada Joint Program Office. The
following are trademarks of Digital Equipment Corporation:  DEC, DECSYSTEM-20,
ULTRIX,  VAX,  VMS.   UNIX  is  a trademark of AT&T  Bell  Laboratories.   The
following are trademarks of Data General Corporation:  AOS, ROLM.  Verdix is a
trademark  of  Verdix Corporation.   TeleGen2 and TeleSoft are  trademarks  of
TeleSoft.

The Ada Software Repository Newsletter is Copyright 1986, 1987 Echelon, Inc.
All  Rights  Reserved.   Permission  to reprint,  wholly  or  partially,  is
automatically granted if source credit is given to Echelon.

                                                                 Echelon, Inc.
                                                       885 N. San Antonio Road
                                                       Los Altos, CA 94022 USA
                                                       Telephone: [phone]