Manycom Message
FTP Client Automation
FTP Server Automation
Manycom Solutions

Home > Products > Manycom Message > FTP Client Automation > Technical Description


FTP Client Automation Module Description

Introduction | Benefits | Technical Description | Cases and References | System Requirements | Prices | Availability and Support | Manuals and Documentation | License and Maintenance Agreements

Technical Description

FTP Client Automation is 'built over' the FTP client feature of the OS/400. It provides a parameterised way to describe and execute automatically FTP file transfer transactions and the related pre- and post-processes.

FTP CA together with the FTP client feature of the OS/400 operates always in the client mode communicating with the FTP server application. FTP CA is the client, which establishes the connection and requests the services via the FTP subcommands (e.g. PUT, GET, DIR, RENAME, DELETE, etc.) from the FTP server.

FTP server typically resides in another system 'behind' the configured TCP/IP connection. The IP addresses of the FTP servers and FTP user IDs and passwords are the only communication related settings defined in the FTP CA configuration. Line resources, routes and other technical settings are defined in the ordinary manner. See the CFGTCP command of the OS/400 for more information.

Notice, that if the partner system is to establish the connection to your AS/400 and will request FTP services from your AS/400, then your system must operate as an FTP server. You have to start the OS/400 FTP server feature, and the other system is the FTP client. Since activation of the OS/400 FTP server brings great security risks, you should use the MCM FTP Server Automation module to secure the use of the FTP server. FTP SA also allows automating the pre- and post-processes.

Transfer jobs

In order to send or receive one or multiple files, you need to define and create a MCM transfer job (request). MCM Base saves the transfer job in the MCM transfer directory in a server specific queue.

Manycom transfer jobs can be created both from 5250 terminals via the MCM user interface, and from user applications (batch or interactive) via the MCM FTP Client API. Transfer jobs can also be created automatically by allowing the Advanced Automation module polling the desire libraries, directories and output queues to find the desired files to send out. For more information how to find out the files and decide the parameter values for the transfer job request to create, see the Advanced Automation module description.

The general structure of a transfer job is presented in the MCM Base module description. Notice, that each script files attached to the transfer job can include:

  • CL commands for the local AS/400
  • remote commands given as FTP subcommands to be executed in the FTP server
  • FTP subcommands supported by the OS/400 FTP client
  • special Manycom script functions

This job structure is very flexible allowing changing settings and starting the desired processes in any phase of the transfer job.

CL and FTP remote commands can be included in the script files to start the pre- and post-processes in the local and remote systems. The local processes can be started (or woken up) also by creating data queue entries during the execution of the scripts. The entries can be used to deliver the names of the transferred files and libraries.

RFC return codes and ways to control the transfer jobs

FTP CA collects the 'standard' RFC return codes provided by the FTP client feature of OS/400 in a special log file, and compares the return codes to the return code values of the code set, which you have defined for the server. You can create separate return code sets for different servers.

This allows defining separately for each FTP server, which FTP subcommand operations (PUT, GET, RENAME, etc.) are controlled, and which are not. You can also define, which return code values are acceptable and which are not for each FTP subcommand. Additionally, you can define your own return codes to be able to control the possible 'non-standard' and 'alias' return code values used by some FTP server implementations.

FTP CA uses also it's own internal controls to decide when the transfer job operation is successful and when not. This includes controlling the execution of the pre- and post-processes, when possible. When an error situation is encountered, FTP CA gives the transfer job an error status, and automatically retries to execute the job the number of times defined for the job after waiting the defined time-interval.

FTP Client API

When you want to create a FTP transfer job from an application, you call the FTP Client API. The FTP Client API consists of a CL command with a parameter list. Parameters contain the data needed for the execution and control of the transfer job. The parameters define for example the name of the FTP server, message type, local and remote file names, local and remote libraries or directories, scheduling data, priority of the job in the server specific queue, etc.

FTP Client API programs check the values of the parameters, and if valid, select the proper pre-created and pre-configured script files. The selection of the script files depends on the entered FTP server, MCM userid or application id requesting the creation of the transfer job, and on the transfer direction (send/receive) and message type of each file.

If the script files corresponding to the requested parameters are found, and the application is allowed to create this job, FTP Client API creates the transfer job entry in the Manycom transfer directory, and returns an ok '000' return code and the unique job ID to the application. Otherwise, an error code and message is returned to the requestor.

The Manycom monitor programs watch the transfer jobs waiting for the execution, and start them as batch jobs at the scheduled times.

Manycom script functions

Manycom script functions have a very important role in FTP automation. They make possible several operations, which are not supported by the FTP client subcommands of the OS/400, and which are necessary when implementing FTP automation in 'real business life'. One of the most important Manycom script functions is the flexible and extensive renaming functions for the local and remote file names.

Other important script functions are the local and remote list (or directory) operations, DIR and LS, which support also the generic file names (e.g. abc*). The consecutive PUT, GET, RENAME and DELETE operations can be executed for each file in the list. Notice, that a status code and log entries will be maintained separately for each transferred file of the transfer job.

Renaming and deleting files

Manycom script language consists of the possibility to rename files in many ways. For example, you can:

  • Append or override prefix characters in front of the base file name, suffix characters in the end of the base file name, or trailing characters after a period is added to the base file name.
  • Append or override a serial number as prefix, suffix or trailing characters.
  • The serial number can be selected from a set of serials with different lengths (1-7 numbers), which makes it possible to use simultaneously different serials e.g. when communicating with different remote systems. FTP CA automatically creates the new serials, which are referred to in the script files.
  • Replace the local or remote file name with another name.
  • Send the 'local file' into the desired 'remote file' and if the PUT operation is successful, renames it to the original 'local file name'.
  • Files can be deleted and renamed in the local and/or remote systems before and/or after the file transfer, when needed.

Data conversion services of FTP CA

FTP CA allows specifying character code conversion tables (e.g. from EBCDIC to ASCII and vice versa) separately for each defined FTP server name. Each physical system can be 'seen' and configured as several different logical FTP servers, if needed, so that different files can be converted through different tables. The conversion tables are used in text mode transfer. Binary mode transfer (no data conversion) is also supported.

For more advanced data file conversion services, see the Data File Conversion module description, which allows to pre- and post-process the data file conversions before and after the FTP file transfer.

Top of the page