Rob,
Ok, I found the thread here:
http://archive.midrange.com/midrange-l/200912/msg00488.html
Let me show that post here, as I believe it does explain it a lot better
than I can (or ever could :-) :
(in a thread regarding qsh's grep)
-----------------------------------------------
Hello Luis,
" I believe that QSH has its own QTEMP, separate from the one your job
uses."
That's more or less true.
Basically, when you run grep, it's running at the same time as your job. So
if you're reading the output of 'grep', you're reading it real-time as it's
happening.
This is more important if you're doing something like this:
QSH CMD('ls | grep blah')
In this example, the output of 'ls' is being read by 'grep'. These two
things run simultaneously... the ls and the grep programs are running
concurrently, which greatly improves performance not to mention memory
usage. (If they didn't run concurrently, the output of 'ls' would have to
be saved into a buffer somewhere so it could be processed by grep
separately, that buffer could potentially be hundreds of megabytes long...)
Likewise, the output from grep is being displayed concurrently on your
screen if you're running it interactively. (Or if you're reading the output
directly in a program -- though, since you're running this from CL, you
probably aren't)
To enable that concurrency, they are running in separate jobs. the 'ls' is
running in one job, the 'grep' in another, and your program in a 3rd job.
That's how QShell (and indeed, all Unix environments) work.
Therefore, QTEMP and QShell don't play well together. If you want to use
QTEMP you have to make sure it's being used by your CL program so that it
runs inside the same job. If QTEMP is being used by the background
components of QSH (in my example, the 'ls' and the 'grep', or in Alan's
example, the 'db2' and the 'grep') they will have a separate QTEMP from
your CL program.
-----------------------------------------------
HTH,
Luis
Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
midrange.com
