Unsolicited message processor

The unsolicited message processor (UMP) processes all the unsolicited messages addressed to a terminal. A message is classified as unsolicited when it is not generated as a response to an input message. The distinction between solicited and unsolicited messages is not made when the destination is an application rather than a terminal. Unsolicited messages originate at a terminal, in az/TPF processor or in an SCP processor. They are identified as unsolicited by the textual contents of the input message if the origin is a terminal or by the information in the RCPL in addition to content if the origin is a program in a z/TPF or SCP processor.

The destination of an unsolicited message may be a specific terminal (single message) or a group of terminals (broadcast message).

For information about the unsolicited message processor, see Unsolicited message processor. The following describes how the unsolicited message processor interacts with the message router. Two major components of the unsolicited message processor process unsolicited messages in different stages:
  1. Initial processing required to queue messages and send notification to the destination terminal.
  2. Disposition request processing required to comply with the terminal user's request to either display or purge the unsolicited messages.

The initial processing component of UMP is invoked by the Message Router Program for processing unsolicited messages addressed to non-receive-only terminals directly controlled by this CPU. It is also invoked by SMP when an unsolicited message request is entered at a terminal. Since the request is in the form of a command, it would have been entered by a CRAS terminal logged in to SMP as previously described.

The Unsolicited Message Processor uses Unsolicited Message Directories (CODR) to maintain references to unsolicited messages until they are successfully transmitted or are purged as a result of a disposition request.

When processing an unsolicited message, a reference item is created and inserted in a directory record. The directory record is retrieved using the address of the destination terminal to compute the needed ordinal number within the directory's record type. A reference item contains information such as:
  • Message and destination terminal characteristics
  • Destination address
  • Origin
  • Message file address, etc.

Broadcast messages require the creation of reference items for the addressed terminals through the use of the WGTA table (WG0TA). Once the unsolicited message directory has been updated, a notification message is sent to the destination terminal to inform the operator of the existence of the unsolicited message. This notification (whose form depends on the terminal characteristics) is immediately sent for all broadcast messages. In order to schedule delivery of these messages, an Unsolicited Notification List (CONL) is created containing the addresses of each relevant receiving terminal. This list is processed by a component of UMP.

For non-broadcast messages (single messages) the destination terminal is immediately notified of the existence of the unsolicited message. After receiving notification, the terminal operator may either temporarily disregard the notice or immediately request a display of the message by following one of the procedures described in System usage terminal operations. The appropriate input activates UMP which retrieves and searches the unsolicited message directory for the proper item based upon an originating application and the operator's terminal address. The unsolicited message is formatted appropriately and sent to the requesting terminal through the ROUTC macro, the Output Edit CRT Driver (03-UIO) or the Output Message Transmission Program.

A third functional component of UMP will, on a time initiated basis, police the Unsolicited Message Directory (CODR) to again advise terminal users of unsolicited messages queued for the terminal. This policing function will also purge, out of the system, any messages not displayed after several attempts at notifying the terminal user. The purge function may also be initiated by a direct request from the terminal user. It is described in System usage terminal operations.