× 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.



Greg,

You are using an outdated copy of HSSFR4. Please download and use the current one. I know that your copy is outdated because the FileInputStream vs FileOutputStream thing was corrected in Aug 2006 -- more than a year ago.

The most recent version can be found in the following article (Systeminetwork.com membership required, but a free "associate" membership will work):
http://www.systeminetwork.com/article.cfm?id=55032

Having said that, it's important to understand that RPG's O=Object data type aren't the actual Java objects. They're just REFERENCES to the objects. Under the covers, they're just numbers -- and the numbers are used by the JVM to locate the actual object, which always resides in the JVM itself. So whether I coded FileInputStream or FileOutputStream doesn't really matter, as long as the number does actually refer to a FileInputStream object in the JVM. The reason that code made it into wide use is because it worked, despite being coded incorrectly, because it still referred to the right type of object.


Regarding the "JVM ended, Reason code 2" error:

That almost always happens when you pass a *NULL object to a Java routine. Like I said, RPG's O=Object data type is only a number that refers to a Java object. If you set that number to *NULL (which under the covers is zero) the JVM will be trying to refer to an object that doesn't exist, and that causes it to become confused and end abnormally.

Note that hssf_open() returns *NULL if it can't open the file. Your code is SUPPOSED to check for that *NULL, and either try again, or end the program, or whatever it needs to do, when it encounters the *NULL. What it should NOT do is pass that *NULL object to another Java routine. And I suspect that this is what it's doing.... it's not checking for the *NULL, and is proceeding as if everything is fine. And when Java gets that *NULL value, it crashes the JVM.

So you can fix that by changing your code to something like this:

book = HSSF_open('/path/to/whatever.xls');
if (book = *null);
*inlr = *on;
return;
endif;

So... if the open failed, the program does not try to manipulate the workbook (since it was never loaded), it just ends.

That'll stop the JVM from crashing, but won't cause the HSSF_open() routine to load your spreadsheet. There should be earlier messages in the job log (earlier than that JVM ended thing) that explain why the file didn't open...



Fleming, Greg (ED) wrote:
Scott,

Some further info may help us narrow this down.

In debug, the error appears to occur in the HSSF_Open procedure at line
1559 wwFile = new_FileInputStream(wwStr);

I had read on another list somewhere that the preceding definition on
line 1553:
D wwFile s like(jFileOutputStream) Was in error and should be corrected to: D wwFile s like(jFileInputStream) .

I did this, recompiled the module and re-created the service program,
then rebound The upddemo program. But I still get the same error either way.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.