Re: floundering with sftp

On 12-Mar-2014 11:49 -0700, Alan Shore wrote:

I (hopefully) understand what you are saying about the running
interactively versus by submit job (SBMJOB)

Perhaps not. Because I would have expected in that reply, either a confirmation that the "SBMJOB CMD(CALL the_CLP)" was used and either the output was found to be in a QPRINT spool file for that batch job or that the joblog of the batch job confirmed the output was purged [i.e. the implicitly created database file QPRINT in QTEMP was deleted], or an implication that the OP had failed to include any mention that the output from the ls request appeared at the display.

If the override scope is explicit [e.g. OVRSCOPE(*CALLLVL)] or by another means is ensured to be appropriate for the invocation [of either QP2SHELL or QP2SHELL2], then the use of batch versus interactive should be moot. That is, having ensured the Override With Database File (OVRDBF) to the FILE(STDOUT) is in effect for the invoked shell request [i.e. ensuring a properly scoped override], the Standard Output always should be directed consistently to the named TOFILE() [and MBR()] instead of going to the display when run interactively and instead of going to whatever is the available QPRINT when run in batch.

However - you state
"Instead of piping the results of the request directly to grep, log
the output from the request to a file, and then grep the file that
holds that output. The output file can be reviewed after the request
completes."

The question is - how would I do that in the example I included
(forgive me - my mind is just mush with this)

Redirect instead of pipe.

The example is currently; truncating the grep activity, replaced with an ellipsis:

echo "cd DNBT2O/incoming/ATG/ESB/RequestCatalog/feed/\nls" > /tmp/sftpscript.txt && sftp -b /tmp/sftpscript.txt j_nbty@sftp ftpnonprodnbtysldc | grep ...

My alluded change to that, would be something like the following, whereby the grep request must get updated to act on the sftpoutputfile:

echo "cd DNBT2O/incoming/ATG/ESB/RequestCatalog/feed/\nls" > /tmp/sftpscript.txt && sftp -b /tmp/sftpscript.txt j_nbty@sftp ftpnonprodnbtysldc > sftpOutputFile && grep ...

Having redirected the sftp output to the sftpOutpuFile [instead of piping the output to the grep] means that the file by that name [in the current directory] will remain for later access\viewing after the overall request completes, *and* that the file remains available as input to the next request [which is the grep request]. The use of '&' vs '&&' might be a consideration; I chose the '&&' in my revision alluded above.