Program modification requirements for DDM

In most cases, these applications can access both local or remote files without the programs being changed. However, some considerations and restrictions might require the programs to be changed and recompiled. These are grouped in three categories:

• iSeries functions that are not supported by the DDM architecture, but for which a System/38™ extension to the architecture might exist. These functions can be used only when the source and target servers are System/38s or iSeries servers.
• Restrictions and considerations that apply when the source or target server is an iSeries server.
• Restrictions and considerations that apply to all target servers (iSeries servers and non-iSeries servers). User programs accessing local files should program for abnormal conditions such as No record found, End of file, and Record lock time-out on read for update. These conditions can also occur when a remote file is being accessed using DDM. In addition, the use of DDM exposes the program to communication line failures while sending disk I/O operations.

  When a communications failure occurs, the server sends an appropriate message to the job, which is returned to the application program as a generic file error. Each high-level language provides unique user syntax capabilities for user-controlled handling or default processing of exceptional results of a disk operation. Some languages might permit the user to retrieve the job message identification (ID) that would specifically indicate a DDM communications failure. Refer to the appropriate language manual for specific capabilities.

  For secondary SDLC lines, it is recommended that the INACTTMR parameter of the Create Line Description (SDLC) (CRTLINSDLC) command be set on the source and target servers to detect the stopping of polling by the primary server. This prevents the possibility of a DDM read-for-update record lock lasting indefinitely due to a communications failure on the primary server.