Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!batcomputer!tedcrane
From: tedcrane@batcomputer.tn.cornell.edu (Ted Crane)
Newsgroups: comp.os.vms
Subject: Re: faster VMS spawn
Message-ID: <780@batcomputer.tn.cornell.edu>
Date: Wed, 22-Apr-87 10:31:23 EST
Article-I.D.: batcompu.780
Posted: Wed Apr 22 10:31:23 1987
Date-Received: Fri, 24-Apr-87 23:43:57 EST
References: <8704220233.AA01827@ucbvax.Berkeley.EDU>
Reply-To: tedcrane@tcgould.tn.cornell.edu.UUCP (Ted Crane)
Distribution: world
Organization: Program of Computer Graphics, Cornell University
Lines: 47

In article <8704220233.AA01827@ucbvax.Berkeley.EDU> KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso) writes:
>>                                  If we can't find any better way we are
>> going to be forced to link all of our object code (currently about 13
>> Megabytes of object code constituting 66 separate executables) into one
>> gigantic executable (gag!).
>
>Using VMS facilities (e.g. sharable images) and reasonable development tools,
>the MATHLIB project I'm associated with has never had a problem maintaining a
>large software system with several large executables.

I'd recommend going the multiple sharable image route (or the load-the-image-
at-runtime route) also.

If you can isolate chunks of your program (for example, a set of matrix
manipulation utilities which might reference each other, but do not generally
call back to the main program), then by all means, build them into a sharable
image.  The main program can link with this image.  Positive results:
	Relinks are quicker.  You're either linking the (smaller)
	sharable image or the main image which is now referencing
	the resolved symbols in the sharable images.

	You save physical memory and disk space.  If more than one
	program uses the sharable images, only one copy if the sharable
	part is kept on disk (unless you choose otherwise).  If, by
	some lucky chance, you run more than one copy of (or two separate
	programs) a program that references the sharable image at the same
	time, then physical memory can be shared between the two processes.

	Increased modularity.  Divide the work and conquer.  Developers
	are responsible for a smaller, more manageable piece of code.
	Fewer "global" variables, etc.
Problems:
	Someone has to learn how to create sharable image.  Easy enough,
	look in the linker manual.

Another alternative is to make use ofthe LIB$FIND_IMAGE_SYMBOL routine.
This way, you don't even have to link the utility programs into the main
image.  You call that routine and VMS maps the requested image into
your process' address space AT RUNTIME!  You also get the address of
a routine which you can call to take advantage of the utility's functionality.

Anyway, I agree with Kevin that 66 separate programs is not a fun way to
go.  Probably bad for system response, too.
-- 
- ted crane, alias (tc)
tedcrane@tcgould.tn.cornell.edu          BITNET: tedcrane@CRNLTHRY
tedcrane@squid.tn.cornell.edu            DECnet: GOPHER::THC