Batch file processing with DDM

• When an application opens a local file for sequential input only or output add, the server uses blocking techniques to achieve maximum throughput. To ensure blocking is used for a remote file accessed by using DDM, do not use random record processing operations in the program but specify OVRDBF SEQONLY(*YES) against the DDM files opened by the program.
• Use of read and read-next operations in the high-level language (HLL) program to access the file maximizes the effect of the SEQONLY(*YES) specification.
• The use of random processing operations, such as chain operations of ILE RPG or start operations of ILE COBOL programming language, causes DDM to send deblocked operations across the communications line even if the application processes the file data sequentially. This results in significant differences between local and remote file processing.
• When simple physical file transfer is desired (all records transferred and no application processing of the data), use of DDM by using the Copy File (CPYF) command, or a user-written program using DDM with the Override Database File (OVRDBF) command SEQONLY(*YES number-of-records) specified, transfers the data more quickly than a user-written APPC program. The Copy File command and the DDM SEQONLY(*YES) support require less calls and returns between the program and APPC data management modules than does a standard ILE RPG or ILE COBOL APPC program.
• For ILE RPG or ILE COBOL sequential input-only applications, SEQONLY(*YES) should be specified with no number of records to achieve best throughput. For ILE RPG or ILE COBOL sequential output-only applications to keyed files, a large number-of-records value should be used.
• The Send Network File (SNDNETF) command can be considered as an alternative to DDM or user-written APPC programs when transferring all records within a file to a remote iSeries™ server. The SNDNETF command requires SNADS to be configured on the source and target iSeries server. If one or more intermediate servers are between the source and target iSeries servers, SNADS provides intermediate node routing of the data when correctly configured.
• Use of the SNDNETF command by using SNADS offers the advantages of transmitting one copy of the data to multiple users on one or more target servers through a multiple node network, and the time scheduled transmission of that data by using the SNADS distribution queue parameter.

  However, in addition to requiring SNADS to use the SNDNETF command, the target server user must also run the Receive Network File (RCVNETF) command to make the file usable on the target server. Use of DDM would not require this additional target server processing.

  In general, the file transmission times by using SNADS (user program DDM sequential file processing, the DDM Copy File command, and a user-written APPC program between two iSeries servers) are within 10% of each other. However, the use of the SNDNETF and RCVNETF commands to make a copy of the data usable on the target server does add total processing time over the other methods of file transfer.

• Because the SNDNETF command can transmit objects within a save file, the amount of data that is actually sent by using this technique might be less than that sent using the other techniques. If the database file data sent contains a significant number of duplicate character strings, use of the Save Object (SAVOBJ) command parameter DTACPR(*YES) (data compression) can significantly reduce the amount of data that is actually sent by using a SNADS distribution. However, if there are few duplicate character strings, there is little change in the amount of data sent.
• The iSeries file transfer subroutines might also be used to transfer an entire file between iSeries servers and an iSeries server and a System/36™. These subroutines might be called from high-level language programs, and in some cases throughput is achieved similar to that by using DDM.

See the SNA Distribution Services manual on the V5R1 Supplemental Manuals Web site.