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.