CSIO TRANSMISSION SESSION STANDARD OPTIONS
CSIO Std.#:
Version:
Date:
Status:
C110
12(i)
March, 2012
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
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
Purpose 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 System 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 Controller ...................................................................................................... 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 Options Control Group
4ROC .................................... 56
Signoff Group
4SOF .................................... 60
Message Acknowledgement Group
4MAK .................................... 63
Negative Message Acknowledgement Group
4NMK .................................... 66
Stream Terminator Group
4STG .................................... 70
Phase Terminator Group
4PTG .................................... 73
Control Request Group
4CRG .................................... 76
Control Request Rejection Group
4CRR .................................... 79
C110- 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 2
CSIO TRANSMISSION SESSION STANDARD – INTERNET .......................................................... 83
RECORD OF AMENDMENTS .................................................................................................. 84
1.0
INTRODUCTION ........................................................................................................................ 85
2.0
TRANSACTION FLOW ............................................................................................................. 85
3.0
CSIO STANDARD TRANSMISSION MESSAGES ................................................................. 85
3.1
CSIO Data Transmission ................................................................................................... 85
3.2
Mail Box Delivery Notification Message .......................................................................... 88
3.3
Acknowledgement Message Format .................................................................................. 88
C110- 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 3
CSIO TRANSMISSION SESSION STANDARD - BATCH
RECORD OF AMENDMENTS
Release
Date
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 definitions to
C900 - Document renamed to 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 5
CSIO TRANSMISSION SESSION STANDARD
1.0
INTRODUCTION
1.1
Purpose of This Standard
The purpose of this 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 specifically oriented towards batch (as 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 broker-company data communications capability. It contains requirements for the
preferred implementation of message text and transmission control elements within a data
communications session. This Standard will serve to establish definitions for the characteristics of the
information-carrying structure within the overall communications envelope between any two independent
systems.
This Standard assumes the existence of the various data communication 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 established 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, provision 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 distinction 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 sending 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 designed 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 communications 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 environment 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 and 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 expected to transmit information to or receive information
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 6
from companies by using a physical or protocol interface which is different on a company-by-company basis.
The Intelligent Access Functional specifications detail the protocols required and the functions 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 sections 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 addition, 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 components (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, that 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 data 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 anticipated 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 influences, 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 implementation 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,
and element groups.
o
Section 4.0, provides a description of the session structure specified.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 7
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 or "optional" control groups.
o
Section 6.0, is a detailed, element-by-element, description 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 modifications, 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 Standards 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 International Standards Organization (ISO) has
developed a general model 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 Interconnection (OSI), provides a useful framework for the discussion 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 the OSI model
together with a discussion of where within the model the message structure and session control procedures
fall.
2.2
ISO Open System Interconnection Reference Model
The protocol Reference Model of Open System Interconnection of the International 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 communicating 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 considering 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 is 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 system B as opposed to virtual
communication at the higher levels.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 8
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 below. 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
those of the OSI Reference Model.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 9
Figure 2.1
ISO OPEN SYSTEM INTERCONNECTION REFERENCE MODEL
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 10
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 are 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 transmission errors to the next higher layer, the Network Layer. Some typical data link protocols in
use are SDLC, binary 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. Although 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 layers. 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 Network 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 its 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 example), 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 11
This is specifically the case with packet switch networks in general and the Intelligent Access implementation
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 verify 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
and, 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 is 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 multiplex 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 virtual 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 provides 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 the 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 compression
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 this 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 operating systems or application software.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 12
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 make 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 intermediary 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 specifically aimed at being useful in the
current agent/broker-company environment 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 will 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 capability to systems 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 characters 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
protocol 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 13
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 opposed 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 transactions 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 companies
could be transmitted in a single communications session to a value-added network which would, possibly
among other value-added functions, route and transmit individual messages to their individual addresses.
In the absence of a value-added network, 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 for an broker's system to transmit individual transactions as they occur and thus send
single-transaction messages. 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 application 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 level. 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 batch
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 insurance-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-machine 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 also 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 and 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 14
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 support 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 individual messages to various
company locations such as a claims, branch office, etc.
b.
If an agent/broker system is being shared by several agencies/ brokerages, 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 transmission 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 15
Figure 3.1
COMPONENTS OF THE TRANSMISSION STREAM
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 16
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 individual 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 acknowledgement:
(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 used 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 transaction control
information. Specification of message acknowledgement 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 indicate 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 CONTROL 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 direct 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 transactions 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 Group 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
indicate that a received Signon Group contains invalid data.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 17
5.0
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 flow 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 Terminator Group (PTERM): A control group used to indicate that one phase of the
communications session has been completed.
THE BATCH COMMUNICATIONS SESSION
5.1
Definitions
A Batch Transmission Communications Session is defined to be the entire exchange 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 program 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 transmitted,
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 physical layer-procedures required to
terminate a communications session. Whenever it is specified in this Standard that a Session Participant
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 protocol 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 implemented 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
participant'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 18
The presentation of the communications session in this Standard addresses 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
computer 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 the Communications Session
The Batch Communications Session as defined above is composed of four functional phases:
o
o
o
o
The Control Establishment Phase.
The Signon Phase.
A series of Message Transfer Phases.
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 dial-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 required 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 19
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
acknowledgement 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 may 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 Phase. 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 between 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 number 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
Standard.
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 participants' 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.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 20
Information that a Session Termination is imminent is provided to the communications applications
programs 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, depending 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 presented later in this section.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 21
Figure 5.2
EXAMPLES OF A MESSAGE TRANSFER PHASE
PARTY A
Example 1:
PARTY B
MESSAGE (MSG)
ACKNOWLEDGEMENT (ACK)
Example 2:
MSG
ACK
MSG
ACK
EXAMPLES OF MESSAGE TRANSFER PHASE PAIRS
PARTY A
Example 3:
PARTY B
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 22
5.3
The Session Controller
5.3.1
Definition
In each communications session, one of the Session Participants exercises overall control 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 session. 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 Establishment 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 Answerer 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, they 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 23
COMMENTARY
In the current broker-company communications environment, the system initiating the communications session
is the Session Controller. In nearly 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 respond to session initiations automatically. In order to lessen
the impact of the software development necessary to meet such a requirement, this Standard provides for the
above mechanism to transfer session control to the Session Answerer. It is expected that implementation of
this mechanism will be cost-effective relative to developing the capability to act as both Session Controller and
Session 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 provide 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 session, 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 elements 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 an image of the Session Controller's Signon Group with different
values of the Signon Response Code and Error Code data elements. (The Group Designator value
is, of course also different). The Signon Response Code specifies the first data element in error
and the error code specifies the nature of the error. After transmitting the Signon Rejection
Group, the Session Responder terminates 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, 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 24
(d)
The Session Controller edits the Session Responder's Signon Group and Receive 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 25
Figure 5.4
THE SIGNON PHASE
SESSION
CONTROLLER
a.
SESSION
RESPONDER
Sends Signon Group followed, 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 protocol 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 according 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 26
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
Capacity 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 includes 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 specified 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 specific 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.
Selective 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 expected 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 27
Insurance agency/brokerage systems 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 Message 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, the 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 of 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 during 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 halves 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. This 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 28
Figure 5.2
Message Acknowledgement Option A
Message
Transmitter
MSG
MSG
MSG
Message
Receiver
(sends no groups)
...
MSG
PTERM
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 Transfer
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 which Option B is used is illustrated in Figures 5.3 and 5.6.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 29
Figure 5.3
Message Acknowledgement Option B
Message
Transmitter
MSG
MSG
...
MSG
STERM
Message
Receiver
PTERM
STERM
COMMENTARY
Option B is considered an "intermediate" level of 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 communications 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 transmitted in units, called Message Streams, 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 Message 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 messages
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 protocol. 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 30
When a Message Stream has been received, the Message Receiver transmits 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 Option 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
Transmitter
MSG
MSG
...
MSG
STERM
PTERM
Message
Receiver
MACK MACK ...
MACK STERM
Figure 5.5
Message Acknowledgement Option. C for N = 2
Message
Transmitter
MSG
Message
Receiver
C110 – 12(i)
MSG
...
MSG
MACK MACK
©2012
MSG
MSG
STERM
PTERM
MACK MACK MACK STERM
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 31
One function of the Message Acknowledgement is to inform the Message Transmitter 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 that 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
Receiver 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 (NMACK) 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 acknowledged. 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 error. 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 than 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 between 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 error. 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 32
A Message 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 next 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
Message 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 Feature 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 STERM 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 MTP. 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 Message 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 Message 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
Transmitter
MSG
Message
Receiver
C110 – 12(i)
MSG
MSG
...
MSG
PTERM
(sends no groups)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 33
Figure 5.6 (b)
Message Acknowledgement Option B
Message
Transmitter
MSG
MSG ...
MSG
STERM
Message
Receiver
PTERM
STERM
Figure 5.6 (c)
Message Acknowledgement Option C for N = 9998
Message
Transmitter
MSG
Message
Receiver
MSG
...
MSG
MACK MACK ...
STERM
PTERM
MACK STERM
Figure 5.6 (d)
Message Acknowledgement Option C for N = 2
Message
Transmitter
MSG
MSG
Message
Receiver
C110 – 12(i)
...
MACK MACK
©2012
MSG
MSG
MSG
STERM
MACK MACK
CSIO TRANSMISSION SESSION STANDARD OPTIONS
PTERM
MACK STERM
page 34
COMMENTARY
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 completely 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 Transmitter 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 accumulations, 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 also 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 Participant. 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 specific 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 the 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 35
5.6.2
Emergency Signoff Phase
The communications session may be terminated prior to its 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
The 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 would 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 link protocol level but an expected transmission is not received within the
communications program timeout period. The duration of this period is to be established on an
individual basis.
o
If the Count Verification Feature of Message Acknowledgement Option B is implemented, an
Emergency Signoff Phase may be initiated for the error conditions specified in Section 5.5.2.4.
For Restart/Recovery purposes, an Emergency Signoff has the same effect as a communications line
failure at the point the Signoff Phase is initiated.
5.7
Restart/Recovery Procedures
5.7.1
Introduction
The Restart/Recovery Procedures described below are designed for three basic purposes:
o
To assure that no messages transmitted between Session Participants are lost.
o
To assure that no duplicate messages are transmitted without the receiver of a message being fully
advised that a message might be a duplicate.
o
To permit a participant, optionally, to avoid re-transmitting messages which they knows have
been successfully received prior to the advent of a session abort.
The specific procedure employed between a pair of Session Participants must be determined by the
message acknowledgement option selected (as described in Section 5.5) by prior agreement between the
Session Participants.
All restart/recovery procedures are based on recognizing the requirement for re-transmission of either a
complete session, a Message Transfer Phase, or partial Message Transfer Phase.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 36
o
Message Acknowledgement Option A is, in effect, an example of an entire communications
session being composed of a single message transfer phase pair. In the event of a session abort at
any point during the session, the entire session must be re-transmitted since message transmitters
have no way of assuring that their messages have been received short of the successful
completion of the session.
o
Option B, as described in Section 5.5 allows participants to avoid, optionally, re-transmitting
message transfer phases which have been successfully completed prior to the session abort.
o
Participants having selected message acknowledgement Option C are given the ability to avoid
re-transmitting any portion of a message transfer phase which has been successfully completed
prior to a session abort.
Thus, restart/recovery procedures are based on the principle that re-transmission must occur for whatever
portion of a communications session is not known to have been completed successfully. Successful
completion of any portion of a session is defined to mean that the transmitter knows that receiver has
successfully received their transmission. As described above, the message acknowledgement options
described in Section 5.5 allow users of Option C to know whether or not individual messages have been
received successfully, users of Option B to know whether or not a Message Transfer Phase has been
received successfully and users of Option A to know only whether or not an entire session has been
completed successfully.
Since Restart/Recovery is concerned with the integrity of messages, sessions need be recovered, if they
fail during a Message Transfer Phase. Sessions that abort or are discontinued during Signon or Normal
Signoff Phases need not be recovered.
When a communications session is aborted both parties will promptly set the value of the Session Restart
Flag in their respective Signon Group to indicate a phase restart in the restarted session.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 37
Figure 5.7
RESTART/RECOVERY EXAMPLES
SESSION
CONTROLLER
Message Transmitter
Message Receiver
(First Phase)
(First Phase)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
C110 – 12(i)
SESSION
RESPONDER
MSG #1
MSG #2
MSG #3
MACK (MSG #1)
MACK (MSG #2)
MACK (MSG #3)
MSG #4
MSG #5
STERM
MACK (MSG #4)
MACK (MSG #5)
STERM
PTERM
Message Receiver
Message Transmitter
(Second Phase)
(Second Phase)
14.
15.
-----
MSG #362
MSG #363
----(Etc.)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 38
Referring to figure 5.7, a Message Transfer Phase is indicated by items 1 through 13. The Message
Transmitter knows that the phase has been successfully completed when they receive message #362 (Item
#14) from the Message Receiver. A message transmitter becomes a receiver just prior to sending a
PTERM. This is true, regardless of whether or not they receive the required response. Some examples of
restart/recovery philosophy using figure 5.7 as a reference, are:
a.
If the session is aborted during transmission of message 3, the Message Transmitter, having
received no indication that any messages have been received, must re-transmit beginning with the
start of the Message Transfer Phase.
b.
If the session is aborted during transmission of the MACK for message 3 (item 6 in figure 5.7),
the Message Transmitter, having received MACKs for messages 1 and 2, has the option of
beginning re-transmission with message 3 in the restated session.
c.
If the Session is aborted after the Message Transmitter has sent their PTERM (item 13) but before
they have received message 362 (item 14) from the receiver, the Message Transmitter, will
consider themselves a receiver and await data. If the original receiver received the PTERM they
will now be in a transmit mode and begin to transmit messages, starting with MSG#362. If they
did not receive the PTERM they will still consider themselves a receiver. However, when they
receive the transmitter's PTERM, in the restarted session, they will then switch mode to
transmitter and begin to transmit messages, starting with MSG#362.
d.
If, in the situation described above, the receiver having switched modes had no messages to
transmit, they would transmit a PTERM of their own, concluding the restarted session. This
situation, in which neither participant in a restarted session has messages to transmit results in a
restart session with no data exchanged, a "null" session. This circumstance will happen
infrequently.
Note that figure 5.7 is a specific example of Option C as described in Section 5.5 but also includes
Options A and B as special cases of Option C and thus applies to all message transfer options.
The critical point is that a Transmitter become a receiver as soon as they send a PTERM and a receiver
becomes a transmitter as soon as they receive a PTERM.
When a (restarted session) controller was the transmitter in the aborted session, they may send either
message, a STERM, or a PTERM in a restarted session. If a controller believes they were the receiver,
they may send only a PTERM.
When a (restarted session) responder was the transmitter in the aborted session, they may send either
messages, a STERM, or a PTERM. If the responder believes they was the receiver, their action will be
dictated by what they have received in the restarted session. If it was a message, they remain in normal
receive mode. If it was a PTERM, they will switch to transmit mode and send messages if they have them
to send. If not, they will transmit a PTERM, concluding a "null" session.
This rather complex manoeuvring allows the restart/recovery when neither party knows exactly whether or
not their partner got the intended message or control group.
The procedures and examples outlined above and described in detail in the remainder of this Section 5.7,
are specifically designed to provide for restart/recovery in the broker-company environment described in
the following commentary.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 39
COMMENTARY
In most data communications environment, the transmitter of messages is expected to be capable of
re-transmitting a given message until they know it has been successfully received. Since the transmitter must
be alert to the possibility that the original message was in fact received even though he, the transmitter, are not
aware of that fact, it is often prudent for all re-transmission of a message to be marked by the transmitter as
"duplicates". This provides the message receiver with two options. They may choose to process messages as
they are received and be prepared to "throw away" messages marked "duplicate" if they have already been
processed, or they may choose to suspend processing of messages they receive until they, the receiver, knows
that the transmitter knows that they have been received and that they will thus not re-transmit the message.
This process depends on the Message Transmitter being able to guarantee that any messages re-transmitted are
exact duplicates of the original message. If this were not so, the Message Receiver would have no option but
to suspend processing because there would be no way to "throw away" messages since they may not be exact
duplicates of the original which been processed. In the existing broker-company environment, there are
systems, particularly brokerage systems, that construct messages "on the fly" from their data bases and are not
in a position to guarantee that re-transmitted messages are exact duplicates of the message which was being
transmitted when the communications session was aborted. There are, of course, other systems which do have
that capability.
If the Message Transmitter cannot guarantee re-transmission of exact duplicate messages, the Message
Receiver must suspend all messages received until they know that the transmitter is aware of the fact that they
have been received and thus not re-transmit the given message. There is no alternative if message integrity is
to be maintained.
A flag has been provided in the Signon Group called a Recovery Type Flag to indicate whether or not the
session participant is capable of guaranteeing that re-transmitted messages will be exact duplicates of the
messages in the aborted communications session. The restart/recovery procedures described overleaf have
been designed to be identical under either circumstance. The only difference will be in the processing
required by the message receiver's system. In one case, messages may be processed as they are received
while in the other, messages must be suspended until
the receiver knows that the Message Transmitter is aware of the fact that a message has in fact been
received successfully.
The above philosophy has been implemented in the following set of rules.
5.7.2
Definitions and Rules
The following definitions and rules are applicable to the message delivery process and restart/recovery
procedures.
A communications session is considered to be established if the first Message Transfer Phase has begun.
An established communications session is defined to have been aborted if any of the following conditions
occur before the Session Responder has received the Session Controller's normal Signoff Group.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 40
a.
There is a line failure, that is, an abort at or below the data link protocol level.
b.
Either Session Participant initiates an Emergency Signoff as a result of a communications
program timeout, reception of unrecognizable data, or any other reason.
A Message Transfer Phase is defined to be aborted if the communications session is aborted at any point
after the Message Transmitter for the MTP has started transmitting their first message and before they
have received a valid response to transmission of their PTERM. The following rules apply to the
restart/recovery procedure.
o
If a communications session is aborted, the next session between the two Session Participants
will be a restart session.
o
The Session Initiator for the aborted session is responsible for seeing to it that the restart session
is initiated. The Session Controller for the aborted session will be the Session Controller for the
restart session.
o
Either Session Participant may set the value of the Session Restart Flag of their Signon Group to
indicate a restart session. Otherwise the Session Restart Flag will indicate an original session. See
Section 6.1.12.
o
If the Session Restart Flag of the Session Controller indicates an original session and that of the
Session Responder indicates a restart session, the Session Controller will transmit a PTERM so
that the aborted session may be concluded.
The following rules apply to the Message Transmitter for an aborted Message Transfer Phase.
o
The Message Transmitter for an aborted Message Transfer Phase must retransmit any messages
or control groups for which they have not received an expected response. An Emergency Signoff
Group is not an expected response but an NMACK is an expected response to a message.
o
A Message Transmitter in an aborted Message Transfer Phase, may not retransmit messages from
message streams prior to the one during which the session was aborted. That is, messages from a
prior (already acknowledged) message stream may not be retransmitted.
o
If the Message Transmitter guaranteed duplicate message re-transmission for the aborted session,
the Transmission Status Flag data element of the Message Header of each re-transmitted message
must specify a duplicate message.
o
If the Message Transmitter did not guarantee duplicate message re-transmission for the aborted
session, the Transmission Status Flag for the first re-transmitted message must specify a
replacement message.
The following rules apply to the Message Receiver for a normal Message Transfer Phase:
o
C110 – 12(i)
If the Message Transmitter has guaranteed duplicate message re-transmission for the session, no
message suspension is required.
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 41
o
If the Message Transmitter has not guaranteed duplicate message re-transmission for the session,
the Message Receiver must suspend processing of received messages until, after transmitting one
or more groups, they receive a valid group other than an Emergency Signoff Group.
o
If a communications session is aborted, then all messages in suspense at the time of the abort
remain in suspense.
The following rules apply to a Message Receiver for a restarted Message Transfer Phase if the Message
Transmitter did not guarantee duplicate message re-transmission.
o
If the first group (following the Signon Phase) received by the Message Receiver is a control
group that they would next expect to receive, had the Message Transfer Phase not aborted, (i.e.
Message Header, STERM or PTERM) they continue processing as if the MTP had not failed.
o
If the first group received is not a next expected control group, it must be a Message Header. The
Message Sequence Number data element of the Message Header must be that of a suspended
message and the Transmission Status Flag must specify a replacement message. In this case, the
Message Receiver releases from suspense (for processing) those messages with Message
Sequence Number prior to that of the newly received message and purges the remaining
suspended messages. The newly received message is then suspended and the Message Receiver
continues processing from this point as if the MTP had not failed.
o
If the first group or the first message received is in error (a message which is "NMACKed" is not
an error for restart purposes), the Message Receiver will purge all data received in the restarted
MTP and initiate an Emergency Signoff at the first opportunity.
5.7.3
Option A: Additional Requirement
If the Message Acknowledgement Option A is in effect for a communications session, both participants
must specify duplicate message re-transmission for the session.
6.0
GROUPS (DETAIL)
6.1
Documentation Format
Each of the control groups are documented in three sub-sections which cover Group Format, Group Data
Elements and an example of a hypothetical group.
The Group Format sub-section provides an overall picture of the control group including its header and
each data element of the group in its proper sequence. This sub-section also provides the specified value
for the data elements which make up the group header itself. Where specified, the value for these data
elements must be followed exactly. For the data elements which make up the group, following the header,
this sub-section also provides each element's length attribute in characters, its data type and its presence
code. (See Standard No.C900 for a full explanation of data element attributes).
The sub-section covering the group data elements provides a detailed description of the function and
content of each data element which is found in the group outside of the header.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 42
The last sub-section for each group is a hypothetical example of a completely filled-out control group
including header and data elements. This example is provided solely for clarification and is not intended
to, in any way, suggest an optimum selection of the various codes or options which may be available for
any data elements within the control groups.
Note that these following sections provide the detail of the various control groups. A general description
of these control groups, their purpose and relationship to each other is found in prior sections of this
document and should be considered prerequisite reading for these detailed following sections.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 43
Signon Group
4SOG
Signon Group Format
Sequence
Number
Refer.
Name
--
SOG01
SOG02
SOG03
SOG04
SOG05
SOG06
SOG07
SOG08
SOG09
SOG10
SOG11
SOG12
SOG13
SOG14
SOG15
SOG16
SOG17
SOG18
Start
Pos
Length
Group Header (see below)
1
10
--
Machine Address (Origination)
Password (Session)
Session Reference Number
Capacity Unit Code
Capacity
Communications Device Protocol Code
System Type Code
Interface Software Revision Level
Message Standard Revision Level
Message Acknowledgement Option
Receive Options Count
Session Restart Flag
Signon Response Code
Error Code
Recovery Type Flag
Message Transfer Phase Limit
Terminator Count Unit Code
Count Verification Indicator
11
23
35
39
40
48
52
58
62
64
68
70
71
75
81
82
84
85
12
12
4
1
8
4
6
4
2
4
2
1
4
6
1
2
1
1
AN
AN
N
N
N
AN
AN
N
N
N
N
N
T
AN
N
N
N
N
Reserved for Future Use
86
40
Data Element
MCADD
PSSWD
SRNFO
CPUCD
CAP
CDPCD
SYSCD
CSRLV
MTRLV
MACKO
RCVCT
SRSTF
SGRCD
ERRCD
RCVTP
MTPHL
TRMCU
CTVCD
TOTAL DATA LENGTH
Class
CD
IC
IC
CD
CD
CD
CD
CD
CD
CD
Data
Type
Presence
Code
M
M
M
M
M
M
M
M
M
M
M
M
M
115
SIGNON GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use (blanks)
©2012
4SOG
125
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 44
Signon Group Data Elements
1.1
Machine Address (Origination) (SOG01)
-
Network Prefix Portion
Area Code Portion
Originator Code Portion
(As discussed in section 5.0, a two-way signon procedure is specified for broker-company data
communications. This signon is at a machine-to-machine level.)
The Machine Address (Origination) data element, therefore, is a unique identifier for the data processing
device originating this portion of the two-way signon process. It is a 12-character field in which the first
three characters are a Network Prefix. In a direct link, this portion of the data element should be ignored.
The next three characters are the numeric telephone area code in which the device is located and the last 6
characters are a self-assigned code for the organization using the device.
The 12-character Machine Address will be the first 12 characters of a more complex Message Address
described in the Message Header group.
1.2
Password (Session) (SOG02)
The Password (Session) data element is used to provide unique identification to prevent accidental or
unauthorized exchanges of information. Passwords will be self-assigned by users and will not be
published generally. Passwords should be communicated on an "ad hoc" basis between users who wish to
communicate with each other. They are subject to change at the discretion of individual communicating
pairs as required to maintain an appropriate level of security. It is the responsibility of each user to
maintain a list of their own passwords as well as the current passwords of those parties with whom they
will authorize communications.
1.3
Session Reference Number (SOG03)
The Session Reference Number is a numeric data element that is incremented by the sender before the
start of any session with any party. Each party generates its own number. It is not a control number. In the
event of an aborted and/or re-started session, the Session Reference Number will be incremented.
1.4
Capacity Unit Code (SOG04)
The Capacity Unit Code is an indicator as to the units used in expressing the capacity of the system
transmitting this Signon Group to accept data during this session. The codes are:
»Capacity Unit Code (CPUCD)
Code
Description
0
1
«
1.5
Capacity is expressed in characters
Capacity is expressed in element groups (maximum group length is 240 characters)
Capacity (SOG05)
The Capacity data element establishes the maximum capacity of the system transmitting this Signon
Group to receive data during this session. (This provision is made to meet known constraints which exist
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 45
in the capability of some current brokerage systems.) It is the responsibility of the responding party to
assure that the sum of the Group Length data elements of all the groups they transmit does not exceed this
limit. If the responding party has more data than can be handled by the receiving system, either smaller
messages must be constructed, the transmission must be postponed, or manual intervention must occur.
The Capacity data element is coded:
All Zeros
All Nines
Other Values
=
=
=
No messages are to be sent in the return transmission
Unlimited receive capacity
The specific capacity
Note that capacity, as specified in the Sign-on group, (SOG) is meant to reflect actual system capacity to
receive and store messages (including headers, trailers, transaction groups, etc.). Control groups (such as
Sign-on, Sign-off, MACK, NMACK, STERM, etc., should not be figured in capacity, since actual
extended storage of these groups should not be necessary. All systems should anticipate a minimum
storage capacity to complete a normal exchange of control groups in a session. Hence, that minimum
capacity should not be reflected in the capacity specified at Sign-on.
1.6
Communications Device Protocol Code (SOG06)
This code expresses the communications environment under which this session is to proceed when a port
is called which can support multiple device types which use a variation of a common data link protocol.
The codes will be specified by each sender/receiver pair.
Note:
The communications Device Protocol Code is passed only within the Signon Group. It is a single
session-oriented code that is sufficient for handling any combination of data
compression/decompression techniques which may be used during a single "physical" session. If
a Value-Added Network is being used as an intermediary, however, and the "physical" sessions
which the Network will conduct between sender and ultimate receiver utilizes different protocols,
data compression techniques, etc., it is the responsibility of the Network to "logically"
decompress the data from the first session and recompress it (possibly using different techniques)
for the second session. This does not imply that under these circumstances, data must be stored in
decompressed form within the Network, only that a "logical" decompression and recompression
must occur. For CSIO compression, the following code values will be used (refer to CSIO
Syntax Rules for compression algorithm):
Code
Specification
X25U
X25C
X25 Uncompressed
X25 Compressed
COMMENTARY
It is anticipated that in implementing this Standard within the context of a value added network, the supplier of
the network service will have to reconstruct this data element when receiving messages from a single origin, to
be delivered to multiple destinations. The nature of the reconstruction will depend upon what level of service
the receiver has requested from the network. It will range from no change (and therefore, no reconstruction)
for those receivers who wish messages passed to them in the same format as received by the vendor, to
changing.
This field is provided for possible use in a future implementation. In the Intelligent Access implementation,
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 46
the default compression technique will be 3780.
Details of the protocol's compression technique may be found in Intelligent Access Functional Specification
C210.
Data element SOG06 will always specify the data link protocol that the current message stream appears in.
The network supplier will presumably access some table of value added functions, organized by user, to
determine what network processing, if any needs to be performed on this data element.
1.7
System Type Code (SOG07)
This code will be assigned by individual users to specifically describe the originating system being used
for the communications session. Examples might be ARC001, CICS15, or any other code which
meaningfully describes the total system configuration of the originator.
1.8
Interface Software Revision Level (SOG08)
This data element allows the sender to notify the receiver as to the software used to construct messages.
This enables the coordination necessary to assure that the Messages being sent can be accurately received.
Any relationship of that data element upward to the Transaction level is coincidental.
1.9
Message Standard Revision Level (SOG09)
This element reflects the individual's specific revision level of the Batch Transmission Session and
Message Structure Standard under which communication is proceeding. For example, using Standard
Number C110-2.0, the Standard revision level will have a value of 20.
1.10
Message Acknowledgement Option (SOG10)
The Message Acknowledgement Option data element is used to confirm the type of message
acknowledgement agreed to by the session participants. The specific codes are:
1.11
0000
=
No message acknowledgements or STERMS will be sent. (Option A)
0001-8999
=
Message acknowledgements will be sent following whatever number of
messages is specified. For example, if the code is 0001, an acknowledgement
will be sent in response to each individual message before the next message is
sent. (Option C)
9998
=
All message acknowledgements will be sent following receipt of the Stream
Terminator Group. If there were, for instance, 7 messages in the stream, 7
MACKS would be sent by the receiver following receipt of the Stream
Terminator Group (Option C)
9999
=
A single stream acknowledgement (a special case of the Stream Terminator
Group) will be sent following receipt of the Stream Terminator Group (Option
B)
Receive Options Count (SOG11)
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 47
This indicator identifies the number of Receive Options Control Groups which follow the Signon Group
in this transmission stream. Its values are:
00
=
No Receive Options Groups are being sent and the responder in this session has blanket
authority to transmit messages from any authorized recipient to any authorized originator
up to the capacity indicated by data element SOG05 in this Signon Group.
Note: An agency/brokerage system is not required to respond to an option other than
00.
99
=
No Receive Options Control Groups are being sent. Traffic can be delivered up to the
capacity indicated by data element SOG05 in this Signon Group but only for those users
from whom messages will be sent in this session. (See Section 5.4).
01-98 =
1.12
1 to 98 Receive Options Control Groups follows.
Session Restart Flag (SOG12)
This is a flag sent by the Session Participant if they are re-starting an aborted session. Its purpose is to
assure that the parties are in sync at the signon time or, if not, that they are aware of that fact. It informs
the receiver that additional checking might be necessary to validate messages in this session since a
possibility exists that they may already have been received. The codes are:
»Session Restart Flag (SRSTF)
1.13
Code
Description
0
1
«
Original session
This is a restart session
Signon Response Code (SOG13)
The Signon Response Code will have a value of all blanks in the Signon Group. It is a data element which
is used in the Signon Rejection Group (where it is described) and is contained in the Signon Group in
order to provide a single group format for both the Signon and Signon Rejection Groups.
1.14
Error Code (SOG14)
The Error Code is also used in the Signon Rejection Group and has a value of blanks in the Signon
Group.
1.15
Recovery Type Flag (SOG15)
This code specifies whether messages which will be re-transmitted because of an abort of the current
session will be duplicates or replacements of the original messages. A message is a retransmitted message
if it has the same Message Sequence Number as a previously delivered message (allowing for Message
Sequence Number Rollover). A message is a duplicate message of a previously delivered message if the
transactions contained in the two messages are character by character equal, otherwise it is a replacement.
The values of the Recovery Type Flag are:
»Recovery Type Flag (RCVTP)
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 48
Code
Description
0
Duplicate message re-transmissions are not guaranteed. and re-transmitted messages will
be replacements
Duplicate message retransmission is guaranteed
1
«
1.16
Message Transfer Phase Limit (SOG16)
This data element is used to limit the number of pairs of Message Transfer Phases for the session. The
session controller will set its value. However, if the session responder cannot deal with more than one
phase pair, they may override a value of 00 and replace it with 01. If so, the session controller must accept
the override.
A restarted session need not have the same n count as the original session. The values of the data element
are:
»Message Transfer Phase Limit (MTPHL)
Code
Description
00
01
«
There is no limit on the number of Message Transfer Phases
There may be only one pair of Message Transfer Phases in the session
COMMENTARY
This facility is provided to accommodate some existing system's inability to accept more than one Message
Transfer Phase in a session.
1.17
Terminator Count Unit Code (SOG17)
This data element specifies the units of measurement for the value of the Total Data in Phase data element
of the Stream Terminator Group. It is present in the Signon Group to permit the "physical" Message
Receiver to count correct units. The codes are:
»Terminator Count Unit Code (TRMCU)
1.18
Code
Description
0
1
«
Value is in characters
Value is in element groups
Count Verification Indicator (SOG18)
This data element is used to specify that the Count Verification Feature of Message Acknowledgement
Option B is in effect. It is coded as follows:
»Count Verification Indicator (CTVCD)
Code
C110 – 12(i)
Description
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 49
0
1
2
3
«
1.19
Option is not in effect
Both Total Data and Messages in Phase data elements will be transmitted for verification
Only Total Data in Phase will be transmitted for verification
Only Total Messages in Phase will be transmitted for verification
Reserved for Future Use
This data element must be blank.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 50
Signon Group Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Format Flag
Reserved for Future Use
Data Elements
Machine Address (Origination)
Password (Session)
Session Reference Number
Capacity Unit Code
Capacity
Communication Device Protocol Code
System Type Code
Interface Software Revision Level
Message Standard Revision Level
Message Acknowledgement Option
Receive Options Indicator
Session Restart Flag
Signon Response Code
Error Code
Recovery Type Flag
Message Transfer Phase Limit
Terminator Count Unit Code
Count Verification Indicator
Reserved for Future Use
4SOG
125
b
bb
bbb914AGENT1
INSAGENTbbbb
0123
0
01000000
bbbb
ARC02b
0000
20
0000
00
0
bbbb
bbbbbb
0
00
0
0
(40 blanks)
BYTE 125
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 51
Signon Rejection Group
4SOR
Signon Rejection Group Format
Sequence
Number
Refer.
Name
--
SOR01
SOR02
SOR03
SOR04
SOR05
SOR06
SOR07
SOR08
SOR09
SOR10
SOR11
SOR12
SOR13
SOR14
SOR15
SOR16
SOR17
SOR18
Start
Pos
Length
Group Header (see below)
1
10
--
Machine Address (Origination)
Password (Session)
Session Reference Number
Capacity Unit Code
Capacity
Communications Device Protocol Code
System Type Code
Interface Software Revision Level
Message Standard Revision Level
Message Acknowledgement Option
Receive Options Indicator
Session Restart Flag
Signon Response Code
Error Code
Recovery Type Flag
Message Transfer Phase Limit
Terminator Count Unit Code
Count Verification Indicator
11
23
35
39
40
48
52
58
62
64
68
70
71
75
81
82
84
85
12
12
4
1
8
4
6
4
2
4
2
1
4
6
1
2
1
1
AN
AN
N
N
N
AN
AN
N
N
N
N
N
AN
AN
N
N
N
N
Reserved for Future Use
86
40
Data Element
MCADD
PSSWD
SRNFO
CPUCD
CAP
CDPCD
SYSCD
CSRLV
MTRLV
MACKO
RCVCT
SRSTF
SGRCD
ERRCD
RCVTP
MTPHL
TRMCU
CTVCD
TOTAL DATA LENGTH
Class
CD
IC
IC
CD
CD
CD
CD
CD
CD
CD
Data
Type
Presence
Code
M
M
M
115
SIGNON REJECTION GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use (blanks)
©2012
4SOR
125
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 52
Signon Rejection Group Data Elements
The description of data elements SOR01 through SOR12 and SOR15 through SOR18 is identical to that
found in the Signon Group for the corresponding data elements. These data elements are returned exactly as
received.
1.1
Machine Address (Origination) (SOR01)
Refer to definition of 4SOG01. This data element is returned exactly as received.
1.2
Password (Session) (SOR02)
Refer to definition of 4SOG02. This data element is returned exactly as received.
1.3
Session Reference Number (SOR03)
Refer to definition of 4SOG03. This data element is returned exactly as received.
1.4
Capacity Unit Code (SOR04)
Refer to definition of 4SOG04. This data element is returned exactly as received.
1.5
Capacity (SOR05)
Refer to definition of 4SOG05. This data element is returned exactly as received.
1.6
Communications Device Protocol Code (SOR06)
Refer to definition of 4SOG06. This data element is returned exactly as received.
1.7
System Type Code (SOR07)
Refer to definition of 4SOG07. This data element is returned exactly as received.
1.8
Interface Software Revision Level (SOR08)
Refer to definition of 4SOG08. This data element is returned exactly as received.
1.9
Message Standard Revision Level (SOR09)
Refer to definition of 4SOG09. This data element is returned exactly as received.
1.10
Message Acknowledgement Option (SOR10)
Refer to definition of 4SOG10. This data element is returned exactly as received.
1.11
Receive Options Count (SOR11)
Refer to definition of 4SOG11. This data element is returned exactly as received.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 53
1.12
Session Restart Flag (SOR12)
Refer to definition of 4SOG12. This data element is returned exactly as received.
1.13
Signon Response Code (SOR13)
The Signon Response Code is used to identify the data element which is in error in the Signon transaction.
The codes are:
»Signon Response Code (SGRCD)
Code
Description
SHnn
SDnn
mmHn
The error is in Signon Group header element Hnn.
The error is in Signon Group data element SOGnn.
The error is in header element Hn of Receive Options Control Group number mm. The
Receive Options Control Groups are numbered in the order of transmission beginning
with the number 1.
The error is in data element ROCnn of Receive Options Control Group number mm.
mmnn
«
1.14
Error Code (SOR14)
The error code indicates the nature of the error condition found. The codes are:
»Error Code (ERRCD)
Code
Description
SOG000
SOG001
Specified field error. A specified field does not contain its specific value.
Data type error. The data type for the element is incorrect. For instance, numeric
information appears in an alphabetic field.
Edit error. The data content of the field in question does not meet the specified editing
criteria.
SOG002
«
1.15
Recovery Type Flag (SOR15)
Refer to definition of 4SOG15. This data element is returned exactly as received.
1.16
Message Transfer Phase Limit (SOR16)
Refer to definition of 4SOG16. This data element is returned exactly as received.
1.17
Terminator Count Unit Code (SOR17)
Refer to definition of 4SOG17. This data element is returned exactly as received.
1.18
Count Verification Indicator (SOR18)
Refer to definition of 4SOG18. This data element is returned exactly as received.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 54
Signon Rejection Group Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Format Flag
Reserved for Future Use
Data Elements
Machine Address (Origination)
Password (Session)
Session Reference Number
Capacity Unit Code
Capacity
Communication Device Protocol Code
System Type Code
Interface Software Revision Level
Message Standard Revision Level
Message Acknowledgement Option
Receive Options Indicator
Session Restart Flag
Signon Response Code
Error Code
Recovery Type Flag
Message Transfer Phase Limit
Terminator Count Unit Code
Count Verification Indicator
Reserved for Future Use
4SOR
125
b
bb
bbb914AGENT1
INSAGENTbbbb
0123
0
01000000
bbbb
ARC02b
0000
20
0000
00
0
SD02
SOG001
0
00
0
0
(40 blanks)
BYTE 125
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 55
Receive Options Control Group
4ROC
Receive Options Control Group Format
Sequence
Number
Refer.
Name
Data Element
--
ROC01
ROC02
ROC03
ROC04
ROC05
ROC06
ROC07
ROC08
ROC09
ROC10
ROC11
ROC12
ROC13
ROC14
ROC15
ROC16
ROC17
ROC18
ROC19
ROC20
ROC21
ROC22
ROC23
ROC24
Group Header (see below)
SBADD
MSADD
CAPUN
CAP
PROPT
ROCRV
SBADD
MSADD
CAPUN
CAP
PROPT
ROCRV
SBADD
MSADD
CAPUN
CAP
PROPT
ROCRV
SBADD
MSADD
CAPUN
CAP
PROPT
ROCRV
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Option
Reserved for Future Use
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Option
Reserved for Future Use
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Option
Reserved for Future Use
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Option
Reserved for Future Use
TOTAL DATA LENGTH
Start
Pos
Length
1
10
--
11
17
35
36
44
64
68
74
92
93
101
121
125
131
149
150
158
178
182
188
206
207
215
235
6
18
1
8
20
4
6
18
1
8
20
4
6
18
1
8
20
4
6
18
1
8
20
4
AN
AN
N
N
AN
T
AN
AN
N
N
AN
T
AN
AN
N
N
AN
T
AN
AN
N
N
AN
T
Class
CD
CD
CD
CD
Data
Type
Presence
Code
M
M
M
M
M
M
M
M
228
RECEIVE OPTIONS CONTROL GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use (blanks)
©2012
4ROC
238
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 56
Receive Options Control Group Data Elements
ROC01 through ROC06 is a set of related data elements which, taken together, specify the delivery of a set of
messages and the maximum amount of data that may be delivered for that set.
1.1
Subaddress (Destination) (ROC01)
The Subaddress data element identifies the shared user or second-level processor for which messages are
to be delivered in this session.
1.2
Message Address (Origination) (ROC02)
The Message Address data element is used by the receiver to qualify and select the messages to be
received. Only messages sent from this Message Address are to be considered eligible for delivery subject
to any capacity limitations. If Subaddress is specified, these two data elements are operated in conjunction
to specify the total message delivery option. The format of this data element is the same as the format of
the Origination Message Address data element of the Message Header Group (MHG01).
1.3
Capacity Unit Code (ROC03)
The Capacity Unit Code indicates the units in expressing the Capacity data element which follows. The
codes are:
»Capacity Unit Code (CAPUN)
1.4
Code
Description
0
1
«
Capacity expressed in characters
Capacity expressed in element groups (maximum group size is 240 characters)
Capacity (ROC04)
The Capacity data element establishes the maximum capacity of the transmitting system to receive data in
the return transmission. It is the responsibility of the responding party to assure that this limit is not
exceeded. The Capacity data element is coded:
All zeros
=
No messages are to be sent to/from this Subaddress/Message Address pair
All nines
=
Unlimited capacity of receive
Other
=
Exact capacity is specified
As in the Sign-on group (SOG05), capacity as specified on the Receive Options Group (ROC04) should
reflect actual system capacity to receive and store messages (including headers, trailers, and transaction
groups). Control groups (such as Sign-on, Sign-off, MACK, NMACK, STERM, etc., should not be
figured in capacity since actual extended storage of these groups should not be necessary.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 57
1.5
Processing Options (ROC05)
This data element is intended to be used when communicating via a value-added network and the contents
will be specified at a future time. This, as well as other network-oriented data elements is included in
order to avoid the necessity of redesigning the various control groups when a value-added network is
used.
1.6
Reserved for Future Use (ROC06)
This data element must be blank.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 58
Receive Options Control Group Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Format Flag
Reserved For Future Use
Data Elements
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Options
Reserved for Future Use
Subaddress (Destination)
Message Address (Origination)
Capacity Unit Code
Capacity
Processing Options
Reserved for Future Use
---
4ROC
238
b
bb
AGENT1
(18 blanks)
0
01000000
(20 blanks)
bbbb
AGENT2
(18 blanks)
1
00000500
(20 blanks)
bbbb
(114 blanks)
BYTE 238
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 59
Signoff Group
4SOF
Signoff Group Format
Sequence
Number
Refer.
Name
--
SOF01
SOF02
SOF03
SOF04
Start
Pos
Length
Group Header (see below)
1
10
Signoff Type
Signoff Condition
Reserved for Future Use
Signoff Information Field
11
12
14
54
1
2
40
187
Data Element
SNOFT
SNOFC
SOFRV
SNOFI
TOTAL DATA LENGTH
Class
Data
Type
Presence
Code
--
CD
CD
N
N
T
T
M
230
SIGNOFF GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use
©2012
4SOF
240
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 60
Signoff Group Data Elements
1.1
Signoff Type (SOF01)
The Signoff Type data element is used by the Signoff Initiator to specify either a normal signoff or an
emergency signoff. The Signoff Type is coded as follows:
»Signoff Type (SNOFT)
1.2
Code
Description
0
1
«
Normal Sign off
Emergency Sign off
Signoff Condition (SOF02)
The Signoff Condition data element is used by the initiator of an Emergency Signoff to specify the
condition which resulted in the signoff initiation. It is coded as follows: (See Section 5.4)
»Signoff Condition (SNOFC)
Code
Description
00
01
02
03
Unspecified condition in Signoff Initiator's system
Unspecified condition related to data received
Communications application program receive time out
Loss of group synchronization (e.g.: Presence of an alpha or special character in a group
length field)
Unexpected group received (e.g.: Presence of a valid control group received in an
incorrect order - receipt of a second message header before receiving a message trailer,
etc.)
Count Verification Failure
Invalid Message Sequence Number
Invalid Message Acknowledgement Group
04
10
11
12
«
1.3
Reserved for Future Use (SOF03)
This data element must contain a value of 40 blanks.
1.4
Signoff Information Field (SOF04)
This data element may be used in an emergency signoff to transmit a message regarding the nature of the
emergency. For example, it may be used to transmit the message header of the message which brought
about the signoff.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 61
Signoff Group Example (Hypothetical)
Header
Group Designator
Group Length
Group Flag
Reserved for Future Use
Data Elements
Signoff Type
Signoff Condition
Reserved for Future Use
Signoff Information Field
BYTE 1
4SOF
240
b
bb
0
00
(40 blanks)
(187 blanks)
BYTE 240
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 62
Message Acknowledgement Group
4MAK
Message Acknowledgement Group Format
Sequence
Number
Refer.
Name
--
MAK01
MAK02
MAK03
MAK04
Start
Pos
Length
Group Header (see below)
1
10
--
Message Address (Origination)
Message Address (Destination)
Message Sequence Number
Network Reference Number
11
29
47
53
18
18
6
20
AN
AN
N
AN
Data Element
MSADD
MSADD
MSQNO
MRFNO
TOTAL DATA LENGTH
Class
Data
Type
Presence
Code
62
MESSAGE ACKNOWLEDGEMENT GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag (blank)
Reserved for Future Use (blanks)
©2012
4MAK
072
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 63
Message Acknowledgement Group Data Elements
1.1
Message Address (Origination) (MAK01)
Refer to definition of 1MHG01. This data element along with all other data elements in this group are
returned exactly as received.
1.2
Message Address (Destination) (MAK02)
Refer to definition of 1MHG02. This data element along with all other data elements in this group are
returned exactly as received.
1.3
Message Sequence Number (MAK03)
Refer to definition of 1MHG07. This data element along with all other data elements in this group are
returned exactly as received.
1.4
Network Reference Number (MAK04)
Refer to definition of 1MHG015. This data element along with all other data elements in this group are
returned exactly as received.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 64
Message Acknowledgement Group Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Format Flag
Reserved For Future Use
Data Elements
Message Address (Origination)
Message Address (Destination)
Message Sequence Number
Network Reference Number
4MAK
072
b
bb
bbb914AGENTIOFFOO1
bbb121COMPYIB00123
001234
(20 blanks)
BYTE 72
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 65
Negative Message Acknowledgement Group
4NMK
Negative Message Acknowledgement Group Format
Sequence
Number
Refer.
Name
Data Element
--
NMK01
NMK02
NMK03
NMK04
NMK05
NMK06
NMK07
NMK08
NMK09
NMK10
NMK11
NMK12
NMK13
NMK14
NMK15
NMK16
Group Header (see below)
MSADD
MSADD
CNTNO
PSSWD
SYSCD
MSRVL
MSQNO
MTDTM
CNTUN
SPCHD
MTRLV
TRXSF
MSGRC
ERRCD
NRFHO
NRSVD
Message Address (Origination)
Message Address (Destination)
Contract Number
Password (User)
System Type Code
Message Software Revision Level
Message Sequence Number
Message Transmission Date/Time
Count Unit Code
Special Handling
Message Standard Revision Level
Transmission Status Flag
Message Response Code
Error Code
Network Reference Number
Network Reserved for Future Use
TOTAL DATA LENGTH
Start
Pos
Length
1
10
--
11
29
47
57
69
75
79
85
98
99
109
111
112
116
122
142
18
18
10
12
6
4
6
13
1
10
2
1
4
6
20
20
AN
AN
AN
AN
AN
N
N
N
N
AN
N
N
AN
AN
AN
T
Class
IC
CD
CD
CD
Data
Type
Presence
Code
151
MESSAGE ACKNOWLEDGEMENT GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use (blanks)
©2012
4NMK
161
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 66
Negative Message Acknowledgement Group Data Elements
All data elements with the exception of NMK13, Message Response Code and NMK14, Error Code are
identical to the corresponding data elements in the Message Header Group. These data elements are
returned in the Negative Message Acknowledgement Group exactly as received.
1.1
Message Address (Origination) (NMK01)
Refer to definition of 1MHG01. This data element is returned exactly as received.
1.2
Message Address (Destination) (NMK02)
Refer to definition of 1MHG02. This data element is returned exactly as received.
1.3
Contract Number (NMK03)
Refer to definition of 1MHG03. This data element is returned exactly as received.
1.4
Password (User) (NMK04)
Refer to definition of 1MHG04. This data element is returned exactly as received.
1.5
System Type Code (NMK05)
Refer to definition of 1MHG05. This data element is returned exactly as received.
1.6
Message Software Revision Level (NMK06)
Refer to definition of 1MHG06. This data element is returned exactly as received.
1.7
Message Sequence Number (NMK07)
Refer to definition of 1MHG07. This data element is returned exactly as received.
1.8
Message Transmission Date/Time (NMK08)
Refer to definition of 1MHG08. This data element is returned exactly as received.
1.9
Count Unit Code (NMK09)
Refer to definition of 1MHG09. This data element is returned exactly as received.
1.10
Special Handling (NMK10)
Refer to definition of 1MHG10.Data element is returned exactly as received.
1.11
Message Standard Revision Level (NMK11)
Refer to definition of 1MHG11. This data element is returned exactly as received.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 67
1.12
Transmission Status Flag (NMK12)
Refer to definition of 1MHG12. This data element is returned exactly as received.
1.13
Message Response Code (NMK13)
The Message Response Code is used to identify the element which is in error in the Message Header
Group or Message Trailer Group. The data elements which will be edited are as specified in Section
5.5.2.2 (Option B description). The data element codes are as follows.
MHnn =
MDnn =
THnn =
TDnn =
1.14
ZZ99
=
ZZnn
=
The error is in Message Header Group header element Hnn.
The error is in Message Header Group data element MHGnn. (Initially, only the Machine
Address and Message Sequence data elements are to be checked.)
The error is in Message Trailer Group header element Hnn.
The error is in Message Trailer Group data element MTGnn. (Initially, only the Counts
are to be checked.)
Invalid Message Sequence Number. These codes are not valid for use unless the physical
and logical communication pairs are one and the same.
The error is in an element not contained within the message header or trailer. An nn
value of 00 would indicate a totally undefined error. These codes are not valid for use
unless the physical and logical communication pairs are one and the same.
Error Code (NMK14)
The error code indicates the nature of the error condition found. The codes are as follows:
»Error Code (ERRCD)
Code
Description
NMK000
NMK001
Specified field error. A specified field does not contain its specified value.
Data type error. The data type for the element is incorrect. For instance, numeric
information appears in an alphabetic field.
Edit error. The data content of the field in question does not meet the specific editing
criteria.
Unspecified error.
NMK002
NMK003
«
1.15
Network Reference Number (NMK15)
Refer to definition of 1MHG15. This data element is returned exactly as received.
1.16
Network Reserved for future use (NMK16)
Refer to definition of 1MHG16. This data element is returned exactly as received.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 68
Negative Message Acknowledgement Group Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Group Flag
Reserved For Future Use
Data Elements
Message Address (Origination)
Message Address (Destination)
Contract Number
Password (Message)
System Type Code
Message Software Revision Level
Message Sequence Number
Message Transmission Date/Time
Count Unit Code
Special Handling
Message Standard Revision Level
Transmission Status Flag
Message Response Code
Error Code
Network Reference Number
Network Reserved for Future Use
4MAK
161
b
bb
bbb914AGENTlOFFOO1
bbb121COMPYlB00123
bbbbbbbbbb
INSAGENTbbbb
RED03b
0002
001412
8111061903412
0
bbbbbbbbbb
01
0
MD03
NMKOO1
(20 blanks)
(20 blanks)
BYTE 161
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 69
Stream Terminator Group
4STG
Stream Terminator Group Format
Sequence
Number
Refer.
Name
--
STG01
STG02
STG03
STG04
STG05
Start
Pos
Length
Group Header (see below)
1
10
--
Total Data in Phase
Total Messages
Additional Data Flag
Stream Terminator Response Code
Error Code
11
19
23
24
28
8
4
1
4
6
N
N
N
AN
AN
Reserved for Future Use
34
10
Data Element
TOTDF
TOTMG
ADDDF
STRTR
ERRCD
TOTAL DATA LENGTH
Class
CD
CD
Data
Type
Presence
Code
M
33
STREAM TERMINATOR HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag (blank)
Reserved for Future Use
©2012
4STG
043
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 70
Stream Terminator Group Data Elements
1.1
Total Data in Phase (STG01)
The Total Data in Phase data element specifies the total data transmitted in the Message Transfer Phase up
to and including the Stream Terminator Group containing this data element. The unit of measurement is
either element groups or characters and is specified by the Terminator Count Unit Code of the Signon
Group. If the unit of measurement is characters, the value of the Total Data in Phase data element is equal
to the sum of the values of the Group length data elements for each element group transmitted in the
Message Transfer Phase.
1.2
Total Messages (STG02)
The total number of messages or message acknowledgements, as appropriate, transmitted in the Message
Transfer Phase.
1.3
Additional Data Flag (STG03)
The Additional Data Flag is used to notify the receiver whether or not all messages were sent or if
additional messages remain to be sent but the capacity limit has been reached. The specific codes are:
0
1
=
=
Complete
Incomplete (More to Come)
The additional data may either be for same message address or for entities other than ones who have
received messages in this transmission stream.
1.4
Stream Terminator Response Code (STG04)
The Stream Terminator Response Code may be used by the receiver to notify the sender, in the event of an
error condition, that the count fields sent by the sender in their Stream Terminator did not agree with the
corresponding accumulated counts. The contents of the data element will identify which count is in
disagreement. The specific codes are:
bbbb
0001
0002
=
=
=
No Error
Total Data in Phase Error
Total Messages Error
This data element is operative only if message acknowledgement opt.B is in effect and the Count
Verification Feature of that option is also in effect.
1.5
Error Code (STG05)
The error codes indicate the nature of the error condition found:
»Error Code (ERRCD)
Code
Description
STG000
«
C110 – 12(i)
Indicated field error. The indicated field does not contain a proper value.
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 71
Stream Terminator Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Group Flag
Reserved for Future Use
Data Elements
Total Data in Phase
Total Messages
Additional Data Flag
Stream Terminator Response Code
Error Code
Reserved for Future Use
4STG
043
b
bb
00021690
0003
0
bbbb
bbbbbb
(10 blanks)
BYTE 43
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 72
Phase Terminator Group
4PTG
Phase Terminator Group Format
Sequence
Number
Refer.
Name
Start
Pos
Length
Group Header (see below)
1
10
Reserved for Future Use
11
40
Data Element
--
TOTAL DATA LENGTH
Class
Data
Type
Presence
Code
--
40
PHASE TERMINATOR HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag (blank)
Reserved for Future Use
©2012
4PTG
050
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 73
Phase Terminator Group Data Elements
1.1
Reserved for Future Use
This data element is reserved space for future use and must be blank filled.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 74
Phase Terminator Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Group Flag
Reserved for Future Use
Data Elements
Reserved for Future Use
4PTG
050
b
bb
(40 blanks)
BYTE 50
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 75
Control Request Group
4CRG
Control Request Group Format
Sequence
Number
Refer.
Name
--
CRG01
CRG02
CRG03
Start
Pos
Length
Group Header (see below)
1
10
--
Machine Address (Origination)
Password (Session)
Error Code
11
23
25
12
12
2
AN
AN
N
Reserved for Future Use
27
40
Data Element
MCADD
PSSWD
ERCD
TOTAL DATA LENGTH
Class
CD
Data
Type
Presence
Code
M
M
66
CONTROL REQUEST GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use
©2012
4CRG
076
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 76
Control Request Group Data Elements
1.1
Machine Address (Origination) (CRG01)
Refer to definition of 4SOG01. The content of this data element is identical to the content of the user's
4SOG01. (See section 6.2.2).
1.2
Password (Session) (CRG02)
Refer to definition of 4SOG02. The content of this data element is identical to the content of the 4SOG02.
1.3
Error Code (CRG03)
The Error Code will have a value of blank in the Control Request Group. It is a data element which is
used in the Control Request Rejection Group and is contained in the Control Request Group in order to
provide a single format for the two groups.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 77
Control Request Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Group Flag
Reserved for Future Use
Data Elements
Machine Address (Origination)
Password (Session)
Error Code
Reserved for Future Use
4CRG
076
b
bb
bbb914AGENT1
INSAGENTbbb
bb
(40 blanks)
BYTE 76
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 78
Control Request Rejection Group
4CRR
Control Request Rejection Group Format
Sequence
Number
Refer.
Name
Data Element
Start
Pos
Length
Class
Data
Type
--
Group Header (see below)
1
10
--
CRR01 MCADD
CRR02 PSSWD
CRR03 ERCD
Machine Address (Origination)
Password (Session)
Error Code
Reserved for Future Use
11
23
25
27
12
12
2
40
AN
AN
N
TOTAL DATA LENGTH
CD
Presence
Code
M
M
M
66
CONTROL REQUEST GROUP HEADER VALUES
H1
H2
H3
H4
C110 – 12(i)
Group Designator Value
Total Group Length
Format Flag
Reserved for Future Use
©2012
4CRR
076
b
bb
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 79
Control Request Rejection Group Data Elements
1.1
Machine Address (Origination) (CRR01)
This data element is used to return the value of the data element CRG01 of the Control Request Group
exactly as received.
1.2
Password (Session) (CRR02)
This data element is used to return the value of the data element CRG02 of the Control Request Group
exactly as received.
1.3
Error Code (CRR03)
The Error Code indicates the reason for transmission of the Control Request Rejection Group. The codes
are:
»Error Code (ERCD)
Code
Description
01
02
03
10
«
Invalid Group Designator in the received Control Request Group
Invalid value of CRG001
Invalid value of CRG002
Session Answerer will not accept control of the session
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 80
Control Request Rejection Example (Hypothetical)
BYTE 1
Header
Group Designator
Group Length
Group Flag
Reserved for Future Use
Data Elements
Machine Address (Origination)
Password (Session)
Error Code
Reserved for Future Use
4CRG
076
b
bb
bbb914AGENT1
INSAGENTbbb
01
(40 blanks)
BYTE 76
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD OPTIONS
page 81
CSIO TRANSMISSION SESSION STANDARD – INTERNET
RECORD OF AMENDMENTS
Release
Date
Issued
Description
2000
Jan/2000
Released
2006
June/2006
Amended definition of 3.2 “Mail Box Delivery Notification Message”
(MR06-396)
2012
Mar/2012
Add the ability to send XML transactions through CSIOnet (MR2012010)
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD INTERNET
Page &/or
Section
page 84
1.0
INTRODUCTION
In 1997 the majority of broker interface transactions were transmitted via ICEnet which was at that
time the Insurance industries value added network. This became very costly as more and more brokers
were implementing broker interface and the data volumes increased dramatically.
In 1996 a CSIO project was launched to investigate more cost effective ways of transmitting policy
information. It was found that the utilization of Internet technologies would reduce the
telecommunications cost to the industry by approximately 90%.
CSIO lead a project to build a secure telecommunication environment and in 1998 and 1999 the
industry migrated from ICEnet to an industry intranet. This resulted in a change to the way that CSIO
transactions are transmitted.
2.0
TRANSACTION FLOW
In order to insure that messages get from one place to another successfully a standard transaction flow
was established. The following steps take place:
1.
2.
3.
4.
5.
6.
3.0
The sender connects to the IP (Internet Protocol) network.
The sender sends a message to the receiver’s POP3(Post Office Protocol) mailbox.
The POP server replies to the sender notifying them that the receivers mail box has
successfully received the message.
The receiver connects to the network.
The receiver retrieves the message from their mailbox.
The receiver sends an acknowledgement back to the sender informing them that the message
has been received successfully. This acknowledgement does not mean that the transaction is
valid or approved but that the receiver has received a message that conforms to the CSIO
transmission standard.
CSIO STANDARD TRANSMISSION MESSAGES
The CSIO standard for Internet transmission utilises 3 SMTP (Simple Mail Transfer Protocol)
transmissions.
3.1
CSIO Data Transmission
The CSIO data transmission is the transmission that contains the insurance business data in CSIO
standard format. Ie. The 1MHG and its contents. The business data is a base64 MIME encoded
attachment to an SMTP mail message. The SMTP message has a standard format. As a security
precaution, if the message does not conform to the exact CSIO standard format, the message is
disregarded by the receiving system.
The following is the standard for CSIO compliant SMTP messages:
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD INTERNET
page 85
3.1.1
“To:”
The destination userid. i.e. Who you are sending the message to
3.1.2
“From:”
The sender’s userid. i.e. your userid
3.1.3
“Subject:”
This is the index information in both the audit trail and archive. Each data element is separated by a
period. The line must be in the following
format:

"Subject: EDI Xmit Msg-Id#:" This is a fixed text field for AL3 transaction Or
"Subject: XML Xmit Msg-Id#:" This is a fixed text field for XML transactions.

“{date stamp}.” The date stamp generated in the following way.
DATE(YYYYMMDD)+ticks since midnight. There are 18.2 ticks per second. This
corresponds to the C function biostime().

“{a userid}.” The userid is the senders userid.
3.1.4
“Return-Receipt-To:”
The userid that will receive delivery notifications, usually the same as
3.1.5
“From” above.
“Content-Type:”
Must specify at least "BOUNDARY="{unique piece of text}". This text
and end of the message.
3.1.6
delineates the start
“Content-Type:” (in body)
Must specify at least name="filename.xxx"
3.1.7
“Content-Disposition:”
Must specify at least filename="filename.xxx"
3.1.8
MIME Encoded Business Message
Use Base64 mime encoding for the business message. Surround MIME (Multi Purpose Internet
Extensions) and mime header with the boundary separator. See the example below:
Note #1: It is allowable to specify the transaction in the second MIME boundary providing that the
first MIME boundary contains no mime headers or data. This accommodates the use of some UNIX
style MIME generation software.
Note #2: The body of this document does not contain any text, just MIME encoding.
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD INTERNET
page 86
Example:
Return-Path: <anotherco@edi.csio.com>
Received: from 10.254.254.28 ([10.254.254.28])
by csio (JAMES SMTP Server 2.3.1) with SMTP ID 778
for <csionetadmin@broker.edi.csio.com>;
Wed, 15 Feb 2012 15:02:54 -0700 (MST)
To: <testco@edi.csio.com>
From: Another Co. <anotherco@edi.csio.com>
Subject: EDI Xmit Msg-Id#:199708121084159.anotherco@edi.csio.com OR
Subject: XML Xmit Msg-Id#:199708121084159.anotherco@edi.csio.com
MIME-Version: 1.0
Return-Receipt-To: ABC <anotherco@edi.csio.com>
Message-Id: <199708121084159.anotherco@edi.csio.com>
Content-Type: MULTIPART/MIXED; BOUNDARY="=====_34934934312BDY_==="
--=====_34934934312BDY_===
Content-Type: application/octet-stream; name="U970055.002"
Content-Transfer-Encoding: BASE64
Content-Disposition: attachment; filename="U970055.002"
ICAgICAgICAgICAgICAgICAgICAgICA1QklTMjQwICAgQjEwMDAxICAgICAgICAgIEEgICBURGVi
cmFoIEFubiBCZWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCRUNLNTMwIDEwICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5QklTMjQwICAgQjEwMDAxICAgICAg
ICAgIEEgICA0MjMgMTIndGggU3RyZWVyIFdlc3QgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBQcmluY2UgQWxiZXJ0ICAgICAgU0tTNlYzQjkgICAxMjM0ICAgICAgICAgIDEy
M05CUyAgICAgICAgICAgICAgICAgICAgT04gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAyVENHMTM1ICAgMDIwOTY5MDA5NjkxMDk2OTIwOTYzMDI5NjkyMTk2
OTI1OTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1QklTMjQwICAgQjEwMDAxICAg
ICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
--=====_34934934312BDY_===--
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD INTERNET
page 87
3.2
Mail Box Delivery Notification Message
The community has adopted the RFC-1891.
3.3
Acknowledgement Message Format
The following is the format of the Acknowledgement message sent back to the sender of a transaction
to confirm the successful receipt and decoding of a transaction. Note that there is no "Negative ACK",
only a positive one.
Note that the body text "Document ACK" is present for completeness. The Message-Id is the field that
is used to designate that the transaction is an ACK, and the original message id.
Example:
Received: from Test (csio.com [204.191.155.17]) by
csio.com (8.8.5/8.7.5) with SMTP id VAA20098 for <testco@edi.csio.com>;
Wed, 15 Apr 1998 21:14:17 -0400 (EDT
Date: Wed, 15 Apr 1998 21:14:17 -0400 (EDT)
X-Mailer: AMU-Mailer
To: <testco@edi.csio.com>
From: Another Co. <anotherco@edi.csio.com>
Subject: ACK-<199804151180725.penncgy@amuedi.com>.199804151181002.penncgy@amuedi.com
Message-Id: <"ACK<199804151180725.penncgy@amuedi.com>".199804151181002.penncgy@amuedi.com
Content-Type: text
Document ACK
C110 – 12(i)
©2012
CSIO TRANSMISSION SESSION STANDARD INTERNET
page 88