Host-Initiated Processing
Host-initiated processing (HIP) enables a host application to call a method of a COM or .NET object, pass parameters to the method, and receive parameters back from the method. As data travels first from the host to the client and then from the client to the host, the data is transformed from a format understandable by the host to the format appropriate for the client
Host-initiated processing is implemented in the following steps:
The HIP service process, called an application, begins listening for incoming connections on a list of endpoints specified by a local environment definition.
The client application, running on the host, initiates a TCP connection to a HIP system using one of the endpoints
The HIP service process checks if there is an established association between the endpoint and the clients host name or IP address. If no association is found, the connection is aborted.
The association uniquely identifies the work plan that is a sequence of workflows to be performed to complete the clients request. There are three types of work plans:
Endpoint
Transaction Request Message
Data.
Endpoint
The endpoint work plan consists of a single final workflow. The association is directly mapped to a method of a COM object that is to be invoked for the clients request processing. The endpoint workflow performs the following:
Receives client data
Unpacks data and populates parameters for the method
Creates the object and calls the method
Packs returned parameters into the client data
Sends client data
Closes connection.
Transaction Request Message
The Transaction Request Message (TRM) work plan consists of two workflows: TRM and Final workflow. TRM workflow handles initial part of the conversation when client sends the TRM and the workflow replies with the TRM Reply. Depending on the type of TRM, the TRM workflow can use one of three TRM Handlers: Microsoft Concurrent Server, Microsoft Link, IBM Concurrent Server. The TRM workflow performs the following:
Receives and unpacks the TRM using the assigned input format
Passes the TRM to the assigned handler
The handler returns the resolution information and the positive TRM Reply
The resolution information, which is expected to be character data, is converted to Unicode using the code page associated with the host environment
Workflow queries the database if there is a mapping to a method of an object defined for the resolution information
In case the match is not found, the handler is called to get the negative TRM Reply
The TRM Reply is packed using the assigned output format and sent. In the negative case, the connection is aborted
Workflow passes control to Final workflow along with the method identity found
Data
The Data determinant work plan consists of two workflows: Data Determinant and Final workflow. Data Determinant workflow preprocesses the client data trying to find a match to one of the determinants defined for the association. Determinant includes a string of characters and the position of the string in the client data. Each determinant is mapped to a method of an object. At startup the determinants are pre-converted to all code pages of hosts associated with determinants. The rules are enforced that determinants for an end point – host association are not duplicated or one determinant is not a part of the other. The workflow follows these steps:
The list of determinants for the given End Point – Host combination is obtained and sorted by the sum of the length and position in ascending order
The first determinant is taken from the list
A part of client data is received
The data is checked if it matches the determinant
In case of no match the next determinant is taken from the list, more client data received if needed, data compared to determinant
When no available determinant matches the data the connection is aborted
If a determinant is found the control is passed to Final workflow along with the method identity and the client data already read. There could be a situation when the determinant data is located within or even after the client data mapped to the methods parameters.
Note
A HIP MVS client must perform a socket shutdown immediately after a socket send and before a socket receive. Failure to perform an immediate socket shutdown causes the TI runtime to refuse the data, break the connection, and log an 808 event message (A Transaction Integrator HIP application received more data than expected.) to the server application event log. In addition, the packet containing the data being sent to the workstation might appear misleading: the Microsoft Network Monitor shows the data within the packet and data length not being excessive.