HP3000-L Archives

October 1998, Week 3

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:
Lee Gunter <[log in to unmask]>
Reply To:
Lee Gunter <[log in to unmask]>
Date:
Mon, 19 Oct 1998 15:32:53 -0700
Content-Type:
multipart/mixed
Parts/Attachments:
text/plain (1295 bytes) , text/plain (169 bytes)
Listers,

One of our interactive user applications now consists of 30+ linked modules
in one NM program file plus a few external routines in three local XL's.
Because a fair number of batch processes must also now use some of these
modules, we're considering the pros and cons of either combining all the
modules into one XL, driven by a simple outer block program for the online
application, or combining only the shared modules into an XL.  Questions
were forwarded to me for which I'd like to enlist some of the expertise on
this list, namely:

   "What if the common module now residing in the XL calls another module
   which is not shared.  Wouldt the called module also have to be moved to
   the XL?"  (from Lee:  I'm reasonably certain I know the answer to this
   one ..       :-)

   "If we wind up putting a large number of the modules into the XL, what
   about going all the way and putting all of the modules in the XL ?.  We
   would then have just a  program that would call a module rather that
   creating a process like it currently does." (from Lee:  our current
   online app launches a main program which then process-handles other
   modules.).

   "Would this work?  How would memory usage and system efficiency be
   affected?  Would this lend itself to the use of TRAX for debugging which
   won


?t work in the current environment?" Any thoughts or experience will be appreciated. Please reply privately at your discretion. TIA, Lee Gunter [log in to unmask]

ATOM RSS1 RSS2