zavgren@hpsrad.enet.dec.com (John Zavgren) (08/21/90)
I am about to write a discrete-event simulation of a communications network. The object-oriented paradigm looks like it should save a lot of programming time, but I have never programmed in an object-oriented language, let alone C++. Can anyone furnish me with a few well-written well-commented C++ programs that I can use to get started with this project? I am especially interested in queueing network simulations. RSVP John Zavgren
ecsv38@castle.ed.ac.uk (S Manoharan) (08/21/90)
In article <2533@ryn.esg.dec.com> zavgren@hpsrad.enet.dec.com (John Zavgren) writes: >I am about to write a discrete-event simulation of a communications >network. The object-oriented paradigm looks like it should save a lot >of programming time, but I have never programmed in an object-oriented >language, let alone C++. Can anyone furnish me with a few well-written >well-commented C++ programs that I can use to get started with this project? I have this library of C++ classes for constructing event-based (event-driven) simulations. If you need it, give me a loud shout. But, could someone tell me how event-based simulations compare with process-based simulations with respect to: 1. Ease of development 2. Code updatability and maintainability 3. Code size 4. ..... Are event-based simulations stuffs of stone-age? Manoharan.
korsberg@abaa.uucp (Ed Korsberg) (08/22/90)
In article <5845@castle.ed.ac.uk> ecsv38@castle.ed.ac.uk (S Manoharan) writes: >But, could someone tell me how event-based simulations compare >with process-based simulations with respect to: > 1. Ease of development > 2. Code updatability and maintainability > 3. Code size > 4. ..... > >Are event-based simulations stuffs of stone-age? > I think process based simulations are more appropriate for modeling multi-tasking computer systems. It would also seem to be more "object oriented" than event based simulations in that an object can be modeled independently of another object. Event based simulations still have their place but I believe that process based simulations have replaced it for most models. -------------------------------------------------------------------------------- -- Ed Korsberg E-mail: korsberg@aa.ab.com Allen Bradley phone: 313-998-2470 555 Briarwood Circle Ann Arbor, Mich 48104
korsberg@abaa.uucp (Ed Korsberg) (08/22/90)
In article <2533@ryn.esg.dec.com> zavgren@hpsrad.enet.dec.com (John Zavgren) writes: >I am about to write a discrete-event simulation of a communications >network. The object-oriented paradigm looks like it should save a lot >of programming time, but I have never programmed in an object-oriented >language, let alone C++. Can anyone furnish me with a few well-written >well-commented C++ programs that I can use to get started with this project? >I am especially interested in queueing network simulations. > I am interested in this too! Have you taken a look at the CSIM program available through MCC? It's only $150 and runs on a variety of machines. Also have you though about using Smalltalk for you simulation? I think that C++ is an attempt to mimic some of the concepts promoted in Smalltalk. Smalltalk already has simulation classes for doing discrete event simulation, although I do not know if it can do higher level process simulation. Please let me know which route you take for your project, I need to do something similar soon. ------------------------------------------------------------------------------ -- Ed Korsberg E-mail: korsberg@aa.ab.com Allen Bradley Inc. phone: 313-998-2470 555 Briarwood Circle Ann Arbor, Mich 48104
mip@IDA.LiU.SE (Mikael Patel) (08/23/90)
Discrete event simulation should be done in SIMULA, the grandfather of
object-oriented programming languages. What you need is classes and
COROUTINES to make life easy for you! C++ has only classes. Try looking
at DEMOS. Its a nice simulation package written in Simula-67 that is very
easy to use and generates all the statistics you need without you
having to implement random functions, histograms, etc. There is a text
book; G.M. Birtwistle, Discrete Event Modelling on Simula, Macmillan,
1979, ISBN 0-333-23881-8. Simula compilers for most modern machines
(workstations, pc, macintosh, etc) are available.
Mikael R.K. Patel
Researcher and Lecturer
Computer Aided Design Laboratory (CADLAB)
Department of Computer and Information Science
Linkoping University, S-581 83 LINKOPING, SWEDEN
Phone: +46 13281821
Telex: 8155076 LIUIDA S Telefax: +46 13142231
Internet: mip@ida.liu.se UUCP: {uunet,mcsun,...}!liuida!mip
Bitnet: MIP@SELIUIDA SUNET: LIUIDA::MIPpawel@cs.UAlberta.CA (Pawel Gburzynski) (08/23/90)
From article <2533@ryn.esg.dec.com>, by zavgren@hpsrad.enet.dec.com (John Zavgren): > I am about to write a discrete-event simulation of a communications > network. The object-oriented paradigm looks like it should save a lot > of programming time, but I have never programmed in an object-oriented > language, let alone C++. Can anyone furnish me with a few well-written > well-commented C++ programs that I can use to get started with this project? > I am especially interested in queueing network simulations. > > RSVP > John Zavgren I am currently developing a package for modelling communication networks in g++. The package is called SMURPH and descends from LANSF -- an earlier version of the package written in plain C. For all practical purposes SMURPH is ready, but still undocumented. I anticipate to have a distributable version by the end of September. It is my intention to distribute SMURPH for FREE. There may be some subtle problems, though, as SMURPH will be used in my book on protocol design and Prentice Hall may have some objections. Anyway, I believe that individual cases can be handled without problems. In some sense SMURPH is both event-driven and process-driven. The user sees only the process driven part. If anybody is interested, I can provide some related papers (including examples of networks and protocols programmed in SMURPH). Moreover, LANSF (the SMURPH's predecessor) is available without restrictions and, of course, it is absolutely free. You can copy it using anonymous ftp from menaik.cs.ualberta.ca (pub/lansf.2.11.tar.Z). It comes with a (somewhat lengthy) manual that must be processed by LaTeX. Pawel Gburzynski Department of Computing Science University of Alberta 615 GSB Edmonton, Alberta, Canada T6G 2H1
jwa@lanl.gov (Wayne Anderson) (08/23/90)
Process oriented simulation seems to me to provide a somewhat more natural way of writing simulations. However, there also seems to be an efficiency trade off (as compared to discrete-event simulation). Herb Schwetman, the author of CSIM, also has a "C++" version but I'm not sure if he is distributing it as yet. Another simulator coming down the pike is XSIM being developed by Bob Jump at Rice. XSIM is based on, and written in, C++. It actually is a family of simulators: ESIM, a discrete-event simulator; PSIM, a process oriented simulator; and ASIM a parallel computer simulator. Bob gave me a rough draft of his user manual and I've been quite impressed. It looks to me like they've done a very thorough job. Wayne
bs@alice.UUCP (Bjarne Stroustrup) (08/23/90)
> From: korsberg@abaa.uucp (Ed Korsberg @ Allen Bradley) > In article <2533@ryn.esg.dec.com> zavgren@hpsrad.enet.dec.com (John Zavgren) writes: > >I am about to write a discrete-event simulation of a communications > >network. The object-oriented paradigm looks like it should save a lot > >of programming time, but I have never programmed in an object-oriented > >language, let alone C++. Can anyone furnish me with a few well-written > >well-commented C++ programs that I can use to get started with this project? > >I am especially interested in queueing network simulations. > > I am interested in this too! Have you taken a look at the CSIM program > available through MCC? It's only $150 and runs on a variety of machines. > Also have you though about using Smalltalk for you simulation? > I think that C++ is an attempt to mimic some of the concepts promoted in Smalltalk. C++ wasn't `an attempt to mimic some of the concepts promoted in Smalltalk.' It is the result of blending the Simula class concept into C in such a way that C's low-level efficiency and general abilities and a system's programming language wasn't impared. The first use of C++ was for Simula-like simulations (what is called process level simulation) with thousands of processes. The task library that comes with the AT&T distribution supports such work in a way rather similar to what is provided in Simula.
kjetil@ifi.uio.no (Holm-Kjetil Holmsen) (08/23/90)
In article <5606@abaa.UUCP>, korsberg@abaa.uucp (Ed Korsberg) writes: > > Also have you though about using Smalltalk for you simulation? > I think that C++ is an attempt to mimic some of the concepts promoted in > Smalltalk. > Not quite right! C++ _originally_ was an attempt to mimic the _simulation_ part of SIMULA-67. > Smalltalk already has simulation classes for doing discrete event > simulation, although I do not know if it can do higher level process > simulation. > The funny part of this is that the Smalltalk simulation classes are (at least was) based on the SIMULA-67 simulation concept. Actually, the idea of Smalltalk was born when Allan Key learned about SIMULA doing his Ph.D. thesis. The chapter on simulation in the "Smalltalk books" is more or less a copy of the chapter on "class simulation" in the book "SIMULA BEGIN" by O-J Dahl et. al. The "carwash" example is a _direct_ copy. Simula originated in the beginning of the '60s, as an Algol based language for descrete event simulation. This language was refined, and emerged as a superset of Algol-60 in 1967: a block-structured laguage with the class concept (with inheritance and virtuals) Holm-Kjetil Holmsen, C.Sc student email: kjetil@ifi.uio.no Dept. of Informatics University of Oslo NORWAY
korsberg@abaa.uucp (Ed Korsberg) (08/23/90)
In article <60862@lanl.gov> jwa@lanl.gov (Wayne Anderson) writes: >Another simulator coming down the pike is XSIM being developed by Bob Jump >at Rice. XSIM is based on, and written in, C++. It actually is a family >of simulators: ESIM, a discrete-event simulator; PSIM, a process oriented >simulator; and ASIM a parallel computer simulator. Bob gave me a rough >draft of his user manual and I've been quite impressed. It looks to me like >they've done a very thorough job. I think this news group and/or the comp.simulation group would be very interested in this new package. Would Bob Jump be willing to post it to the net or e-mail it to interested parties (like myself)? -- Ed Korsberg E-mail: korsberg@aa.ab.com Allen Bradley Inc. phone: 313-998-2470 555 Briarwood Circle Ann Arbor, Mich 48104
gordon@mead.UUCP (Gordon Edwards) (08/23/90)
To the person who originally started this thread. In article <1990Aug22.171319.12499@ida.liu.se>, mip@IDA.LiU.SE (Mikael Patel) writes: |> |> Discrete event simulation should be done in SIMULA, the grandfather of |> object-oriented programming languages. What you need is classes and |> COROUTINES to make life easy for you! C++ has only classes. Try looking |> at DEMOS. Its a nice simulation package written in Simula-67 that is very |> easy to use and generates all the statistics you need without you |> having to implement random functions, histograms, etc. There is a text |> book; G.M. Birtwistle, Discrete Event Modelling on Simula, Macmillan, |> 1979, ISBN 0-333-23881-8. Simula compilers for most modern machines |> (workstations, pc, macintosh, etc) are available. |> First, remember that there is three (at least) different flavors of the discrete-event simulation. You do not need coroutines if you are using the event-scheduling or activity-scanning paradigms. AT&T provides a task library that will allow you to perform the necessary tasking operations for the process-interaction paradigm. I have used C++ for event-scheduling simulations, and have found it to be quite flexible. Process-interaction simulations are currently very popular, however, they allow the introduction of artifactual deadlock. Depending on your level of experience with discrete-event simulations, you might want to stick to the event-scheduling paradigm (concentrates on the events). -- Gordon Edwards Mead Data Central, Dayton OH
vaughan@mcc.com (Paul Vaughan) (08/23/90)
Discrete event simulation should be done in SIMULA, the grandfather of object-oriented programming languages. What you need is classes and COROUTINES to make life easy for you! C++ has only classes. Try looking at DEMOS. Its a nice simulation package written in Simula-67 that is very easy to use and generates all the statistics you need without you having to implement random functions, histograms, etc. There is a text book; G.M. Birtwistle, Discrete Event Modelling on Simula, Macmillan, 1979, ISBN 0-333-23881-8. Simula compilers for most modern machines (workstations, pc, macintosh, etc) are available. Not to knock SIMULA, but you can get all these things and more in C++. For instance, ATT distributes its tasking library (coroutines) and there should be a tasking package in libg++ soon. Libg++ has a choice of random stream generators and about every distribution you could need. It also has classes for recording statistics, histograms, etc. You can get plotters (notably Dag Bruck's plotter in the InterViews contrib library) and all sorts of useful classes in the public domain or in libraries. I'm not sure what SIMULA does in the way of dynamic type checking, but you can use the NIHL stuff to accomplish that in C++. So, there certainly is a choice these days. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
rjfrey@kepler.com (Robert J Frey) (08/23/90)
In article <60862@lanl.gov> jwa@lanl.gov (Wayne Anderson) writes: >Process oriented simulation seems to me to provide a somewhat more natural >way of writing simulations. However, there also seems to be an efficiency >trade off (as compared to discrete-event simulation). > I'm aware that many people feel that way, of course, but for me whether I use a discrete-event or process-oriented approach depends very much on the problem at hand. For simulations of any size or complexity I find it most convenient to move back and forth between representations, which is why I prefer languages such as SIMSCRIPT or SLAM. I also believe very strongly that any serious simulation facility has to pro- vide for both approaches. A big problem with process-oriented approaches is extensibility; often I am forced into an event-oriented representation because the process-oriented one can't quite handle what I want. Because I often choose an event-oriented representation, I want it available, but I want it to be my choice. This is something OO techniques can go a long way towards solving. -- Dr. Robert J Frey, Kepler Financial Management, Ltd. rjfrey@kepler.com *or* frey@chaos.sunysb.edu voice: (516) 689-6300 * fax: (516) 751-8678
davidm@uunet.UU.NET (David S. Masterson) (08/24/90)
In article <60862@lanl.gov> jwa@lanl.gov (Wayne Anderson) writes:
Process oriented simulation seems to me to provide a somewhat more natural
way of writing simulations. However, there also seems to be an efficiency
trade off (as compared to discrete-event simulation).
Could someone please explain (briefly) what process oriented simulation is and
contrast it to event oriented simulation? Something tells me I'll probably
get it as soon as someone starts explaining it, but, right now, its meaning
escapes me.
Thanks
--
====================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"grunwald@foobar.colorado.edu (Dirk Grunwald) (08/24/90)
The ``awesime-2.0'' library implements threads and a one subclass implements a SimulationMultiplexor for threads that provides a typical process-oriented simulation environment. The awesime threads will eventually be integrated into libg++ (doub, stop me if I lie). It current works on i386, m68k, ns32k, MIPS, SPARC and m88k. True parallelism is only current available on the Encore Multimax; it should be simple to hack for the solbourne (sparc) or sequenet (i386), but i haven't done it yet. I'm planning on finding a student to hack a discrete event simulation environment using this threads package, allowing people to implement distributed simulation environments as well as simpler global time systems. IMHO, DES packages are more efficient than process oriented systems (POS), but can be more of a pain to set up if they don't match your model very well. They're more eff. because you don't need to switch thread context all the time. You can implement it to maintain context using e..g, one or two words in an object. Thus, you could get decent performance out of e.g., a SPARC, which is very hard for POS because of all the register window overhead. For a ``proper'' DES, you'd only have one thread per physical CPU, and use those to execute the DES objects. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) (grunwald@boulder.colorado.edu)
gordon@mead.UUCP (Gordon Edwards) (08/24/90)
In article <CIMSHOP!DAVIDM.90Aug23104145@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: |> In article <60862@lanl.gov> jwa@lanl.gov (Wayne Anderson) writes: |> |> Process oriented simulation seems to me to provide a somewhat more natural |> way of writing simulations. However, there also seems to be an efficiency |> trade off (as compared to discrete-event simulation). |> |> Could someone please explain (briefly) what process oriented simulation is and |> contrast it to event oriented simulation? Something tells me I'll probably |> get it as soon as someone starts explaining it, but, right now, its meaning |> escapes me. |> The process oriented, or process-interaction, simulation is a discrete-event simulation. There are four gross categories of simulations: Continuous-Event/Continuous-Time Continuous-Event/Discrete-Time Discrete-Event/Continous-Time Discrete-Event/Discrete-Time The term discrete-event simulations normaly refers to the discrete-event/ continuous-time category. This category can be further calssified into: Event-Scheduling Simulations Activity-Scanning Simulations Process-Interaction Simulations The event-scheduling simulations concentrate on the events that occur, activity- scanning simulations concentrate on the set of states required for an event to occur (often implemented using a big state table), and process-interaction simulations concentrate on the entities/objects as they are acted upon by events. Each type has its advantages and disadvantages. Process-interaction simulations have a great deal of popularity (I tend to agree with Wayne on their virtues), however, if you are not experienced developing simulations or you don't have a good understanding of concurrent processing they can be dangerous. Process-interaction simulations can introduce "artifactual deadlock". This is a type of deadlock that occurs due to the implementation of the simulation. For example, in a harbor simulation tankers wait outside the harbor for a tug to take them to the (1) berth, they then unload and wait for the tug to take them back to sea. Now from a process viewpoint (highly simplified): [1] Tanker_1 comes into port. [2] Tanker_1 acquires tug. [3] Tanker_1 acquires berth. [4] Tanker_1 releases tug and begins to unload. [5] Tanker_2 arrives and acquires the tug. [6] Tanker_2 tries to acquire the berth and is locked. [7] Tanker_1 finishes unloading and tries to acquire the tug (to free the berth) and is locked. Now there are a number of things you can do to solve this problem (use a petri net for ideas) but the point is that this is not a real-life problem but a problem imposed by the model. Since process-interaction simulations are literaly multi-tasking, the deadlock is very real. -- Gordon Edwards Mead Data Central, Dayton OH
sam@cs.ed.ac.uk (S. Manoharan) (08/24/90)
In article <5845@castle.ed.ac.uk> ecsv38@castle.ed.ac.uk (S Manoharan) I wrote: > >But, could someone tell me how event-based simulations compare >with process-based simulations with respect to: > 1. Ease of development > 2. Code updatability and maintainability > 3. Code size > 4. ..... > I just found a reference which suggests the better-ness of process-based simulations over others: @article{Birt85, author = "Graham Birtwistle and Greg Lomow and Brian Unger and Paul Lucker", year = "May 1985", journal = "Trans. of the society for computer simulation", number = "1", pages = "27-56", title = "Process Style Packages for Discrete Event Modelling: Experience from the transaction, activity and event approaches", volume = "2" } In case someone's interested. Manoharan. Ps - Those who wanted the class library, please hold on for a few days. I will mail it soon. -- S. Manoharan Janet: sam@uk.ac.ed.lfcs Dept of Computer Science Uucp : ..!mcsun!ukc!edcastle!lfcs!sam University of Edinburgh Arpa : sam%lfcs.ed.ac.uk@nsfnet-relay.ac.uk Edinburgh EH9 3JZ UK. Voice: 667 8323(home) 667 1081x2708(office)
vaughan@mcc.com (Paul Vaughan) (08/25/90)
Could someone please explain (briefly) what process oriented simulation is and contrast it to event oriented simulation? Something tells me I'll probably get it as soon as someone starts explaining it, but, right now, its meaning escapes me. Briefly, process base simulation allows simulation time to pass during the execution of a user-written function expressing simulation behavior. Functions such as wait(time), waitforevent(Event), etc., are provided in a library. That's why you need process switching capability to keep the context of several execution environments that are all at least conceptually concurrently executing. In a purely event based system all behavior functions are executed in zero simulation time. Events may be posted to cause things to happen at future times. All process based systems are essentially constructed out of event scheduling systems (it's all discrete event simulation, after all). Most process based libraries support the use of explicit events in addition to wait constructs. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
hansen@pegasus.ATT.COM (Tony L. Hansen) (08/26/90)
< From: bs@alice.UUCP (Bjarne Stroustrup) < The first use of C++ was for Simula-like simulations (what is called < process level simulation) with thousands of processes. The task library < that comes with the AT&T distribution supports such work in a way rather < similar to what is provided in Simula. Another implementation of a task library, called class process, is available as a part of The C++ Answer Book. The code is written completely in C++ and is portable to most machines. (Some restrictions do apply.) The code itself is available from netlib@research.att.com. (Send a message with the contents "send index from c++/answerbook" to that address for further information.) Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
feustel@well.sf.ca.us (David Alan Feustel) (08/27/90)
What is the relationship between C++ and Concurrent C? If Concurrent C
is a superset of C++ is there any company making the product available
for pcs?
--
Phone: (work) 219-482-9631; MCI mail: DFEUSTEL
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805-2710rjfrey@kepler.com (Robert J Frey) (08/27/90)
In article <CIMSHOP!DAVIDM.90Aug23104145@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >Could someone please explain (briefly) what process oriented simulation is and >contrast it to event oriented simulation? > In discrete event simulation the the system is represented by a collection of states and a set of events which describe state changes. In process oriented simulations the simulation is defined by a collection of processes: that is the sequence of events that an entity experiences as it goes through the sys- tem. In languages which support both paradigms the process-oriented part of the model is "interpeted" or "compiled" internally as event-oriented. Rather than go into more detail here, I recommend you check an introductory text on simulation. E.g., Averill Law has a pretty good text available. Sorry, I don't have the title with me. George Fishman's Principles of Discrete Event Simulation is also good. -- Dr. Robert J Frey, Kepler Financial Management, Ltd. rjfrey@kepler.com *or* frey@chaos.sunysb.edu voice: (516) 689-6300 * fax: (516) 751-8678
jxf@procyon.cis.ksu.edu (Jerry Frain) (08/28/90)
In article <20036@well.sf.ca.us> feustel@well.sf.ca.us (David Alan Feustel) writes: >What is the relationship between C++ and Concurrent C? If Concurrent C >is a superset of C++ is there any company making the product available >for pcs? Wow, ever since this thread started up, I've been wondering if anyone was ever going to mention Concurrent C. The answer to your question is "no," Concurrent C is not a superset of C++. However, it bears a striking resemblence to C++ in that the process delcaration, creation, and invocations of transactions are similiar to methods and data of classes. However, there is a Concurrent C++ under development at Bell Labs (see the paper "Concurrent C++: Concurrent Programming With Class(es)" written by N.H. Gehani and W.D. Roome for more info). I am very excited at the prospects of the merging of these two languages, which have much in common, and yet much to share with each other. As far as discrete event simulation goes, it is my personal opinion (after using both C++ and Concurrent C) that Concurrent C is better suited for the job. -- Jerry Frain -- Perpetual Student Kansas State University Department of Computing & Info Sciences Internet : jxf@ksuvax1.cis.ksu.edu Manhattan, Kansas UUCP : ...!{rutgers,textbell}!ksuvax1!jxf
muyanja@hpdmd48.boi.hp.com (bill muyanja) (09/09/90)
[Dr. Robert Frey writes] |Rather than go into more detail here, I recommend you check an introductory |text on simulation. E.g., Averill Law has a pretty good text available. Sorry, I don't have the title with me. George Fishman's Principles of Discrete Event |Simulation is also good. The book is: Law, Averill M. and Kelton, W. David: _Simulation Modeling and Analysis_ McGraw-Hill, 1982. The second edition may be out by now - I had the misfortune of being one of the poor graduate students who beta-tested it in 1987! Professor Law's book is an excellent treatment of discrete-event simulation, especially the stastistical aspects and output analysis. S. Manoharan has posted a discrete-event simulation platform, SILO, in comp.sources.unix. It is written in C++, and it is based on the concepts in M.H. MacDougall's "Simulating Computer Systems" (MIT Press, 1987). MacDougall's book itself is based on a lot of the concepts in Law and Kelton and includes a simulation system, "smpl", written in C, source code and all. It also contain fairly sophisticated examples of a multiprocessing computer simulation and an Ethernet LAN simulation, which is what the original poster may have been looking for. Greetings, Bill -----
muyanja@hpdmd48.boi.hp.com (bill muyanja) (09/09/90)
[Bill Muyanja writes] |S. Manoharan has posted a discrete-event simulation platform, SILO, in |comp.sources.unix. It is written in C++, and it is based on the concepts |in M.H. MacDougall's "Simulating Computer Systems" (MIT Press, 1987). SILO is actually in archive.comp.sources.misc. Greetings, Bill -----