Application Flags

Application flags are included on the following messages:

All Data messages (both inbound and outbound)
Status-Acknowledge(Ack) (outbound only)
Status-Acknowledge(Nack-1) (outbound only)
All Status-Control messages (both inbound and outbound)

These flags represent key indicators of the state of the session to which the message relates and are closely related (but not always equivalent) to the request header or response header (RH) indicators in the SNA request or response. Note that for inbound messages, applications need to set the flags on Data messages and Status-Control messages only.

For outbound messages, the local node sets the application flags to reflect the contents of the RH in the corresponding SNA message. The local node performs checks on the SNA message before sending it to the application; therefore, the application can assume that the RH indicators obey the SNA protocols and need not perform its own checks. The application's task in interpreting the application flags is much simpler than if the local node presented the message with the uninterpreted RH. For example:

If the application specified the segment delivery option when the PLU connection was opened (see Opening the PLU Connection), the end chain indicator (ECI) on an SNA request will occur on the first segment of the last request unit (RU) in a chain, but the chain is not complete until the last segment of that RU is received. In this case, the local node manipulates the application flags so that the ECI flag is set in the last segment rather than the first.
Applications using TS profile 4 (transmission service profile 4) on the PLU session can receive the DR2 (definite response 2) RH indicator in combination with DR1 (definite response 1) or ER (exception response) to give RQD2, RQD3, RQE2, and RQE3 requests. The local node interprets the RH indicators and sets the COMMIT application flag accordingly.

For inbound Data and Status-Control messages, the application should set the flags to control session characteristics such as chaining, direction control, and brackets. For Status-Acknowledge messages, the local node generates an SNA response and sets the RH indicators using information saved from the corresponding request; the application does not need to set the flags on this message.

For information on application flag usage when FMI chunking is being used, see Chunking.

In most cases, the application will not need to consider the application flags on Status-Acknowledge(Ack) messages, which derive from the RH indicators on the corresponding response. However, certain applications do require access to the RH flags on responses — for example, transaction-processing applications using TS profile 4 can receive the DR2 flag on responses, which will appear as the COMMIT flag in the application flags.

The application flag usage on Status-Control messages is derived from the RH indicators in the corresponding DFC or session control (SC) RU. Applications may need to be aware of the RH flags for Status-Control messages. For example, LUSTAT request type 6 is a "no-op" used solely to allow RH flags to be sent when no other request is allowed. The local node delivers the request to the application as a Status-Control(LUSTAT) Request with the relevant application flags set. See SNA Format and Protocol Reference Manual: Architectural Logic (IBM publication SC30-3112) for summaries of valid RH usage for DFC RUs and of valid RH indicators for SC requests.

In the summary of the application flags below, bits are numbered with bit 0 as the most significant bit in a byte and bit 7 as the least significant. An application flag is set if the relevant bit for the flag is 1 and not set if the bit is 0.

Flag 1 occurs in all messages. The meanings of the individual bits and values that can be ORed together to set them are listed below.

Bits in flag 1	Meaning
FMHI [bit 0, flag 1] Value: AF_FMH (0x80)	Function management header indicator — set if a function management header is present in the message, or if the message is a function management data network services (FMD NS) request. Only valid on Data messages. This flag is always set for 3270 user alerts, which are sent on the SSCP connection (see 3270 User Alerts).
BCI [bit 1, flag 1] Value: AF_BC (0x40)	Begin chain indicator — set if this message starts a chain (see Outbound Chaining and Inbound Chaining).
ECI [bit 2, flag 1] Value: AF_EC (0x20)	End chain indicator — set if this message ends a chain (see Outbound Chaining and Inbound Chaining).
COMMIT [bit 3, flag 1] Value: AF_COMM (0x10)	Commit indicator — set if chain carries DR2 (definite response 2).
BBI [bit 4, flag 1] Value: AF_BB (0x08)	Begin bracket indicator — set if chain carries BB (begin bracket). Note that this does not necessarily indicate that the bracket has been initiated (see Brackets).
EBI [bit 5, flag 1] Value: AF_EB (0x04)	End bracket indicator — set if chain carries EB (end bracket). Note that this does not indicate that the bracket has terminated (see Brackets).
CDI [bit 6, flag 1] Value: AF_CD (0x02)	Change direction indicator — set if chain carries CD (change direction); see Direction.
SDI [bit 7, flag 1] Value: AF_SD (0x01)	System detected error indicator — set if the local node detects an error in outbound data; see Outbound Data.

Flag 2 occurs in all messages except Status-Control(STSN), where the indicators included in this byte are not applicable. The meanings of the individual bits and values that can be ORed together to set them are listed below.

Bits in flag 2	Meaning
CODE [bit 0, flag 2] Value: AF_CODE (0x80)	Alternate code indicator — set if the alternate code set (usually ASCII) is used for this Data message. Note that function management headers are unaffected by the code selection indicator.
ENCRYP [bit 1, flag 2] Value: AF_ENCR (0x40)	Enciphered data indicator — set to indicate that the information in the Data message is enciphered under session level cryptography protocols. Users should note that they must provide the necessary support for data encryption; the SNA Server local node does not support cryptography.
ENPAD [bit 2, flag 2] Value: AF_ENPD (0x20)	Padded data indicator — set in conjunction with the ENCRYP flag to indicate that the data was padded at the end to the next integral multiple of eight bytes before encipherment.
QRI [bit 3, flag 2] Value: AF_QRI (0x10)	Queued response indicator — set if the response to this request is to be queued in the transmission control and data flow control layers. This flag is only significant for inbound messages.
CEI [bit 4, flag 2] Value: AF_CEI (0x08)	Chain ending indicator — set on a message corresponding to an outbound SNA request with EC (end chain) and BBIU (begin basic information unit). This flag is provided solely for the use of SNA Server components; your application should not attempt to use it.
BBIUI [bit 5, flag 2] Value: AF_BBIU (0x04)	Begin basic information unit indicator — set on a message corresponding to an outbound SNA request with BBIU (begin basic information unit). This flag is provided for the use of SNA Server components and for applications using segment delivery and outbound pacing together (see Pacing and Chunking); your application should not attempt to use it.
EBIUI [bit 6, flag 2] Value: AF_EBIU (0x02)	End basic information unit indicator — set on a message corresponding to an outbound SNA request with EBIU (end basic information unit). This flag is provided solely for the use of SNA Server components; your application should not attempt to use it.
RBI [bit 7, flag 2] Value: AF_RBI (0x01)	Real BID indicator — set on Status-Control(BID) Request messages from the local node only. 0x01 indicates that the message is due to an SNA BID RU, 0x00 indicates that the message is due to an outbound FMD (function management data) RU with BB (begin bracket) set.