×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On Fri, Jun 7, 2019 at 11:36 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
Not quite true - you can do it if you can constrain the problem space. I wrote up quite a versatile approach here:
http://ibmsystemsmag.com/ibmi/developer/rpg/even-more-flexible-calculations/
What I said is absolutely true. Maybe you skipped the second part of it:
In principle, you can do anything in RPG, but in this case, all the
alternatives would be even more complicated than the compare/selects.
Your "versatile approach" as well as Nathan's are all well and good,
but they are definitely on the path toward being examples of
Greenspun's tenth rule:
<blockquote>
Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp.
</blockquote>
The rule is very generalizable. The specific languages don't matter
too much. The point is that RPG is Turing complete; therefore if
something can be done at all, it *can* be done in RPG. But you don't
necessarily want to.
Of course even using SQL means constraining the problem to what dynamic SQL statements can do!
Right, absolutely. But SQL, by its nature, makes it fairly easy and
straightforward to do what OP was describing. And if some of what OP
needs to do is awkward in SQL but easy in RPG, that's all the more
reason to use SQL embedded in RPG.
The awkwardness of cramming as much logic as possible into SQL (which
some people tend to do) is the very reason my own SQL skills are
fairly modest; it is so much more expedient to use *simple* SQL and
embed it in *simple* Python (or whatever host language is most
comfortable).
John Y.
midrange.com
