Scott Klement wrote:
I'd recommend that you not use STRQSH in the first place in a compiled
CL program. Especially if at V5R4, use ILE CL and the QzshSystem() API:
My experience is the opposite of yours. I've found QzshSystem() to only
work well if used from a program that's already in the QShell
environment. In my experience, QzshSystem() doesn't set up the QShell
environment with all of it's descriptors, etc, causing a lot of things
to fail. So you can run it without problems when you're already in
QShell, but from a CL program, it doesn't work so well.
By contrast, I've found STRQSH CMD('xxx') to work flawlessly from CL
programs.
So, I'm really surprised by your suggestion.
Scott:
Two things -- First, my statement was too short. Second, it was just
before getting too tied up to follow up immediately. (Work always
must come first.) I hope to have time this weekend to prepare a
better response for this; this will have to do for now.
My first significant use of the API was a real success that
surprised me quite a while ago. A problem was resolved that wasn't
even apparent with STRQSH. So I started looking for info -- mostly
because the more I played with the API later, the more confused I
got about how it worked.
Eventually, you supplied a post in (I think) the RPG list that
suddenly clarified much of what contributed to my confusion. And
particularly with pointer support in V5R4, it started coming
together and working consistently.
The more I've used the API, the more the whole _idea_ of Qshell has
been illuminated. For a dinosaur AS/400 guy, the illumination has
made a big difference. I no longer see Qshell as just some tacked on
option to help with "IFS stuff", but rather as an integral part of
the system to be used whenever appropriate.
For me, STRQSH always seemed to cause a conceptual barrier that
separated things without allowing mental linkage that contributed to
'integration'. Investigation and use of the API has really helped
create a new paradigm for me.
There is a subset group of "programmers" who don't know RPG well,
nor C, nor COBOL. They tend towards operational functions and
essentially live in CL. Other programmers are deep into RPG (or
whatever) and mostly venture into CL to do a OVRDBF or CPYF, etc. We
see evidence with actions like WRKACTJOB *PRINT followed by copying
the spooled file to a PF, in order to find what jobs are active.
But there are other tools. Experience with multiple tools makes
numerous differences as time goes by.
I use STRQSH regularly; but now I know another tool, and I can make
better choices. Nowadays, unless I'm at a command line, I no longer
actually _need_ STRQSH. Now, it's better positioned as a tool to use
when it's right for the circumstance. For me, the API has become the
power tool.
Even better (and probably self-serving too), the more people who use
alternatives, the more investigation happens. More circumstances are
covered. IBM gets more calls about them. Things get improved. New
environment variables get created in new releases to control behaviors.
But that's all secondary and isn't direct to your concern.
Hopefully, I can do better after this work-week ends.
Tom Liotta
midrange.com
