Re: PCML

["Dave Wall" <dawall@xxxxxxxxxx>]

Two more comments ...

1) If you serialize (pre-parse) your PCML then you don't need the parser in
your classpath.  I mention this only because parsers have not learned yet
that compatibility is a good thing.  It seems like every time we move to a
new major level of the parser we have to change our code because a parser
method signature or behavior has changed.  If I code to the new behavior
and you code to the old one then we are broken because two parser versions
cannot be in the classpath at the same time.  If you serialize your PCML
then you don't need the parser at run time.  The "PCML Process" section of
the Toolbox pub describes how to serialize PCML.

2) PCML is slower than the ProgramCall class.  I love PCML because it is
easy to use and improves programmer productivity.  It is slower than the
Toolbox ProgramCall class, however.  Actually PCML is really just a wrapper
on top of ProgramCall.  It does a bunch of work then carries out the
request by using ProgramCall.  All that xml parsing and PCML logic takes
time.  In most cases it does not matter, but if performance is critical and
it looks like the client side is too slow, prototype switching to
ProgramCall to see if that helps.

David Wall
Toolbox for Java
iSeries ODBC Driver for Linux




                      "Tanveer,
                      Mohammad"                To:       
"'java400-l@midrange.com'" <java400-l@midrange.com>
                      <MTanveer@friedma        cc:
                      ncorp.com>               Subject:  PCML
                      Sent by:
                      java400-l-admin@m
                      idrange.com


                      05/30/2002 12:41
                      PM
                      Please respond to
                      java400-l





Interesting :-)  Do you have a documented procedure how to deploy PCML on
Websphere? Which jar files are required and how/where to specify classpath
for the required jar files.  We are not able to deploy it successfully in
multiple production environment using one standard procedure.





-----Original Message-----
From: Eyers, Daniel [mailto:daniel.eyers@honeywell.com]
Sent: Thursday, May 30, 2002 12:07 PM
To: 'java400-l@midrange.com'
Subject: RE: Calling Java from RPG/COBOL


Any reason why no one's talking PCML?  Work ok for us... a little slow,
maybe???

dan


-----Original Message-----
From: Jon Paris [mailto:Jon.Paris@Partner400.com]
Sent: Thursday, May 30, 2002 12:38 PM
To: java400-l@midrange.com
Subject: Calling Java from RPG/COBOL


 >> I would second the recommendation of a queue for any call intensive
operation.

The trouble is it isn't call intensive and I just need the simplest
approach
possible.  DQs and all the rest are great but total overkill for the
application in question.

Jon Paris
Partner400


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