Asynchronous job usage parameter with DB2^® Multisystem

 

You can use the asynchronous job usage (ASYNCJ) parameter to control the usage of the temporary result writer.

The ASYNCJ parameter has the following options:

• *ANY—allows the temporary result writer jobs to be used for database queries involving distributed files.

• *DIST—allows the temporary result writer jobs to be used for database queries involving distributed files.

• *LOCAL—allows the temporary result writer jobs to be used for queries of local files only. Although this option is allowed, currently there is no system support for using temporary result writers for local query processing. *LOCAL was added to disable the temporary result writer for distributed queries, yet still allow communications to be performed asynchronously.

• *NONE—never use the temporary result writer. In addition, when distributed processing is performed, communications are performed synchronously. This can be very useful when analyzing queries, because it allows query debug messages from remote systems to be returned to the local system.

The following example shows you how to disable asynchronous job usage for distributed file processing:

CHGQRYA ASYNCJ(*LOCAL)

This command prevents asynchronous jobs from being used for queries involving distributed files. The following example shows you how to completely disable asynchronous job usage:

CHGQRYA ASYNCJ(*NONE)

This command prevents asynchronous jobs from being used for any queries. In addition, for queries involving distributed files, communications to remote systems are done in a synchronous fashion. The following example shows you how to use the CHGQRYA command in combination with the Start Debug (STRDBG) command to analyze a distributed query:

STRDBG UPDPROD(*YES)
CHGQRYA ASYNCJ(*NONE)
STRSQL        SELECT COUNT(*) FROM EMPLOYEE A

The following debug messages are put into the job log:

        Current connection is to relational database SYSA.
        DDM job started.
        Optimizer debug messages for distributed query step 1 of 2 follow:         Temporary distributed result file *QQTDF0001 built for query.
        Following messages created on target system SYSB.
        Arrival sequence access was used for file EMPLOYEE.
        Arrival sequence access was used for file EMPLOYEE.
        Optimizer debug messages for distributed query step 2 of 2 follow:         Arrival sequence access was used for file EMPLOYEE.
        ODP created.
        Blocking used for query.

 

Parent topic:

Changes to the Change Query Attributes command with DB2 Multisystem