×
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 8/20/2019 12:02 PM, John Yeung wrote:
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.
I have genuinely appreciated people showing me the 'Pythonic way' to
write Python code. I believe it's fair to say that CALL/PARM is the 'IBM
i' way to write IBM i code. We can, and do, depart from that norm, but
when we do, it looks funny :-)
QREXQ has some advantages over CALL/PARM - especially in the area around
passing an array, or list back and forth. The disadvantage is that it is
unstructured - the compiler/runtime cannot help you find mismatches
between sender and receiver. That, and it's all-too-possible to have
'leftover' stuff in the external data queue that breaks the expectations
of one side or the other. Imagine that the Rexx side manages to do a
bunch of PUSHes, but the CL encounters an error and QREXQ doesn't pull
them all off... you'll be left with 'replies' in the queue and the next
time the CL tries to put a 'question' in there, the Rexx PULL will
retrieve... an 'answer' instead of a 'question'.
Mindset is indeed an interesting - and very real - problem, but
sometimes it's only a cigar :-)
midrange.com
