I have created a new command called AUTOFTP that can reduce the main security exposure otherwise present when simply batching together FTP scripts (FTP input read by a CL). The command allows the processing of FTP input scripts to be further automated and scheduled (without the standard AS/400 scheduler) and provides a number of clear benefits.
There are two fundamental components to this command. The AUTOFTP and RUNSQL commands. RUNSQL is completely independent from AUTOFTP but is required by AUTOFTP. In brief, RUNSQL is a freeware command available from the AS400 Network Web site (code also included at end of this section). It allows you to run any SQL statement (even without the SQL development kit) either from the command line or from a CL with the added benefit of being able to pass variables to the statement (not possible with standard AS/400 command RUNSQLSTM). Therefore, any SQL statement can be constructed by using either simple or complex combinations of fixed parameters and variables as desired.
AUTOFTP is a new command that relies on the RUNSQL command to perform a part of its operation. (It's used to temporarily store the password entered in the input script.) AUTOFTP is a generic mechanism for running FTP input scripts between AS/400s. This is because it asks for the script location and member among other things, like username, password and target system. It also offers batch mode by way of the AUTOFTPBCH command. It does not require the use of the AS/400 job scheduler, though it can still used. One of the principal disadvantages on the AS/400 scheduler is that it does not hide passwords entered as part of the scheduled command. Instead, the built-in basic scheduling capabilities of the AUTOFTP command will hide the password. Even on the command prompt it will not be visible.
My initial intention when writing AUTOFTP was to prompt the user for enough information, including where to find an FTP input script, username and password, and then perform the transfer without the need to have the password stored in a CL or script permanently. The idea also meant that a separate CL was not needed to read the input scripts and then perform the FTP transfer, etc., because all was done by the AUTOFTP command. Three further developments have since been added to the command.
- To provide FTP transfer capability from the AS/400 to NT by allowing longer target system names to be specified and the same for usernames and passwords (up to 15 characters) on the command prompt. Also, to request the domain name because this is needed as a prefix to the username during login on NT. The trick that the command performs is to take the domain name and/or username/password you enter and for the duration of the transfer, store them on the fist line of the input script (which should be reserved for this purpose) to be used for login prior to transfer. Then upon completion remove them from the script leaving no ongoing trace.
- To allow batch or interactive modes to be selected. Interactive is simpler but results in the screen being tied up during transfer. However, this does not produce a full job log and requires you to press "enter" in the FTP session window upon completion. In this mode, the FTP session window is basically your job log and will be lost upon completion. Therefore, batch is more useful if you always want a job log created in addition to the FTP session log, which is generated in both modes.
- To provide some basic scheduling capabilities so that for regular transfers (i.e. daily) there is no need to manually initiate the command (since the username and password is always required). This way the password can be recycled each time the transfer takes place without being seen in any job logs. The command AUTOFTP prompts you for all the information it needs and if batch mode is selected, further features are available (i.e., indicating that the transfer is "recurring" and then you indicate which days to run on and the time etc). In this mode, the command submits a controlling job (another command called AUTOFTPSCH, which receives all the information you entered from the AUTOFTP command).
The submitted AUTOFTPSCH batch job now knows when to perform the transfer you requested. What it will do is submit a transfer job AUTOFTPBCH to run the first time (immediately, if you did not specify a date and time or at the date/time you specified) and in the job queue you specified. Then, if "recurring" was specified, the controlling job AUTOFTPSCH will then continue to run (looping every 60 seconds) and waits until the day/time specified under "recurring" arrives before submitting the transfer job again AUTOFTPBCH, and so on. The controlling job does not run in the job queue that you specified; it runs in your default job queue/sub system (as specified in your default job description -- perhaps QBATCH). The transfer job will run in the job queue you specified.
There are a few considerations when using AUTOFTP you should be aware of because unfortunately FTP always requires a password. (At least you should always want FTP to want a password!). The problem is that it is not possible (to my knowledge) to store and use a hidden or encrypted password and use it with FTP. The question is all about striking the right balance between automation and security and taking into account what the alternatives are. With this method, there is no security exposure while the controlling job is waiting for the scheduled day/date/time to arrive. It is from moment of transfer job submission to transfer completion. The reason is that if the transfer job is submitted into a job queue that is held, then the username and password has already been placed inside the input script file. Hence, even if the transfer takes only minutes or seconds, the queue could be held for hours -- perhaps as part of a night job workflow -- resulting in a vastly increased security exposure period.
There is a subtle reason why the username and password must be placed inside the script file at the time of transfer job submission by the controlling job and not during transfer execution. To place the username and password in the input script at transfer time would require the transfer job to perform the placement task and that means the username and password would need to be passed by the controlling job during submission. If the job queue is held, the password becomes visible when you display the transfer job's log. This method is safer and avoids that problem.
Incidental note: The commands AUTOFTPBCH and AUTOFTPSCH are not designed to be run from the command line like AUTOFTP. They are designed to be run behind the scenes if batch mode is selected receiving the appropriate parameters already entered.
This mechanism can be used generically for any script recognized by FTP and can be used for data warehouse transfers on NT. For transfers to NT, you will be prompted for the domain name because this is required as a prefix to the password (i.e., DOMAINusername password) as opposed to AS/400 transfers (i.e., username password).
Code for "Run FTP Script Command (AUTOFTP)"
All source code and instructions are available from Philip Howells (via *SAVF email attachment) by dropping him a line at Philip Howells.
==================================
MORE INFORMATION ON THIS TOPIC
==================================
