×
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.
Ah, yes.. I was going to reply, but I see you already found the
answer. Great!
One caveat to consider is the 'where allowed to run' parameter of a
command. When you use QCAPCMD with type=0, it runs the same as QCMDEXC
-- the command must have allow(*EXEC) in the 'where allowed to run'
parameter in order to run it.
If your command-running interface is intended to implement a command
line, this may seem very strange, since in command lines, the 'where
allowed to run' option is expected to be allow(*interact). This may
even pose a security issue, if someone deliberately set up a command not
to be allowed interactively, and you've just bypassed that...
If you change the type=2, that will make it work like a command line,
and *INTERACT will be expected instead.
But, then of course, the user must not be set up as 'limited user'...
i.e. must have access to run commands. So in this scenario, you could
have the opposite, if you are expecting to make this command run as it
would from a program, and you used type=2, it might deny users access to
run it.
So... that's the caveat, you need to make sure you're using the right
'type' value for the type of interface you are expecting.
(You probably know all of this already, but wanted to bring it up in
case you hadn't thought of it..)
On 2/19/2014 5:57 PM, James H. H. Lampert wrote:
On 2/19/14 2:20 PM, Carel wrote:
You must SNDPGMMSG (type *RQS IIRC) and RTVPGMMSG the complete command
string instantaneously within the embedding programme.
Thanks, Carel. That bit of wisdom prompted me to find an online example
(by no less than Scott Klement!) that is almost exactly what I was after
(including, Chuck, the use of QCAPCMD instead of QCMDEXC).
--
JHHL
midrange.com
