HP3000-L Archives

March 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Scott Herman <[log in to unmask]>
Reply To:
Scott Herman <[log in to unmask]>
Date:
Fri, 24 Mar 1995 10:11:52 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
At 11:37 PM 3/23/95 GMT, Mike Paivinen wrote:
>
>During the "shared globals" project, we discussed whether to restructure
>the POSIX libraries and create a /lib/libc.sl.  At this time, we have
>no plans to create a /lib/libc.sl.
 
 
That's too bad. What you have, in effect done, is to limit C/POSIX
development efforts to non-XL able code. Although consistent with the old
Unix/POSIX approach, this cuts developers off from one of the biggest
advantages of MPE from a both the performance and development/maintenance
perspectives, shareable run time bound code, known in MPE/iX as the XL.
 
I have developed code using both methods, relocatable libraries bound at
link time, and shared libraries bound at run time. I use somewhat of a mix
of both, however, reusable code usually ends up in the XL. Here's a list of
drawbacks to the relocatable method, which are big advantages for the XL method.
 
o   OS version/patch dependency. Every time you upgrade your OS, or install
an     OS patch, you run the risk of incompatability. For a Zero Fault
Tolerant       environment, such as ours, every little patch requires
extensive testing of     every executable. Verry expensive and unpleasant.
 
o   Performance. Bigger executables require more memory, load slower and run
slower.
 
o   Maintenance. It's almost impossible to know which executables are
dependent     on which relocatable binaries. This means that if a bug gets
fixed in a        library,  EVERY SINGLE PROGRAM  that might use aprocedure
that migh call       a procedure that might call the repaired module, has to
be recompiled and      relinked. Again, verry expensive and unpleasant.
 
o   Inconsistency/non-concurrence. Unless EVERY SINGLE PROGRAM is recompiled
and relinked, at every OS upgrade or patch, you run the risk of different
programs doing things differently.
 
 
In our environment we simply cannot afford to use the relocatable binaries
approach. shareable run time bound code saves us a lot of aggravation, time,
and money. Consider the amount of aggravation, time, and money the
relocatable binaries approach casts HP, as the developers and maintainers of
a LARGE software facility, the MPE/iX OS.
 
I strongly urge you to reconsider your decision.
 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:                                                                           :
: Scott Herman          [log in to unmask]   Yale-New Haven Hospital
:
: Dept of Lab Medicine                                       20 York Street :
: (203) 785-2449                                       New Haven, Ct. 06504 :
:                                                                           :
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

ATOM RSS1 RSS2