On 09 Mar 2013 08:41, Eric Lehti wrote:
Issue: Want FTP to run unattended in batch mode, and transmit a
different file name each time.
Do you have a suggestion?
The base code I am working from is :
The published example shows the FTP script of subcommands stored in
a source member in a source physical file, which I edited with SEU.
USER [username] [password]
locsite namefmt 1
The file name BATCHSCRIP.FILE is hard-coded in the source member.
Users want the FTP to run every hour and transmit a different file
name each time.
File name would need to be supplied as a parameter.
Appears to me that I would need to recreate the source member every
hour, changing the put statement with the new file name.
Seems very cumbersome to do it this way.
Is there a better technique for transmitting files whose names
change all the time?
I am not recommending as resolution to do so, but FWiW, with probably
the most minimal of changes if the above example describes the current
implementation, consider the following which allows the FTP script to
Since that example is using /QSYS.LIB database file members for its
data, then changing to use NAMEFMT 0 instead of NAMEFMT 1 [and thus
dropping the ".FILE" on the PUT], what is described can be easily
accomplished with just another override [beyond the overrides to INPUT
and OUTPUT]. The CLP would change to accept the file name as a
parameter, e.g. DCL &FILENAME *CHAR 10, and the CLP would issue the
OVRDBF FILE(BATCHSCRIP) TOFILE(C130308A/&FILENAME) sometime before the
FTP request just like the others. The script does not need to be
updated [nor especially be "recreated"] each time, only the override
changes on each invocation, via the input "supplied as a parameter" by
FWiW I would explicitly code the OVRSCOPE on each OVRDBF and code the
corresponding LVL on the DLTOVR in the example CLP so the code is
unaffected if someone changes the commmand default. And if using
OVRSCOPE(*CALLLVL) or the CLP is OPM, then as long as the override scope
is not *JOB, then the DLTOVR can be removed entirely because the
overrides will disappear implicitly.
As tested on V5R3 the FTP is one of the features that fail to process
overrides [properly] for its object name validation. So unfortunately
the file name represented by the FILE(BATCHSCRIP) has to exist in the
local Current Directory [the .LIB named in the LCD] so the PUT request
can process without giving an error TCP10AB "File BATCHSCRI in library
C130308A not found." Note: that is to suggest that the /validation/
includes, beyond the existence of the *FILE, a test for the existence of
a member *FIRST [per lack of a member specification on the PUT
subcommand] and that includes a test of the authority to the user both
to open and to read that file.mbr [even though the override will cause
the open and read to occur with the overridden-to file.mbr instead].