Re: More XLPARSE problems

Scott,

If CLASSPATH is stored at job level (which is what I thought), then how 
come the program gives a 'Class not found' or similar error if I add the 
variable from the command line before running the program interactively, 
but does find the class if the classpath is setup using a system() call 
within the program?

"The excel record that HSSF is not familiar with" always appears to be the 
record below the last relevant row in my sheet.  Strangely enough, if I 
create a sheet that has twice the number of rows, it's again the row 
following the last "filled in" one.

As for stopping the parsing, do I understand correctly that I can simply 
have the subprocedure return *ON if it encounters a "blank" line?  For 
instance, if column 0 is always filled in as character, have the charcell 
procedure return *ON if Value is *blanks?

Sorry if I'm asking stupid or obvious questions, but this is my first 
attempt at this...

Thanks,

Peter Colpaert
Application Developer
Massive - Kontich, Belgium
-----
Yoda of Borg are we.  Futile is resistance, assimilated will you be.
-----




Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
14/07/2005 21:23
Please respond to RPG programming on the AS400 / iSeries

 
        To:     RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
        cc: 
        Subject:        Re: More XLPARSE problems


<---cut--->
CLASSPATH, like all environment variables, is stored at the job level or 
system level. It's not activation group specific.  The JVM isn't related 
to the activation group either, since Java isn't an ILE language.

<---cut--->

Sounds like you have an Excel record in your spreadsheet that HSSF is not 
familiar with.  Not much I can do about that -- you'll have to contact the 

POI developers.

<---cut--->
Have the subprocedure that's called by XLPARSE (the one for numeric cells 
or the one for character cells) return *ON.  That should stop the parsing.