× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Also, I love the idea of using AppServer4RPG, but the amount of work to retrofit existing applications means I won't get it done for this project.  But I can look to implement it on a proof of concept and then maybe I can justify it.

On 5/18/2021 9:11 AM, Joe Pluta wrote:
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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.