That's an interesting concept...

But given it's assumptions and reliance on undocumented implementation
details, I think my assertions on the limitations of the built in FTP
client are valid for us mere mortals. :)


On Tue, Jul 15, 2014 at 5:29 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 15-Jul-2014 11:56 -0500, Charles Wilt wrote:

<<SNIP>> trying to script the built in <ed: FTP> client,

1) It's difficult if not impossible to always know an error has

2) You can't try to check for errors till the script has completed.


FWiW: The FTP subcommand SYSCMD allows calling a program inline to the
scripted requests, such that a called program could perform the oft
described-as /nigh to impossible task/ of error checking, at any point the
System Command (SYSCMD) request was coded into the script. And in response
to an error being found when that program has parsed the OUTPUT, such a
program could even issue an End Request (ENDRQS) to terminate the FTP
client. Or depending on how [or the level of control available to enforce
how] the read of INPUT is effected by the FTP client [an implementation
detail subject to change], the called program could even effect modifying
the remainder of the script [if that program determined or was aware of
what was the INPUT]; the program could change the Source Data (SRCDTA) of
the next RRN of the INPUT to become the QUIT FTP subcommand.

I know these techniques worked in the v4 and v5 time-frame. I had long
ago written some code, first as Proof Of Concept (POC), to do just that;
IIRC the code /assumed/ the override to INPUT had included the SEQONLY(*YES
1) to ensure, given the implementation for the FTP client /read/ support at
that time, a sequential un-buffered read method. That code included both
updating the OUTPUT records [of a PF-SRC] to indicate which line number of
the INPUT provided the subcommand and updates to the Source Date (SRCDAT)
of each record. For just a few administrative tasks, I actually used that
code; given how many times the FTP client had changed something with its
implementation in the past however, and how typically processing of output
scripts can have limitations similar to screen-scraping, I was not
confident that something might not change to cause my code to no longer
function properly [without any means available to overcome the issue]. As
I recall, at some point I even improved the code, something with regard to
taking advantage of the fact that the FTP client had changed to run in

The same technique [including assumptions about implementation] also
allows for creating a partial INPUT script, into which additional requests
could be dynamically appended, or even a [user name and\or] password could
be dynamically set [in lines using the FTP subcommands USER and\or PASS].
For example, additional PUT requests could be generated from data that was
produced by an earlier DIR request that had been directed the directory
listing to an output file; i.e. either a request to "DIR (DISK" or IMO the
less desirable output from "LS (DISK"

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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

Return to Archive home page | Return to MIDRANGE.COM home page