Set and test sequence number (STSN)

In SLU P mode, message sequence numbers are available in the data stream to allow message resynchronization. This can be demanded by a ‘Set and Test Sequence Number’ (STSN) request when a session is started.

The response that IMS requires, and that FEPI supplies if the system programmer has not defined a transaction to handle the STSN request, depends upon whether the STSN request showed ‘SET’ or ‘TEST and SET’:

For ‘SET’, the response is always ‘TEST POSITIVE’.
For ‘TEST and SET’, the response is ‘TEST POSITIVE’ or ‘TEST NEGATIVE’.

Any other response to STSN will cause the session to be unbound.

If an STSN handler is defined, it is started when session resynchronization is requested by the back-end system through an SNA STSN or SDT command. The back-end system sends an SNA STSN command indicating whether the last inbound message was in doubt or not; that is, whether a message had been sent by the back-end system but it had not logged the receipt of a response. The back-end system does not send an SNA STSN command if no traffic has been on the session since the latest cold start of the back-end system, but sends an SNA SDT command directly.

Like other handlers, the STSN handler is a CICS® started task that uses EXEC CICS RETRIEVE to get the start data and FEPI ALLOCATE with PASSCONVID to get ownership of the conversation identified in that data. The STSN handler, which can use the FEPI EXTRACT STSN command to determine what response is needed, must use the FEPI ISSUE command to respond to the STSN.

FEPI normally does all the necessary STSN handling automatically, so an STSN handler is required only where you need to handle the sequence number information yourself. The FEPI SEND, FEPI RECEIVE, and FEPI CONVERSE commands return the current sequence numbers for you.

A sample program illustrates the techniques used. See FEPI sample program: STSN handler.