Release ioncompatibility

Well, folks, after all the crowing I've done about how good IBM has been in
release-to-release compatibility, I've just been bitten pretty majorly by a
release incompatibility.

The problems lies in anonymous logons - that is, using the default
constructor for the AS400 class, with no system, user ID or password.  When
running on a non-AS/400 machine, this should prompt for the system, user ID
and password, which is fine.  But when running on an AS/400 JVM, the native
optimizations SHOULD use the user ID and password of the current job.  And
prior to V4R5, this is exactly what happened.

The problem seems to be in the way JDK1.3 handles the classpath.  Evidently,
IBM moved the Java toolbox to the boot classpath, and failed to put the
native optimizations in that same classpath.  So now, you are stuck with an
unoptimized toolbox that cannot be overridden (since it's in the boot
classpath), and which basically causes programs that used to work to fail
with the rather odd error "AS400SecurityException: Password is not set."
Well, it's not the password, bucko, I haven't set ANYTHING.  But aside from
that quibble, the issue is, how to fix it?

Well, to fix the JDK1.3 you must apply some PTFs, which remove the toolbox
from the boot classpath.  Then you must add it (jt400Access.zip) back in
manually, but ALSO you need to add the native optimizations, jt400ntv.jar,
and include that jar prior to the toolbox jar.

The OTHER workaround is to use the system properties to set the version to
JDK1.1.7, which will make the problem go away, since the 1.1.7 JVM doesn't
have the same classpath issue.  Unfortunately, and this is what's really
killing me and prompting this whole vituperative rant, QSH and RUNJVA don't
work the same.  You can evidently set the system properties on the RUNJVA
command using the PROP() keyword, but this doesn't work on QSH.  And I need
to use QSH because I have to override the STDOUT so that I can call it from
a CL.  When you run a command through RUNJVA, when the Java application is
done, you're stuck at the Java shell screen and you have to hit enter.

I found what I think is one workaround: you can set system properties using
the -D switch on the QSH command (I THINK).  Which means I should be able to
run QSH and run my command by adding the appropriate -D switch:

QSH CMD('java -Djava.version=1.1.7 myfoo.mybar')

Of course, this will fail if you don't have JDK1.1.7 installed on your
machine, so it's a fairly ugly kludge.  The right answer was to leave the
native optimizations in the boot classpath, but evidently that wasn't
acceptable to the design team.  So now I have to test to see which version
of the JDK is installed prior to running my job, or else add a JAR file to
my classpath that isn't used with (and for all I know, might even break) the
standard 1.1.7 JVM.

Somebody tell me I'm wrong, and I'll be happy!

Also, I'd be tickled to know how to override STDOUT when using the RUNJVA
command.  Having to use QSH is a little ugly.

Joe

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---