hi Rob,
On 12/20/2011 4:15 PM, rob@xxxxxxxxx wrote:
[SNIP]
And now it pauses at the "Press ENTER to end terminal session.". I
wouldn't mind seeing the rest of the terminal session data, I just want to
eliminate that pause.
The problem is simple: Without that pause (unless your program is
long-running) you won't see the text on the screen. It'd flash for an
instant, and then be gone.
Unlike a Unix terminal, where the text would remain on the display after
the program is done, QShell switches back to 5250 mode after running the
command, and the output would be lost.
The pause makes sure the user can see it.
That's just the default behavior, of course -- and I think IBM made the
right choice, there. You want the default to be that the user sees the
output. Good job, IBM.
You can control this behavior with the QIBM_QSH_CMD_OUTPUT variable,
which brings me to another part of your message:
I read something about the following:
ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) VALUE(NONE)
MONMSG MSGID(CPFA980) EXEC(DO)
CHGENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) VALUE(NONE)
ENDDO
A simpler solution is to use REPLACE(*YES)... that eliminates the need
to do the MONMSG and CHGENVVAR.
ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) VALUE(whatever) +
REPLACE(*YES)
You were using VALUE(NONE) which means to discard all of the messages,
but that's not the only option. Which brings me to the next part of
your message...
But when I tried that it suppressed everything. Perhaps I can get used to
that. Is that what I should do?
VALUE(NONE) means to discard all output...
You can also do:
VALUE('file=/tmp/robs_qshell_log.txt')
That'll write all of the output to a stream file in the IFS (in this
example, "robs_qshell_log.txt") Each time you run the QSH (or STRQSH)
command, it'll replace the contents of this file with the output from
the QShell session.
Since it replaces the contents each time, you'd only get the output of
the last QSH command you ran -- which isn't always what you want, so
there's a 3rd option:
VALUE('fileappend=/tmp/robs_qshell_log.txt')
Now, instead of replacing the contents of the file, it'll append to it.
So each time you run QSH/STRQSH, the output is added to the end of the
stream file.
From what little I know of your situation, it looks like you are
starting up some background servers (network servers?) that have very
little output, and aren't really interesting to the average user.
So I would consider having it write to a file (as I describe, above)
rather than printing the messages on the screen. That way, if you
discover that something is amiss, a techie can go and look at the file
and see what messages were printed. But, if all is well, nobody needs
to be bothered with it.
Should I be monitoring some other environment variable, message id or
log file generated by the above instead of reading the screen?
Really, all I got when I ran it that way was Command ended normally
with exit status 0. which is QSH0005.
Whenever someone says "all I got was QSH0005, and it didn't say much" I
find myself wondering what they were expecting? Unix systems have
neither a "job log" nor the concept of an *ESCAPE message.
When a Unix program has an error, it does two things:
1) It prints an error message on a screen using the STDERR data stream
(or, sends it to a log file, depending on the application.)
2) -and- it typically sets the exit status to non-zero to notify the
caller (so it can programatically determine that the program failed.)
Since there's no such thing as an *ESCAPE message on Unix you can't
reasonably expect the called program to send you a meaningful *ESCAPE,
can you? But QShell does what it can to help. It sends you a QSH0005
containing the exit status -- you can extract the exit status to
determine if the command set it to a non-zero value.
QShell also has this feature:
ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y) +
REPLACE(*YES)
This means that when a QShell command ends with a non-zero exit status,
the QSH (or STRQSH) command will send the QSH0005 to your CL program as
an *ESCAPE message (by default, it's always a *COMP message). This way,
you can use MONMSG to look for failures -- it'll still just say "command
ended normally with exit status X" but, you'll know that it failed.
A techie can then learn the cause of the failure by looking at
/tmp/robs_qshell_log.txt
Or, perhaps you want to code it like this:
PGM
ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) REPLACE(*YES) +
VALUE('file=/tmp/robs error log.txt')
ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) REPLACE(*YES) +
VALUE(Y)
QSH CMD('your-command-here')
MONMSG MSGID(QSH0005) EXEC(DO)
DSPF STMF('/tmp/robs error log.txt')
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGTYPE(*ESCAPE) +
MSGDTA('GAK! Not Good! It Failed!')
ENDDO
RMVLNK OBJLNK('/tmp/robs error log.txt')
MONMSG CPFA0A9
ENDPGM
So, if it works, the user sees nothing. If it fails, the errors are
displayed for the user, plus the CL program blows up.
Hope that helps.
midrange.com
