Re: Load CL variables from SQL example

On Tue, Aug 20, 2019 at 10:33 AM Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 8/19/2019 11:28 AM, dlclark@xxxxxxxxxxxxxxxx
wrote:

The "problem" in the OS/400 environment is that REXX runs in its
own world and is not easily called from CL or from RPG -- especially if
you want returned information. This is the same problem CL has with SQL
-- or CL with any other specialized language (such as Python, etc.).

I very much agree with Dave.

It's partly a technical problem but also partly a mindset problem.

The parameter-passing mechanism that *PGM objects have can't easily be
used to get information back from Rexx (or Python or whatever), BUT
(1) it is quite easy for Rexx (or Python or whatever) to pass
parameters to and receive them back from *PGM objects and (2) it is
quite easy to pass information back and forth IN EITHER DIRECTION
using means other than parameters.

Remember that Rexx was not conceived as or designed to be a "peer" of
CL and RPG. It was meant to be a scripting language, in the vein of
bash, Perl, or Python. And in that mission it succeeds admirably,
holding its own against those newer languages.

I think a lot of midrange lifers have a distorted sense of what
"scripting" looks like, compared to most of the computing world. They
were given CL and told it was "scripting for OS/400", because CL is,
literally, the command language used at the interactive prompt, and a
CLP is an aggregation of CL commands into program form, with the
attendant minimal branching and conditional control structures. And
yeah, you do script CL commands in a CLP. But you compile it
statically just like RPG, and don't have the richness of a
general-purpose language. (This is why some folks like Rob have taken
to just doing everything in RPG.)

If people can get into the mindset that not all communication has to
be via parameters, it will go a lot smoother. Even more so if people
can conceive of Rexx (or Python or whatever) as
delegating/coordinating/orchestrating *PGM objects, rather than the
other way around.

Naturally, mindset problems tend to be tougher than technical problems.

John Y.