Hi Loyd,

Other than decoupling the program call by adding another layer, what are
the other advantages for calling via JDBC?

There are tradeoffs, advantages and disadvantages to almost anything.
Whether one way is "right" often depends on considerations that aren't
evident to outsiders. At the same time, many decisions are made without
considering alternatives and consequences. One thing interesting to me is
that everyone is thrilled about Java portability as long as its portable
*from* other systems to theirs, and show little concern for the other
direction.

That's not always the overriding consideration. While normally, IMO,
it's better not to have to mess around with converting parameters and
possibly switching to different environment contexts - foe example, Java is
not an ILE participant - it may be that the code in another language
application is the "blessed" way to do things and why have duplicate code?
(To that point, why are there both RPG and SQL versions?) OTOH, if you are
gone, is someone else going to have both Java and RPG knowledge? Or maybe
that's job security (not pointing at you, just saying people consider
different things.) Usually I don't gripe as long as they have considered
them. But too many shops end up with what an acquaintance of mine calls
"get 'er done" and pay for it longer term.

Some benefits of using JDBC instead are: same language constructs;
portable; SQL (portable and, one hopes, standard); no external dependencies;
possibly a new learning opportunity.

Keep in mind that I work in many areas for many different clients, which
may or may not be on the AS/400, so my view is different from someone who
may envision their entire career on one box or even at the same place.
That's why you'll rarely hear me chime in on PCML and other areas that
pretty much work only with the AS/400. At the same time, it seems to me to
only be a boost if the next "management direction" involves some other
system, and you can say, "Yep, we can handle it."

A somewhat extreme example is conceptGO's web site. It runs on a computer in the sky in California (I'm in Florida) on Solaris 10. You now know nearly the extent of my knowledge of Solaris ( not quite, but close enough. ) Yet my code and site just run, because it's all in Java. It could be moved to any other platform and JEE compliant server, and still would just run.


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: "Loyd Goodbar" <loyd@xxxxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Wednesday, October 28, 2009 8:48 AM
Subject: Re: Retrieving integer parameter after JT400 ProgramCall?


James and Joe,

Other than decoupling the program call by adding another layer, what are
the
other advantages for calling via JDBC? Not to say I won't use the stored
procedure in the future but using ProgramCall appeared straightforward and
I
was 90% there. The last 10% is a bear though.

For what it's worth, I got the program working in 20 minutes after looking
at an AS400Bin4 example. The two things I had to change was making
parmList[1] output only and adding conversion code for AS400Bin4 to an
integer.

Here is the relevant snippet:

// Create field types for parameters.
AS400Text txt5 = new AS400Text(5);
AS400Bin4 bin4 = new AS400Bin4();
byte[] b = bin4.toBytes(nextSequence);

// Create parameter array and populate.
ProgramParameter[] parmList = new ProgramParameter[2];
parmList[0] = new ProgramParameter(
txt5.toBytes(vanguardLocation),5);
parmList[1] = new ProgramParameter(4);

// Set up program call and run.
ProgramCall pgm = new ProgramCall(sys,
"/QSYS.LIB/LG.LIB/INCGLJSEQ.PGM", parmList);
if (pgm.run() != true) {
AS400Message[] messageList = pgm.getMessageList();
} else {
AS400Bin4 bin4Converter = new AS400Bin4();
byte[] data = parmList[1].getOutputData();
nextSequence = bin4Converter.toInt(data);
nextSequenceStr = Integer.toString(nextSequence);

System.out.println("Output Data 0: " +
(String)txt5.toObject( parmList[0].getOutputData() ) );
System.out.println("Output Data 1: " + nextSequenceStr);
sys.disconnectService(AS400.COMMAND);
}

With the outputs for three runs:
Output Data 0: WV
Output Data 1: 25672

Output Data 0: WV
Output Data 1: 25673

Output Data 0: WV
Output Data 1: 25674

Now all I have left is parameterize some of the hardcoded values.

Thanks everyone for pointing me in the right direction and advice. The
tool
I'm using (Extol Business Integrator) is written in and loves Java, so
I'll
be slowly learning Java as I go!

--Loyd




On Tue, Oct 27, 2009 at 7:02 PM, James Perkins
<jrperkinsjr@xxxxxxxxx>wrote:

You need the AS400Bin4 object then. Just Google for it and you will see
plenty of examples.

Since though you say SQL is already able to call it, why can't you just
call
it from SQL via JDBC?
--
James R. Perkins
http://twitter.com/the_jamezp


On Tue, Oct 27, 2009 at 16:29, Loyd Goodbar <loyd@xxxxxxxxxxxxxx> wrote:

> Dan,
>
> The numeric in RPG is definitely 10i 0 (integer, 4b0, etc.).
>
> d incgljseq pr extpgm('INCGLJSEQ')
> d inlocation 5a const
> d outuseseq 10i 0
>
> I used a prototype instead of *ENTRY PLIST.
>
> A testing program and SQL external procedure both call this program
> successfully. Due to other limitations (unrelated to RPG or Java), I
> need
> to
> call the program from Java.
>
> Thanks,
> Loyd
>
> 2009/10/27 Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx>
>
> > If you are using a numeric field from RPG most likely it is
> > AS400ZonedDecimal or AS400PackedDecimal. From your description of the
> > characters, I'd bank on packed. Probably 3/0 (three positions, zero
> decimal
> > positions). Something like this
> >
> > BigDecimal result = (BigDecimal)new
> > AS400PackedDecimal(3,0).toObject(parmList[0].getOutputData());
> >
> > I'm working from memory here, but I believe the java object returned
> > by
> the
> > toObject of AS400PackedDecimal is BigDecimal.
> >
> >
> --
> This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
> mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
>
>
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.



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.