Personally, I don't use PCML, I use the standard toolbox classes. 
The nice thing about PCML is it can be generated during the RPG programs
compile which can save a ton of time.I can remember if this is available,
but once you have the PCML one could autogenerate the Java objects needed to
call the RPG programs.

But I don't know of any seven-parameter limitations except on service
programs. 
Most all of my development is done in service programs so this affects me a
lot. Do you have an idea of why this limitation is there?

On the other hand, dates are still tough, though not impossible: you define
the parameter as an array of bytes and then use the DateTimeConverter class
to convert the date to a usable value.

These are the things that should be built into the base offering as date
data types are becoming more common (vs. int fields to hold dates).

Anyway, I suspect your problems arise from your application architecture;
your service programs have lots of small methods that return values, much
like getters in an OO environment.

Nope.  I think getters/setters in RPG (which are usually around a file) are
a waste of time 95% of the time.  I was simply using PCML to call RPG
service programs that encapsulate business logic (and of course multiple
file access).  There is another thread where I commented on this so I wont
go into details here (http://tinyurl.com/fl88p).

Me, I pass data structures between programs; it works much better.
And if I was the one on both ends of the programming I could compose the RPG
to use DS's but that isn't always the case, and to tell somebody that they
need to modify their already modular *SRVPGM because of a PCML limitation is
a little embarrassing on the part of Java (sure it isn't Java and instead
PCML, but guess who gets the blame).

Thanks for you thoughts Joe,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Joe Pluta
Sent: Tuesday, August 01, 2006 2:41 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] PHP to RPG - "tight" integration

Personally, I don't use PCML, I use the standard toolbox classes.  But I
don't know of any seven-parameter limitations except on service programs.
On the other hand, dates are still tough, though not impossible: you define
the parameter as an array of bytes and then use the DateTimeConverter class
to convert the date to a usable value.

Anyway, I suspect your problems arise from your application architecture;
your service programs have lots of small methods that return values, much
like getters in an OO environment.  Me, I pass data structures between
programs; it works much better.  I never have to worry about having too many
parameters, and I can pass structures inside of structures with no problems.

Joe


From: albartell

The last I used Java's integration to RPG, specifically PCML, I made 
some good progress but then was stopped by a brick wall.  The brick 
wall was a limitation on the number of parameters that could be passed 
(i.e. seven parms max at the time), the lack of being able to pass 
date data types, and the lack of being able to pass back anything 
other than an int in the passback parm of an RPG sub procedure.


--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a
message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


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.