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 these categories:

• IBM i 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 client and server systems are running System/38 or IBM i.
• Restrictions and considerations that apply when the client or server system is running IBM i.
• Restrictions and considerations that apply to all target systems. 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 system 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 client and server systems to detect the stopping of polling by the primary system. This prevents the possibility of a DDM read-for-update record lock lasting indefinitely due to a communications failure on the primary system.