Monitor and unsolicited data-handler

This program monitors unexpected events and handles unsolicited data for the FEPI sample programs.

This transaction handles:
  • Unexpected events that are reported by FEPI to a TD queue, which triggers this transaction
  • Unsolicited data from a back-end system, for which FEPI starts this transaction.

Because the event descriptions provided by FEPI and the processing required is basically the same for both cases, this common program is used.

ASSIGN STARTCODE is used to determine how the transaction was started, and ASSIGN QNAME to determine what TD queue triggered it. Details of the event are in the start data or the TD queue record as the case may be.

For illustrative purposes, all events are handled similarly by reporting their details to a TS queue named MONITOR, which can be browsed using CEBR. In practice, for any of the events you can do whatever extra or different processing you require, or (except for unsolicited data) you can ignore the event.

For unsolicited data, the conversation started by FEPI must be accessed so that FEPI knows that the data is being handled. The data itself should be received, or else FEPI ends and restarts the session. For illustration purposes, this program discards the data; in practice, you will probably want to process the data in some way.

However, if you did want to discard such data, you should specify no unsolicited-data handling and use the UNSOLDATACK property to tell FEPI what action to take, as is done for SLU P mode by these samples.

The general format of the TS queue records is:
date time CZUX description
          Event type..ACQFAIL      Pool........POOLNAME
          Target......TGTNAME      Node........NODENAME
          Device......T3278M2      Event data..X'00000000'
          Format......0            Event value.176
The actual details for each event vary. Events with similar details are grouped together for processing. The groups are:
  • Unknown event—an event that is not recognized
  • Unsolicited data
  • Session lost
  • Standard events—all other events.

The groups also determine any additional processing needed. Only unsolicited data needs any processing.

If any errors occur, they are reported to the TS queue.

Program logic

  Main procedure:
    Determine how transaction was started using ASSIGN
    If started with data by FEPI
        RETRIEVE start data
    If triggered by TD queue
        READ the queue record
    Otherwise
        Report start code
        RETURN
    TD-LOOP:
    Locate event type
    Locate device type
    Build description of event:  event type, device type,
        format, event value, date/time, transaction
    Call UNKNOWN-EVENT, UNSOLDATA, STANDARD-EVENT, or
        SESSION-LOST according to event group
    If triggered by TD queue
        READ the next queue record
        If one exists, loop to TD-LOOP
    RETURN
  UNKNOWN-EVENT routine:
    Write event details to TS queue:  description and
        event value
  UNSOLDATA routine:
    Write event details to TS queue:  description, event
        type, pool, target, and node
    Access conversation using FEPI ALLOCATE with PASSCONVID
    FEPI RECEIVE unsolicited data
    Free conversation
    Handle data as required