EVT service test program: evttest

Name

evttest

Purpose

Sample event tracking application for testing and demonstrating the Event Tracking (EVT) service. evttest uses the tik service (TIK) as the runtime control (RTC) event provider and the Event Tracking service (EVT) as the RTC event consumer to demonstrate the features of RTC.

Usage

evttest [options]

where options are:

Option

Specifies...

-m n

Test scenario. The supported test scenarios are:

1 = One Natural Access event queue; ten contexts registered with that queue, all tik event codes added to event-tracking list.

2 = Two Natural Access events queues; one context registered per queue, specific tik event codes added to event-tracking list.

3 = One Natural Access events queue; one context registered on the queue, all tik event codes added to event-tracking list.

For more information about these scenarios, see evttest scenarios.

-t

Tracing on a per-context basis. Set the per-context tracemask to trace DRIVER_EVENTS, DRIVER_COMMANDS, and DEBUG_BIT_0.

-n numTicks

Number of tick strings to request from the tik server. This value overrides the default TIK_START_PARM numTicks parameter.

-f frequency

Frequency of tick strings from the tik server. This value overrides the default TIK_START_PARM frequency parameter.

-l logfile

Path and name of the event log file. If -l is not specified, the standard output file is used.


Description

The Event Tracking (EVT) service is a sample service shipped with the Natural Access Service Writer's Developer's Kit. EVT does not manage any particular resource of its own. It internally uses Natural Access runtime control (RTC) features to log events generated by other services opened under the same context as EVT. No RTC symbol or type definitions are exposed to the user application through EVT API specifications. (RTC is intended for inter-service operations only.)

A user application can specify event codes to track from a service opened under the same context as EVT. These event codes are specified on a per context basis, both for tracking and logging. For each context, the user application can track:

A user application can remove event codes from the existing tracking list, on a per context basis.

A user application can also turn on and off event logging on a per context basis, and specify the event log file for the whole application.

evttest scenarios

This section describes the three test scenarios that evttest can run. The test scenario to run is specified with the -m command line option.

Scenario 1

  1. One queue is created.

  2. Ten contexts are created under the queue.

  3. One instance of TIK and one instance of EVT are opened under each context.

  4. The EVT log file is set for the whole application, based on the filename specified with the -l option.

  5. Event logging is turned on.

  6. All TIK event codes are added to the event-tracking list.

  7. The tick timer is started for each instance of TIK.

  8. A TIKEVN_TIMER_TICK event is issued per tick until the maximum tick count specified with the -n option is reached. If no maximum tick count is specified, it defaults to 2 ticks.

  9. When the maximum tick count is reached, a TIKEVN_TIMER_DONE event with event value (reason code) CTA_REASON_FINISHED is issued for each tick timer.

  10. The same event and reason code is issued when the tick timer is stopped.

  11. The event codes are removed from the event tracking list.

  12. Event logging is turned off.

  13. For each context, the instances of TIK and EVT are closed.

  14. Each context is destroyed.

  15. Each queue is destroyed.

Scenario 2

  1. Two queues are created.

  2. One context is created under each queue.

  3. One instance of TIK and one instance of EVT are opened under each context.

  4. The EVT log file is set for the whole application, based on the filename specified with the -l option.

  5. Event logging is turned on.

  6. For the context under the first queue, the event code TIKEVN_TIMER_DONE with event value CTA_REASON_FINISHED is added to the event tracking list.

  7. For the context under the second queue, the event code TIKEVN_TIMER_DONE (no specific event value) is added the event tracking list.

  8. The tick timer is started for each instance of TIK.

  9. A TIKEVN_TIMER_TICK event is issued per tick until the maximum tick count specified with the -n option is reached. If no maximum tick count is specified, it defaults to 2 ticks.

  10. When the maximum tick count is reached, a TIKEVN_TIMER_DONE event with event value (reason code) CTA_REASON_FINISHED is issued for each tick timer.

  11. The same event and reason code is issued when the tick timer is stopped.

  12. The event codes are removed from the event tracking list.

  13. Event logging is turned off.

  14. For each context, the instances of TIK and EVT are closed.

  15. Each context is destroyed.

  16. Each queue is destroyed.

Scenario 3

  1. One queue is created.

  2. One context is created under the queue.

  3. One instance of TIK and one instance of EVT are opened under each context.

  4. The EVT log file is set for the whole application, based on the filename specified with the -l option.

  5. Event logging is turned on.

  6. Add all TIK event codes to the event-tracking list.

  7. The tick timer is started for each instance of TIK.

  8. A TIKEVN_TIMER_TICK event is issued per tick until the maximum tick count specified with the -n option is reached. If no maximum tick count is specified, it defaults to 2 ticks.

  9. When the maximum tick count is reached, a TIKEVN_TIMER_DONE event with event value (reason code) CTA_REASON_FINISHED is issued for each tick timer.

  10. The same event and reason code is issued when the tick timer is stopped.

  11. The event codes are removed from the event tracking list.

  12. Event logging is turned off.

  13. For each context, the instances of TIK and EVT are closed.

  14. Each context is destroyed.

  15. Each queue is destroyed.

Build procedure

The Event Tracking service and its demonstration program are provided in source only. To build the components:

  1. Build the tik server and the tik service as described in tik service test program: tiktst.

  2. Build the EVT service by entering the following commands:

    Operating system

    Commands

    Windows

    cd nms\ctaccess\demos\evtsvc
    nmake

    UNIX

    cd /nms/ctaccess/demos/evtsvc
    make


  1. Build the EVT test program by entering the following commands:

    Operating system

    Commands

    Windows

    cd nms\ctaccess\demos\evttest
    nmake

    UNIX

    cd /nms/ctaccess/demos/evttest
    make


Test procedure

  1. Ensure that the tik server and the tik service are built.

  2. Ensure that the EVT service and the EVT test program are built.

  3. Configure cta.cfg to include the new services and service managers. To do so, add the following lines in the [ctasys] section of the file:

    4. Service = tik, tikmgr
    Service = evt, evtmgr

  4. Start the tik server:

    5. tiksvr

    Note: To enable tracing, also start the Natural Access Server in interactive mode. To do so, enter: ctdaemon -i. If the Natural Access Server is already running as a service, access it in console mode by entering ctdaemon -c.

  5. Run the first EVT test scenario:

    6. evttest -m1 -l evt1.log

  6. Run the second EVT test scenario:

    7. evttest -m2 -l evt2.log

  7. Run the third EVT test scenario:

    8. evttest -m3 -l evt3.log