Thanks Chuck
I will need to look at all of this tomorrow as I have to go to a presentation
MUCH appreciated
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, March 12, 2014 3:58 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
midrange.com
