Re: JVM Properties -- MIDRANGE-L

Thanks for the response, Dieter. Technically, the QIBM_RPG_JAVA_PROPERTIES isn't an undocumented hack, it's just documented very poorly. As is the #AllowOptions capabilities of the SystemDefault.properties file. I will consider the idea of creating my own JVM at startup. I've done that in the past, but it's quite a while since I did so. The benefit with that approach is that I have complete control.

I'm using HSSF to create Excel spreadsheets, and basically I'm just running out of memory. It's not impossible using .properties and JAVA_HOME, but it sure is tricky.

On 5/18/2021 12:09 AM, D*B wrote:

<Joe>
Technically this may be an RPG question because I only care about this when calling Java from an RPG program, but I'll start here. I seem to be losing my mind, because I've been unable to find a simple way to force the JVM that's created to be a 64-bit with 3G of heap space. I managed to do it, but it wasn't simple. I had to make configuration changes in two different places and that never sits well.

To change the default JVM, I used the JAVA_HOME property and pointed it to (...)/jdk80/64bit.

To change the max heap size, I had to use SystemDefault.properties with an #AllowOptions and then -Xmx3G.

This isn't the end of the world, obviously - it functions. But I'd like to make it a bit simpler, and I'd really prefer to not create a SystemDefault.properties file. I don't mind JAVA_HOME; I can do that at the job level. But SystemDefault.properties is a more user-level thing and that could get messy if only one program needs that setting.

Did I just miss a simpler way to do this?
</Joe>

That's one of the ugly sides of using JNI support of the RPG compiler! BTW: same problem with classpath etc.
Using JNI in a clean way, this would be done by creating the JVM by calling JNI_CreateJavaVM - if this is done under the covers, you would have to manipulate the default settings as you mentioned. There might be an undocumented "hack" using envvar QIBM_RPG_JAVA_OPTIONS, but using undocumented "features" isn't a clean way. Amother problem might be, that diffrent Java functions would need diffrent settings (=> you must not use IBM provided Java SQL functions or your RPG/Java programms won't work).

My answer to these problems is very simple: don't use RPG to Java calls via JNI support of the compiler. More than 10 years ago, I've written a very generic way to start a JVM with all needed settings (simply using the java way with parms) and communicate via dataq between RPG and a generic Java handler. I could start as many JVMs with diffrent settings as needed, each of them could serve as many RPG Jobs as needed. This would solve another ugly side of RPG_2_Java calls: the waist of ressources by starting lots of JVMs. BTW: I've made this Open Source (its called AppServer4RPG) and it's the base layer of ArdGate.

D*B