Re: How to determine if program is running in QSHELL

One possibility is to use the QWVRCSTK API to examine the stack. I put a
sample pgm at:

http://code.midrange.com/753eeb41b7.html

It looks for a pgm/srvpgm in the QSHELL library. If you think there's a
possibility a pgm in QSHELL could be in the stack without actually
running in the QSHELL environment (I don't know whether that's
possible), you could look for something more specific in the stack.
When run in V5R3M0, the stack looked like this:

Lib Pgm Module Function
QSYS QP0ZPCPN QP0ZPCPN Qp0zNewProcess
QSHELL QZSHCHLD QZSHCHLD _CXX_PEP__Fv
QSHELL QZSHCHLD QZSHCHLD main
QSHELL QZSHSRV1 QZSHMAIN QzshChildMain
QSHELL QZSHSRV1 QZSHEVAL evalcmdpart2__FP4nodei
P7backcmd8cmdentryT2PPc7arglist
QSHELL QZSHSRV1 QZSHEXEC shellexec__FPcPPcT2
QSYS QP0ZEXEC QP0ZEXEC Qp0zExecve
QSYS QP0ZEXEC QP0ZEXECUT run__14Qp0zExecutableFv
DAVEM WORKCLE WORKCLE _C_pep
DAVEM WORKCLE WORKCLE main

--Dave

Simon Coulter wrote:

On 24/09/2009, at 9:15 PM, Dennis Lovelady wrote:

Answering my own question... if you did call the program from a
script, and
then (from your program) checked the parent process, you should find
that
the parent process is that script. If it's not that script, then it's
either a CALL command or someone is violating your protocol. Right?

True, but then I'm forcing somewhat unnecessary behaviour by requiring
a script that does nothing other than invoke a program. It's a bit
like sticking a CLP between a CMD and HLL for no reason other than
that's how we usually do it. The HLL could be the CPP for the CMD. It
doesn't need any CL glue. Same here. The symbolic link can be used to
run the program directly. It doesn't need any script glue.

Also, how would I distinguish between a protocol violation and CALL?
The worst that would happen is messages being sent to the wrong place
but still not the behaviour I desire.

Some background:

I'm porting a Unix-y tool to OS/400 (well re-doing something I did
years ago). I really hate the way these open-source tools presume
English by embedding error message text etc. in the program code
(don't they know ANYTHING about software development?). I also LOATHE
the way most Unix-y ports end up running within QSH or PASE instead of
as a native application. I also hate the way they print error text to
STDOUT or STDERR from anywhere within the code. While this sort of
output to a terminal makes sense in their original environment it
doesn't make sense to splatter them willy-nilly through-out the code.
Better would be an error function that received a message ID (or array
element reference) and the error function would print the error. At
least that way other platforms would only have to change the one
function to send the message to a different output.

What I have done is extract all the message text and stick it in a
message catalogue. A proper OS/400 message file would be better but
that's simply to much work (deciding which messages are *DIAG, *INFO,
*COMP, *ESCAPE, etc. and writing second-level text where that concept
simply doesn't exist) and too invasive to the existing code. I'll
modify the existing code to fetch message text from the message
catalogue. Then if it's running in QSHELL I'll just use the existing
fprintf etc. methods to display that text. If it's not running in
QSHELL then I'll use Qp0zLprintf to send the message to the job log.
If some problem occurs retrieving from the message catalogue (or a
national language variant doesn't exist) then I'll send the default
English text.

That seems a reasonable compromise and the code changes will also work
on other platforms that support message catalogues--which seems to be
almost anything with a POSIX-compliant interface.

I just wondered if someone brighter than me had a better alternative
than my suggested approach.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------