|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.