Performance considerations for DDM

These topics provide information to help you improve performance when using DDM and also provide some information about when to use something other than DDM to accomplish some functions.

When a DDM file is specified on the CPYF command, optimal performance is obtained if the following items are all true:
- The from-file is a logical or physical file and the to-file is a physical file.
- FMTOPT is *NONE, *NOCHK, or not specified.
- INCHAR, INCREL, ERRLVL, RCDDMT (*ALL), PRINT(*COPIED), PRINT(*EXCLD), SRCSEQ, TOKEY, SRCOPT, or FROMKEY parameter is not specified.
- The from-file is not overridden with the POS keyword, other than *NONE or *START.
- The to-file is not overridden with INHWRT(*YES).
The Open Query File (OPNQRYF) command uses System/38™ extensions to the DDM architecture. The System/38 DDM architecture extensions minimize DDM system processing time. These extensions are not used when:
- The source server is neither a System/38 nor an iSeries™ server
- The target server is neither a System/38 nor an iSeries server
You can greatly reduce the amount of data transferred between servers if you use query functions such as the iSeries command OPNQRYF OPTIMIZE(*YES). However, for user-written applications, the amount of data exchanged between the servers is larger than that used to communicate using DDM with non-iSeries servers. The additional data provides iSeries extended DDM functions and also reduces source server DDM processing overhead. Using normal read, write, update, add, and delete operations as examples, consider the following items:
- Standard DDM architecture DDM overhead data includes such information as a file identification, operation code, and simple result information. A user program read-by-key operation uses approximately 40 characters of DDM information in addition to the length of the key data. Data returned from the remote server uses approximately 32 characters of DDM information plus the length of the data file record.
- System/38 DDM architecture extensions cause additional data overhead such as record format identification and a major portion of the I/O feedback area information. A user program read-by-key operation uses approximately 60 characters of DDM information in addition to the length of the key data. Data returned from the remote server uses approximately 80 characters of DDM information plus the length of the data file record. Normally, the additional length in data streams is not noticeable. However, as line activity increases, line utilization might peak sooner when using these extended data streams as opposed to standard DDM data streams.
The target DDM job priority is controlled by the job class specified by the associated subsystem description routing entry. The following routing entry is normally the one used for all target (program start request) jobs:
```
ADDRTGE ... PGM(*RTGDTA) ... CMPVAL(PGMEVOKE 29)
```
The subsystems QBASE and QCMN, which are shipped with the iSeries server, have this routing entry.
To have target DDM jobs in a subsystem run at a different priority than other APPC target jobs in the same subsystem, insert the following routing entry with the appropriate sequence number:
```
ADDRTGE SBSD(xxx) SEQNBR(nnn) CMPVAL(QCNTEDDM 37)
        PGM(*RTGDTA) CLS(uuu)
```
The class uuu is used to determine target job priority.
To display records in a remote file, display station pass-through should be used whenever possible. Otherwise, direct record positioning should be used with the Display Physical File Member (DSPPFM) command.
If a DDM user exit security program is a CL program and it creates an i5/OS™ exception and an inquiry message that requires the target system operator to respond, both the user exit program and the source server job must wait for the response. Consider using the default system reply list by specifying INQMSGRPY(*SYSRPYL) for the TDDM job's description specified on the Add Communications Entry (ADDCMNE) command for that APPC remote location information.
The WAIT and WAITFILE parameters, used on commands like Allocate Object (ALCOBJ) or Receive Message (RCVMSG), have no effect on the source server program. These parameters function the same as they do when local files are accessed. The wait time values specified on commands run on the source server do not take effect on the source system; they affect only the target server and only if it is an iSeries server or a System/38.
Notes:
1. The WAITFILE parameter of the create or change i5/OS-Intersystems Communications Function (ICF) file command determines how long the APPC support will wait for session resources to become available when doing an acquire operation or a start function. The WAITFILE value is not used for sessions where the connection to the adjacent server is over a switched connection. An example is an SDLC switched line, an X.25 SVC line, an Ethernet line, or a token-ring connection. Using a switched connection, acquire operations and start functions do not time out.
2. Because APPN sessions might cross multiple servers and lines to reach the remote server, the WAITFILE timer should be adjusted to allow more time in these cases. You should not specify *IMMED for the WAITFILE parameter if your application is running in a network configured to use APPN functions. The value you specify for this parameter is dependent on the size and type of the network.
As for any LU session type 6.2 data exchange, certain SNA parameters can affect performance. These parameters include the path information unit size (MAXFRAME), the request/response unit size (MAXLENRU), SNA pacing (INPACING, OUTPACING), and for X.25, packet size and window size. In general, the larger the value used, the better the realized performance.
SNA path information unit size
The path information unit (PIU) is the size of the actual data transmission block between two servers. The MAXFRAME parameter on the Create Controller Description (APPC) (CRTCTLAPPC) or Create Controller Description (SNA Host) (CRTCTLHOST) command specifies the path information unit size the local server attempts to use. During session establishment, both servers determine which size is used, and it is always the smaller value. Other remote servers might have different PIU size considerations.
SNA response/request unit size
The response/request unit (RU) size (CRTMODD MAXLENRU) controls the amount of server buffering before fitting that data into the path information unit that is actually transmitted. In APPC, the transmit and receive RU lengths are negotiated during session establishment. Again, the negotiation results in the smallest value being used. Other remote servers have different RU size considerations.
SNA pacing values
The pacing value determines how many request/response units (RUs) can be received or sent before a response is required indicating buffer storage is available for more transmissions. During session establishment, both servers determine which size is used, and it is always the smaller value.

In cases where both batch and interactive processing occur at the same time on the same communications line, iSeries job priority might be used to favor interactive processing over batch processing. In addition, reducing the value of pacing for a batch application and raising it for an interactive application might be necessary to provide a level of line activity priority for the interactive application.

On an iSeries server, different pacing values can be specified through the creation of different MODES (Create Mode Description [CRTMODD] command) to the different applications. Other remote systems have different SNA pacing value considerations.
X.25 packet
An X.25 packet smaller than the MAXFRAME value adds data transmission time over a non-X.25 data link. In general, for X.25, the longer the MAXFRAME and the actual amount of data being transmitted, the greater this difference is. In the case of DDM, which adds DDM control information to the normal file record data, the packet size has an additional effect on the difference between local and remote file processing and between non-X.25 and X.25 data links.

In cases of many deblocked DDM operations, the number of packets required to transmit data might become so high that packet processing overhead within the X.25 adapter affects performance significantly. Use the largest X.25 packet window size supported by the network and communicating products to maximize performance.

When X.25 must be used to access remote files, successive transmission of many small deblocked records, such as less than 80 character records, might cause the X.25 adapter to expend a disproportionate amount of time processing X.25 packet characters as opposed to transmission of user data.

In general, the overhead in processing X.25 packets results in less throughput than the use of a conventional line when identical line speeds are used and data transfer is in only one direction. When data is transferred at the same time in both directions, the advantages of X.25 duplex support is realized. On the System/38, the overall processing effect is minimal, because the overhead in processing the packets is done within the Integrated X.25 Adapter.

In general, the processing of remote files by using DDM is transparent to an application program or utility function, such as that provided by the Copy File (CPYF) command. However, additional time is required when accessing remote files by using a communications line. The performance difference between local file and remote file processing is proportional to the number of accesses to remote files, the data record length, and the line speed during a unit of performance measurement.

An additional difference between local and remote file processing is that the input or output operation to a local file might not result in an immediate physical disk operation because the server transfers blocks of data from the disk and writes blocks of data to the disk. There are times, then, that the user program accesses data within main storage and the physical I/O occurs at a different time. Therefore, to minimize the difference between local file and remote file performance, it is essential that knowledge of an application design and the amount and type of accesses to files be considered when determining which files are to be accessed remotely using DDM.

The additional time for each remote access is comprised of:

Additional system processing to convert local server file interfaces to the DDM architecture interfaces
Amount of data transmitted over the communications line
Amount of remote system processing of the file operations
Speed of the communications line

The communications line time accounts for most of the additional time, though the actual time is dependent on line speed and the amount of line activity during the DDM function.

As is true in non-DDM cases, local and remote server job priorities have the most significant effect on performance. On an iSeries server, the PRIORITY and TIME SLICE values of the class being used control job priority. The SDDM runs under the source job, and the TDDM runs under the class assigned to the APPC routing entry of the target server's subsystem. In applications that access multiple files, the best results are achieved when the most heavily accessed files are on the same server as the program that is running and the less heavily accessed files are on a remote server. Key considerations regarding the placement of files and application programs follow:

The system having primary responsibility for file maintenance needs to be identified. In all cases of multiple servers applications, the best performance results if only one server is responsible for file maintenance. If an application program maintains the file through exclusive (nonshared) processing, best performance can be realized when the application program resides on the system with the file.
In some cases, transmitting the file back to the local server might require:
- An APPC program.
- A program using remote DDM files.
- The Copy File (CPYF) command by using DDM.
- Object distribution SNDNETF and RCVNETF operations. In interactive applications, display station pass-through should be considered when the amount of display data transferred is significantly less than the amount of database file data that would be sent by using DDM.
In cases where file placement requires movement of application processing to a remote server for best performance results, use of the Submit Remote Command (SBMRMTCMD) command should be considered. This works best in a batch processing input stream where each program waits for the preceding program to complete. The use of the SBMRMTCMD command is valid only when the source and target servers are iSeries servers or Systems/38s. For example, assume that program A accesses local files. Program A would run on a local server. Program B accesses remote files. You can use the SBMRMTCMD command to run program B on the remote server.
In cases where file maintenance is shared across servers, the best performance can be obtained if the file is placed on the server with the largest percentage of file update, add, and delete operations.
In certain cases, a pair of source and target APPC programs can provide performance improvements over DDM. For example, assume 10 records are to be retrieved from the remote server. When DDM is used and record blocking cannot be used (for example, user program random input operation, sequential input for change, or use of the OVRDBF SEQONLY[*NO] command), assume 10 data transmissions are sent and 10 are received, for a total of 20 transmissions. User-written APPC programs can build additional intelligence into the data stream such that request for the data and receipt of the data can be done in two data transmissions instead of 20, one request for all records of customer 00010 and one response containing 10 records for customer 00010.

Consider two sample application processing techniques, batch file processing and interactive file processing.