Ken writes:
> SUMMARY:  What I was blue-skying was the possibility of
> using JAVA for client-server programming on the 3000,
> where we might never run the resulting code anywhere
> except on the 3000.  And to be able to call Transact modules
> out of an XL, I assumed (am I wrong ??) that we would have
> to have a native Java compiler to be able to do that;  or at
> least to be able to do that with any kind of acceptable
> efficiency ??

You can fairly easily call native code in an XL from Java.  You will
need to write some stub code to handle getting parameters back and
forth between the Java object system's idea of how things work and
how a standard 3000 language stores things, but efficiency wise it's
probably the same whether the Java code is interpreted, Just In Time
compiled, or natively compiled.  The only difference would be the
speed of the Java code.  The Native Code you are calling, and the
calling process itself, will be pretty much the same.  A super whizzo
native 3000 Java compiler could improve things by providing some sort
of "Intrinsic" mechanism to automate parameter type conversion and
whatnot, but at that point you would be starting to mess with the
specification of the Java language itself, and I doubt that this is
going to happen any time soon.  There are already ways of doing just
about anything you would want to with what the Java system provides
today, so the costs probably outweigh the benefits at least at this
point.

For example, it wouldn't be too hard to write an "Intrinsic class" for
Java on MPE that would let you do things like:

import mpe.Intrinsic

...

   fread = new Intrinsic("FREAD");
   fread.setarg(1, fileno);
   fread.setarg(2, buffer);
   fread.setarg(3, buffer.length);
   fread.call();
   if (fread.ccode != 2) {
     throw new IntrinsicException();
   }
   transfercount = fread.result();

The constructor call:

   fread = new Intrinsic("FREAD")

which could also have alternatives like:

   fread = new Intrinsic("FREAD", "NL.PUB.SYS", "SYSINTR.PUB.SYS");
   MyCode = new Intrinsic("MyNMTransactCode", "MYXL", "MYINTRFL");

would look the routine up in a SYSINTR file and dynamically load the
actual routine.  By reading the SYSINTR file it would find out the
appropriate parameter types and return value for the routine so that
the setarg() method would be able to coerce the Java type into the
appropriate MPE type, and the call() method would make the actual
call to the intrinsic and translate the returned parameters back into
Java types.

This could be made to work for your Transact code by simply building a
SYSINTR file that described the routines.

Writing this Intrinsic class (and the native code to support it) would
probably be a lot easier than writing a complete set of interface
routines for all the MPE Intrinsics and subsystems, not to mention user
written routines like the ones Ken is talking about.

G.