Re: Where to post ideas for RPG

-----John Yeung <gallium.arsenide@xxxxxxxxx> wrote: -----

[Mark]
P.S. Every language except embedded SQL would have the same problem that RPG has. Namely the call is strongly typed, down to the precision and scale of the
parameters and return value. So I can't cover every possible option in a single sub-procedure regardless of the language.

[John]
Well, not *every* language. You definitely would not have that problem
in [various IBM i scripting languages, for example]

[Mark]
Given that the context was creating a procedure to be called from RPG to simulate %min and %max functions, yes every language that can be called from RPG as a function, and return a value, can Python even do that, would have the same issues. The reason is, and the limitation of RPG sub-procedure parameters, is that parameters are always strongly typed. I can't just say, this is a number, and any number will work. In fact, unless I use floats, I have to specify the number of decimal positions, and that precludes numbers with more decimal positions, or If I provide the maximum possible decimal positions, that severely limits the size of the integer portion of the number. And floats have their own issues since they are not exact numbers.

[John]

That's not the context, though. I mean, folks were even bringing up
RUNSQL as a solution, albeit a convoluted one. If that's a solution,
then scripting languages sure as hell are too.

[Mark]
The context is that it has to be callable from RPG, and return a value to the caller. RUNSQL can be wrapped in a CL and is therefore callable from RPG. Not as convenient as a procedure, and not better than a new built-in, but at least I could make it work if I was so inclined. This initial thread was not seeking solutions, but soliciting votes for an RFE, so debate must be centered around solutions that are at least as good, or better than just coding the functionality in straight RPG, and it still must be callable from, and able to return a value to RPG.

[John]

If you are saying that whatever solution anyone comes up with must be
wrapped in an RPG subprocedure, and that subprocedure is what is
limiting with regard to types, then even embedded SQL, as in SQLRPGLE,
is **NOT** an acceptable solution, because it has to be wrapped in
type-limiting RPG too!

[Mark]
No, just that it needs to be callable from RPG. Embedded SQL does not need to be wrapped in anything to be executed (called) from an RPG program.

[John]

Your initial quote, as I've included above, states that you feel
embedded SQL meets the requirements. Therefore, so do a number of
other dynamic languages.

[Mark]
As long as the initiator is an RPG program, and that scripting language can be called or executed from RPG and return a value to the calling RPG program in some manner, I would accept it. Though whether it is truly something I would use would depend on whether it was easier (for me) or not, and didn't add significantly more overhead or maintenance burden vs. just writing the solution in plain vanilla RPG.

[John]

I have to stress that no one is saying any of these is a *better*
solution than just writing things in vanilla RPG and being done
already.

[Mark]
Just looking for votes on some RFE's, but I am happy to debate the merits of them. Here are some links:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=93114
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=93115