Temporary result writer job: Disadvantages with DB2^® Multisystem

 

The temporary result writer also has disadvantages that must be considered when you determine its usefulness for queries.

The disadvantages are as follows:

• The temporary result writer is a separate job. Consequently, it can encounter conflicts with the main job. Here are some examples:

  • The main job might have the file locked to itself. In this case, the temporary result writer cannot access the files and cannot complete its query step.

  • The main job might have created the distributed file under commitment control and has not yet committed the create. In this case, the temporary result writer cannot access the file.

• The temporary result writer might encounter a situation that it cannot handle in the same way as the main job. For example, if an inquiry message is signalled, the temporary result writer might cancel, whereas the main job can choose to ignore the message and continue on.

• Temporary result writers are shared by all jobs on the system. If several jobs have requests to the temporary result writers, the requests queue up while the writers attempt to process them.

  The system is shipped with three, active temporary result writer job pairs.

• Attempting to analyze a query (through debug messages, for example) can be complicated if a temporary result writer is involved (because a step of the query is run in a separate job).

The system does not allow the temporary result writer to be used for queries running under commitment control *CS or *ALL. This is because the main job might have records locked in the file, which can cause the temporary result writer to be locked out of these records and not be able to finish.

 

Parent topic:

Temporary result writer with DB2 Multisystem