Commands (YPOPWSIPDD - Y2CALL) › YSTRCHGCTL (Start Change Control) Command › Example

Example

To start change control in model library J4DEVMDL, setting all objects to *DEV and removing any permanent locks:

YSTRCHGCTL SETVSNTYP(*DEV) RMVLCK(*YES )

YSTRTRGSVR (Start Trigger Server) Command

The YSTRTRGSVR command allows you to start one or more Trigger Server jobs to monitor a Trigger Data Queue. Trigger Data Queues are used to provide asynchronous trigger support, allowing Trigger Functions to be run within a separate job to the one that actually caused the trigger to fire.

When a trigger fires due to a database file change and the trigger program is specified as the CA 2E Trigger Router, the Trigger Router will check in the Trigger Control file for any Trigger Functions specified for the trigger. If any are found, they will either be called directly or an entry will be added to the Trigger Data Queue, containing all the data related to the trigger. This entry will then be processed by a Trigger Server job, which will itself call the Trigger Function directly.

This allows potentially long-running Trigger Function processing to be 'off-loaded' to another job from the one that made the database change which caused the trigger to be fired, thus ensuring that the application program can continue without having to wait for all processing to finish.

Some examples of long-running processing contained in a Trigger Function which you may want to be processed asynchronously are:

• Processing which involves printing
• Processing which involves possible object allocation contention
• Processing which involves accessing resources external to the iSeries on which the database transaction is occurring
• Processing which involves the invoking of a web service or similar function

When a Trigger Function is processed asynchronously, there is no way for the Trigger Function to signal to IBM i or to the application program if errors occur. Thus the asynchronous processing of Trigger Functions is not recommended where errors in the Trigger Function would require the database change to be canceled.

Note: Trigger Data Queues are always called YTRIGGERQ. If a Trigger Data Queue does not exist in the library specified in the TRGLIB parameter, one will be created. Trigger Data Queues are unkeyed data queues with a maximum entry length of 32859.

Parameters

The following are parameters for the YSTRTRGSVR command.

TRGLIB

Specifies the name of the library containing the Trigger Data Queue. If a Trigger Data Queue does not exist in the specified library, one is created.

The values are:

*TRGLIB

The library containing the Trigger Server program is used.

library-name

Specify the library name which contains the Trigger Data Queue to be monitored.

JOBD

Specifies the job description that should be used for the Trigger Server job or jobs.

Note: A Trigger Server runs as a continuous batch process until you end it with the End Trigger Server (YENDTRGSVR) command. Due to this, the processor overrides your job description with the system-generated JOBQ(QSYS/QSYSNOMAX). This ensures that the Trigger Server is submitted using a job queue that which multiple active jobs. All other job definition attributes are taken from the job description specified in this parameter.

The values are:

*USRPRF

The trigger server job uses the job description for the user profile used by the job that is currently running.

job-description-name

Specify the name (library-name/job-description-name) of the job description used for the trigger server job.

NBRSVR

Specifies the number of Trigger Server jobs that should be started by this command. All Trigger Server jobs use the same job description, as specified in the JOBD parameter. All jobs monitor the same Trigger Data Queue in the library you specify in the TRGLIB parameter.

The Trigger Data Queue is a FIFO (first-in, first-out) data queue. If multiple Trigger Server jobs are running concurrently, each trigger request is selected from the Trigger Data Queue by the first available Trigger Server job. There is no guarantee of the trigger request processing order, since this depends on many factors affecting the speed at which each Trigger Server job runs. If you must process trigger requests in the same order as the original trigger fired, you have two options:

• Process the trigger requests synchronously as a direct call by the Trigger Router
• Ensure that only a single Trigger Server job monitors a specified Trigger Data Queue.

Note: Running more than one Trigger Server job concurrently can improve system performance where many asynchronous trigger requests may appear at once. However, it will not affect the performance of the job in which the trigger was fired.

Values are:

*DFT

A single Trigger Server job is started to monitor the Trigger Data Queue in the library specified in the TRGLIB parameter.

*MAX

9 Trigger Server jobs are started to monitor the Trigger Data Queue in the library specified in the TRGLIB parameter. The maximum number of Trigger Server jobs that can be started is 99, but we retained the value for this parameter as 9 to preserve existing functionality.

number-of-trigger-server-jobs

Between 1 and 99 Trigger Server jobs can be started to monitor the Trigger Data Queue in the library specified in the TRGLIB parameter.

CLEAR

Specifies whether data should be cleared from the Trigger Data Queue prior to starting the Trigger Server job or jobs.