Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!dvlmarv!zaphod!billj
From: billj@zaphod.UUCP
Newsgroups: comp.sys.apollo
Subject: Re: DSEE Benefits / Converting to DSEE (long)
Message-ID: <1745@zaphod.UUCP>
Date: Sat, 4-Jul-87 00:53:28 EDT
Article-I.D.: zaphod.1745
Posted: Sat Jul  4 00:53:28 1987
Date-Received: Sun, 5-Jul-87 01:07:43 EDT
References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp> <35b36fa0.c366@apollo.uucp>
Reply-To: billj@zaphod.UUCP (Bill Jones)
Organization: Develcon Electronics, Saskatoon SK Canada
Lines: 43

Although I've read the published papers on DSEE, and seen it demoed in
toy situations, I still have some uncertainty about the system's
capabilities.  Though the questions below deal with more demanding
situations, they are not intended as potshots, just requests for
information on DSEE's current practical limits.  All the situations
below, BTW, are everyday real-life concerns in our own environment.

- is there support for maintaining, as Bob Reed mentioned, parallel
  systems of derived objects, say one with debugging turned on and one
  not?  Or will most of the binaries have to be recreated on each build
  as the pool cache capacity is reached?

- in the above environment, what support is there for variant
  implementations of the same module?  Must the elements be named
  differently, and the system model preprocessed, to avoid conflict, or
  can they be distinguished automatically in the directory structure?

- can a bug-fix or feature branch to several elements be treated
  (e.g. named or merged) globally, or must the operations be repeated
  for each element affected?

- can a system be composed of subsystems each maintained in its own
  directory structure, or must there be a single system model (with
  absolute pathnames) for the whole?

The next few questions deal with evolutionary systems where not only
the module code, but the module structure itself may change over time.

- the extracts quoted from system models indicate that include
  dependencies must be specified manually.  I understand that there is
  a make_model program to determine these automatically when the model
  is first written, but has there been any support added to generate
  them dynamically at build time?

- if the structure of the system is changed at some point in a way
  which significantly affects the system model, will subsequent
  modifications to earlier configurations see the new or old model?

My thanks to the long-suffering correspondents at Apollo for any
answers they can provide.
-- 
Bill Jones, Develcon Electronics, 856 51 St E, Saskatoon S7K 5C7 Canada
uucp:  ...ihnp4!sask!zaphod!billj               phone:  +1 306 931 1504