Hi Chuck
MUCH appreciated for your response
I (hopefully) understand what you are saying about the running interactively versus by submit job
(SBMJOB)
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)
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 2:35 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: floundering with sftp
On 12-Mar-2014 05:28 -0700, Alan Shore wrote:
<<SNIP>>
Scott Klement provided examples of which I used
And presumably, the link to the 20 Apr 2009 08:57 AM post by Scott Klement is the origin:
<
http://forums.iprodeveloper.com/forums/aft/55771>
Here is what I have ended up with
PGM
/* To compile: */
/*> CRTPF QTEMP/LSOUTPUT RCDLEN(1000)<*/
<<SNIP some CLP source declarative>>
DCLF FILE(LSOUTPUT)
<<SNIP some CLP source>>
ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) +
VALUE('FILEAPPEND=/tmp/sftplog.txt') +
REPLACE(*YES)
ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y) +
REPLACE(*YES)
DLTF FILE(QTEMP/LSOUTPUT)
MONMSG MSGID(CPF2105)
CRTPF FILE(QTEMP/LSOUTPUT) RCDLEN(1000)
<<SNIP more source>>
OVRDBF FILE(STDOUT) TOFILE(QTEMP/LSOUTPUT)
/* CHGVAR VAR(&CMD) VALUE(&CMD *TCAT '> +
/qtcptmm/SFTPlogoutput.txt 2>&1') */
CHGVAR VAR(&CMD) VALUE(&CMD *TCAT &NULL)
CALL PGM(QP2SHELL) PARM('/QOpenSys/usr/bin/sh' +
'-c' &CMD)
DLTOVR FILE(STDOUT)
OVRDBF FILE(LSOUTPUT) TOFILE(QTEMP/LSOUTPUT)
DOUNTIL COND(&EOF *EQ '1')
RCVF
<<SNIP more source>>
ENDDO
DLTOVR FILE(LSOUTPUT)
ENDPGM
I have compiled this and run it, but the file QTEMP/LSOUTPUT is empty
How the program source was "compiled" is possibly quite pertinent.
I have also run sftp interactively using the following commands
CALL PGM(QP2TERM)
<<SNIP>>
Having "run it <ed: the CLP>" interactively versus by submit job
(SBMJOB) could explain a difference.
The questions are
what is wrong with my CLP program and
My immediate thought for any similar scenario being described is always the /override scope/, as being a possible origin for the issue.
However if the request is being performed interactively, I would expect the output from the ls request to have appeared at the workstation display. And if batch, then expected instead, to have produced a spool file QPRINT showing the output from the ls request; i.e. assuming a printer file QPRINT is in the *LIBL of the batch job, else the job might effectively /lose/ the output, but an indication as to why the output was lost would be apparent by review of the joblog.
how can I log what happens within sftp
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.
As always - any and all responses gratefully accepted
With regard to override scoping, the OVRSCOPE() should be explicitly specified on the OVRDBF to be functional for any /called/ function; i.e.
the function for which the override must be in effect. While the override for the RCVF need not explicitly have a chosen scope, per being functional as an inline command\statement request no matter the chosen or defaulted scope, the invocation [e.g. by CALL] of another program [e.g. the QP2SHELL] is not implicitly covered by whatever is the defaulted scope. The safest choice is to explicitly code the
OVRSCOPE(*CALLLVL) because the effect should be the same irrespective of the compiler and\or binding; e.g. CRTCLPGM vs CRTBNDCL. The following is also a message from Scott, alluding that using QP2SHELL2 instead of QP2SHELL could also resolve the issue, per the former using
ACTGRP(*CALLER) instead of ACTGRP(*NEW) of the latter:
<
http://archive.midrange.com/midrange-l/200712/msg00288.html>
--
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
