iSeries server as the source server for DDM

 

When an application program or user in a source server job first refers to a DDM file, several actions occur as part of processing the request on the source server.

All of these actions, as well as those required on the target server, must complete successfully before any operations (file or nonfile) requested by the source program can be done. When the DDM file is referred to:

• If the request is to open a file, its information is used simultaneously to create an open data path (ODP) on the source server and to start the SDDM support, which runs within the same job as the source program. The SDDM also uses the information: to convert the source server request into a DDM request, to communicate with the appropriate target server, and to establish a DDM conversation to be used for the source job. (The ODP is partially created with the DDM file information; it is not usable until the SDDM processes the remaining information after the DDM conversation is established.)

• The communications portion of DDM establishes a communications path with the target server. The target server is identified by using the remote location information specified in the DDM file, and the target file is identified by the remote file name. Other information about e remote location, not kept in the DDM file, is stored by the SDDM. This includes the transaction program name, user ID, activation group number, and scope of the conversation. Using the remote location information, the TDDM is started on the target server and a DDM conversation is established when the remote server receives the program start request. The conversation is established the first time the remote file is accessed, but only if a conversation using the same remote location values for that target server does not already exist for the source job.

• After the DDM conversation is established, the SDDM (which can be used by multiple programs and multiple DDM files in the same source job) sends the DDM architecture command to the TDDM, for file-related requests. This command describes the file operation to be done and contains the name of the remote file (specified in the DDM file) to be accessed. For nonfile-related requests, such as when the Submit Remote Command (SBMRMTCMD) command is used, the remote file name is not sent to the TDDM; the remote file name is ignored.

The SDDM converts each program request for a file open or input/output operation (received by using the DDM file and ODP) into an equivalent DDM command request and then sends it to the target server.

The following figure shows the basic parts on the source iSeries™ server that are involved in accessing remote files. Figure 1. iSeries server as the DDM source server

open data path, SDDM, DDM Communications manager, and the target system are involved in accessing remote files." />

After each request is handled by the target job, the DDM response from the target server is returned, converted by the SDDM into the appropriate form, and passed back to the user. The response might include data (if data was requested) or an indication of status (for other types of file access). The source program waits until the function completes and the results are received.

The following figure shows a simplified example of the interchange of data between the source and target servers for a typical request to access a remote file. Figure 2. Typical handling of an I/O operation request

After the first DDM file that was opened in the job is closed, the DDM conversation that it used is normally kept active. This allows the same program or another program in the job to use the same conversation when opening another DDM file, or doing other DDM-related operations. (For example, in Figure 1, source job 3A has two DDM files using the same conversation.) This saves the time and resources required to establish a new conversation every time a new DDM file that uses the same remote location information is used in that job.

When a DDM file is closed, the DDM conversation remains active, but nothing happens in the conversation until the SDDM processes the next DDM-related request from a program. While it is not being used, however, the conversation can be dropped. This can occur if the DDMCNV job attribute's default value of *KEEP is changed to *DROP using the Change Job (CHGJOB) command, or if the Reclaim DDM Conversations (RCLDDMCNV) command or Reclaim Resources (RCLRSC) command is used while the job is active.

• Integrated Language Environment and DDM
  Integrated Language Environment^® (ILE) introduces the concept of activation groups that run within jobs on the iSeries server.

• Source server actions dependent on type of target server
  If the target server is not another iSeries server or System/38™, only the DDM architecture commands defined in Level 2.0 and earlier of the DDM architecture are used.

 

Parent topic:

Additional DDM concepts

 

Related concepts

Parts of DDM: Source DDM
Use CL and DDS with DDM

 

Related reference

DDMCNV parameter considerations
Control DDM conversations