System activities after the distributed file is created

As soon as the file is created, the system ensures that the data is partitioned and that the files remain at concurrent levels.

As soon as the file is created, the following activities occur automatically:

• All indexes created for the file are created on all the nodes.
• Authority chaninformation about using distributed files with DB2® Multisystemges are sent to all nodes.
• The system prevents the file from being moved and prevents its library from being renamed.
• If the file itself is renamed, its new name is reflected on all nodes.
• Several commands, such as Allocate Object (ALCOBJ), Reorganize Physical File Member (RGZPFM), and Start Journal Physical File (STRJRNPF), now affect all of the pieces of the file. This allows you to maintain the concept of a local file when working with partitioned files. See CL commands: Affecting all the pieces of a distributed file with DB2 Multisystem for a complete list of these CL commands.

  You can issue the Allocate Object (ALCOBJ) command from any of the nodes in the node group. This locks all the pieces and ensures the same integrity that is granted when a local file is allocated. All of these actions are handled by the system, which keeps you from having to enter the commands on each node.

  In the case of the Start Journal Physical File (STRJRNPF) command, journaling is started on each system. Therefore, each system must have its own journal and journal receiver. Each system has its own journal entries; recovery using the journal entries must be done on each system individually. The commands to start and end journaling affect all of the systems in the node group simultaneously.

• Several commands, such as Dump Object (DMPOBJ), Save Object (SAVOBJ), and Work with Object Locks (WRKOBJLCK), only affect the piece of the file on the system where the command was issued. See CL Commands: Affecting only local pieces of a distributed file with DB2 Multisystem for a complete list of these CL commands.

As soon as a file is created as a distributed file, the opening of the file results in an opening of the local piece of the file as well as connections being made to all of the remote systems. When the file is created, it can be accessed from any of the systems in the node group. The system also determines which nodes and records it needs to use to complete the file I/O task (GETS, PUTs, and UPDATES, for example). You do not need to physically influence or specify any of this activity.

Note that Distributed Relational Database Architecture™ (DRDA) and distributed data management (DDM) requests can target distributed files. Previously distributed applications that use DRDA or DDM to access a database file on a remote system can continue to work even if that database file was changed to be a distributed file.

You should be aware that the arrival sequence of the records is different for distributed database files than that of a local database file.

Because distributed files are physically distributed across systems, you cannot rely on the arrival sequence or relative record number of the records. With a local database file, the records are dealt with in order. If, for example, you are inserting data into a local database file, the data is inserted starting with the first record and continuing through the last record. All records are inserted in sequential order. Records on an individual node are inserted the same way that records are inserted for a local file.

When data is read from a local database file, the data is read from the first record on through the last record. This is not true for a distributed database file. With a distributed database file, the data is read from the records (first to last record) in the first node, then the second node, and so on. For example, reading to record 27 no longer means that you read to a single record. With a distributed file, each node in the node group can contain its own record 27, none of which is the same.