On 19-Aug-2016 13:25 -0700, Mark Murphy wrote:
This is craziness. There is no way I am going to jump into the SQL
precompiler,
Seems a common\recurring theme here on this list; apparently,
somehow, a pre-compiler so complicates coding, that _avoidance_ is the
typical policy.? I do not understand the logic, nor any rationale
stated in the past messages [IIRC, mostly just _any excuse_ used as
rationalization for avoidance; e.g. "I once had this problem back on
v3r# when..." or "I do not want any SQLRPGLE modules in my Service
Program that currently has only RPGLE" modules], and I expect the quite
legitimate issue for lack of SQL pre-compiler would be so rare as to
seem non-existent.
or CLI, or any other language, particularly CL, just to get
a %min or %max function in RPG.
FWiW my somewhat /crazy/ response about using SQL and CL [I even
accused the code of being /bizarre/; just not much more so than what we
often see posted here] for how to obtain a MAX across numerous values
was directed solely to a posited situation whereby the coder does *not*
"have SQL", such that embedded SQL was not an option. I did however,
clarify that just coding in RPG was probably a more appropriate choice,
if embedded SQL was not available; and we know %max is currently
unavailable in RPG, so that is not even an option -- and thus the RFEs.
It is far easier to just code:
fld = value1;
if fld < value2;
fld = value2;
endif;
Yet that simple-example is lacking, with regard to the implication of
the previously noted %max(value1:value2:...) from which almost anyone
would reasonably infer, expresses a desire to have the capability for
%max(value1:value2:...:valueN). With non-contiguous or unaligned
values, and\or inconsistently typed variables, coding the effect of a
MAX is cumbersome [can not just perform the simple predicate in a loop
across the values], and especially so, as the number of values increase.
But still you are going to have to think a little bit to decide (as
you come across it in the source) if it is a %min or a %max
function. Which is it? I'm sure you can determine the answer. But it
would be far easier if I simply could write:
fld = %max(value1: value2);
Which one took you longer to figure out?
*Of course* the if\then is not nice\simple to read and infer. I
*totally agree* that even the simple-case [two variables] benefits from
a %max builtin, *if* only that BIF were available; the more complex
scenario involving numerous values, benefits significantly more with
that BIF syntax.
Yet I find that coding the following is just as conspicuous in that
regard; and for me, not at all problematic to change from using purely
RPGLE to using SQLRPLE to achieve that simplification\conciseness:
exec sql
set :fld = max(:value1,:value2)
;
And yes I could write a sub-procedure that would cover 90%, maybe
even 99% of the cases that I would come across, but that one time in
a hundred that it didn't work because I can't use operation
descriptors to decide what the scale and precision of the number, or
if it is an integer, or a float, just irks me.
FWiW, my first foray into data-pointers in RPG was problematic, and I
never followed-up; I figured the issue was possibly the open pointer
type in RPG, but seem to recall seeing some code that claimed to
function. But I mention those, because their use probably would enable
a much better means to code a generic procedure to do the work of MIN or
MAX, than would OPDESC; and there is support for both FLOAT and INTEGER.
It is a simple thing what is the problem with asking for it.
I did not notice anyone ever suggesting any harm\problem in asking
that RPG include the capability. My first reply was quite simply to
suggest that RPG already has the capability available, _when using_ the
SQL pre-compiler to compile the RPG program. So while not purely RPG,
certainly much more straightforward than many other coding choices for
approaching the issue.
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.
That seems to reiterate my original point; that SQL *already gives*
that capability, including expressions [that need not even evaluate to
the same data-type]. And although an RFE to ask for that capability in
the RPG could see those BIFs appearing in the RPG language eventually,
there is surely going to be a long wait. I prefer to use the SQL to
achieve that conspicuous effect coded in a simple assignment, and avoid
coding convoluted RPG if\then logic; I might prefer the ability to do
that in RPG, but I expect the functionality will lack as compared with
the SQL, and awaiting that eventual support does not help in any way to
accomplish the task presently.
midrange.com
