RE: SQL2JXL gets SQL0204 on one machine, works on another -- MIDRANGE-L

And both jobs use the same language? On DSPJOB OPTION(*DFNA), you'll see CCSID and default ccsid. If CCSID is 65535, then the default ccsid is set from the language defined for the job. Mine says 37 for default CCSID....

I'm just thinking there's something in the environment that's cuasing this....

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Peter Dow (ML)
Sent: Tuesday, August 21, 2007 4:49 PM
To: Midrange Systems Technical Discussion
Subject: Re: SQL2JXL gets SQL0204 on one machine, works on another

It's 65535 on both machines.

DeLong, Eric wrote:

Can you check the QCCSID system value? If 65535, that could be the problem......

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Peter Dow (ML)
Sent: Tuesday, August 21, 2007 2:59 PM
To: Midrange Systems Technical Discussion
Subject: Re: SQL2JXL gets SQL0204 on one machine, works on another

Hi Eric,

Hey, when I don't know better, nothing's silly :-) .

SQL2JXL is a great utility written by Giuseppe Costagliola (see
http://www.mcpressonline.com/mc?14@xxxxxxxxxxxxxxxx@.6b16ef2b). He
wrote another version called SQL2XLS (see
http://www.mcpressonline.com/mc?50@@.6ae8269f). The latter uses the
same POI HSSF APIs that Scott Klement used in his HSSFR4 service
program; the former uses the faster JExcel API developed by Andy Khan.
Both APIs are written in Java.

Basically, it takes any valid SQL SELECT statement and creates a
spreadsheet from it. It also has the ability to merge it with an
existing spreadsheet. Perfect for those users who can't stand reports
anymore and want everything in a spreadsheet.

I've installed it on about 4 machines now (thanks Giuseppe!), and this
is the first time I've had problems. And it's when I have problems that
the real learning begins!

Both jobs have a different library list; however, in both cases, the
file I'm querying is in the library list. The jxl.jar is compiled with

CRTJVAPGM CLSF('/excel/jxl.jar') OPTIMIZE(40)

Near as I can tell, the SQL2JXLC program runs the SQL2JXL class with a
classpath that includes /excel/jxl.jar. The SQL2JXL java class is what
actually excecutes the SQL SELECT statement by using a jdbc driver.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

DeLong, Eric wrote:

Well, I guess that was a little silly... First of all, what is SQL2JXL? I bet it uses QSQPRCED api to get to the data.....

What happens when you qualify the file reference in your SQL? I am sure this should work. Then the question becomes, what happens to your library list.

Are you sure your two jobs have the same LIBL?

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of DeLong, Eric
Sent: Tuesday, August 21, 2007 1:59 PM
To: Midrange Systems Technical Discussion
Subject: RE: SQL2JXL gets SQL0204 on one machine, works on another

Did you compile with commit *none?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Peter Dow (ML)
Sent: Tuesday, August 21, 2007 1:04 PM
To: Midrange Systems Technical Discussion
Subject: SQL2JXL gets SQL0204 on one machine, works on another

Hi Everyone,

I installed SQL2JXL on two separate machines, both have

vrm530
same PTF level
java 1.4.2

and on one of them, SQL2JXL gets an SQL0204 while on the other it works
fine. I tested with a trivial SQL statement which works fine in
interactive SQL, e.g. SELECT * FROM FILEA.

In interactive SQL, both machines show *LIBL as the result for

SELECT CURRENT_PATH FROM SYSIBM/SYSDUMMY1

What am I missing?

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /