Ron asks:
> Is there are procedure to convert an SL to an XL?

You can't really "convert" an SL to an XL.

An SL is a library for CM programs containing compiled CM object modules.
An XL is a library for NM programs containing compiled NM object modules.

If you have NM compilers (and source code) for all the modules in your SL,
then you could recompile them in to NM (making whatever changes might be
required depending on language, intended usage, etc.) and add them to an XL,
thus creating an XL with the equivalent functionality to the SL.

The other thing you can do is create an XL full of "stub" routines that
"switch" (make cross-mode calls) to the code in the SL.  This allows the CM
programs that *use* the SL to be compiled into native mode while retaining
the ability to use the code in the SL without having to also convert the
code in the SL into native mode (often one might not have all the source
code for the SL modules or there might be difficulties in converting it to
NM, etc.).  For NM->CM switch stubs, you can use SWAT.PUB.SYS to generate
the NM code that would go into the XL and which would then invoke the code
in the SL at runtime.

Of course switching from NM to CM is slow, so you only want to do this kind
of thing if you really have to.  Usually you're better off leaving
everything in CM rather than ending up with an NM program making a lot of
switch calls to CM code (at least from a performance point of view).  You
might have capacity or other reasons that require a program to convert to NM
at which point the switch stub mechanism might be the only easy way to get
the program to run at all.

As Jeff mentions you can "OCTCOMP" the CM SL which will make the code in it
run in mostly-native mode (though using several times the memory) and with
exactly the same limitations as the original CM code.  OCTCOMP just adds a
pre-translated version of the CM code to the end of the file that will be
invoked when you run the program or SL on a MPE/XL or MPE/iX system.  This
may or may not have a measurable effect on performance (it will most likely
be a small positive (or negative if the process was not cpu-limited to begin
with due to the extra memory needed to hold the extra code) effect).

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *