CSIO TRANSMISSION SESSION STANDARD OPTIONS

curvyrawrNetworking and Communications

Oct 23, 2013 (3 years and 7 months ago)

127 views
















CSIO TRANSMISSION SESSION STANDARD OPTIONS

















CSIO Std.#:

C110

Version:

12
(i)

Date:

March
, 20
1
2

Status:

Approved









ALL COMMENTS REGARDING THIS STANDARD SHOULD BE ADDRESSED TO:


CENTRE FOR STUDY OF INSURANCE OPERATIONS

110

YONGE STREET, SUITE 500

TORONTO, ONTARIO

M5C 1T4

C110
-

12
(i)

©
2012

CSIO TRANSMISSION SESSION STANDARD OPTIONS

page
2

TABLE OF CONTENTS



DISCLAIMER:

IT IS THE SOLE RESPONSIBILITY OF EACH ORGANIZATION USING THE CSIO
STANDARDS TO VERIFY THE IMPLICATIONS TO/WITH THEIR TRADING PARTNERS WHEN
IMPLEMENTING OR MAKING CHANGES TO
THEIR EDI FUNCTIONALITY. CSIO RECOMMENDS
THAT TESTING BE DONE WITH YOUR TRADING PARTNERS PRIOR TO RELEASING ANY NEW OR
AMENDED IMPLEMENTATION. PLEASE REFER TO SECTION 11.1


GENERAL RULES, OF THE C000
STANDARDS.

CSIO TRANSMISSION SESSION STANDARD
-

BATCH
................................
................................
....

4

RECORD OF AMENDMENTS

................................
................................
................................
.

5

1.0

INTRODUCTION

................................
................................
................................
...................

6

1.1

Purp
ose of This Standard
................................
................................
..............................

6

1.2

How to Read This Document

................................
................................
........................

7

2.0

THE INFORMATION TRANSFER PROCESS

................................
................................
..........

8

2.1

General Description

................................
................................
................................
......

8

2.2

ISO Open Sys
tem Interconnection Reference Model

................................
........................

8

3.0

COMMUNICATIONS STRUCTURE

................................
................................
......................

13

3.1

Environmental Assumptions

................................
................................
........................

13

3.2

Batch Message Transmission Assumptions

................................
................................
...

14

3.3

Components of Session and Message Structure

................................
.............................

14

3.4

Network Considerations
................................
................................
..............................

17

3.5

Acknowledgement and Error Detection
................................
................................
.........

17

4.0

SESSION CONTROL STRUCTURE

................................
................................
......................

17

5.0

THE BATCH COMMUNICATIONS SESSION

................................
................................
.......

18

5.1

Definitions
................................
................................
................................
.................

18

5.2

Functional Phases of the Communications Session
................................
.........................

19

5.3

The Session Co
ntroller
................................
................................
................................

23

5.4

The Signon Phase

................................
................................
................................
......

24

5.5

Message Transfer Process

................................
................................
..........................

28

5.6

The Signoff Phase
................................
................................
................................
......

35

5.7

Restart/Recovery Procedures

................................
................................
......................

36

6.0

GROUPS (DETAIL)
................................
................................
................................
..............

42

6.1

Documentation Format

................................
................................
...............................

42

Signon Group

4SOG
................................
..

44

Signon Rejection Group

4SOR
................................
..

52

Receive Opt
ions Control Group

4ROC
................................
..

56

Signoff Group

4SOF
................................
..

60

Message Acknowledgement Group

4MAK
................................
..

63

Negative Message Acknowledgement Group

4NMK
................................
..

66

St
ream Terminator Group

4STG
................................
..

70

Phase Terminator Group

4PTG
................................
..

73

Control Request Group

4CRG
................................
..

76

C110
-

12
(i)

©
2012

CSIO TRANSMISSION SESSION STANDARD OPTIONS

page
3

Control Request Rejection Group

4CRR
................................
..

79

CSIO
TRANSMISSION SESSION STANDARD


INTERNET

................................
............................

83

RECORD OF AMENDMENTS

................................
................................
...............................

84

1.0

INTRODUCTION

................................
................................
................................
.................

85

2.0

TRANSACTION FLOW
................................
................................
................................
........

85

3.0

CSIO STANDARD TRANSM
ISSION MESSAGES

................................
................................
.

85

3.1

CSIO Data Transmission

................................
................................
............................

85

3.2

Mail Box Delivery Notification Message

................................
................................
........

88

3.3

Acknowledgement Message Format

................................
................................
.............

88




CSIO TRANSMISSION SESSION STANDARD
-

BATCH



C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
5

RECORD OF AMENDMENTS



Date

Release

Issued

Description




3.2

Jan/1992

Repaginated


1992

Jul/1992

Revision to Standards numbering


1994

Jan/1994

Incorporated portions of C210 and moved message structure defini
tions to
C900
-

Document renamed
t
o Transmission Session Standard


2009


Mar/2009

Add Disclaimer just below the Table of Contents Heading

(MR09
-
009)






C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
6

CSIO TRANSMISSION SESSION STANDARD


1.0

INTRODUCTION


1.1

Purpose of This Standard


The purpose of t
his document is to describe a session structure, or framework, for the electronic
communication of data between independent brokers and companies within the Property and Casualty
insurance industry. The structure is specifi
cally oriented towards batch (a
s opposed to interactive)
transmission and does not cover interactive transmission. This document attempts not to limit the designer of
hardware or software systems for communications interface, but to provide guidelines relative to the
implementation of b
roker
-
company data communications capability. It contains requirements for the
preferred implemen
tation of message text and transmission control elements within a data communications
session. This Standard will serve to establish definitions for the char
acteristics of the information
-
carrying
structure within the overall communications envelope between any two independent systems.


This Standard assumes the existence of the various data communica
tion levels described in section 2.0,
including a physical,

or electrical interface, a batch oriented Character Asynchronous, Binary Synchronous,
packet switched or other batch communications link protocol and possibly, a value
-
added communications
network. The physical and link control protocols are long establis
hed defacto Standards and will not be
discussed in this document except to indicate their relationship to session and message structure. Individual
value
-
added network protocols are dependent on the specific network if any to be utilized. However,
provisio
n has been made for accommodating existing and anticipating future commercial networks. (See
Section 2.2.3) In addition, the Standard will point out areas which specifically apply to the CSIO C110
Implementation Requirement.


This Standard makes a distinct
ion between "physical" communication, logical message acceptance and
application processing. Physical communications refers to that aspect of a communications session in which

the content of the communications is totally immaterial to the process of sendi
ng and receiving information.
Logical message acceptance and application processing, on the other hand, imply that the sender and the
ultimate receiver of information must jointly be aware of at least some portion of the content. Standard
No.C11O is desi
gned primarily to deal with "physical" communication. However, there are aspects of the
Standard which imply that specific units of data require special attention and must reach their intended
recipient unchanged by any intermediate physical communication
s processing systems. The Standard deals
with these where appropriate as specific exceptions to normal processing.


In Standard No.C110, the physical and logical pairs are always the same.



COMMENTARY


It is also recognized that the broker
-
company enviro
nment is and is likely to remain characterized by smaller, less
expensive and less powerful data processing systems in agents’/brokers' offices than exist at company locations.

Therefore, it will be assumed that a broker's system is required to transmit a
nd receive information only within
the limits of the capability of its characteristic hardware and software. It should be noted that any required
technical translations, for instance from Asynchronous to Binary Synchronous protocol, from ASCII to EBCDIC,

etc., may not be able to be performed either by companies or by a value
-
added network. It would be appropriate
for the Broker to delay final decision of equipment purchase, until the company(s) of choice have been contacted.


Brokerage systems are
not

expe
cted

to transmit information to or receive information from companies by using a

physical or protocol interface which is different on a company
-
by
-
company basis.

C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
7


The Intelligent Access Functional specifications detail the protocols required and the funct
ions to be performed in
the environment. The specifications make assumptions about certain capabilities of an broker's functional
environment that are beyond the assumptions provided in this Standard.




1.2

How to Read This Document


The following sectio
ns of this Standard present the session and message structure in a top
-
down fashion of
increasing detail. Therefore, Section 3.0 should be considered prerequisite reading for Section 4.0, Section
5.0 prerequisite reading for Section 6.0, and so on.


In add
ition, it should be understood that there is a relatively simple, "basic" message structure which
describes the manner in which information will be delivered between agents/brokers and companies and,
supplementing that structure, a series of optional compo
nents (clearly identified as such) which can be used
to restart and/or recover from communication session failures. It is a measure of the flexibility of this
Standard’s approach that all restart/recovery procedures are in fact optional. Note, however, th
at on an ad
hoc basis, it is likely that a given company may want agents/brokers who wish to interface to have
implemented some portions of the optional restart/recovery structure and vice versa.


More importantly, since this Standard is aimed at batch dat
a communications between independent insurance
agents/brokers and the companies they represent, as opposed to data communication in general, there are a
number of instances where the Standards material presented is a reflection of either the existing or
an
ticipated broker
-
company environment and, as such, may supplement, or differ from classic, or even
"elegant", data processing and data communication practices.


Where it is felt that a particular Standard’s decision is a result of such environmental influe
nces, and that an
explanation would be helpful to the reader, these explanations are separated from the main text of the
document by horizontal lines and the heading "Commentary".


"Commentary" is
not

to be interpreted as Standard’s material in terms of im
plementation by any party. It is
solely

explanatory material designed to inform the reader of the reasoning behind a particular Standard’s item.


Briefly, the following sections of this Standard are:


o

Section 2.0, describes the general data communications
structure within which the
brokerage
-
company interface fits.


o

Section 3.0, provides an overview of the structure of a communications session. It describes how
a communications session is broken into a data communications stream, messages, transactions,
an
d element groups.


o

Section 4.0, provides a description of the session structure specified.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
8

o

Section 5.0, which covers the batch communication structure and describes the various control
groups which comprise both the "basic" set and the restart/recovery o
r "optional" control groups.


o

Section 6.0, is a detailed, element
-
by
-
element, descrip
tion of each control group and the specific
function and content of each data element in each control group.


Readers are invited to make comments and suggest language mo
difica
tions, alternatives, additions, deletions
or other changes to this Standard. Where appropriate, these comments should be supported by data,
references, a discussion paper or other documentation. This and other Standards developed in the CSIO
Standa
rds program should be considered "living" documents which will be revised or updated from
time
-
to
-
time as required.


2.0

THE INFORMATION TRANSFER PROCESS


2.1

General Description


In order to provide an overall context for the message structure and session

control procedures presented in
this Standard, Section 2.0 provides a brief overview of the process by which information is transferred
between two communicating computer systems. The Inter
national Standards Organization (ISO) has
developed a general mod
el for the description of data communication between distinct computer systems or
a pair of terminals attached to distinct computer systems. This model, the Reference Mode for Open
Systems Intercon
nection (OSI), provides a useful framework for the discuss
ion of existing and proposed
computer communications systems.


The message structure and session control procedures presented in this Standard correspond to only some
of the functions performed by the OSI model. Section 2 presents a brief description of th
e OSI model
together with a discussion of where within the model the mes
sage structure and session control procedures
fall.


2.2

ISO Open System Interconnection Reference Model


The protocol Reference Model of Open System Interconnection of the Internati
onal Standards Organization
is shown in Figure 2.1. This model is organized as a series of seven layers or levels, each one built upon its
predecessor. The level protocols provide the means of exchanging information between peer architectural
layers of com
municating data terminal equipment (user systems). Communication between adjacent
architectural layers can take place by conforming to a specific interface Standard at that level. This
multi
-
level approach provides for a separation of functions by conside
ring each level as a separate module in
order to allow for evolutionary changes to each level of interface protocols.


The process of communicating from the Application Layer of system A to the Application Layer of system B
using the Application Protocol i
s as follows:


o

Each layer of system A passes data to the layer immediately below it, adding the necessary control
information, until the lowest level is reached.


o

At the lowest level, there is physical communication with sys
tem B as opposed to virtual
com
munication at the higher levels.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
9

o

The data then travels from each layer of system B to the next higher level, with appropriate control
information removed until the Application level is reached.


The seven levels of the OSI protocol model are described be
low. It should be emphasized that the proposed
OSI model is, at this point in time, a first step toward international standardization of the various protocols.
The protocols currently in use in Canada have levels that correspond only approximately to tho
se of the OSI
Reference Model.

C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
10

Figure 2.1



ISO OPEN SYSTEM INTERCONNECTION REFERENCE MODEL






C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
11

2.2.1

The Physical Layer


The Physical Layer is concerned with the physical transmission of raw data bits over a communications link.

Some typical issues a
re the electrical signal representation of bits, the order and timing of bit transmission in

a character, and the number and functions of pins in circuit connectors. This Session and Message
Structure Standard does not address the Physical Layer.


2.2.2

The Data Link Layer


The objective of the Data Link Layer is to transform the raw transmission facility into a link that appears free
of trans
mission errors to the next higher layer, the Network Layer. Some typical data link protocols in use
are SDLC, bin
ary synchronous (BSC), and asynchronous start/stop. This Standard does not address the
Data Link Layer.



COMMENTARY


The message structure and session control structure presented in this document are independent from the
underlying data link protocol. Alt
hough the data link protocol currently used today in brokerage
-
company
communications is almost exclusively BSC, it is anticipated that other data link protocols will be utilized in the
near future. The possible future offering of services to the insurance

industry by value
-
added networks or
packet
-
switching may impact protocol usage. Asynchronous start/stop communications with a low error rate
may be used by small brokerage systems when accessing local network nodes or company systems. The
extensive use of

satellite circuits by the public telephone system and the rapid pace of development of
communications hardware components will also impact protocol usage.


The protocols required for packet
-
switched networks offer options at the physical and Data Link lay
ers. The
availability of these options will depend on the access method to the network and the network supplier's
implementation. The specifications for Intelligent Access define the options implemented at the physical and Data
Link layers.




2.2.3

The Ne
twork Layer


The Network Layer controls the transmission of data between a user system and a private network or a
value
-
added network part. This layer of software provides routing and billing information or other data
required for the network to perform it
s services. This Standard provides for data commonly required by
networks by means of data elements in Headers and Trailers.



COMMENTARY


It is recognized, however, that existing network architectures (IBM's Systems Network Architecture (SNA) is an
exampl
e), as well as some future networks may require additional structure which is unique to the particular
network. In such a case, the entire session and message structure described in this Standard is likely to be
considered formatted "text" by the network (
formatted to the extent that the network will understand the format
and be able to apply value
-
added functions) within its own unique "envelope".


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
12

This is specifically the case with packet switch networks in general and the Intelligent Access implementati
on in
particular. The network layer is referred to as the packet layer as the access method envelopes the data into data
packets which are then passed across the network. The envelope is removed by the recipient after using the
envelope information to veri
fy the reliability of the information.


The reason for providing for data commonly required, or likely to be required, by networks within this Standard
is to provide for the attractive possibility that some networks will
not

require additional structure an
d, thus, that
agent/ broker
-
company implementers of this Standard will be able to utilize a virtually identical structure in both a
direct brokerage
-
company link and in a network environment.




2.2.4

The Transport Layer


The Transport layer or host
-
host i
s a true source
-
to
-
destination or end
-
to
-
end layer. Its purpose is to relieve
the next higher level of any concern with the way in which reliable and cost effective transfer of data is
achieved. Some typical functions of the transport layer might be to mul
tiplex several transport connections
onto the same network connection, to create multiple network connections in order to obtain higher
throughput, or to select the most cost effective network for the session.


The transport layer typically provides a virt
ual circuit by means of which the two user systems carry on a
conversation. This Standard does not address the Transport Layer.


2.2.5

The Session Layer


In the ISO reference model, the Session Layer is the user's interface into a network. The user may be
a
human being using an interactive terminal or a process in a host computer system. It is with this layer that a
user must interact to establish a connection with a process on another machine. Once the connection has
been established, the session layer may

be used to manage the data exchange in an orderly manner. The
session layer validates user ID's and passwords, and other information used to control options that may be in
communications service offered by the next lower layer. The session layer often pro
vides a facility by which
a group of messages or transactions can be bracketed, so that none of them are delivered to the remote user
until all of them have arrived.


Most of the features of session control presented in this Standard are functionally in th
e Session Layer.
However, the organization of the software modules in either the agency/ brokerage or insurance company
system may not precisely reflect the OSI organization.


2.2.6

The Presentation Layer


The Presentation Layer performs functions that are

requested sufficiently often to warrant finding a general
solution for them, rather than letting each user solve the problems on their own. These functions can often
be performed by library routines called by the user. Some typical examples are text compr
ession by
removing multiple blanks or encoding commonly used data such as city names, dates, or terminology
common to the users, data encryption, or conversion between EBCDIC and ASCII. (See COMMENTARY,
Section 1.1, Broker systems are
not

expected to do th
is type of conversion.) The message and transaction
structure presented in this Standard falls within this layer. Many of the functions the OSI reference model
places in the presentation level will be found at various positions in brokerage and company ope
rating
systems or application software.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
13

2.2.7

Application Layer


The Application Layer is the highest level in the OSI model. It is the layer in which Insurance Transactions
are processed.


There are several data elements contained in the Message Header
Group which contain information required
by the "logical" receiver of a message in order to assure proper end to end message processing. Still others
are required by the applications programs which will process the message's contents. This Standard will
ma
ke specific reference to all such data and describe the logic to be followed in instances where the
"physical" communicating systems are not identical to the "logical" communicators. This normally occurs
when a Value
-
Added Network is acting as a intermedia
ry between the sender and the ultimate receiver of the
information contained within a session. The network actually conducts two physical sessions, one with the
sender of messages and another with their receiver.


In the Intelligent Access environment, the

physical and logical communicators are always the same.


3.0

COMMUNICATIONS STRUCTURE


3.1

Environmental Assumptions


The session and message structure defined in this Standard is spe
cifically aimed at being useful in the current
agent/broker
-
company env
iron
ment as well as in the future. Therefore, a number of assumptions have been
made about the existing environment which, to one degree or another, have influenced this Standard.


The most fundamental of these assumptions is that there are today, and wi
ll continue to be in the future, a
wide variety of systems and data processing capability in agents’/brokers' offices. This equipment varies
from microcomputers with limited storage and programming capability to minicomputers with considerably
more capabil
ity to sys
tems which could be characterized as "host"
-
type environments. This Standard is
intended to be independent of this environment to the extent that no assumptions have been made regarding
any specific limitations or capabilities while, as the same

time, it is recognized that the structure which has
been defined must be capable of implementation within potentially limited capability.

Another assumption made is that there are no hardware limitations at either end of the communications link
regarding
the physical record size which can be transmitted. In other words, the computer at either end of
the link can take a stream of characters and decompose logical records into a series of physical records for
processing within that system. This stream of char
acters will obviously, be interspersed with hardware
delimiters as specified by the link control protocol use. A corresponding assumption is that logical record
lengths are unlimited and can span physical block limits. It is assumed that the link control p
rotocol used, or
either hardware or software protocol emulator packages employed, will automatically "chop up" logical
records into block sizes of the specific length indicated by the link control protocol.


In summary, the transmission structure described

below does not cover the specific way in which it will be
implemented in any given system. It is expected that various implementations will be based on the techniques
employed by the implementer, the constraints imposed by the systems with which they must

deal and by the
software applications which are provided in the sending and receiving systems.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
14

3.2

Batch Message Transmission Assumptions


In a typical broker's system, transactions
may

be accumulated on storage as they occur throughout the day
(as oppo
sed to being transmitted as they occur). In this environment, at the close of the day, the files will
consist of numbers of transactions for several companies. The data structure described in this Standard
permits maximum flexibility in the way these trans
actions can be transmitted. The only rigid requirement is
that individual transactions, or groups of transactions, for a given company must be enclosed within a
message envelope. Once this has been done, however, the entire file of messages for multiple c
ompanies
could be transmitted in a single communications session to a value
-
added net
work which would, possibly
among other value
-
added functions, route and transmit individual messages to their individual addresses. In
the absence of a value
-
added networ
k, an individual communications session would be required for each
company. The Functional Specifications for Intelligent Access assume that the latter will take place and that
the agency/brokerage system will control these sessions.


It is also possible f
or an broker's system
to

transmit individ
ual transactions as they occur and thus send
single
-
transaction mes
sages. It is likewise possible to transmit multiple messages to a single company.
Control information allows the addressee to verify among other
things, that the entire stream of messages
transmitted during the communications session has in fact been received. The specific format of the control
information is defined in Section 5.0.


It is assumed that a functional acknowledgement or other applicat
ion level response to a received transaction
will normally be transmitted in a separate communications session. This Standard does not address, but does
not preclude, interface between user systems which require interactive processing at the application le
vel.
Data base inquiry or update systems and interactive data collection systems are included in this category.


3.3

Components of Session and Message Structure


Figure 3.1 shows the various components of a transmission stream which are required in the bat
ch
transmission environment.


3.3.1

Transmission Stream and Messages


Figure 3.1 shows the breakdown of a transmission stream into its information
-
carrying or message
components. Messages, in turn, are composed of Transactions, which are the actual insuran
ce
-
information
carrying units.


The components of the transmission stream are designed to carry information between independent
insurance agents/brokers and the companies they represent.
The transmission stream itself can be thought of
as a machine
-
to
-
mac
hine physical communication.

An example is a minicomputer

in an agent’s/broker's
office to a host computer at a company location
or

to an entry node of a valued
-
added network. A
transmission stream, as shown, may contain multiple Messages.


A Message is a
lso a "physical" communication between machines, normally the agent/broker's and
company's.

Note, however, that several units of information contained within the Message Header Group are
required for "logical" acceptance of the message between its sender a
nd ultimate receiver and others for
subsequent processing of the transactions it contains. Although use of a packet switch network in Intelligent
Access does technically involve two separate communication sessions (the sender to the network and the
network

to the receiver), this can be considered as one session since the protocols in the network access
provide for reliability of the transmission and retransmissions in the event of compromised data
and

are
transparent to the application.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
15

On the other hand,
some brokerage systems may find it preferable to include only a single transaction in any
given message and to transmit multiple messages in a batch to any given company. The structure described
in this Standard provides the flexibility necessary to suppor
t either approach.



COMMENTARY


Multiple messages in a direct broker
-
company transmission stream will generally be used in order to facilitate
restart/recovery procedures as described in Section 5.0. Other possible uses for a multiple
-
message stream in a
direct broker
-
company link are:


a.

A company host computer could function as a switch to direct in
dividual messages to various company
locations such as a claims, branch office, etc.

b.

If an agent/broker system is being shared by several agencies/ broke
rages, each of the sharing
agencies/brokerages can address their message(s) to a company distinct from other agencies/brokerages sharing
the system and yet permit a single communications session for a particular company.


Multiple messages in a transmissio
n stream are expected to be the
rule

when using a value
-
added network. In this
case, the broker can transmit all messages for all companies in a single session and have the network forward the
messages to their various destinations.




C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
16

Figure 3.1



COMPON
ENTS OF THE TRANSMISSION STREAM






C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
17

3.4

Network Considerations


The session and message control
structure

defined in this Standard is designed to anticipate the requirements
of value
-
added networks. It is hoped that this structure will suffice for that
purpose. It should be understood
however, that additional information may be required to satisfy the communications service used. The
format

of these parts of the communication session will not be defined in this Standard since they are specific to
individ
ual entities. They must however, be considered a potential part of the overall "text" for a
communications session.


3.5

Acknowledgement and Error Detection


Electronic Data interface in accordance with this environment assumes three levels of acknowledgem
ent:


(1)

Communications Acknowledgement: A response to the sender at the data link protocol level to
indicate the status of communications validation and error detection. The format and content of this
acknowledgement will depend upon the link control use
d and is independent of the session and
message structure described in this document.


(2)

Message Acknowledgement: A response to the sender during the communications session to
indicate receipt of message(s) and the status of validation of message and tra
nsaction control
information. Specification of message acknowledge
ment is part of this Standard and is defined in
Section 5.0.


(3)

Functional Acknowledgement: A transmission of a delayed message (an Acceptance/Rejection
transaction) to the sender to ind
icate status of this transmission with respect to processing
performed on the transaction by the receiver.


Acceptance/Rejection transactions are not included as a part of this Standard. They are defined in the Policy
Processing section.


4.0

SESSION CONTR
OL STRUCTURE


Session control groups are data element groups whose functions are to communicate session control
information between two communicating systems. They are used to transfer the information required to
establish a communications session, to dire
ct the flow of messages between the two session participants,
and to terminate the session in an orderly manner. Session Control Groups are transmitted as stand
-
alone
units outside of the transaction and message structure. These groups never appear in tran
sactions or
messages.


The following is a brief definition of each Session Control Group. Detailed definitions may be found in
Section 6.0. The usage of each Session Control Group is specified in Section 5.0.


o

Signon Group: The primary Session Control Grou
p utilized in the signon procedure. Its function is
to transmit the session participant’s identification and other information required for overall session
control.


o

Signon Rejection Group: A Session Control Group transmitted in the signon procedure to ind
icate
that a received Signon Group contains invalid data.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
18

o

Receive Options Control Group: An optional auxiliary group utilized in the signon procedure. Its
function is to specify from which originating addressees, messages will be accepted in the session
and to place restrictions on the amount of data that will be accepted from each addressee.


o

Signoff Group: A control group used to indicate the logical termination of the session and the
imminent termination of the physical communications circuit.


o

Message

Acknowledgement Group (MACK): A control group used to acknowledge receipt of a
message and to indicate that no error was found in the message header or message trailer.


o

Stream Terminator Group (STERM): A control group which is used to indicate that a flo
w of
groups in one direction has been completed.


o

Negative Message Acknowledgement Group (NMACK): A control group used to acknowledge
receipt of a message and to indicate that an error was found in a message header or message trailer
data element.


o

Phase T
erminator Group (PTERM): A control group used to indicate that one phase of the
communications session has been completed.


5.0

THE BATCH COMMUNICATIONS SESSION


5.1

Definitions


A Batch Transmission Communications Session is defined to be the en
tire exch
ange of information (after
having established the communications link) between any two independent computer systems within some
discrete interval of time. A complete session will include all bi
-
directional data flow at the communications
application progra
m level from initiation to termination of the session.


The term
Session Initiator

refers to the Session Participant who transmits the first group of the session. This
group is always a Signon Group or a Control Request Group. Before the first group is tra
nsmitted,
procedures must be executed at the data link layer (and perhaps at the physical layer) in order to establish an
operations data link.


The term
Session Termination

refers to the data link layer and phy
sical layer
-
procedures required to
terminate

a communications ses
sion. Whenever it is specified in this Standard that a Session Par
ticipant
generates a Session Termination, it is not intended that normal data link procedures be short
-
cut. That is, it is
required that the appropriate data link pro
tocol acknowledgement procedures for all previously transmitted
and received data, be executed.


The functions described in this section are conceptually in layers
above

the data link protocol layer (OSI
layer 2). The manner in which communication is imple
mented at the data link protocol level will depend not
only on the line protocol (e.g. BSC, SDLC), but also on the particular device emulation by a given session
participant's system (e.g. 3780, System/3) and the processing software in a given session part
icipant's
system (e.g. CICS, JES2). This Standard does not address the data link protocol layer of communications.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
19

The presentation of the communications session in this Standard ad
dresses functions which are performed
by the session protocol (layer 5)
and the presentation protocol (layer 6) of the ISO reference model of
Open Systems Interconnection (OSI). The term
Communication

Application Program
or
Application
Program

when used in this Section 5.0, refers to a software module performing a layer 5 or

layer 6 function.

The location of the module in a user's system depends on the organization of the operating system and
communications software and will vary from system to system.


The important distinction to be made is that these terms do
not

apply to

insurance application programs
which may exist in the application layer (layer 7) of the ISO model.


During a communications session, the information which may flow between the two communicating
systems may have originated from several users of one system

and may be destined for several users of the
other system. For example, messages may originate from several agencies/brokerages sharing a computer
system. The messages may be addressed to several different insurance processing programs in a company
compu
ter system, or to several insurance company departments or branch offices serviced by that system.
The Session Participants are however, the two communicating computer systems and not one of the several
"users" of each system.


5.2

Functional Phases of th
e Communications Session


The Batch Communications Session as defined above is composed of four functional phases:


o

The Control Establishment Phase.

o

The Signon Phase.

o

A series of Message Transfer Phases.

o

The Signoff Phase.


It is assumed that prior to the
first phase, Control Establishment, the physical communications link, must be
established and the required protocol handshaking performed. This handshaking is at the data link protocol
level and is outside the scope of this Standard.



COMMENTARY


In a di
al
-
up 3780 BSC environment, one session participant makes a telephone call to establish the physical
communications link. One of the participants then successfully bids for the line, transmits session
-
oriented data
as described above, and thus becomes the

Session Initiator. This is usually the participant who made the
telephone call.

In a leased line 3780 BSC environment, the session is initiated by one of the two participants successfully bidding
for the line and transmitting session
-
oriented data when no

session is in progress.




The first functional phase, Control Establishment, provides for the session participants to each understand
which participant is to control the communications session. As explained in detail in Section 5.3, the
software require
d to act as a
Session Controller

is slightly different from that required to be the
Session
Responder.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
20

The Signon Phase, described in Section 5.4, is the phase in which each party identifies itself to the other and
agrees that a communications session in

which messages may be transferred can take place.


The message transfer function consists of a series of
Message Transfer Phases
. A
Message Transfer Phase

consists of a message or messages flowing in one direction and either real or implied message
ackno
wledgement or acknowledgements flowing in the opposite direction. Message Transfer Phases always
occur in pairs with the direction of message flow reversed between each transfer phase and its successor.
For instance, the initial Transfer Phase of a pair ma
y consist of an agent/broker sending messages to a
company and the company sending acknowledgements. In the second half of the Transfer Phase, the flow
reverses and the company transmits messages while the agent/broker acknowledges.
Note

that either party
may transmit the PTERM (Phase Terminator) if they have no messages to transmit in a phase. A
communications session must include at least one Message Transfer Phase pair. It may include several pairs.


Figure 5.2 shows two examples of a Message Transfer Ph
ase. In the first example, party A transmits a
single message to party B and party B acknowledges. In example 2, party A has two messages to transmit to
party B and each message is acknowledged. Each example shows a Message Transfer Phase. Examples 3
and 4

graphically show a Message Transfer Phase pair. In example 3, both party A and party B each transmit
one message and one acknowledgement; in example 4, party A transmits two messages to party B, who
acknowledges them, and then party B has one message for
party A, who acknowledges.


When the Batch Transmission Standard is being used in conjunction with a value added communications
network, it is important to note that the Message Sequence Number (MSN) is intended to maintain the
integrity of messages betwee
n two communicating systems as this is the only possible interpretation for use
of the MSN.


In order to establish an audit trail for messages travelling through the network in this manner, the Network
Reference Number (NRN) has been established. This numb
er is assigned by a network upon receipt of a
message and is thereafter passed, intact, through the remainder of the message's communications path. The
NRN will be defined individually by each network vendor as they implement the Batch Transmission
Standar
d.


The Signoff Phase is the one in which a communications session is terminated.
Session Termination

has
been defined above.



COMMENTARY


In a 3780 BSC leased line environment, a Session Termination may consist of the line being in an idle state (and
the

session parti
cipants' communications applications program being in an appropriate state).


In a 3780 BSC dial
-
up environment, a Session Participant would generate a Session Termination by transmitting a
BSC disconnect sequence (DLE EOT) and placing their

local telephone line "on
-
hook". On receipt of the
disconnect sequence, the other Session Participant places their local telephone line "on
-
hook". Some 3780
emulators currently in use in the agency/broker
-
company environment do not have the capability of
generating a
disconnect sequence on demand. In addition, some telephone companies do not terminate a telephone call until
the calling party goes "on
-
hook". In such cases, manual procedures must be implemented in order to prevent
excessive line charges.




Information that a Session Termination is imminent is provided to the communications applications programs
C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
21

by the Signoff Phase.


There are variations in each of the four types of phases, and especially in the organization of the message
transfer phases, d
epending on the choice of optional session control features. One of the purposes of the
optional features is to provide the mechanisms to permit several degrees of sophistication of restart/recovery
procedures. The restart/recovery mechanisms are also pres
ented later in this section.

C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
22

Figure 5.2



EXAMPLES OF A MESSAGE TRANSFER PHASE





PARTY A

PARTY B



Example 1:

MESSAGE (MSG)




ACKNOWLEDGEMENT (ACK)




Example 2:

MSG



ACK


MSG



ACK







EXAMPLES OF MESSAGE TRANSFER PHASE PAIRS




PARTY A

PARTY B



E
xample 3:

MSG



ACK


PHASE END



MSG


ACK



PHASE END




Example 4:

MSG



ACK


MSG



ACK


PHASE END



MSG


ACK



PHASE END


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
23

5.3

The Session Controller


5.3.1

Definition


In each communications session, one of the Session Participants exercises overall co
ntrol of the session and
is designated the
Session Controller.

The term
Session Responder

is used for the other Session Participant.


The Session Controller performs the following functions:


o

Initiates the Signon Phase


o

Initiates the first Message Transfer

Phase


o

Determines the number of Message Transfer Phases in the session


o

Initiates the Signoff Phase in an error
-
free session.


The Session Controller is established by the Session Initiator through their choice of the first Phase of the
communications s
ession. If the Session Initiator is to be the Session Controller, they initiate the Signon
Phase. If the other Session Participant is to be the Session Controller, then the Session Initiator initiates a
Control Establishment Phase.


5.3.2

The Control Esta
blishment Phase


The Control Establishment Phase consists of the following sequence of steps:


(a)

The Session Initiator transmits a Control Request Group.


(b)

The Session Answerer edits the Group Designator, Origination Machine Address, and Password
data

elements of the Control Request Group.


(c)

If no errors are found in the edited data elements and if the Session Answerer will accept control of
the session, they initiate the Signon Phase.


(d)

If an error is found in a data element or if the Session An
swerer will not accept control of the
Session, they transmit a Control Request Rejection Group. The Error Code data element specifies
the reason the group is transmitted.


(e)

When a Control Request Rejection Group is received by the Session Originator, t
hey must terminate
the connection according to the procedures of the data link protocol being used.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
24


COMMENTARY


In the current broker
-
company communications environment, the system initiating the communications session is
the Session Control
ler. In ne
arly all cases, the brokerage system initiates the session and does not have the
capability to automatically respond to a session initiation by another party. It is anticipated that, in the future,
brokerage systems may have a requirement to res
pond to s
ession initiations automatically. In order to lessen the
impact of the software development necessary to meet such a require
ment, this Standard provides for the above
mechanism to transfer session control to the Session Answerer. It is expected that imple
mentation of this
mechanism will be cost
-
effective relative to developing the capability to act as both Session Controller and Ses
-
sion Responder in brokerage systems.




5.4

The Signon Phase


5.4.1

General Description


The Signon Phase is the first phase

of the communications session executed by the Session Controller. It is a
two
-
way signon requiring validation of machine address and passwords by both participants. The purpose of
the procedure is to validate each Session Participant to the other and to p
rovide information required by each
participant for management of the session. The session management information includes information
relating to the configuration of the communicating systems, the type of message acknowledgement to be
used in the sessio
n, receive capacities of the systems, and requests for delivery of specific types of
messages.


5.4.2

Signon Phase Detail


The Signon Phase is illustrated in Figure 5.4. It consists of the following sequence of steps:


(a)

The Session Controller transmits

a Signon Group, followed optionally by one or more Receive
Options Control Groups.


(b)

The Session Responder edits the Signon Group Designator, the Origination Machine Address, and
Session Password data elements of the Signon Group. Additional data elem
ents of the Signon
Group and Receive Options Control Groups may also be edited by agreement between the two
participants.


(c)

If an error is found in a data
element, the Session Responder
transmits a Signon Rejection Group.
The Signon Rejection Group is a
n image of the Session Controller's Signon Group with different
values of the Signon Response Code and Error Code data elements. (The Group Desig
nator value is,
of course also
different). The Signon Response Code specifies the first data element in error a
nd the
erro
r code specifies the nature of
the error. After transmitting the Signon Rejection Group, the
Session Responder terminates t
he connection according to the
procedures of the data link protocol
in use.



If
no

errors are found in the data elements
which are edited, no Signon Rejection Group is
transmitted. The Session Responder transmits their own Signon Group followed, optionally, by
their Receive Option Control Groups.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
25

(d)

The Session Controller edits the Session Responder's Signon Group and Re
ceive Options Control
Groups. Again, at least the Signon Group Designator, Origination Machine Address and Session
Password must be edited.


(e)

If an error is found in a data element, the Session Controller will transmit a Signon Rejection Group
and then
terminate the connection according to the procedures of the data link protocol in use.



If
no

errors are found in the data elements which are edited, the Session Controller will begin
transmission of the first Message Transfer Phase. Receipt of any Group

Header other than a Signon
Rejection Group Header by the Session Responder at this point indicates that the Signon Phase has
been successfully concluded.

C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
26

Figure 5.4



THE SIGNON PHASE




SESSION

CONTROLLER



SESSION

RESPONDER




a.

Sends Signon Group f
ollowed, optionally,
by Receive Options Control Groups






b.


Edits Session Controller's data elements




c.


o
If error






Sends Signon Rejection Group, then
terminates communications connection
according to procedures of the data
link protoco
l in use.







o
else






Sends Signon Group, followed,
optionally, by Receive Options Groups.




d.

Edits Session Responder's data elements






e.

o
If error






Sends Signon Rejection Group, then
terminates communications
connection acc
ording to procedures
of the data link protocol in use.












o
else






Begins the first Message

Transfer Phase






C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
27

5.4.3

System Receive Capacity Specification


Each Session Participant may specify a maximum for the amount
of data to be received in the session. It is
the responsibility of the responding party to assure that this limit is not exceeded. This capacity is a
maximum capacity for the participating computer system and is specified by the capacity Unit Code and
Capa
city data elements of the participants Signon Group.


The receive capacity is the number of characters or element groups within messages that can be stored in a
system. Receive capacity is calculated on the basis of uncompressed data. Receive capacity inc
ludes the
capacity to receive both acceptable and unacceptable messages, implying that messages which are
NMACKed (not accepted) can deplete capacity.


The minimum unit of deliverable insurance data is a message. This Standard does not support delivery of
partial messages. The Additional Data Flag data elements of Message Trailer Groups and Stream Terminator
Groups indicate whether messages await delivery but cannot be delivered because of capacity limitations.


5.4.4

Message Delivery Options


Messages are
delivered between
physically

communicating pairs which may or may not be
logical

pairs (the
sender and ultimate receiver of a message).


5.4.4.1

Matching Addressee Message Delivery


A Session Participant may limit reception of messages in a communications
session to those Message
Addressees for whom the participant transmitted messages. In order to use this feature the Session
Participant must transmit their messages first, i.e., they must be the Session Controller. Matching Message
Address delivery is sp
ecified by the value of 99 in the Receive Options Indicator of the participants Signon
Group.


5.4.4.2

Selective Message Delivery Option


A Session Participant may specify that message delivery be restricted to specific Destination Message
Addresses, to s
pecific Origination Message Addresses, or to specific Destination Message
Address/Origination Message Address pairs for each Destination Address designated. The maximum amount
of data to be delivered for each of the above cases may also be specified.


Sele
ctive Message Delivery is specified by transmitting Receive Options Control Groups during the Signon
Phase.



COMMENTARY


The selective message delivery option is intended to be used by possible future multi
-
user insurance
agency/brokerage systems. It is e
xpected that value
-
added networks will have the capability of responding to the
option. It is also expected, but not required, as part of this Standard, that insurance company systems will be able
to respond to the option.




C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
28

Insurance agency/brokerage sy
stems are not required to respond to any message selection criteria other than
system receive capacity. The more complex criteria described above are intended for the "special case", and
are expected to be the exception rather than the rule.


5.5

Message
Transfer Process


Transfer of messages between the Session Participants is accomplished in Message Transfer Phases. As
defined in Section 5.2, a Message Transfer Phase (MTP) is a part of the message transfer process in which
all
messages

flow in the same
direction. Session control groups, however, may be transmitted in both
directions during one Message Transfer Phase.


The term
Message Transmitter

refers to the Session Participant who is transmitting messages during a
Message Transfer Phase and the term
M
essage Receiver

refers to the other Session Participant. Message
Transfer Phases occur in pairs. The Message Transmitter of the first MTP of the pair is always the Session
Controller. The direction of message flow reverses from one MTP to the next. Thus, t
he roles of the
Message Transmitter and Message Receiver are reversed as one MTP ends and the next MTP begins.


The number of Message Transfer Phase Pairs (MTPPs) in a session is variable but is normally at least one.
The number of MTPPs is determined by
the Session Controller. After the completion of an MTPP, the
Session Controller may start another MTPP or they may initiate a Signoff Phase.


If the Message Transmitter for a Message Transfer Phase does not wish to send messages in that MTP, they
transmit
only a Phase Terminator Group.


5.5.1

Message Acknowledgement Options


Three types of Message Acknowledgements are provided, varying from data acknowledgement only (at the
data link protocol level) up to communications application program acknowledgement o
f each message. The
type of Message Acknowledgement employed between a pair of Session Participants is normally determined
by contractual agreement between the two parties. The confirmation of the correct Message
Acknowledgement option is accomplished duri
ng the Signon Phase by means of the Message
Acknowledgement option data element in the Sign
-
on Group. The message acknowledgement options
provide information for audit trails and input to manual and automatic recovery
-
restart procedures.


Note that both ha
lves of a Message Transfer Phase pair must use the same option.


5.5.1.1

Option A


Option A provides for no Message Acknowledgement at the communications application program level. All
transmission acknowledgements are at the data link protocol level. Thi
s option is specified by a zero value of
the Message Acknowledgement Option data element. No transmission checkpoints are used.


An Option A Message Transfer Phase is illustrated in Figures 5.2 and 5.6. All groups flow from the
Message Transmitter to the

Message Receiver. The MTP consists entirely of a sequence of messages, with
the last message followed by a Phase Terminator Group (PTERM).


The second half of the Message Transfer Phase pair is identical in construction but in the opposite direction.



C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
29


Figure 5.2



Message Acknowledgement Option A




Message


MSG

MSG

MSG

...

MSG

PTERM

Transmitter


Message


(sends no groups)

Receiver





COMMENTARY


It is likely that some individual participants may find use of Option A an inadequate procedure because of
its
limited capability for restart/recovery while others may consider its simplicity and ease of implementation to be
the overriding factors.




5.5.1.2

Option B


Option B provides for a single acknowledgement of the messages received in the Message Tran
sfer Phase.
The Message Transmitter sends all their messages in the MTP followed by a STERM. The Message Receiver

may edit the count fields of the STERM. They then transmit a STERM to the Message Transmitter. An
Emergency Signoff Phase may be issued if an
error is found in the following data elements:


o

An error in the count fields (STG0l or STG02) of the Stream Terminator Group


o

An error in the Message Sequence Number of the Message Header Group


If there are no errors, the Message Transmitter then sends a

PTERM to the Message Receiver to indicate the
reception of the Message Receiver's STERM and to terminate the Transmission Phase.


Option B is specified by a value of 9999 of the Message Acknowledgement Option of the Signon Group. A
Transmission Phase in w
hich Option B is used is illustrated in Figures 5.3 and 5.6.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
30


Figure 5.3



Message Acknowledgement Option B




Message

MSG

MSG

...

MSG

STERM


PTERM

Transmitter


Message







STERM

Receiver





COMMENTARY


Option B is considered an "intermediate" level o
f acknowledgement which some participants may find an adequate

compromise between Option A and the more complex, secure, but correspondingly difficult to implement,
acknowledgement Option C which follows.




5.5.1.3

Option C


Option C provides for a comm
unications applications program level acknowledgement of each message
transmitted. The acknowledgement is accomplished by the Message Receiver transmitting a Control Group
for each message received. Messages are tran
smitted in units, called
Message Strea
ms
, with a specified
number (N) of messages in each Message Stream. Each Message Stream, with the possible exception of the
last one in the Message Transfer Phase, will contain the same number of messages.


The Message Receiver will determine that a Messa
ge Stream has been received by counting messages. There
is no application level termination of a Message Stream, with the exception that the last Message Stream is
always terminated by the transmission of a Stream Terminator Group. If the number of message
s
transmitted in the Message Transfer Phase is exactly divisible by N, then the last Message Stream will
consist only of the Stream Terminator Group.




COMMENTARY


There may be a data link protocol termination of each Message Stream, depending on the pro
tocol. For example,
if BSC is used, the Message Transmitter must release the line after transmitting each Message Stream so that the
Message Receiver may transmit message acknowledgements.




C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
31

When a Message Stream has been received, the Message Receiver
trans
mits the message acknowledgements
for the messages in the Message Stream. The message acknowledgements are transmitted in the same order
as their corresponding messages.


The number (N) of messages in each Message Stream may range from 1 to 8999 and
is specified by
assigning that value to the Message Acknowledgement Option data element in the Signon Group. If N is
larger than the number of messages transmitted, there will be only one Message Stream. A value of 9998 for
the Message Acknowledgement Opt
ion data element is used to deliberately represent a number larger than the
number of messages to be transmitted. Thus, if 9998 is specified as the Message Acknowledgement Option,
all messages will be transmitted in one Message Stream, regardless of their
number.


Option C is illustrated in figures 5.4, 5.5, and 5.6.



Figure 5.4



Message Acknowledgement Option C for N = 9998




Message



MSG

MSG

...

MSG

STERM

Transmitter










PTERM


Message









MACK

MACK

...

MACK

STERM

Receiver





Figure 5.5



Message Acknowledgement Option. C for N = 2




Message



MSG

MSG

...

MSG

MSG


MSG

STERM

Transmitter











PTERM


Message





MACK MACK



MACK MACK

MACK STERM

Receiver






C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
32

One function of the Message Acknowledgement is to inform the Message Transmitte
r that the message has
been accepted or rejected by the receiving communications application program. Acceptance consists of
locating and identifying the Message Header and the Message Trailer and editing certain data elements in
those two groups. Note tha
t in order to identify the start of a message, each successive group header may be
located by use of the Group Length data element of the preceding group.


The
Total Data In Message

field in the Message Trailer Group must be verified by the Message Rec
eiver
as part of the Message acknowledgement function.


Each Message Acknowledgement is one of two control groups: A Message Acknowledgement Group
(MACK) is transmitted to indicate a positive acknowledgement and a Negative Message Acknowledgement
Group (N
MACK) is transmitted to indicate a negative acknowledgement. The MACK contains data elements
which uniquely identify the message being acknowledged to the Message Transmitter.


The NMACK is an image of the Message Header Group of the message being acknowle
dged. The values of
all data elements are the same as in the received message, except for the group Designator and the Message
Response Code and Error Code data elements. The Message Response Code specifies the first edited data
element found to be in erro
r. The Error Code specifies the type of error.


In all cases the sender of a message is responsible for that message until a MACK has been received. That is,
they must save (or be able to reconstruct) the message until they know the receiver has MACKED it.

Once
the message has been MACKED, the receiver takes over responsibility for it.


If the sender of a message receives an NMACK, they
remain

responsible for that message and for the
handling of the NMACK. An NMACK may
not

be issued for any errors other tha
n the ones itemized below
unless

the "physically" communicating pair is the same as the "logically" communicating pair.


o

The machine’s address portion of the Origination Message Address (in direct link communications
only)


o

The message sequence number of
the Message Header Group


o

The count data elements of the Message Trailer Group


If the NMACK was issued for an error in a data element other than those listed above, the responsibility for
the message and the handling of the NMACK is to be negotiated betwe
en the communicating Session
Participants.


If a message is NMACKED for a message sequence number error, all subsequent messages transmitted by
the Session Participant who transmitted that message, will be acknowledged by NMACKS which indicate the
same err
or. The alternative is to initiate an Emergency Signoff Procedure upon receipt of a message which
contains a message sequence number error.


If a Control Group Designator is in error, the Message Receiver will initiate an Emergency Signoff
Procedure.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
33

A M
essage Transfer Phase starts with the transmission of the first Message Stream and continues with
transmission of alternating acknowledgement transmissions and Message Stream transmissions until the last
Message Stream in the MTP has been transmitted.
As mentioned previously, the last Message Stream is
terminated with the transmission of a Stream Terminator Group (STERM).


Receiving the STERM indicates to the Message Receiver that the last Message Stream contains a short count
of messages and that the n
ext transmission will be a PTERM.


The Message Receiver then transmits the message acknowledgements for the last Message Stream and
follows them by a STERM.


After receiving the Message Receiver's STERM, the Message Transmitter sends a PTERM to the Messa
ge
Receiver. The PTERM notifies the Message Receiver that the Message Transmitter has received the
Message Receiver's STERM and that the Message Transfer Phase has been completed.


5.5.1.4

Count Verification Feature


An optional Count Verification Featur
e is provided. Use of this feature is normally determined by contractual
agreement between the two communication parties. Its use is specified via the Count Verification Indicator in
the Signon Group. The feature does not apply to Option A or C.


The STER
M transmitted by each Session Participant in a Message Transfer Phase contains data elements
specifying the total data transmitted and the total number of messages or message acknowledgements, as
applicable, transmitted by the Session Participant in the MT
P. The total data includes the characters in the
STERM. It does not include data link protocol control characters or other characters, if any, which are
considered to be transparent to the message group structure of this Standard.


On receipt of the Messag
e Transmitter's STERM, the Message Receiver may edit the Total Data in Phase
and Total Messages data elements against their accumulations. The Stream Terminator Response Code of the
Message Receiver's STERM may be used to indicate a disagreement to the M
essage Transmitter. In this
case, the Message Receiver may initiate an Emergency Signoff after transmitting the STERM.



Figure 5.6 (a)



Message Acknowledgement Option A




Message


MSG


MSG


MSG

...


MSG


PTERM

Transmitter


Message





(sends no groups)

Receiver




C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
34


Figure 5.6 (b)



Message Acknowledgement Option B




Message


MSG


MSG

...

MSG


STERM


PTERM

Transmitter


Message









STERM

Receiver





Figure 5.6 (c)



Message Acknowledgement Option C for N = 9998




Message


MSG

MSG


...

MSG

STERM


PTERM

Transmitter


Message




MACK

MACK

...

MACK

STERM

Receiver





Figure 5.6 (d)



Message Acknowledgement Option C for N = 2




Message

MSG

MSG


...

MSG

MSG


MSG

STERM


PTERM

Transmitter


Message



MACK

MACK


MACK

MACK



MACK STERM

Receiver




C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
35


COMME
NTARY


It is implied that use of the Count Verification Feature in Message Acknowledgement Option B, means that
messages cannot be submitted for processing by the receiver's application system until the receiver is sure that
they have accurately and comple
tely received all of the messages in that stream.


Any other action on the receiver's part, could bring about a situation where a message has been processed with
an intermediate level (before the stream is completed) only to find that the two communicants
disagree on the
count verifications in their respective STERMS. This would be an intolerable situation and must be avoided, as
described above, if the Counter Verification Feature is used.




On receipt of the Message Receiver's STERM, the Message Transmi
tter may edit the Total Data in Phase
and Total Messages data elements. The Total Messages data element, if used, will contain the number of
message acknowledgements the Message Receiver has transmitted in the MTP. If the counts do not match
their accumula
tions, the Message Transmitter should indicate the error by initiating an Emergency Sign
-
off.


5.6

The Signoff Phase


5.6.1

Normal Signoff Phase


The Signoff Phase is a two
-
way signoff requiring a transmission by both Session Participants. The function
of
the Signoff Phase is to provide for an orderly shutdown of the communications session at the
communications applications program level. The Signoff Initiator initiates the Signoff Phase by transmitting a
Signoff Group and the Signoff Answerer responds by a
lso transmitting a Signoff Group A Signoff Phase is
required in all cases before the generation of a Session Termination.


The following sequence of steps constitutes the Normal Signoff Phase:


o

The Signoff Initiator transmits a Signoff Group. The Signoff
Group is the last group transmitted by
that Session Par
ticipant. It informs the other Session Participant, the Signoff Receiver, that a
Session Termination is imminent.


o

The Signoff Receiver transmits a Signoff Group to the Signoff Initiator. This is the
only valid
response by the Signoff Receiver.


o

After the Signoff Initiator receives any transmission from the Signoff Receiver, they then initiate a
Session Termination.


o

If the Signoff Initiator receives no response from the Sign
-
off Receiver within a spec
ific period of
time, the Signoff Timeout Period, they initiate a Session Termination. The duration of the Signoff
Timeout Period is established on an individual user basis.


In the absence of an error condition, a communications session is terminated by th
e Session Controller after
the completion of a Message Transfer Phase Pair. The Session Controller always initiates the Signoff Phase
for a normal session termination.


C110



12
(i)

©
2012

CSIO
TRANSMISSION

SESSION

STANDARD

OPTIONS

page
36

5.6.2

Emergency Signoff Phase


The communications session may be terminated prior to i
ts normal completion under certain conditions by
either Session Participant. The Signoff Phase employed under these circumstances is called an Emergency
Signoff. It is distinguished from a Normal Signoff by the value of the Signoff Type data element of the

Signoff Initiator's Signoff Group, and the fact that the Signoff Receiver makes no response to the Signoff
Initiator upon receiving the Signoff Group.


An Emergency Signoff may be initiated during the Message Transfer Procedure at the following points:


o

T
he current Message Transmitter may initiate an Emergency Signoff by transmitting a Signoff
Group when they would otherwise transmit a Message Header Group, a STERM, or a PTERM.


o

The current Message Receiver may initiate an Emergency Sign
-
off when they woul
d otherwise
transmit a MACK, a NMACK, or a STERM.


o

Either Session Participant may initiate an Emergency Signoff in case of a communications
application program timeout. Such a timeout occurs if the communications session is apparently
active at the data li
nk protocol level but an expected transmission is not received within the