From:	CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 28-NOV-1988 13:55
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: Splitting a big EXE into shareable images


Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Mon, 28 NOV 88 09:36:24 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Mon, 28 Nov 88 09:06:32 PST
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA10056; Mon, 28 Nov 88 08:38:13 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Nov 88 14:35:59 GMT
From: rti!sas!cole@mcnc.org  (Tom Cole)
Organization: SAS Institute Inc.,Cary NC,25712
Subject: Re: Splitting a big EXE into shareable images
Message-Id: <722@sas.UUCP>
References: <4093@enea.se>, <456@cullsj.UUCP>, <2589@rti.UUCP>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com


[Lots of discussion about the merits of breaking a large program into
 sharable images deleted]

We originally developed our product (SAS(r)) as a single large image,
almost 17,000 blocks large before going to sharable images.  Some 
things we learned:

o  Each sharable image uses up one open file (channel) and also has
   a control block in P1 space (controlled by the special SYSGEN
   parameter CTLPAGES in VMS 4.x, by two new parameters whose name
   I don't remember in VMS 5.x, but are CTL*).  This means that memory
   is consumed in sometimes unexpected ways if you make 150 sharable
   images.  Also, if you expect to have lots of open files (SAS is
   notorious for opening a zillion files) you have to trade off open
   files for images loaded.

o  If you use LIB$FIND_IMAGE_SYMBOL then you also consume memory for
   the image symbol table.  This is  mapped into memory just like the
   image sections.  It is stored in such a way that the LIB$FIND_IMAGE_SYMBOL
   library routine can use the LIB$ tree look-up routines to locate the
   symbols (more on this in the VMS 4.x fiche).  So if you pack a lot
   of entry points into a single image you eat space for the symbol
   table data.

o  If you get bold enough to try unloading the images you load (after
   use or whatever) you will find that LIB$FIND_IMAGE_SYMBOL will make
   your life much more difficult that you might wish - you have to locate
   and delete the memory for the symbol table as well as the image control
   block in P1 space - not much fun.

o  If you create your own entry point table that is exported by a single
   call to a single entry point in your sharable image, you can later
   easily free this table up again - memory management is therefore much
   easier.

o  You might consider looking at calling the image activator directory
   for your sharable image - use SYS$IMGACT and SYS$IMGFIX.  This causes
   a single image control block (ICB) to be allocated in P1 space, and
   an open chanel to be allocated.  The entry point to the sharable image
   is normally the first routine in the sharable image if you refrain from
   constructs like the C "main" routine.

o  If you load the sharable image yourself, you can free it up again later
   by deleting the virtual address space, closing the open chanel, and
   deallocating the ICB.  The deallocate o the ICB is the only part that
   requires privilege.  This lets you unload the code from memory fairly
   cleanly.


NOTE:  No warranty, expressed or implied, should be assumed for the above
       remarks.  These are just based on some research we did to solve
       similar problems.  In this research we determined that we should
       not use LIB$FIND_IMAGE_SYMBOL because it left too many footprints
       lying around.  We elected to call the VMS image activator ourselves
       so we could do better resource management and cleanup.  Your mileage
       may vary.



Tom Cole
SAS Institute Inc
{anywhere}mcnc|rti|sas|cole

Opinions?  No thanks, I gave at the office.

evs