Re: Using FTP to transmit a file in the IFS

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
occurred
2) You can't try to check for errors till the script has completed.

<<SNIP>>

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 ACTGRP(*NEW).

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"