Any known problems with JZOS and RMI

jvanparijs · Post by **jvanparijs** » Tue May 10, 2005 8:40 pm

Hi,

I'm testing JZOS to run an application that uses the Java RMI (Remote Method Invocation) to wait for requests coming from other platforms. The application just runs fine when I run it from normal USS, and via BPXBATCH (both as a JOB and an STC). When I try to run it via JZOS, the application starts normally, but in stead of waiting to be woken up by an RMI call, it ends immediately (without any error messages). I have a complete JOBLOG available (produced with IBM_JAVA_OPTIONS=
-verbose:class,jni,Xclassdep, so it's about 5,500 lines) that I can send if needed. Any ideas?
PS: I'm running with the new Beta version JZOS 1.2.0

Post by **dovetail** » Thu May 12, 2005 8:40 am

Seems odd, I can think of no reason why it shouldn't work (its the same JVM, after all), unless your classpath is not being set the same. Please check that, and if that's not the problem, then send the job log to dev@jzos.com and we'll take a look.

(please run with LOGLVL="+T", but its probably not necessary to run with -verbose:class,jni,Xclassdep (since its not a performance / initialization problem)

jvanparijs · Post by **jvanparijs** » Fri May 13, 2005 2:07 am

Hi, I sent the log to dev@jzos.com, but apart from showing that are class starts Ok, I can't see anything in there...

Post by **dovetail** » Sun May 15, 2005 9:10 am

This is an interesting case. I suspect that you are starting a thread that runs your ReQuestAgent and then letting your main() method to run to completion.

The JZOS launcher invokes System.exit() when main completes. This invocation causes the JVM to exit, even if there are other threads running. We do this so that we can ensure graceful cleanup and enable job step to step processing to work consistently.

In your case, you want your agent thread to continue even after main completes, which is how a traditional launcher operates. In order to get this behavior under JZOS, you can issue a wait() at the end of your main method. This will keep the launcher from invoking System.exit(). When you're ready to stop your agent, you can use the MVS stop (P) command from the console (or use the 'Y' prefix command from SDSF.DA).

Give this a try and let us know if it solves your problem.

We realize that this behavior, being different from the standard launcher is likely to cause problems. We are currently testing a new version of the launcher that will work like the traditional java launcher, but still handle cleanup and exit code processing.

jvanparijs · Post by **jvanparijs** » Tue May 17, 2005 2:21 am

Hi, I checked with my colleagues who handle the Java part of our application, and your assumption is correct: our main () class starts another thread, and terminates. According to them it won't be a problem to put in a wait (), so that main remains active, but they're right now making some important other changes, and don't have time to do this immediately. We're now about ready to start testing our new jar files, and when that doesn't reveal (too many) problems, we'll probably be able to put in the wait...

I'll keep you informed of our findings. Regards...

Post by **coz** » Tue May 17, 2005 5:45 am

Juul,

We've changed the way we handle the launcher termination to support the case that you have. If you download the latest version of JZOS (1.2.1) it should work without you having to issue the wait(). Just make sure that any threads you create are non-daemon threads (this it the default, so unless you are explicitly calling setDaemon() you should be fine).

Let us know how this works...

jvanparijs · Post by **jvanparijs** » Tue May 17, 2005 8:55 am

I just downloaded the new 1.2.1 release, and tested it with our classes. Everything works fine now; just 2 small remarks:
1. Immediately after termination of our main (), JZOS produces messages that it is "about" to terminate. This could confuse some people, as termination can still be hours, days, weeks away. Here are the messages from the joblog:
01:04:04 JZOSVM14(D): About to invoke info.cressida.mqla.agent.AgentServer.main()
01:04:13 JZOSVM14(T): <- invoke()
01:04:13 JZOSVM14(N): info.cressida.mqla.agent.AgentServer.main() completed.
01:04:13 JZOSVM14(T): <- invokeMain()
01:04:13 JZOSVM14(T): <- run()
01:04:13 JZOSVM14(T): -> cleanup()
01:04:13 JZOSVM14(I): About to destroy JVM...

2. I'm not all that familiar with USS and related, so I didn't really know what was going to happen when I unpacked the jzos.pax.Z file into the same path; it apparently worked ok, but this could be better documented in the install guide; also, I didn't care too much as I didn't modify/create any files in the jzos directories, but I'm still not sure what will happen with new files, or probably even worse, files changed by the user...;
Likewise, for people not all that familiar with z/OS, it would be useful to document that installing the z/OS parts into the existing libraries will preserve new members, but OVERWRITE any changed members (which can be rather painful if the "unknowing" tailored EXJZOSVM or RUN14 members in the JZOS SAMPJCL library)...

Anyways, good (AND FAST) work... Thanks