thomson reuters elektron edge v2.3 · 2018. 7. 6. · thomson reuters elektron edge programmer’s...

Version: 1.0 07 May 2013

Thomson Reuters Elektron Edge v2.3.0

Programmer’s Guide

Thomson Reuters Elektron Edge Programmer’s Guide ii

© Thomson Reuters 2013. All Rights Reserved. Thomson Reuters, by publishing this document, does not guarantee that any information contained herein is and will remain accurate or that use of the information will ensure correct and faultless operation of the relevant service or equipment. Thomson Reuters, its agents and employees, shall not be held liable to or through any user for any loss or damage whatsoever resulting from reliance on the information contained herein.

This document contains information proprietary to Thomson Reuters and may not be reproduced, disclosed, or used in whole or part without the express written permission of Thomson Reuters. Any Software, including but not limited to, the code, screen, structure, sequence, and organization thereof, and Documentation are protected by national copyright laws and international treaty provisions. This manual is subject to U.S. and other national export regulations. Nothing in this document is intended, nor does it, alter the legal obligations, responsibilities or relationship between yourself and Thomson Reuters as set out in the contract existing between us.

Thomson Reuters Elektron Edge Programmer’s Guide iii

1 Table of Contents

1 Table of Contents ............................................................................................................................ iii 2 List of Figures................................................................................................................................... v 3 List of Tables ................................................................................................................................... vi 4 INTRODUCTION TO THOMSON REUTERS ELEKTRON EDGE ............................................. 7

4.1 Who should read this Guide ..................................................................................................... 9 4.2 How to Use this Guide .............................................................................................................. 9 4.3 Other References ...................................................................................................................... 9

5 ABOUT THE THOMSON REUTERS ELEKTRON EDGE ......................................................... 10 5.1 Organisation of Document ...................................................................................................... 10 5.2 Quality Guidelines and Checklist ........................................................................................... 10 5.3 News 2000 Quality Guidelines and Checklist ........................................................................ 11 5.4 Conventions Used in Part I ..................................................................................................... 11

6 CONCEPTS .................................................................................................................................... 12 6.1 Thomson Reuters Instrument Code (RIC) .............................................................................. 12

6.1.1 The Component Parts of a RIC ....................................................................................... 12 6.1.2 Database Access Rules ................................................................................................... 13 6.1.3 Instrument Code Constituents ......................................................................................... 13 6.1.4 Summary of Instrument Type Delimiters ....................................................................... 20 6.1.5 Source Code Constituents ............................................................................................... 20

6.2 Chain Records......................................................................................................................... 20 6.3 Page Records .......................................................................................................................... 21

6.3.1 ‗Monitor Style‘ Pages (64x14) ....................................................................................... 21 6.3.2 Large Page Records (80x25) and 99-Character Pages .................................................... 21

6.4 Field Identifiers (FIDs) and Values ........................................................................................ 21 6.4.1 A Word About Time Fields ............................................................................................ 22

6.5 Record Classification .............................................................................................................. 22 6.6 Permissions ............................................................................................................................. 23

6.6.1 IDN Permissions ............................................................................................................. 23 6.6.2 User Permissioning ......................................................................................................... 23

6.7 Watchlist ................................................................................................................................. 23 6.8 Delivery Path and Services ..................................................................................................... 23 6.9 Data Group ............................................................................................................................. 24 6.10 Data Health ............................................................................................................................. 24 6.11 Snapshots ................................................................................................................................ 24 6.12 Non-updating Item Support .................................................................................................... 24 6.13 Support Aliases ....................................................................................................................... 25 6.14 TCP/IP Nagle Algorithm ........................................................................................................ 25 6.15 Support Statistic RIC (%CSTATRIC) .................................................................................... 26 6.16 Support Pseudo RIC for Elektron Edge Configurations (%CCONFIG) ................................. 28

7 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE .................................... 30 7.1 Elektron Edge Design Goals ................................................................................................... 30 7.2 Elektron Edge Connectivity .................................................................................................... 30

7.2.1 Ultra Performance API (UPA) ........................................................................................ 30 7.2.2 Robust Foundation API (RFA) ....................................................................................... 30 7.2.3 Software Foundation Classes (SFC) ............................................................................... 31 SSL Classic Edition/SSL SDK API ........................................................................................ 31 7.2.4 ................................................................................................................................................ 31

7.3 Criteria Based Requests (SSL/Market Feed), Symbol List Requests (OMM) ........................ 31 7.3.1 Criteria/Symbol List Resolution ..................................................................................... 32

7.4 Multiple Channel Support ....................................................................................................... 32 7.5 Watchlist Support ................................................................................................................... 32 7.6 Data Health and Recovery ...................................................................................................... 32

7.6.1 Image Refresh ................................................................................................................. 32 7.7 News Services......................................................................................................................... 33

8 LOGICAL DATA FORMATS IN SSL .......................................................................................... 34 8.1 Overview ................................................................................................................................ 34 8.2 Notation .................................................................................................................................. 34

8.2.1 ASCII Characters ............................................................................................................ 34 8.2.2 Special Character Representations .................................................................................. 34 8.2.3 Separators ....................................................................................................................... 35 8.2.4 Message Structure ........................................................................................................... 35

Thomson Reuters Elektron Edge Programmer’s Guide iv

8.2.5 Repetitions ...................................................................................................................... 35 8.2.6 Intra-Field Position Sequence ......................................................................................... 35 8.2.7 Character Repetition ....................................................................................................... 36

8.3 General Marketfeed Message Format ..................................................................................... 36 8.3.1 Header Portion of a Marketfeed Record ......................................................................... 36 8.3.2 Data Field Portion of a Marketfeed Record .................................................................... 37 8.3.3 Data Types Supported for Marketfeed Fields ................................................................. 37

8.4 Marketfeed Messages Types ................................................................................................... 39 8.4.1 Record_Response and Snap_Response (340) ................................................................. 39 8.4.2 Update_Record (316) ...................................................................................................... 47 8.4.3 Correct_Record (317) ..................................................................................................... 47 8.4.4 Close_Record (312) ........................................................................................................ 48 8.4.5 Verify_Record (318) ....................................................................................................... 48

8.5 Ripple Fields ........................................................................................................................... 49 9 IMPLEMENTATION GUIDELINES ............................................................................................ 50

9.1 Data Enhancement Releases ................................................................................................... 50 9.1.1 Administrative Messages ................................................................................................ 50

9.2 Processing FIDs ...................................................................................................................... 51 9.2.1 Latest Activity ................................................................................................................ 51

9.3 Processing Chains and Tiles ................................................................................................... 53 9.4 Processing Page Records ........................................................................................................ 58 9.5 Processing Correction Messages ............................................................................................ 58

9.5.1 Consolidated Ticker System (CTS) ................................................................................ 59 9.5.2 NASD Market Ticker System (NMTS) .......................................................................... 59 9.5.3 Canadian Equity Exchanges ........................................................................................... 59

9.6 Time & Sales Data .................................................................................................................. 59 9.6.1 Requesting Time & Sales Logs ...................................................................................... 60 9.6.2 Response Message .......................................................................................................... 60

9.7 News 2000 .............................................................................................................................. 61 9.7.1 How a Story is Constructed ............................................................................................ 61 9.7.2 Coding ............................................................................................................................ 61 9.7.3 Directories ...................................................................................................................... 62 9.7.4 Broadcast Messages and Text Segments ........................................................................ 63 9.7.5 Character Sets in News 2000 .......................................................................................... 64 9.7.6 News Permissioning ....................................................................................................... 65 9.7.7 Broadcast Messages ........................................................................................................ 65 9.7.8 Text Segments ................................................................................................................ 69 9.7.9 Recommended Processing Rules .................................................................................... 73 9.7.10 Recommended Display Application Functionalities ....................................................... 77

9.8 Guidelines for Processing Marketfeed Messages ................................................................... 79 9.8.1 Marketfeed Template Changes ....................................................................................... 79 9.8.2 Optional Fields ............................................................................................................... 79 9.8.3 New Message Types ....................................................................................................... 80 9.8.4 Control Codes ................................................................................................................. 80

9.9 Programming Guidelines ........................................................................................................ 80 9.10 Performance Requirements ..................................................................................................... 81

APPENDIX A GLOSSARY ........................................................................................................... 82 APPENDIX B ITEM STATUS TEXT TO CLIENTS ........................................................................ 86 Index ....................................................................................................................................................... 87

Thomson Reuters Elektron Edge Programmer’s Guide v

2 List of Figures

Figure 4-1 Component diagram with Elektron Edge connected to the Elektron Data Network .............. 8 Figure 6-1 A sample pseudo RIC response of %CSTATRIC from Kobra (Display All Fields) ............ 27 Figure 6-2 A sample pseudo RIC response of %CCONFIG from Kobra ............................................... 28 Figure 9-1 Marketfeed Message Header Syntax ..................................................................................... 37 Figure 9-2 Data Fields within a Marketfeed Message ............................................................................ 37 Figure 9-3 Analysis of a Typical Record_Response............................................................................... 46 Figure 21-1 Example – Suggested Message Processing Algorithm. ...................................................... 51 Figure 21-2 Representation of Linked Text Segment Records ............................................................... 63

Thomson Reuters Elektron Edge Programmer’s Guide vi

3 List of Tables

Table 9-1 Standard Marketfeed Field Types .......................................................................................... 38 Table 21-1 Chain Record FIDs ............................................................................................................... 55

4 INTRODUCTION TO THOMSON REUTERS ELEKTRON EDGE

The Thomson Reuters Elektron Edge is a datafeed server offers access to the full range of information

products available on the Elektron Network. Clients can access the electron Edge by utilizing any of

our supported Thomson Reuters Application Programming Interfaces (APIs). Examples of these APIs

are:

Ultra Performance API (UPA)

Robust Foundation API (RFA)

Software Foundation Classes (SFC)

SSL Classic Edition/SSL SDK API

Any application or solution, currently written to the above mentioned APIs, can access an Elektron

Edge Device. Examples of these solutions would be:

Thomson Reuters Enterprise Platform for Real-Time (TREP-RT)

Reuters Market Data System (RMDS)

The Elektron Edge currently supports two types of connectivity. This connectivity is based on:

Our strategic Open Message Model (OMM) offerings which utilize Reuters Wire Format

(RWF) technologies.

Our legacy SSL/Market Feed techonoligies

Elektron Edge, which is located at client site, is part of a multi-component configuration with another

portion — Distribution POP — located at the Thomson Reuters Data Center LAN. A local cache is

maintained on Elektron Edge to facilitate fast retrievals.

Elektron Edge receives full images and realtime tick-by-tick updates from Distribution POP, where

Distribution POP receives updates from Elektron Data Highway to provide market data with extremely

low-latency.

This document will describe the details of what is provided by the Elektron Edge. Once you decide on

the use of a particular API interact with the Elektron Edge, you will need to refer to documentation and

examples contained in the APIs‘ Developers Kit. See Section 7.2 for details.

INTRODUCTION TO THOMSON REUTERS ELEKTRON EDGE

Thomson Reuters Elektron Edge Programmer’s Guide 8

Elektron Edge Product

Distribution POP (DistPOP)

Client Applications/Solutions

Elektron Data Network

Elektron Edge

Client’s LAN at client site

Thomson Reuters

Enterprise Platform – Real Time

(TREP-RT)

Client Applications/Solutions

Figure 4-1 Component diagram with Elektron Edge connected to the Elektron Data Network

INTRODUCTION TO THOMSON REUTERS ELEKTRON EDGE


4.1 Who should read this Guide

This guide, complemented with documentation from API Product releases, provide the information

required to write an OMM-based application or SSL-based applicaiton which interfaces with Elektron

Edge. As such it should be read by:

Managers who want an overview on Elektron Edge, along with an insight into

development requirements and performance issues.

Systems Designers/Analysts who want detailed knowledge of the Elektron Edge‘s capabilities,

features, volumes, response times and restrictions.

Systems Programmers who require guidance on using the OMM or SSL-based APIs to

communicate with the Elektron Edge.

4.2 How to Use this Guide

This guide is divided into three parts:

Contains information about the content and format of Elektron data which is delivered to

Edge; provides guidelines for implementing an application to access data.

Provides guidelines for API access.

4.3 Other References

[1] TRSC for Elektron Edge User Guide

Provides help on TRSC to users

[2] Edge Notifications

Information on data enhancements which is published via the quote pages CHANGES and

DNLATEST1.

[3] Thomson Reuters Multilingual Text Encoding Standard

A guide containing the Thomson Reuters basic character set and details of how to interpret ISO

2022 international character sets

[4] News 2000 User Guide

A guide gives full details of the regional news services which are available on News 2000

[5] Open Message Model – White Paper

A white paper focuses on the Open Message Model (OMM) and how it can be used.

ABOUT THE THOMSON REUTERS ELEKTRON EDGE


5 ABOUT THE THOMSON REUTERS ELEKTRON EDGE

Thomson Reuters Elektron Edge provides a window into the world of data available on Elektron. Data

from Elektron Edge can be in Thomson Reuters Marketfeed as the data format. The consistency of

Marketfeed ensures applications to correctly interpret data regardless of its original source. The market

data can be also in RWF format which can be retrieved via any OMM-based API. Examples of OMM

based APIs are the Ultra Performance API (UPA) and the Robust Foundation API (RFA)

Each instrument is stored as a single record and is identified by a unique Thomson Reuters Instrument

Code (RIC). Elektron currently supports both logical and page records. Logical records are arranged as

discrete sets of fields which its format is predictable by type. Each field consists of a Field Identifier

(FID) and a value. Page records consist of rows of data, where each row represents a FID.

The logical record structure not only meets user requirements on processable data, but also simplifies

record handlings.

To minimize traffics in transmitting update messages through Elektron, partial records with only the

updated FIDs and their corresponding values are sent out for a logical record, instead of sending out a

full version. For page records, only those updated rows are sent out, instead of the entire page.

When there are any changes on Elektron affecting Edge clients, you will be notified via our notification

procedures. Thomson Reuters has an on-line notification method using page CHANGES or

DNLATEST1 on the system. Further details are in section 9.1.1, Edge Administrative Messages.

5.1 Organisation of Document

Section 6 CONCEPTS Describes Elektron and how to interpret both

logical records and paginated structures; it

discusses concepts such as a watchlist, data health,

and request rate settings.

Section 7 DESIGN GOALS AND SYSTEM

FEATURES OF ELEKTRON

EDGE

Describes the goals of Elektron Edge design, as

well as major system features. This section also

includes recommendations of API choices for

access to the system

APPENDIX A

GLOSSARY Defines key terms.

5.2 Quality Guidelines and Checklist

This is a list of recommended checks that a client application should handle to maximise the quality of

Elektron Edge:

FID Ordering The application processes should not rely on the FID number ordering

of a received data item, it cannot assume the FIDs are in ascending

order. (see section 9.2, Processing FIDs).

Time Fields The application must be able to adjust the time fields according to the

method that they use to process the data (see section 6.4.1, A Word

About Time Fields).

Handling News 2000 News alerts and headlines should be passed to all end-user displays with

minimum delay, since alerts and headlines contain potential market-

moving information. (see section 9.7, News 2000).

Processing Chains The application should be able to retrieve chain records. This is

performed by a series of requests, each request receives a link in the

chain (see section 6.2, Chain Records and section 9.3, Processing

Chains and Tiles).

Marketfeed Messages Follow the guidelines presented in section 9.8 for processing Marketfeed

messages.

RWF Messages Follow the guidelines presented in section Error! Reference source not

found. for processing RWF messages.

Data Health Since stale data can be accessed from cache during a communications

ABOUT THE THOMSON REUTERS ELEKTRON EDGE


fault (see section 6.10, Data Health), applications should monitor the

data status and take appropriate actions. Stale data should be indicated

clearly on the application display screen.

5.3 News 2000 Quality Guidelines and Checklist

Time Ordering of

Messages

The application should not rely on the time ordering of messages but should

use the PNAC, story date/time instead. It should also take date/time to

maintain the news database. Elektron does not guarantee temporal order of

data.

News Watchlist

Management

It is recommended that a minimum of two RIC references should be held in

the watchlist for a story. These should be the first text segment record

(PNAC) and the latest text segment record. (See section 9.7.9.3, Text

Segment Handling Rules.)

Displaying News Stories It is recommended that a news application display only enough story text to

fill up the window on the user‘s display. This may reduce the number of

requests that will have to be made.

Duplicated Headlines The message processing rules listed in section 9.7.9.2, Broadcast Message

Handling Rules, should be adhered to for catering the possibility of handling

duplicated headlines.

Corrected Messages The application must apply corrected messages at all times and clear all story

displays if a corrected message is received for that particular story.

Archiving News Edge is not designed for archiving news stories purpose. To enable clients to

archive news stories, Edge is required to configure to on-pass all stories and

a client application has to support this functionality.

5.4 Conventions Used in Part I

Names of RICs, SSL functions, parameters, structures, etc, within the text of this document appear

in a bold text font; e.g.:

TRI

sslSnkMount()

Pathnames and filenames appear in a bold italic font; e.g.:

MasterFidList

ssl.h

Information to be entered exactly as shown appears in a bold typewriter font whereas variable

information appears in an italic typewriter font; e.g. sslPostEvent(Channel, SSL_ET_IMAGE_REQ, &PostEvent)

Marketfeed messages, file listings or code samples appear in a plain typewriter font; e.g.: <FS>316<US>34<GS>FXFX<US>12345

<RS>216<US><CSI>10<HPA>XYZ BANK<CSI>32<HPA>654.32<FS>

CONCEPTS


6 CONCEPTS

The Elektron provides real-time information for over ten million financial records, of both logical and

paginated in ultra-low latency. Elektron sources the latest information from most of the world

exchanges and a large number of contributors, and simultaneously broadcasts the information to

clients.

To meet user requirements for processable data, logical records are arranged as discrete sets of fields

and each field in the set, depending on its type, has a predictable format. Each field consists of a Field

Identifier (FID) and a value, in which the value‘s type, format and maximum size can be determined by

table lookup.

A page record structure is different in the sense that it consists of rows of data, where each row in the

page is uniquely defined by a FID. (See section 6.3, Page Records.)

Complete records retrieved from one-off snapshots do not receive any updates, while normal complete

records keep receiving updates. Updates only consist of partial full record, i.e. only the FID and value

for fields that have changed. This optimisation not only simplifies the record interpretation, but reduces

transmission time.

All messages pertaining to records are classified such that your application can distinguish between and

process appropriately for messages including market activity, corrections, adjustments, and

verifications.

The information in Elektron records is presented using the Elektron standard character set (see [3],

Thomson Reuters Multilingual Text Encoding Standard), making it ideal to be inputted directly to

applications such as customised screen displays, minute-by-minute portfolio evaluation, cross-rates

calculators for foreign exchange dealing or real-time spreadsheets.

Following sub-sections explain how RICs are constructed and how the user should interpret records

and updates. Also, concepts of watchlist, delivery path, data health, and request rate throttling are

presented in detail.

6.1 Thomson Reuters Instrument Code (RIC)

Each record on Elektron is retrievable by using a unique Thomson Reuters Instrument Code (RIC).

RICs are constructed using strict rules defined by the Elektron Quality Group. This section details the

RIC constructions for all instrument types on Elektron, in which the RICs have been implemented and

approved. The description is not exhaustive, you are recommended to also reference the relevant

Information Product Directory.

On Elektron, dual indexing (aliasing) enables the usages of a globally consistent structure and

structures derived from local markets concurrently. For example, Swiss Equities can be retrieved by

either its RIC name or the Valoren Number. Dual indexing ensures Thomson Reuters services are easy

to access for both domestic and international users.

This section describes the components of a RIC; these rules vary from instrument types to instrument

types.

6.1.1 The Component Parts of a RIC

RIC is a convention for naming financial instruments, such that data related to these instruments can be

easily accessed from Thomson Reuters databases. The composition of each code depends on the type of

instrument. The code is structured with a number of elements, and their complete combination makes

up a unique RIC for each instrument.

Due to the complexity and diversity of the instrument types covered, it is not possible to define an

overall generic rule. As a guidance, RICs include some, but not necessarily all, of the following

components:

database identifier (see section 6.1.2)

instrument code (see section 6.1.3)

period or time interval

delimiter (possibly more than one)

source code (see section 6.1.5)

The database identifier is blank for records retrieved from the main Elektron real-time database; the

remaining values are defined in the next section.

CONCEPTS


Not all of these elements are required in each RIC but there can be no imbedded spaces within a RIC.

6.1.2 Database Access Rules

A RIC can be used to retrieve information of an instrument from different databases. This includes the

facility to retrieve historical information, such as prices from timeseries database.

The first character of a RIC indicates the source it retrieves information from. Lower case characters

are reserved for sources not belong to the Elektron real-time databases. Following characters are

assigned to particular databases:

d Thomson Reuters Timeseries Database (TSDS) Prices

n News 2000

t Time & Sales

RICs sourced from the Elektron real-time database begin with the following characters:

Capital A – Z

Numeric 0 – 9

Period .

Hash #

The character % is reserved for server information.

Remaining punctuation characters are reserved for special internal Elektron functions.

6.1.3 Instrument Code Constituents

This section describes all the instrument code constituents which can be used to assemble a complete

RIC. The instrument code has a structure of its own.

The minimum structure required for an instrument description is a root. A root can be one or more

characters. The simplest type of roots is the equity roots which can be a single letter, e.g. F = Ford

Motor Co, or two letters, e.g. BP = British Petroleum Co PLC, and commodity roots which can also be

as small as a single letter. Roots can be rather lengthy, such as a bond root which may be upwards of

ten characters.

The following sections will introduce all possible RIC constituents arranged in alphabetical order.

6.1.3.1 Brokerage Characters

This subdivision of an equity or debt instrument code can be a combination of special characters and/or

lowercase letters used to distinguish among different classes, forms or states of instruments from a

single issuer.

Note that you have to use the following brokerage characters instead of those published in directories:

For instruments listed on NASDAQ, the fifth character is the brokerage character. It is a single

uppercase letter. For capital markets instruments, the ―When Issued‖ status is denoted by upper case

WI.

Datafeed Chars Published Chars

Preferred _p PR

Rights _r RT

Units _u UN

When Issued _w WI

Warrants _t WS

6.1.3.2 Call / Put Month

This subdivision of an option instrument code denotes the month in which a call or put option will

expire. The codes used are A-L for call option expiration and M-X for put option expiration:

Month Call Put

January A M

February B N

March C O

April D P

May E Q

June F R

CONCEPTS


July G S

August H T

September I U

October J V

November K W

December L X

These month codes are used for options which will expire in the next 12 months. For longer term

options, Thomson Reuters tries to accommodate solutions provide by individual exchanges. Some

exchanges provide modified root codes, in those cases, Thomson Reuters uses the exchange root. When

a modified root is not provided, the following rules are used:

For a 12 to 24-month expiry period, a lowercase letter is used for the expiry call / put month.

For more than 24 months out, the last digit of the expiration year is used for call options, and a

single letter is used, either Y, Z, y or z for the expiry year for put options.

For 17-character long RICs, the structure is as per options that expire during the next 12 months, with

the addition of the last digit of the expiry year before the exchange identifier.

6.1.3.3 Call / Put Year

This subdivision of an option instrument code identifies the expiration year of an option. If an option

expires in 2006, then the Call / Put Year is 6.

6.1.3.4 Category Codes

The News 2000 service has the facility for searching headlines/alerts based on news category codes.

There are five code classes:

Product Codes up to four characters

Topic Codes up to six characters

Named Item Codes (also known as Report Codes) up to ten characters

Company Codes up to ten characters (company RICs)

Attribution Codes up to four characters

News 2000 codes may be subdivided into Company Codes and non-Company Codes which occupy

distinct and non-intersecting name spaces. Non-Company Codes are listed in online News 2000

directory stories (as described in section 9.7.2, Coding) and are usually composed of only alphanumeric

characters. For Company Codes, allowed characters are:

Upper and lower case letters

Arabic numerals

Period / full stop (.)

Plus sign (+)

Equals sign (=)

Forward Slash (/)

Semi-colon (;)

Note that category codes do not begin with a lower case ―n‖ since this is reserved for the database

indicator code for News.

The following characters are not used in category codes, they are reserved for boolean logic searches of

headlines/alerts within the client application:

Space Asterisk *

Ampersand & Question Mark ?

Minus Sign - Pound / Hash Sign #

Square Brackets [] Dollar Sign $

Less/Greater Signs <> ―At‖ Sign @

Apostrophe ‘ Caret ^

Back Slash \ Accent ‗ Percent Sign % Stylized Brackets {}

Round Brackets () Vertical Divider |

Quotation Mark ― Tilde ~

CONCEPTS


For full details and listings of the News 2000 category codes please refer to [4], News 2000 User

Guide.

6.1.3.5 Country Codes

Any Country Code adopted within the RIC conforms to ISO 3166, including XM for Multinational and

XS for Supranational.

6.1.3.6 Coupon Rate

Several methods are currently employed to define coupon rates.

All bonds traded in the US have a coupon component of up to four characters. This includes a one to

two digit whole number component and a one to two character fractional component. The fractional

component has two digits if it is decimal. If it is a fraction denominated in eighths, the first character is

the digit of the numerator and the second character is a forward slash (/). For Zero Coupon issues, the

coupon component is omitted.

Examples

coupon = 12.65% coupon code = 1265

coupon = 10-7/8% coupon code = 107/

The scheme adopted overall for debt instruments provides for a three-digit number where the context is

critical. Rates are assumed to hover in a bond around 10%. Two-digit numbers other than 10 are

assumed to relate a whole number and a fraction. Three-digit numbers are assumed to relate two whole

numbers and a fraction. The number 10 is unique and indicates two whole numbers.

97 9 7/8%

10 10%

101 10 1/8%

102 10 1/4%

103 10 3/8%

104 10 1/2%

105 10 5/8%

106 10 3/4%

107 10 7/8%

UK Gilt issues use a code with one to three-characters. The code consists of a one to two digit integer

follows by a single letter (if applicable). The integer is the integral part of the coupon rate, while the

single letter is its decimal part, which is defined in this way:

Letter Meaning

E 1/8

Q 1/4

R 3/8

H 1/2

F 5/8

T 3/4

S 7/8

Examples

coupon = 12-1/4% Coupon code = 12Q

coupon = 9% Coupon code = 9

6.1.3.7 Currency

Thomson Reuters uses the three letter ISO 4217 (Swift) currency code where possible (except XEU

which is replaced with ECU). For Forex RICs the presence of a single currency code indicates the

transaction is settled in US dollars. Where two currency codes are shown, the first is the base currency.

For domestic money market instruments, the two-letter ISO 3166 country code is used instead of the

Swift code. The exception is Eurodollar issues which are identified by ―USD‖ rather than ―US‖ for

domestic dollar denominated instruments.

6.1.3.8 Delivery Period Indicator

This subdivision of an instrument code is used to indicate the delivery period. Delivery period is a

characteristic of the transaction as opposed to maturity or expiration, which is a characteristic of the

CONCEPTS


instrument. In markets where delivery is highly standardized, such as most equity markets, the delivery

period indicator is omitted. In other markets, such as Money, there is a wide variety of delivery periods

and they must be included.

The London Metal Exchange is a special case.

Consult the respective directories for details on delivery periods for other instruments, such as cash

energy and commodities.

Period Indicators Period Indicators

D

10 Year for JGB xW Number of Weeks

E

Early xWO Number of Weeks (Over the

Weeks)

F

Final (Japan) xM F Number of Months

L

Late/Long term (10

Year) JGB (Japan)

xMO Number of Months (Over

the Months)

M Medium Term JGB

(Reserved)

xMOS Number of Months (Over

the Months / Small Trades)

ON Over/Night xMS Number of Months (Small

Trades)

TN Tomorrow/Next x20 Year for JGB

SW Spot Week xY Number of Years

SN Spot/Next xYS Number of Years (Small Trades)

xD Number of Days

6.1.3.9 Expiration Month

The code used to represent the month in which a Commodity or Futures contract expires. The code is a

single letter. The convention is as follow:

Month Code Month Code

January F July N

February G August Q

March H September U

April J October V

May K November X

June M December Z

6.1.3.10 Expiration Year

The code used to represent the year in which a Commodity or Financial Futures contract expires. The

code is a one-digit number which is the least significant digit of the delivery year, for example 7 for

2007.

6.1.3.11 German Security Codes

BA 10 year

BO 5 year

BP Bundespost

DB Bahnanleihe

BF Unity Bond

BS Bundes Schatzanweisung

The foll1owing is a list of the subcategories of Gilts or Gilt Types:

CONCEPTS


T Treasury

E Exchequer

F Funding

C Conversion

6.1.3.12 Instrument Indicator

A one- to four-letter code defines a subcategory of debt instrument in the Money and Capital Markets.

Examples would be Treasury Bills, Certificates of Deposit, Forward Rate Agreements, Repurchase

Agreements and the like.

BA Bankers Acceptance DS Discount for JGB (Reserved)

BNR Bank Note Rate E Ex-warrant bond (Reserved)

C Convertible Bond (Japan) EB Eligible Bills

CA Interest Rate Cap EX Exchange Rate Agreement

CD Certificate of Deposit F Forward Rate Agreements

CDCB Certificate of Deposit – Clearing

Bank FB Financing Bills

CDE Certificate of Deposit –

Secondary(Outright, Japan) FF Federal Funds

CDG

Certificate of Deposit – Secondary

(Gensaki / RP, Japan) FFAG Federal Funds Agency

CDN

Certificate of Deposit – New Issue

(Japan) FIX Exchange Fixing

CDOB Certificate of Deposit – Other

Banks FI Fixed Interest

CDP Certificate of Deposit – Primary FL Floating Rate

CDS Certificate of Deposit – Secondary FR Interest Rates Floor

CDT Certificate of Deposit – Secondary

(Tenbai, Japan) FS Forward Rate Agreements – Strip

CDBS Certificate of Deposit – Building

Society FSR FRA Settlement Rates

CMT Cash Management Treasury GIC Guaranteed Investment Contracts

CP Commercial Paper IB Ineligible Bills

CPD Commercial Paper – Dealer MU Mutan Call

CPDI Commercial Paper – Direct Issuer PR Prime Rates

CPE Commercial Paper – Secondary

(Outright, Japan) RP Repurchase Agreement

CPG Commercial Paper – Secondary

(Gensaki / RP, Japan) RPT Repurchase Agreement – Treasury

D Deposit RPM Repurchase Agreement – Mortgage

Backed

DC Dollar Call RPMM Repurchase Agreement – Money

Market

RPGN Repurchase Agreement – Ginny

Mae TE Tax Exempt

RPFN Repurchase Agreement – Fanny

Mae TEMM Tax Exempt – Money Market

RPFH Repurchase Agreement – FHLMC TEMN Tax Exempt – Municipal Note

S Swap TG Tegata

SF Synthetic Agreement for Forward

Exchange W Warrant Bonds

SS Secured Sterling w Weighted Average Spread (Paris)

T Treasury Note / Bond / Bill WS Warrants

TB Treasury Bill Tanshi RICs YU Yutan Call

6.1.3.13 Location Code

A location code is a one to four letter identifier for a physical location. These can be major geographic

areas such as continents or countries or smaller areas such as regions or cities. Generally speaking,

single letters are used for major geographic areas (e.g. A = Asia). Thomson Reuters uses the ISO 3166

two-letter country codes where possible. Three and four-letter codes are usually applied to cities or

regions. Consult the individual service directories for details. The following is a list of Intercity Bank

codes defined already.

AI Amsterdam Interbank MI Madrid Interbank

CONCEPTS


BI Brussels Interbank OI Oslo Interbank

CI Copenhagen Interbank PI Paris Interbank

DI Dublin Interbank RI Rome Interbank

FI Frankfurt Interbank SI Singapore Interbank

HEI Helsinki Interbank STI Stockholm Interbank

HI Hong Kong Interbank TI Tokyo Interbank

II Italian Consortium Interbank VI Vienna Interbank

LI London Interbank

LUI Luxembourg Interbank

6.1.3.14 Market Identifier

The following market identifiers are defined for Money:

Blank World

A Asia

E Europe

N North and South America

SEA South East Asia

R Thomson Reuters

BST Best rate -this identifier was originally BEST.

XX All 2-character ISO 3166 Country Codes for Country-level contributions

6.1.3.15 Maturity Month

The general scheme for most instruments is to use a single letter to indicate the debt instrument matures

month. The code uses A to L to indicate January to December.

The scheme for the US provides distinguishing registered versions of a bond from the bearer (coupon)

form of the bonds. Registered is the most common form and under US law, no new bonds may be

issued in bearer form. However, there are still many issues trading in bearer form until they mature.

Months Gen US Registered US Bearer Tie Breaker

January A 1 A

February B 2 B

March C 3 C

April D 4 D

May E 5 E

June F 6 F

July G 7 G

August H 8 H

September I 9 I

October J O J

November K N K

December L D L

6.1.3.16 Maturity Year

This is a two-digit number to identify the year in which a debt instrument matures. The code is the last

two digits of the year; that is, for a bond maturing in 2012 the maturity year code is 12.

6.1.3.17 Root

A RIC root is a set of characters denoting some basic instrument differentiations:

it may identify an instrument issuer

it may define a product or category of tradable items

it may/may not have an internal structure

In Money, the root has such a complex internal structure that the concept does not really apply.

6.1.3.18 Strike Price Code

There are two separate rules for strike price codes: one for equity options and another for futures

options.

6.1.3.18.1 Cash/Equity Options

CONCEPTS


This is a two- or three- character code depending on the strike price:

If the strike price is less than or equal to 10, then the two-digit code used is the integer component

of the strike price multiplied by 10. For example, if the strike price is 7.3, the code will be 73.

If the strike price is from 10 - 99.9, then the three-digit code used is the integer component of the

price multiplied by 10. For example, if the strike price is 12.25, the code will be 122, or if the

strike price is 95, the code will be 950.

If the strike price is equal to or larger than 100, then the three-digit code used is the three most

significant (leftmost) digits of the price. For example, if the strike price is 191.5, the code will be

191, or if the strike price is 12500, the code will be 125.

6.1.3.18.2 Futures Options

This is a code up to five digits, depending on the exercise price:

If the exercise price has five or less figures, then the code is the exercise price (excluding the

decimal point). For example, if the exercise price is 234.5, the code will be 2345.

If the exercise price has more than five figures, then the code is the five least significant

(rightmost) digits (excluding the decimal point). For example, if the exercise price is 1234.75, the

code will be 23475.

6.1.3.19 Size

The size of the transaction is indicated in RICs for certain Japanese debt instruments traded on the

Japanese Government Bond (JGB) section of the Tokyo Stock Exchange (TSE) and the Tegata of Ueda

Tanshi.

These indicators are included in the Period indicator for Tegata of Ueda Tanshi (see section 6.1.3.8,

Delivery Period Indicator).

For JGB of TSE, the size indicators are:

L Large Lots – Transactions of 10 million yen or more

S Small Lots – Transactions of one to 10 million yen

6.1.3.20 Trading Session

The trading session on the London Metal Exchange is represented by a two-character alphanumeric

code.

In other futures markets, sessions refer to broad time periods of continuous trading such as a day

session, an evening session or an overnight session. The futures RICs have a single digit prefix

indicating a specific day portion. With this prefix, a full trading day record or all the day portion

records can be provided.

Sessions for North American futures markets are defined as follow:

1 = Evening (1800 local to about midnight)

2 = Overnight (Just after midnight to about 0600)

3 = Day session (0730 to late afternoon)

Sessions for MATIF are defined as follow:

1 = Open outcry (MATIF) traded

2 = Globex traded

The chain records for trading sessions follow the structure:

session numeric

contract root

futures delimiter (:)

6.1.3.21 Uniqueness Identifier or Tie Breaker

An alternative set of month codes for Maturity Month is used to distinguish between two or more

instruments which would have the same logical RIC structure. This is necessary to ensure that the RIC

does not become too lengthy. For US Treasuries, the Tie Breaker would occasionally be needed to

distinguish Treasuries with identical coupon, maturity month and year, but with different middle dates

(day of the month). The letter A would represent the second such occurrence in the month.

CONCEPTS


For JGB on the TSE, A month code would be placed in front of the RIC to distinguish the first and

second issues which share the same issue number.

Month Code Meaning

1 First issue using the same issue number

2 Second issue using the same issue number

6.1.4 Summary of Instrument Type Delimiters

The current separator characters are:

Instrument Character Instrument Character

Bonds (Chain) ! Indices . (dot)

Capital Markets = Marketscope , (comma)

Closing/Delayed Data / (used as a prefix) Money Markets (Forex) = Equities and Equity

Options

. Options on Futures

(Chain) +

Equity Options (Chain) * (plus market

separator)

Physical

Commodities

-

Expired RICs > (plus market

separators)

Pre-Packed Data , (comma)

Futures (Chain) : Spreads -

Page RICs / Timeseries \ (plus market

separators)

6.1.5 Source Code Constituents

Usually source code is the last component of a RIC. Traditionally, this has been used to designate the

exchange from which a quote originated in the form of an exchange identifier. With the expansion of

the database to include quotes and contributions from additional sources, it has been necessary to

expand the exchange identifier function into a source code which can be a contributor code (market

maker identifier), bulk contributor code, exchange identifier or market identifiers. Conventions defined

by the International Standards Organisation have been incorporated where they are applicable.

6.1.5.1 Contributor Code/Market Maker Identification

A contributor code is used to identify the source of information which is supplied directly to Thomson

Reuters. This code is unique.

A market maker code is used to identify a market maker who contributes quotes on a particular

exchange. This is applicable on exchanges which use a Competing Market Marker style of trading,

such as, the International Stock Exchange (SEAQ) and the National Association of Security Dealers

(NASDAQ). This code consists of four upper case alpha characters.

6.1.5.2 Bulk Contributor Code

Bulk contributors are key contributors who provide logical data feeds to Thomson Reuters. This code is

unique, that consists of three-character upper case alpha codes.

6.1.5.3 Exchange Identifier

One to two upper or lower case letters used to identify the exchange where an instrument is traded. All

exchange codes are listed in the directories.

6.1.5.4 Market Identifiers

All market identifiers are covered in detail by section 6.1.3, Instrument Code Constituents.

6.2 Chain Records

Chain records are used to hold RIC references that have a common association; for example, all strike

prices on a particular option contract. Inside the response of a chain record, its underlying RIC

references and forward linking chain record are identified; each chain record can hold up to 14 RIC

references. The RIC references are then used to request the individual RICs and their associated

information.

The first chain record of a series is prefixed with 0#. No assumptions should be made about the

structure of the subsequent chain records in the series.

CONCEPTS


Please note that some chains omit the 0# as the first chain record, notably some Money 2000 RICs and

Indices.

For further details of processing chains please see section 9.3, Processing Chains and Tiles.

The chain record construction specification within each Information Products can be found in the

relevant Directory.

6.3 Page Records

Page records are delivered to Edge row by row, each row is identified by a unique FID. There are

several sizes available:

14 rows of 64 characters (‗Monitor Style‘ pages)

25 rows of 80 characters (Large page record)

a single row of 99 characters

12 rows of 99 characters

20 rows of 99 characters

6.3.1 ‘Monitor Style’ Pages (64x14)

Some pages from the Monitor database are also stored on the main Elektron database for retrieval. The

RIC for a ‗Monitor Style‘ page held on Elektron is the same as the Monitor page code and is subjected

to the same basic rules:

RIC is four characters long.

Valid characters are upper case letters (A to Z), lower case letters (a to z) and numeric (1 to 9,

exclude zero). Separators are not supported.

The RIC does not end at a numeric if the penultimate character is a valid futures delivery month,

i.e. F, G, H, J, K, M, N, Q, U, V, X, Z.

Please note that not all monitor pages are available via Edge. Monitor pages with its data "logicised”

into a logical record or a chain record, are remove from Elektron.

Some data with Monitor page structure on Elektron is not sourced from the Monitor network, its codes

thus does not follow the above rules. Instead, the codes adhere to Elektron RIC structures. An Elektron

data example is time series one (TS1) data.

6.3.2 Large Page Records (80x25) and 99-Character Pages

RICs for Large page records have a minimum of 5 characters and a maximum of 17; there may be

some specific examples of 4-character Large pages. All alphanumeric characters are supported,

including lower case letters, with the following rules:

The RIC does not start with a lower case letter.

The RIC does not end with a numeric if the penultimate character is an upper case letter.

For RICs of 5 characters in length, the final character must not be a ‗v‘.

These rules also apply to 99-character pages.

6.4 Field Identifiers (FIDs) and Values

Each field in a record (or each row in a page) contains a FID and a value. The FID determines its value

content.

This logical structure has the following advantages:

Field values can have a variable length, up to the published maximum, so that Elektron network

does not have to transmit superfluous characters.

Only changed fields/rows are transmitted on Elektron in updates.

By applying only relevant fields to applications using Thomson Reuters data, maximum flexibility

and efficiency can be obtained.

See also section 9.2, Processing FIDs, which provides guidelines for implementing software to handle

FID numbers in record and to update messages.

CONCEPTS


6.4.1 A Word About Time Fields

Time fields in datafeed messages store time in 24-hour format, for example, 15:35 (or 15:35:03 for

accuracy to seconds). The time zone of the reported time varies. All logical records quoted are reported

in GMT; it should be noted that logical contributor records may not adhere to this rule. On pages from

the Monitor network, the applicable time zone depends on the origin of the information: European,

African and Middle Eastern pages use GMT; Asian and Australian pages use Tokyo time; American

pages use New York time. Please consult the relevant directory to ensure the given time stamp

interpretation.

6.5 Record Classification

Within each record structure, there is a field helps to identify which market sector the record is from

and what type of data item it is. This field (FID 259, RECORDTYPE) contains one of the values in the

matrix below.

This field may be used for a variety of applications. It is guaranteed that the value in the record fields

do not change, unless a record changes its meaning. If it is necessary to alter the FID 259 values, the

change will be subjected to Data Notification.

NOTE: The information contained in this field is useful for determining display formats.

Instrument Type

Building Block

a b c d e F g h I j k l m N o p

XMT 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

TSY 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

SOV 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

MTG 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

CORP 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

EQL 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

EQ 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127

EN 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143

SOF 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159

BASE 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175

CAPM 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191

GOL 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207

FX 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223

MM 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255

where:

a = fund instrument i = link record

b = cash instrument j = large page

c = futures instrument k = small Monitor page

d = cash option l = small non-Monitor page

e = futures option m = spread data

f = market statistics n = tile records

g = market indices o = not yet allocated

h = time series data p = not yet allocated

XMT = Cross-market EN = Energy

TSY = Treasury debt BASE = Base Metals

SOV = Sovereign debt CAPM = Coins & Precious Metals

MTG = Mortgage backed debt SOF = Softs

CORP = Corporate debt GOL = Grains & Oilseeds

EQL = Equity linked FX = Forex

EQ = Equities MM = Money Markets

The following values are also defined:

0 Not allocated

1-15 Reserved for future building block expansion

224 Complex chain / tiles

225 Retired record

CONCEPTS


226 Speed Guide page

227 Headings / title page

228 Product Definition page

229 Alias record

230 Permissions record

231 Program record

232 News 2000

233 Pre-packaged data

234 Editorial news / rates page

235 IRG data

236 Not yet allocated

237 Not yet allocated

238 Network status

239 Dummy record

6.6 Permissions

6.6.1 IDN Permissions

Access to Elektron is controlled by an ILA permissions scheme. When Edge is installed, it is given a

set of permissions, which is agreed by the client and Thomson Reuters. The permissions control the

client accesses to different records. If a client attempts to request records without permission, the

request would be rejected by Elektron Edge and a negative response is returned.

6.6.2 User Permissioning

User permissioning can be used in your application by implementing a permissioning scheme as part of

your application.

To enable clients to manage site control on fee liable data, Thomson Reuters provides the

permissioning details to both exchange data and specialist data services in RIC form on Elektron.

The permissioning details enable clients to develop a network management and permissioning system

to control data usages of individual users/applications.

Permissioning is controlled through Permissionable Entities (PEs). All RICs (both logical and

paginated), except news items, each is assigned a universal PE value. News items can belong to more

than one PE.

PE value is carried in FID1 (PROD_PERM) in each RIC. For news items, the PE values are carried in

FID1 and service bank (FID456 and FID457).

Currently PEs range from 0 to 11519, it is advised to make your applications to deal with PE values up

to 32,767, such that your applications can adapt to new PE values in future.

The PE information for fee liable entities, and for Thomson Reuters Information Products, is stored in a

series of Thomson Reuters Product Definition Pages. These pages list both the administrative and the

permissioning information, which its index page is PERMINDEX000.

6.7 Watchlist

Edge provides an interface to Elektron through which user applications can access individual items (i.e.

RICs). The list of RICs being monitored by Edge in a time instance is called a watchlist.

It is important that a client is not limited to a static selection of records. Rather, the watchlist

mechanism provides a window into the Elektron database of over ten million records and page records.

Your application can re-arrange the window as required by issuing requests to Edge which affect the

content of the watchlist.

Depending on the datafeed mode, Edge can be configured with a watchlist size up to 1,000,000 RICs.

Multiple Edges can be installed for sites require monitoring more than 1,000,000 RICs. The watchlist

size limitation ensures an Edge has an adequate capacity to handle traffics of monitored RIC updates.

6.8 Delivery Path and Services

A delivery path is a communications link used to transport data between Edge and the Elektron data

center. Only one delivery path is available:

Retrieval (i.e. Distribution POP)

CONCEPTS


Edge delivers data from Distribution POP under two services:

ELEKTRON_DD (Elektron Default Distribution) is analogous to the IDN_RDF service

exposed today by the IDN_RDF. The ELEKTRON_DD service provides access to all content

that is available on IDN.

ELEKTRON_AD (Elektron Application Distribution) provides access to the same venues as

the ―ELEKRON_DD‖ service, but it allows applications to access content from a venue which

is migrated from being collected on IDN to being collected natively on Elektron at the earliest

possible opportunity. From time to time, a venue migrates from IDN to Elektron, Edge may

inform your application any involved item in such switch over through an item status message.

See APPENDIX B for the message.

Your application would be notified the available services at the Edge. Handling of the service

information in SSL- and OMM-based applications are given in sections Error! Reference source not

found. and Error! Reference source not found., respectively. Sink applications can request items

from different services by specifying the corresponding service name in the request.

6.9 Data Group

At any time, each item delivered to the client application will associate with a one-and-only-one data

group. The item‘s data group can be associated with the item‘s delivery path, but this association is not

always guaranteed. There may be situations where the data group and delivery path of an item is not

related in this manner. For this reason, the data group should only be used in reporting a data health

change.

Each service will provide its own set of data group information. As such, Edge will provide two sets of

such information for services ELEKTRON_DD and ELEKTRON_AD. However, if ELEKTRON_AD

is disabled (by default), only a set of group information is provided from Edge.

While an item is being watched, the group ID may be changed. If Edge has to re-open items, the group

ID may differ from the item‘s group ID received via a previous request. Your application would be

notified for the change in group ID with an appropriate status message.

Handling of the data group information in SSL- and OMM-based applications are given in sections

Error! Reference source not found. and Error! Reference source not found., respectively.

6.10 Data Health

Data health reflects the quality of the update stream for a particular RIC. For records accessed by Edge,

there are two possible values for the data health status: OK and STALE.

OK indicates that the update stream for a RIC is healthy and users can trust the data for that record.

STALE is generated either when the delivery path for a record is severed or when an error has

been detected in Edge or other devices. Users should avoid making decisions based on data in

records that have a STALE status.

When the condition that caused the STALE status restored, Edge will recover all stale instruments and

forward them to your application.

Handling of the data health information in SSL-, RFA- and UPA-based applications are given in

sections Error! Reference source not found. and Error! Reference source not found. of this

document and section 11.2.6 of Error! Reference source not found., respectively.

6.11 Snapshots

Edge supports snapshot requests which provide current images without any updates to follow. The

transaction to satisfy a snapshot request is completed with the image. Since a record requested as a

snapshot is not cached, it is not counted against the watchlist. However, a snapshot request takes up

capacity in the request window.

6.12 Non-updating Item Support

Some items, such as Time & Sales (TAS) and TS1 records, do not receive updates. These are called

non-updating items. Elektron Edge handles these non-updating items in a special way. That is, it treats

requests of non-updating items similar to snapshots and does not cache these items, since cached data

of that type may be out-dated and stale without updates.

CONCEPTS


Non-updating items are identified by the first character of the RIC. For example, the RICs for TAS

items always have ‗t‘, and have ‗d‘ for TS1, as the first character.

Elektron Edge will also send out non-updating items other than those listed above.

Each non-updating item image is followed by an SSL_ET_ITEM_STATUS_CLOSED event indicating

that the item was closed because of its non-updating characteristics. The Text field will contain the

message ―Non-updating item‖.

6.13 Support Aliases

Elektron Edge is enhanced to support aliases.

Aliases provide a secondary record indexing form. An Alias is essentially an intermediary RIC which

maps onto another RIC which is used to access a record.

Aliases satisfy two specific key business needs:

Allow an alternative symbology to access exchange data held on Elektron.

Create a level of indirection which allows client site applications to monitor a front contract (i.e. a

generic contract that points to the next contract to rollover). This allows applications, e.g. graphical

displays, to continue without being updated after a futures contract rollover.

In most cases, the aliasing function is transparent to user applications. Elektron Edge will request the

underlying record on behalf of the user application, and a pseudo record will be returned to user.

Although these processes require Elektron Edge to keep two items in the internal watchlist, it will only

be counted once from the user watchlist limit.

6.14 TCP/IP Nagle Algorithm

6.14.1 Server Side

TCP/IP Nagle algorithm is disabled at Server Side due to the low latency nature of Elektron Edge. All

messages to be sent to the TCP/IP stack are sent out as soon as bandwidth is available. This reduces the

message latency caused by the TCP/IP stack. However, messages are sent with smaller packets and

thus overall network efficiency is lower. Further, this higher packet rates can also increase the

workload of your application.

6.14.2 Client Side

Other than disabling Nagle on the server side, you can also choose to reduce the delayed ACK timer in

your application from the default 200ms to 0ms.

A sample setting for Windows based OS is described below.

Windows 2000

Edit the TcpDelAckTicks registry value to adjust the delayed ACK timer. By default, the

delayed ACK timer value is 2 (200 milliseconds).

Add or Set the TcpDelAckTicks value to 0, delayed acknowledgments are disabled. This

setting causes the computer to immediately send an ACK packet for every packet it receives.

Restart Windows for this change to take effect.

Information about TcpDelAckTicks:

Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip

\Parameters\Interfaces\interface

Value Type REG_DWORD-number

Valid Range 0-6

Default 2 (200 milliseconds)

Description

Specifies the number of 100-millisecond intervals to use for the delayed-

ACK timer on a per-interface basis. By default, the delayed-ACK timer is

200 milliseconds. Setting this value to 0 disables delayed

acknowledgments, which causes the computer to immediately ACK every

packet it receives.

Windows XP / Windows Server 2003

Adjust the delayed ACK timer by editing the registry entry TcpAckFrequency.

CONCEPTS


TcpAckFrequency is a new registry entry in Microsoft Windows XP and Microsoft Windows

Server 2003 that determines the number of TCP acknowledgments (ACKs) that will be

outstanding before the delayed ACK timer is ignored.

Set the TcpAckFrequency value to 1, every packet is then acknowledged immediately. Restart

Windows for this change to take effect.

Information about TcpAckFrequency:

Subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip

\Parameters\Interfaces\<Interface GUID>

Entry TcpAckFrequency

Value Type REG_DWORD, number

Valid Range 0-255

Default 2

Description Specifies the number of ACKs that will be outstanding before the delayed

ACK timer is ignored.

Important Note:

Before editing this registry entry, you must first install the Microsoft Windows Hotfix

KB328890. Visit the Microsoft web page for more information.

The Nagle algorithm feature is runtime configurable, but would only be effective when your

application reconnects to Elektron Edge.

6.15 Support Statistic RIC (%CSTATRIC)

Elektron Edge allows its clients to access their channel information by requesting the pseudo RIC

―%CSTATRIC‖. The pseudo response uses template 17 and display template 190. Updates will be sent

to the client application once per second if it is a normal request (not a snapshot request).

CONCEPTS


Figure 6-1 A sample pseudo RIC response of %CSTATRIC from Kobra (Display All Fields)

The pseudo response provides the following information:

1. FID 3: User name – the username of the channel (response only).

2. FID 188: Channel‘s SSL/RSSL buffer utilization (percentage).

3. FID 189: Channel‘s message rate.

4. FID 190: Channel‘s throughput in bps.

5. FID 191: Total number of open requests that resulted in closed recoverable status

messages.

6. FID 216: Server name (response only).

7. FID 995: User ILA – the ILA of the channel (response only).

8. FID 1001: Protocol type (e.g. SSL and RWF1. Response only).

User name (FID 3), User ILA (FID 995) and Protocol type (FID 1001) may not be available at the time

when %CSTATRIC is requested. Those fields are blank in the response. VSYNC will be sent to client

if this information becomes available. Server Name is available at the time of request. This name is

carried in FID 216 which is similar as in %CCONFIG (see section 6.16).

%CSTATRIC update messages only contain the fields that are changed. In most time, FID 188

(Channel‘s SSL/RSSL buffer utilization), FID 189 (channel‘s message rate), FID 190 (channel‘s

CONCEPTS


throughput) and FID 191 (Total number of open requests that resulted in closed recoverable status

messages) are included in an update message. FID 188 would be a non-zero value only when there is

some network latency/error, or when the client infrastructure is not fast enough to catch up with the

update rate in that particular time.

Note: Please note that the FIDs of template 17 not shown in the above list are reserved for future use.

6.16 Support Pseudo RIC for Elektron Edge Configurations (%CCONFIG)

To obtain the basic configuration and versioning information for Elektron Edge, clients can request the

pseudo RIC ―%CCONFIG‖. The retrieved information helps clients to provide clearer information

regarding the Elektron Edge delivery and configuration to assist speedy investigation upon support

issues.

This pseudo RIC response uses template 51 (i.e. 14 rows x 64 columns page record) and display

template 132. Its content contains configuration information including Product Type, Product Version,

Server Name, Server ILA, Server ID, Delivery Service Name, Field Definition Version, Hardware

Platform, Memory Size and Maximum Server Watchlist Size. A sample pseudo RIC response is shown

below for reference.

Delivery Services provided by Elektron Edge are:

- FTN – Full Tick Network

- BON – Bandwidth Optimized Network

Figure 6-2 A sample pseudo RIC response of %CCONFIG from Kobra

As seen above, the pseudo RIC response provides the following information:

1. FID 215: Product Type and Product Version

2. FID 216: Server Name

3. FID 217: Server ILA

4. FID 218: Server ID

5. FID 219: Delivery Service Name

6. FID 220: Field Definition Version

7. FID 222: Hardware Platform

8. FID 223: Memory Size (MB)

9. FID 225: Maximum Server Watchlist Size

The MarketFeed of the above sample pseudo RIC response is shown below:

<FS>340<US>XX<GS>%CCONFIG<US>51<US>0<RS>1<US>212<RS>2<US>132<RS>104<US>0

<RS>215<US>Product : Elektron Edge 2.2.0

<RS>216<US>Server Name : EDGEHK10056

CONCEPTS


<RS>217<US>Server ILA : #E08001

<RS>218<US>Server ID : 62b7

<RS>219<US>Service : FTN

<RS>220<US>Field Def : 4.10.17

<RS>221<US>

<RS>222<US>Platform : HP ProLiant DL360 G7

<RS>223<US>Memory (MB) : 12276

<RS>224<US>

<RS>225<US>Max Server Watchlist Size: 500000

<RS>226<US><RS>227<US><RS>228<US><RS>259<US>0<RS>456<US>@@@<RS>457<US><R

S>701<US> : <RS>702<US> : <RS>703<US> : <RS>704<US> :

<RS>705<US> : <RS>706<US> : <RS>707<US> : <RS>708<US> :

<RS>709<US> : <RS>710<US> : <RS>711<US> : <RS>712<US> :

<RS>713<US> : <RS>714<US> :

<RS>1079<US>0<RS>1080<US>@@@<RS>1383<US>@@@<FS>

This pseudo RIC is delivered in Data Group 1 and is non-updating. In other words, its group status

would change according to Data Group 1‘s health status, and your application would receive neither

update nor verify messages of %CCONFIG.

DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE


7 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE

7.1 Elektron Edge Design Goals

Elektron Edge is a high capacity, digital datafeed product, capable of delivering full content of

Thomson Reuters information products and support compatiablity with the suite of supported Real-

Time APIs and products. We target users who require instant access to exchanges they deal with and

who are maintaining more than 100K instruments in their real-time tick databases.

The product provides the following features:

RSSL/RWF (OMM-based connections) and SSL (Market Feed-based connections)

Criteria based requests(SSL/MF) / Symbol List Requests( OMM-based) for Broadcast data streams

Multiple channel support

Watchlist mechanism

Data health and recovery

Access to all real-time services

7.2 Elektron Edge Connectivity

The Elektron Edge currently supports two types of connectivity. This connectivity is based on:

Our strategic Open Message Model (OMM) offerings which utilize Reuters Wire Format

(RWF) technologies.

Our legacy SSL/Market Feed techonoligies

Clients can use any of our Real-Time APIs that support SSL/MF or RSSL/RWF to connect, and

interact directly with the Elektron Edge. Each of these APIs is part of a Developers Kit that includes its

own documentation (developer‘s guides, reference manuals, config guides, etc). Each kit provides

example programs with source code, which allow application developers to see how to write

applications.

Clients can access the electron Edge by utilizing any of our supported Thomson Reuters Application

Programming Interfaces (APIs). Examples of these APIs are:

7.2.1 Ultra Performance API (UPA)

The UPA product suite contains the strategic low-level, transport APIs for multi-threaded access to

subscription, publication, and contribution capabilities of Thomson Reuters Enterprise Platform. UPA

was introduced in 2009. The UPA subscriber (consumer-side) can connect directly to the Elektron

Edge. The UPA standardizes on the strategic Open Message Model (OMM) which allows clients to use

Rich Data Models from Thomson Reuters, or create and utilize their own customs data models. The

UPA is designed to take full advantage of throughput and latency benefits of the optimized Thomson

Reuters Wire Format (RWF) for connectivity to the Thomson Reuters Enterprise Platform for Real

Time Components (Advanced Distribution Server, Advanced Data Hub, etc), Elektron Elektron Edge,

and the Thomson Reuters Data Feed Direct. Clients wishing the highest throughtput and lowest latency

should consider utilizing this API. The UPA Product is currently available in C, and Java. When

looking at the UPA documentation and examples, refer to using a UPA consumer. A UPA consumer is

what you would write to connect to the Elektron Edge.

7.2.2 Robust Foundation API (RFA)

The RFA is the strategic, message-oriented, Session Level API for multi-threaded access to

subscription, publication and contribution capabilities. The RFA Market feed was introduce in 2001

and the OMM support was introduced in 2006. The RFA subscriber (consumer-side) can connect

directly to the Elektron Edge. The RFA standardizes on the strategic Open Message Model (OMM)

which allows clients to use Rich Data Models from Thomson Reuters, or create and utilize their own

customs data models. The RFA utilizes the benefits of the optimized Thomson Reuters Wire Format

(RWF) for connectivity to the Thomson Reuters Enterprise Platform for Real Time Components

(Advanced Distribution Server, Advanced Data Hub, etc), Elektron Edge, and the Thomson Reuters

Data Feed Direct. Certain RFA Products contain Legacy Market Data Interfaces, which support SSL.

The RFA Products are available are available in C++ and Java for both OMM and SSL connectivity.

RFA is also available in .Net for OMM connectivity.



When looking at the RFA documentation and examples for doing OMM connectivity, refer to using a

RFA OMM consumer. A RFA OMM consumer is what you would write to connect to the Elektron

Edge.

When looking at the RFA documentation and examples for doing SSL connectivity, refer to using a

RFA MD (Market Data) consumer. A RFA MD (Market Data) consumer is what you would write to

connect to the Elektron Edge.

7.2.3 Software Foundation Classes (SFC)

SFC is a suite of high-level, Object-Oriented API‘s used to publish and subscribe to data on the

Thomson Reuters Enterprise Platform for Real Time via SSL. The SFC was introduced about 18 years

ago. The SFC subscriber (consumer-side/sink side) can connect directly to the Elektron Edge.The SFC

complements the RFA Market Data Interfaces (which support SSL/MF Connectivity) by providing

objects that encapsulate the data distribution and data Market Data models. The objects facilitate

publication and contribution of real-time records as well as subscription to real-time records, chains,

pages and TS1 time series. The product is mature and feature complete. SFC Products are available are

available in C++, Java, and COM languages. When looking at the SFC documentation and examples

for doing SSL connectivity, refer to using a SFC Client. A SFC Client is what you would write to

connect to the Elektron Edge.

7.2.4 SSL Classic Edition/SSL SDK API

The SSL Classic Edition or the SDK 4.5 are legacy SSL/MarketFeed APIs that were introduced about

20 years ago. They are single threaded, thread-safe APIs that are written in the C-language. These APIs

are currently in active obsolescence (SSL Classic Edition) or may move that way in the future (SDK

4.5). When looking at the SSL Classsic or SD 4.5 documentation and examples for doing SSL

connectivity, refer to using a Sink Application. A Sink Application is what you would write to connect

to the Elektron Edge.

Clients wishing to write new applications are encouraged to write to UPA or RFA (OMM-based) APIs

to take full advantage of the wire format benefits, as well as availability to future content that may only

be available via OMM-Based connections.

7.3 Criteria Based Requests (SSL/Market Feed), Symbol List Requests (OMM)

A criteria-based request (SSL/MF – SDK 4.5 API only) or a symbol List request (OMM – RFA or

UPA) is the mechanism that applications use to open a pre-defined set of items based on a named

criteria/symbol list with a single request. This facility can be used to:

Obtain the list of instrument names that matches some specific criteria (Symbol List and

CriteriaBased Requests)

Provide users/applications with a convenient way of retrieving multiple instruments without asking

on a name-by-name basis. (Currently Criteria-Based only. Symbol Lists may support this in the

future)

Because the list of items that meet a criteria can change over time, the contents of the response to the

Criteria-based request or Synbol List are open-ended, i.e. items can be added to or deleted from stream

dynamically by Elektron Edge.

Elektron Edge allows for the configuration of multiple criteria/symbol list definitions that are stored on

the server. Each definition is assigned a unique name by which it can be requested by a consumer

application. The creation of Critera-based/Symbol List definitions is an administrative function

performed on the Elektron Edge (through TRSC), and is not available programmatically through a real-

time API.

Criteria/Symbol List definitions can be constructed using any combinations of the following elements:

The first, and the simplest, is a reference to a file containing a list of RICs.

The second, is a reference to a specific database query (SQL statement) based on the following

criteria:

By RIC name with using SQL wildcard characters (―_‖, ―%‖, ―[charlist]‖ and ―[^charlist]‖

where charlist = a character or a group of characters)



By Exchange (ID, ISO, and Full Name)

By Country

By Record Type (ID and Display Name)

Or any combinations of the above (using AND or OR)

NOTE: The available criteria types will depend on the Data Dictionary Source that Elektron Edge has

connected to.

This query is submitted to a relational database, the result of which is a set of item names that

match the given query.

The third possibility is a reference to another Criteria-based/Symbol List definition.

7.3.1 Criteria/Symbol List Resolution

To resolve a database query and create the list of instruments that match the required criteria, Edge will

use information obtained from the Data Dictionary Source. The Data Dictionary Source is a Thomson

Reuters centrally-sited relational database that holds extensive reference information for all of the

exchange data, e.g., RIC, exchange, PE, record type plus many other fields.

A subset of the information held on the Data Dictionary Source (only the fields required for the criteria

search) will be retrieved by Edge and held in a local client-sited database on Edge. A search of the local

database will then be executed to identify all the instrument names that match the criteria defined by

the client. The local database is refreshed on a regular basis to ensure changes on the central database

are reflected locally.

7.4 Multiple Channel Support

Multiple logical channels are available to provide:

The ability to send logically different data streams, e.g. news or quotes or statistics, on separate

channels.

To establish and manage a number of different broadcast data streams.

There is no inter-channel request/response traffic, that is, all data retrieval requests sent over a specific

channel result in responses being sent over the same channel.

7.5 Watchlist Support

A watchlist is the sum of all unique items simultaneously in use across a client‘s channels; i.e., a

‗window‘ on the data the client is permissioned to access. There is an ‗overall‘ watchlist size for Edge

and this is defined centrally by Thomson Reuters. Edge‘s watchlist will contain both named items and

items in the broadcast data streams.

7.6 Data Health and Recovery

In the event of a communications link or source failure, the application will be notified and all records

sourced from that link will be marked as stale. When the communications link or the source is restored,

the application will be notified. Recovery mechanisms will vary according to the configuration of the

Elektron Edge installation.

The application will receive full unsolicited images after restoration of the communications channel.

The time taken to recover in either of these configurations will depend upon bandwidth availability and

number of instruments in the watchlists.

In the event of a failure between Edge and the user application, Edge will provide the following levels

of recovery (see sectionError! Reference source not found. for more details):

7.6.1 Image Refresh

After datafeed detected the outage, datafeed maintains a list of all records updated during the outage

and, when communications are restored, it forwards a full verify record of each record updated to the

user.

For outages longer than a second threshold, it is assumed that most records will have received updates;

therefore, full verify record for all open items will be sent.



7.7 News Services

Elektron Edge supports news headlines. Your application can access the incoming real-time headlines

by using the News 2000.

Story text segments can be accessed by requesting the text segment using the news access code

(PNAC) defined in the relevant headline. Refer to section 9.7, News 2000, for more information.

To receive News 2000 headlines, client can request N2_UBMS and Elektron Edge will then forward

the permissioned headlines to the sink application. Your application can access broadcast headlines by

requesting a pseudo RIC, ―N2_UBMS‖. The permissioned news headlines and story segments will then

be forwarded to your application.

LOGICAL DATA FORMATS IN SSL


8 LOGICAL DATA FORMATS IN SSL

8.1 Overview

Thomson Reuters uses the Marketfeed protocol for distributing logical (record) data to clients.

Marketfeed defines a set of messages and the protocol syntax and semantics of those messages. This

section defines the Marketfeed message structure and the specific Marketfeed messages which must be

processed by an SSL-based application.

When SSL posts an Image or Update event, the Data field of its information structure points to the

Marketfeed message.

8.2 Notation

The notations used to describe Marketfeed messages in this document are as follow:

[ ] Square brackets1 enclose optional message elements.

< > Angled brackets enclose ASCII control characters.

{} Curly brackets denote 0 or more repetitions in a message.

8.2.1 ASCII Characters

Obtainable from your local sales office, provides complete specifications on the character sets that are

currently in use. Edge uses the extended 8-bit ASCII character set. Since the ASCII character set

includes control characters which cannot be displayed or printed, the text in this manual encloses a

pseudonym for each such character in angle brackets, e.g. <FS>, where FS is the pseudonym for the

File Separator which has the ASCII value 0x1C. Wherever such representations occur in the text of this

section, the true ASCII hexadecimal value should be assumed.

Certain special characters use the extended 8-bit ASCII character set as representation.

8.2.2 Special Character Representations

8.2.2.1 Fractions in Price Fields

Price fields may contain fractional values using ASCII strings. For example, a BID price field might

contain the string ―113 ½‖ to represent the price ―one hundred thirteen and one half‖ or ―12 1/8‖ to

represent the price ―twelve and one eighth‖.

8.2.2.2 Special Brokerage Characters

Brokerage characters are incorporated into the RICs of many instruments. In order to represent special

brokerage characters using the Marketfeed character set, two-character strings are used. These strings

consist of an underscore (Hex 5F) followed by a lower case alphanumeric character.

The special brokerage characters that are currently defined, along with their equivalent two-character

representation, are:

Preferred PR _p

Warrants WT _t

When Issued WI _w

Units UNT _u

Rights RT _r

For example, Continental Bank Mortgage warrants class ‗o‘ traded over Instinet have the RIC name

CTB_to.I. This would normally be displayed (and would appear in Thomson Reuters directories) as

CTBWT o.I.

8.2.2.3 Price Ticks

Price ticks indicate the direction of trading from a previous trade. The characters (Hex DE) for an up

tick and (Hex FE) for a down tick are used.

1 A left square bracket character preceded by an ESC character (0x1B) does not indicate the start of an

optional sequence.



8.2.2.4 Special Language Characters

Special language characters are supported with their accents and other diacritics; for example, è.

8.2.3 Separators

The following delimiters are used in the protocol to separate fields within a record:

<FS> File Separator (0x1C)

<GS> Group Separator (0x1D)

<RS> Record Separator (0x1E)

<US> Unit Separator (0x1F)

Messages may also contain the following control characters:

<ESC>[ Two-byte control sequence introducer (0x1B 0x5B)

8.2.4 Message Structure

Marketfeed uses the following general message structure for all functions:

<FS>FUNCTION<US>TAG<GS>DATA<FS>

where: FUNCTION is a three-character function number which denotes the message type. The

function number determines the format, content, and purpose of a message. TAG is a two-character code used to track response. DATA is function-dependent data (such as a RIC, a code, or the contents of a record).

All messages start and end with a File Separator.

8.2.5 Repetitions

In the following protocol description, braces {} are used to denote repetition of elements within

Marketfeed records. The general format is:

{<RS>FID<US>VALUE}

where {<RS>FID<US>VALUE} is repeated for each field in a Marketfeed record.

Note that the braces are for notation only and are not transmitted as part of the message.

8.2.6 Intra-Field Position Sequence

Normally, updates to specific fields would be accomplished by sending the whole data field; however

with some large fields this can be inefficient when only a few characters within the data field are to be

updated. In such cases, Edge sends an intra-field positioning sequence within the data field, so that the

minimum number of characters is transmitted for a change.

The syntax of an intra-field positioning sequence is as follow: <ESC>[n<HPA>

where: <ESC>[ is the control sequence introducer (Hex 1B Hex 5B) n is an ASCII numeric string representing the cursor offset position relative to the

start of the field. <HPA> is the Horizontal Position Adjust character which terminates the intra-field

position sequence (Hex 60, which is the character ― ‗ ‖).

For example, for record FXFX, if the 64-byte FID 216 is currently stored as:

RATES FOR SOMEBODY BANK....USD 789.1 FRF123.45 SFR 67.890

where the field offset is: 0.........1.........2.........3.........4.........5.........6

0123456789012345678901234567890123456789012345678901234567890

and the following update is received (see section 8.4.2 for a full explanation of the Update_Record

(316) message):

<FS>316<US>34<GS>FXFX<US>12345

<RS>216<US><ESC>[10<HPA>XYZ BANK <ESC>[31<HPA>654.32<FS>



Then after the update is processed, the field will be stored as:

RATES FOR XYZ BANK ....USD 654.32 FRF123.45 SFR 67.890

NOTE:

Partial field updates always begin with an escape sequence.

The intra-field positioning sequence is not restricted to messages of any specific FID type.

Intra-field position offsets are zero relative to the start of the field; therefore it is possible to

receive a field containing a zero offset.

There can be any number of escape sequences within a data field.

It is possible that an intra-field positioning sequence might not be followed by data; i.e., the same

escape sequence could appear twice in succession preceding the characters to be updated at that

position.

8.2.7 Character Repetition

Marketfeed saves bandwidth by replacing strings of the same repeated character with a special short

sequence: <char><ESC>[n<REP>

Where: <char> is the character to be repeated (e.g. a blank space) <ESC>[ is the control sequence introducer (Hex 1B5B) n is an ASCII numeric string representing the number of times to repeat the

character <REP> is the repeat function sequence termination (Hex 62 which is an ASCII ―b‖)

For example, for record FXFX, if the 64-byte FID 216 is currently stored as:

RATES FOR SOMEBODY BANK....USD 789.1 FRF123.45 SFR 678

where the field offset is: 0.........1.........2.........3.........4.........5.........6

0123456789012345678901234567890123456789012345678901234567890

and the following update is received:

<FS>316<US>34<GS>FXFX<US>12345

<RS>216<US><ESC>[10<HPA> <ESC>[6<REP><FS>

Then after the update is processed, the field will be stored as:

RATES FOR Y BANK....USD 789.1 FRF123.45 SFR 678

The above update will cause the receiving system to apply an ASCII space at offset 10 from the start of

the field and to repeat the space 6 times from offset 11 onwards. A total of 7 spaces are therefore

written to the field starting at offset 10. Note that character repetition operates on the octet preceding

the control sequence.

8.3 General Marketfeed Message Format

Within a Marketfeed message, the information is organized in two groups: header information and

data fields.

NOTE:

As described below, most of the Marketfeed header information (except for the Functionfield) is

already provided by the SSL and thus does not need to be used by sink applications.

8.3.1 Header Portion of a Marketfeed Record

The Marketfeed Header Portion has the following general structure2:

Function

U

S

Tag G

S RIC

R

S R_Status

U

S

Field_

List_No

U

S RTL

G

S

Status

Code

R

S Text

2 The actual ordering of each header field is slightly different for different ―function‖ types.



Figure 8-1 Marketfeed Message Header Syntax

The following fields are of interest to Edge:

Function: Conveys the semantic value beyond that of the SSL Message Type. Applications may or

may not make use of the additional meaning associated with the message type. For example, an

application receiving an SSL update may choose to ignore the Marketfeed message type and treat

the message purely as a change in the data. On the other hand, an application concerned with (tic-

by-tic) market movements needs to differentiate among the different types of updates because

certain types do not reflect actual trading activity. Knowledge of the Marketfeed message type is

needed to correctly parse the Marketfeed message header. See section 8.4 for each message type.

Tag: Filled in with a constant value by Edge. A related functionality is provided by the SSL

ClientItemTag.

RIC: Usage of this field is optional.

Field_List_No: This field is of interest if the application is caching data.

RTL: Record transaction level. This optional field should not be used.

8.3.2 Data Field Portion of a Marketfeed Record

The data field portion of a Marketfeed record contains the real-time market data. It consists of a

sequence of data field pairs (where a pair consists of a unique FID and a data field value). These pairs

may be repeated many times. The data field has the following structure:

Figure 8-2 Data Fields within a Marketfeed Message

NOTE: Applications should not rely on a particular sequence of FIDs in data received.

A FID is a unique field identifier. The FID allows the application to determine the semantics of the

data field. It indicates both the field type of the data and its meaning. The type of the data indicates the

maximum size of the data and its format.

To illustrate, FID 6 from Edge is a PRICE field and it represents the Last Price of the underlying

instrument. An example of a data value for FID 6 is ―125 ¾‖.

8.3.3 Data Types Supported for Marketfeed Fields

Marketfeed-supported data types are listed in Table 8-1. All data of a given type may be treated the

same, no matter which service it originates from.

It is possible that additional FID types will be defined. An application should prepare to handle such a

situation.

What this means in practice is that applications may parse, store, and display data from a service by

simply handling the basic field types. To assign additional ―value‖ to data, an application must contain

additional service-specific information. For example, to record the daily closing price of an instrument

from a service, the application must ―know‖ which FID from that service indicates the closing price of

the underlying instrument. Elektron Edge uses FID 21 (HST_CLOSE) for the ―most recent non-zero

closing value or settlement price‖.

The only data type which requires specific guidelines is ENUMERATED. The Marketfeed protocol

supports enumerated types. Essentially, ENUMERATED fields contain integer data which can be

expanded to configured strings. Mapping the numeric ENUMERATED values to expanded



ALPHANUMERIC values is implemented by the application. The expansion process yields a new field

of type ALPHANUMERIC.

Applications converting ENUMERATED data should be prepared for circumstances where no mapping

can be found. In such a case, the application should use the un-expanded integer value in place of the

expanded ALPHANUMERIC.

Field Type Description

ALPHANUMERIC (5) The length quoted for any given Alphanumeric field is the maximum

length of the string that could present for that field.

Strings shorter than the quoted length can be received. An

Alphanumeric field may contain bytes in the range 0x00 through

0xFF, except 0x1C (<FS>) and 0x1E (<RS>). Those two bytes are

reserved for use in ending the field value string.

DATE (3) In 11-character format: dd mmm YYYY

01 FEB 2006

15 APR 2006

INTEGER (1) Integer fields have an optional minus character and may contain

ASCII characters 0-9.

LONG_ALPHANUMERIC (9) A synonym for Alphanumeric, except that it is typically assigned a

longer length (refer to the FID definition provided by the service).

PRICE (4) A Price field may contain integer, decimal, fractional or percentage

values, with an optional leading plus or minus character.

Decimals are expressed as:

12.34

Fractions are expressed as:

12 3/4

Percentages are expressed as:

12.34%

TIME (7) In 5-character 24-hour format: hh:mm

12:31

23:48

TIMSECS (0) In 8-character 24-hour format: hh:mm:ss

12:31:45

23:48:09

ENUMERATED (6)

An Enumerated field has a fixed list of contents within a defined

numeric range. The field contents can be delivered as either a numeric

value or as an alphanumeric abbreviation. When delivered as a

numeric, the value can be used as an index in a table of alphanumeric

abbreviations.

BINARY 8-bit binary codes for each character in the field; refer to section

8.3.3.1 for how to decode this type of data.

Table 8-1 Standard Marketfeed Field Types

8.3.3.1 Decoding Binary Data

In order to interpret the information in a binary data field, the following algorithm needs to be

implemented:

1. Extract the low order 6 bits (AND with a 6-bit mask) for each character.



2. Concatenate the bits. The first character (leftmost) in the FID value string provides

the least significant 6 bits. Prefix the 6 bits from each succeeding character to the

growing binary string.

3. Starting from the least significant bit, split the string into 8-bit bytes to get the final

value. (Discard any extra bits on the left.)

For example, if FID 1080 contains a binary value that displays as EP@ in ASCII, the decoded result is

the decimal value 1029 as illustrated below.

Character ASCII Hex Binary LO 6 bits

E 0x45 01000101 000101

P 0x50 01010000 010000

@ 0x40 01000000 000000

The concatenated string is:

000000010000000101

When this is divided into 8-bit bytes (starting at the right):

00000100 00000101

it decodes as 0405 in hex or 1029 in decimal.

The actual interpretation of the decoded binary depends on the field type.

8.4 Marketfeed Messages Types

This section lists all possible messages which may be sent by source applications or received by sink

applications. For more information on source and sink applications, please refer to section Error!

Reference source not found..

Each record type includes some or all of the following elements:

FUNCTION This field is used to specify the particular type of Marketfeed message being

received. The FUNCTION is found immediately after the initial <FS>.

TAG This field is replaced with a ClientItemTag. This field should be ignored

when parsing a message. The TAG follows a <US> separator.

RIC This field is not needed and should be skipped when parsing the message. The

RIC follows a <GS> separator.

R_STATUS Optional field which is not always present. This information is not needed by

the user application so this field should be skipped when parsing the message.

It is preserved for the sake of compatibility.

FIELD_LIST_NO This field can be used for efficient definition of field lists.

RTL Optional field which is not always present. Historically this field is used to

detect message loss and duplications. DO NOT USE.

<RS>FID<US>VALUE Field values are specified using repetitions of <RS>FID<US> and the field‘s

VALUE. The VALUE field may be of variables with length up to the maximum

length of the field and may contain white space characters (0x20).

NOTE:

In the examples that follow, certain positive numeric field values are preceded by a ‘+’ character

which is not shown here. Tag values shown are not necessarily as produced by Elektron Edge.

8.4.1 Record_Response and Snap_Response (340)

Format: <FS>340<US>TAG<GS>RIC[<RS>R_STATUS]<US>FIELD_LIST_NO<US>RTL{<RS>FID<U

S>VALUE}<FS>



Description: A Record_Response is an image which contains all fields for the requested record or for the record

being verified. This information is received by sink applications in an image event

(SSL_ET_ITEM_IMAGE). If the image is already stored in the application, all fields found in the

message should be applied to it (i.e. existing fields should be updated, new fields should be created and

their value set, and fields now missing should be dropped). Using the FID list for the service from

which the record was obtained, the application program can interpret the record on a field-by-field

basis using a simple table look-up procedure. Each field is of the general format:

<RS>FID<US>VALUE

Example 1 - Logical Record: In response to a sink application request for the record TRI, Edge might respond with the following

Record_Response:

<FS>340<US>XX<GS>TRI<US>78<US>31376<RS>1<US>6562<RS>2<US>67<RS>3<US>T

HOMSON REUTERS

<RS>4<US>9<RS>6<US>+32.15<RS>7<US>+32.14<RS>8<US>+32.15<RS>9<US>+32.1

300<RS>10<US>+32.14<RS>11<US>-

0.20<RS>12<US>+32.37<RS>13<US>+31.66<RS>14<US>1<RS>15<US>840<RS>16<US

>05 NOV

2009<RS>18<US>21:05<RS>19<US>+32.04<RS>21<US>+32.35<RS>22<US>+0.00<RS

>23<US>+0.00<RS>24<US>+0.00<RS>25<US>+0.00<RS>26<US>+34.19<RS>27<US>+

32.99<RS>28<US>YYYY<RS>29<US>02:10<RS>30<US>+0<RS>31<US>+0<RS>32<US>+

730084<RS>34<US>+1.57447<RS>35<US>+3.46<RS>36<US>+20.55<RS>37<US>0<RS

>38<US>15 DEC 2009<RS>39<US>18 NOV

2009<RS>40<US>212<RS>42<US>+1<RS>43<US>+70000<RS>44<US>2<RS>53<US>2<R

S>56<US>-

0.62<RS>57<US>+0<RS>58<US>17:50<RS>60<US>+0<RS>61<US>+0<RS>71<US>+1.1

2<RS>77<US>+0<RS>78<US>000884903105<RS>79<US>04 NOV

2009<RS>90<US>+35.88<RS>91<US>+19.30<RS>100<US>+32.35<RS>104<US>0<RS>

105<US>

<RS>110<US>0<RS>111<US>0<RS>114<US>+0<RS>115<US>0<RS>117<US>0<RS>118<

US>30<RS>119<US>0<RS>131<US>0<RS>178<US>+600<RS>199<US>7<RS>200<US>2<

RS>203<US>+0<RS>204<US>+0<RS>205<US>+0<RS>206<US>+0<RS>207<US>+0<RS>2

08<US>

<RS>209<US>0<RS>210<US>0<RS>211<US>+0<RS>259<US>113<RS>293<US>

<RS>296<US> <RS>340<US>PWXY <RS>350<US>14 SEP 2009<RS>351<US>21

NOV 2008<RS>372<US>+32.03<RS>373<US>+100<RS>374<US>587<RS>375<US> :

:

<RS>376<US>+0.0000<RS>377<US>+0<RS>378<US>0<RS>379<US>22:15:24<RS>380

<US>0<RS>728<US>TRI.TO

<RS>825<US>0<RS>850<US>+0.00<RS>851<US>0<RS>869<US>4<RS>886<US>+0.00<

RS>901<US> <RS>967<US>

<RS>996<US>+0.00<RS>997<US>+0.00<RS>998<US>+0.00<RS>999<US>+0.00<RS>1

000<US> 6 <RS>1001<US> <RS>1002<US> <RS>1003<US> U

<RS>1018<US>53<RS>1021<US>+2037330<RS>1022<US>

<RS>1023<US>+0<RS>1025<US>01:00:00<RS>1041<US>N<RS>1042<US>

<RS>1043<US>T<RS>1044<US><0x00><RS>1055<US>0<RS>1056<US>0CWiMnKNPTzB<

RS>1061<US> : : <RS>1062<US> : :

<RS>1067<US>21:05:12<RS>1075<US>4<RS>1076<US>4<RS>1077<US>+0.00<RS>10

80<US>Nc@<RS>1352<US>

<RS>1379<US>+32.0390<RS>1383<US>@p@<RS>1425<US>

<RS>1465<US>+0<RS>1496<US>+0.00<RS>1501<US><0x00><0x00><0x00><RS>1642

<US>+0.35273<RS>1709<US>9<RS>1787<US>+0<RS>1788<US>

<RS>2142<US>+0<RS>2150<US>+0<RS>2321<US>+0<RS>2323<US>+0.00<RS>2324<U

S>+0.00<RS>2325<US>

<RS>2326<US><0x00><0x00><0x00><0x00><RS>2396<US>0<RS>2397<US>0<RS>273

8<US> : : <RS>2739<US> : :

<RS>2744<US>+0<RS>3131<US>+0<RS>3132<US>+0<RS>3246<US>+0.00<RS>3247<U

S>+0<RS>3248<US>+1<RS>3249<US>+0<RS>3250<US>+32.89<RS>3251<US>+31.02<

RS>3252<US>+29.42<RS>3253<US>+621643<RS>3254<US>+510311<RS>3255<US>+6

50348<RS>3256<US>+0.00<RS>3257<US>+0.00<RS>3261<US>0<RS>3262<US>

<RS>3263<US>@@@<RS>3264<US>30<RS>3297<US>0<RS>3298<US>0<RS>3364<US>0<



RS>3372<US>+0.00<RS>3386<US> <RS>3404<US>+0<RS>3422<US>

<RS>3580<US> <RS>3655<US> <RS>3694<US>

<RS>3750<US>+0.00<RS>3756<US><0x00><0x00><0x00><0x00><0x00><0x00><0x0

0><0x00><0x00><0x00><0x00><0x00><RS>3830<US>+0<RS>3831<US>+0<RS>3853<

US>+75912703<RS>3854<US>+80124639<RS>3855<US>+3600383<RS>3856<US>+733

69846<RS>3888<US> <RS>3889<US> <RS>3890<US> <RS>4058<US>

<RS>4230<US> <RS>4232<US>

<RS>4235<US>+0<RS>4236<US>0<RS>4238<US> <RS>4241<US>

<RS>4267<US><RS>4268<US><RS>4300<US>

<RS>4305<US>+0<RS>4345<US> <RS>4346<US> <RS>4373<US> <RS>4374<US>

<RS>4375<US> <RS>4377<US>0<RS>4378<US>0<RS>4379<US>0<RS>4410<US>

<FS>

The message is transmitted as a sequence of ASCII characters including the special separator

characters. (Note that the carriage returns used to format the message in the preceding text are not

included in the actual message. Messages are delivered as a continuous ASCII string with <FS>

identifying the start and end of the message.)

Message Acronym Field Meaning <FS> 340<US> Record_Response command XX<GS> TAG TRI<US> RIC 78<US> Field List Number 31376<RS> Record Transaction Level 1<US>6562<RS> PROD_PERM IDN Permissions Code 2<US>67<RS> RDNDISPLAY Display type (please ignore) 3<US>THOMSON REUTERS

<RS>

DSPLY_NAME Name of Instrument

4<US>9<RS> RDN_EXCHID Exchange identifier 6<US>+32.15<RS> TRDPRC_1 Last trade price 7<US>+32.14<RS> TRDPRC_2 Previous last trade price 8<US>+32.15<RS> TRDPRC_3 Previous last trade prices or values. 9<US>+32.1300<RS> TRDPRC_4 Previous last trade prices or values. 10<US>+32.14<RS> TRDPRC_5 Previous last trade prices or values. 11<US>-0.20<RS> NETCHNG_1 Net change 12<US>+32.37<RS> HIGH_1 Today‘s highest trade price 13<US>+31.66<RS> LOW_1 Today‘s lowest trade price 14<US>1<RS> PRCTCK_1 Price Tick (direction of trading from

previous trade) 15<US>840<RS> CURRENCY Currency in which prices are quoted 16<US>05 NOV 2009<RS> TRADE_DATE Date of last trade 18<US>21:05<RS> TRDTIM_1 Time of last trade 19<US>+32.04<RS> OPEN_PRC Today‘s opening price 21<US>+32.35<RS> HST_CLOS Most recent non-zero closing price 22<US>+0.00<RS> BID Latest bid price 23<US>+0.00<RS> BID_1 Previous latest bid prices the first being most

recent 24<US>+0.00<RS> BID_2 Previous latest bid prices the first being most

recent 25<US>+0.00<RS> ASK Latest ask price 26<US>+34.19<RS> ASK_1 Previous latest ask prices the first being most

recent 27<US>+32.99<RS> ASK_2 Previous latest ask prices the first being most

recent 28<US>YYYY<RS> NEWS News RIC (page code of latest news story

for instrument) 29<US>02:10<RS> NEWS_TIME Time of news story (FID 28) 30<US>+0<RS> BIDSIZE Quantity bid at latest bid price 31<US>+0<RS> ASkSIZE Quantity ask at latest ask price 32<US>+730084<RS> ACVOL_1 Volume accumulated 34<US>+1.57447<RS> EARNINGS Latest reported earnings per share 35<US>+3.46<RS> YIELD Dividend per share as % of price



Message Acronym Field Meaning 36<US>+20.55<RS> PERATIO Ratio of stock price to earnings per share 37<US>0<RS> DIVIDENDTP Latest reported dividend type 38<US>15 DEC 2009<RS> DIVPAYDATE Date on which dividend paid 39<US>18 NOV 2009<RS> EXDIVDATE Date on which issue trades ex-dividend 40<US>212<RS> CTS_QUAL For US stock the CTS ticker price qualifier 42<US>+1<RS> BLKCOUNT Number of block trades today 43<US>+70000<RS> BLKVOLUM Today‘s total block trading volumn 44<US>2<RS> TRDXID_1 Exchange identifier of the latest trade 53<US>2<RS> TRD_UNITS Price units in which instrument trades 56<US>-0.62<RS> PCTCHNG Percentage change in latest trade price 57<US>+0<RS> OPEN_BID First bid price of the day 58<US>17:50<RS> DJTIME Time of latest Dow Jones news story on the

company 60<US>+0<RS> CLOSE_BID Last bid price of day 61<US>+0<RS> CLOSE_ASK Last ask price of day 71<US>+1.12<RS> DIVIDEND Latest reported dividend paid per share 77<US>+0<RS> NUM_MOVES Number of trades today 78<US>000884903105<RS> OFFCL_CODE The SEDOL 79<US>04 NOV 2009<RS> HSTCLSDATE Date for historical close value 90<US>+35.88<RS> YRHIGH Highest value this year 91<US>+19.30<RS> YRLOW Lowest value this year 100<US>+32.35<RS> TURNOVER The daily turnover revenue or value of all

shares for either a particular instrument or an

exchange. 104<US>0<RS> BOND_TYPE Type of instrument 105<US> <RS> BCKGRNDPAG Background page code 110<US>0<RS> YCHIGH_IND Year high indicator 111<US>0<RS> YCLOW_IND Year low indicator 114<US>+0<RS> BID_NET_CH The difference between the latest bid and the

historic closing bid 115<US>0<RS> BID_TICK_1 The direction of bidding from the previous

bid

117<US>0<RS> CUM_EX_MKR Cum/Ex security marker

118<US>30<RS> PRC_QL_CD Price qualifier code 119<US>0<RS> NASDSTATUS For NASD and SEAQ issues this indicates

the market status 131<US>0<RS> PRC_QL2 Second price qualifier code 178<US>+600<RS> TRDVOL_1 Transactional volume of last trade price 199<US>7<RS> OPENEXID For US composite quotes the exchange

identifier of the exchange where the opening

price was made 200<US>2<RS> CLSEXID For US composite quotes the exchange

identifier of the exchange from where the

historic close originates 203<US>+0<RS> BID_HIGH_1 Today‘s highest bid price 204<US>+0<RS> BID_LOW_1 Today‘s lowest bid price 205<US>+0<RS> YRBIDHIGH The highest bid this calendar year 206<US>+0<RS> YRBIDLOW The lowest bid this calendar year 207<US>+0<RS> HST_CLSBID The historic closing bid 208<US> <RS> HSTCLBDDAT The historic closing bid date 209<US>0<RS> YRBDHI_IND Indicator showing whether or not the highest

bid this calendar year was made today 210<US>0<RS> YRBDLO_IND Indicator showing whether or not the lowest

bid this calendar year was made today 211<US>+0<RS> NUM_BIDS The number of bids made for a NASDAQ

bid ask quoted equity 259<US>113<RS> RECORDTYPE Indicates which building block/instrument

class record belongs to 293<US> <RS> BID_MMID_1 Identifiers showing three market-makers on

the bid side of a quote. 296<US> <RS> ASK_MMID_1 Identifiers showing three market-makers on

the ask side of a quote



Message Acronym Field Meaning 340<US>PWXY <RS> OPTION_XID An ASCII string holding up to six exchange

identifiers of where options on an equity are

traded 350<US>14 SEP 2009<RS> YRHIGHDAT Date on which the year or contract high as

held in the YRHIGH and LOCHIGH fields

respectively was made 351<US>21 NOV 2008<RS> YRLOWDAT Date on which the year or contract low as

held in the YRLOW and LOCLOW fields

respectively was made 372<US>+32.03<RS> IRGPRC A cancelled, inserted, retransmitted, or

irregular price 373<US>+100<RS> IRGVOL Volume associated with FID 372 374<US>587<RS> IRGCOND IRG price type 375<US> : : <RS> TIMCOR Time of price correction 376<US>+0.0000<RS> INSPRC When an exchange sends a correction report

with details of both the cancelled and

inserted price this field holds the inserted

price 377<US>+0<RS> INSVOL The volume associated with the price held in

the field INSPRC (FID 376) 378<US>0<RS> INSCOND An indication of the type of price held in the

field INSPRC (FID 376) 379<US>22:15:24<RS> SALTIM Time of last trade 380<US>0<RS> TNOVER_SC Turnover scale 728<US>TRI.TO <RS> BCAST_REF Cross-reference for News 2000 825<US>0<RS> CROSS_SC Scaling for cross-rates 850<US>+0.00<RS> AMT_OS For debt or equity instruments the number

outstanding and therefore still tradable 851<US>0<RS> AMT_OS_SC The scaling of the amount outstanding field

AMT_OS 869<US>4<RS> OFF_CD_IND Official code indicator for FID 78 886<US>+0.00<RS> PRC_VOLTY Price volatility 901<US> <RS> AMT_OS_DAT The date of the amount outstanding

AMT_OS 967<US> <RS> BKGD_REF Pointer for background page 996<US>+0.00<RS> GEN_VAL1 General purpose numerical field, meaning

deter-mined by FID 1000 997<US>+0.00<RS> GEN_VAL2 General purpose numerical field, meaning



deter-mined by FID 1003 1000<US> 6 <RS> GV1_TEST Describes contents of FID 996 1001<US> <RS> GV2_TEST Describes contents of FID 997 1002<US> <RS> GV3_TEXT Describes contents of FID 998 1003<US> U <RS> GV4_TEST Describes contents of FID 999 1018<US>53<RS> IRGXID This field will be used to transmit the

Exchange Identifier of all CTS trades

desinated as ‗not last‘ trades 1021<US>+2037330<RS> SEQNUM This field contains the message sequence

number. For NMTS this is a six-digit

number. 1022<US> <RS> PRNTYP Label for SIAC trade reports signifying

whether the trade report print contains a

single, double or triple trade. 1023<US>+0<RS> PRNTBCK Transmitted by RQS on receipt of a

correction message from SIAC containing

the 'print back' count. 1025<US>01:00:00<RS> QUOTIM Quote time given in seconds 1041<US>N<RS> GV1_FLAG Generic flags applicable to GEN_VAL1. 1042<US> <RS> GV2_FLAG Generic flags applicable to GEN_VAL2.



Message Acronym Field Meaning 1043<US>T<RS> GV3_FLAG Generic flags applicable to GEN_VAL3. 1044<US><0x00><RS> GV4_FLAG Generic flags applicable to GEN_VAL4. 1055<US>0<RS> OFF_CD_IN2 Unique numeric code assigned to the

instrument and indication of source of code. 1056<US>0CWiMnKNPTzB<RS

>

OFFC_CODE_1 Unique numeric code assigned to the

instrument and indication of source of code. 1061<US> : : <RS> GV1_TIME Generic time given in seconds. 1062<US> : : <RS> GV2_TIME Generic time given in seconds. 1067<US>21:05:12<RS> EXCHTIM The exchange time 1075<US>4<RS> YRHI_IND Indicates to greater detail the content of

YRHIGH 1076<US>4<RS> YRLO_IND Indicates to greater detail the content of

YRLOW 1077<US>+0.00<RS> BETA_VAL Beta value 1080<US>Nc@<RS> PREF_DISP The 'preferred' display template number. 1352<US>

<RS>

DSPLY_NMLL 2Local language instrument name.

1379<US>+32.0390<RS> VOL_X_PRC1 Numeric field to contain a value equivalent

to the product of latest trade volume and

latest trade price (TRDVOL_1 *

TRDPRC_1) 1383<US>@p@<RS> DSO_ID Data source owner 1425<US> <RS> UPC71_REST A flag which indicates whether or not a

NASDAQ security is UPC-71

―RESTRICTED‖ 1465<US>+0<RS> ADJUST_CLS The last value available for close which is

stored for Graphics also adjusted for capital

changes. 1496<US>+0.00<RS WEIGHTING The weighting of a stock within an index. 1501<US><0x00><0x00><0x

00><RS>

STOCK_TYPE This field details stock class

Bearer/registered status and any other

security feature affecting security holder

rights. 1642<US>+0.35273<RS> IMP_VOLT Implied Volatility 1709<US>9<RS> RDN_EXCHD2 Identifier for the exchange on which the

instrument trades. 1787<US>+0<RS> GV3_DATE Generic date field 1788<US> <RS> CP_ADJ_DAT Capital adjustment date 2142<US>+0<RS> AMT_ISSUE Total amount of issued share 2150<US>+0<RS> MKT_VALUE Issue amount * Last Price 2321<US>+0<RS> SPEC_TRADE Special terms trading flag 2323<US>+0.00<RS> FCAST_EARN Forecasted earnings 2324<US>+0.00<RS> EARANK_RAT Earnings rank ratio 2325<US> <RS> FCAST_DATE Date of the Forecast 2326<US><0x00><0x00><0x

00><0x00><RS>

YEAR_FCAST Year forecast

2396<US>0<RS> IRGMOD A modifier to the enumerated type field

IRGCOND (FID 374) which is in turn an

indicator of the type of price held in the field

IRGPRC (FID 372) 2397<US>0<RS> INSMOD A modifier to the enumerated type field

INSCOND (FID 378) which is in turn an

indicator of the type of price held in the field

INSPRC (FID 376) 2738<US> : : <RS> GV3_DATE Generic time fields in Seconds. 2739<US> : : <RS> GV4_TIME Generic time fields in Seconds. 2744<US>+0<RS> MKT_CAP Market Capitalisation of a security 3131<US>+0<RS> IRGFID IRGVAL data FID number 3132<US>+0<RS> IRGVAL IRGFID correction value 3246<US>+0.00<RS> PCT_ABNVOL Percentage of abnormal volume increase

based on the last 10-day moving average

volume



Message Acronym Field Meaning 3247<US>+0<RS> BC_10_50K Number of block transactions between 10K

and 50K shares 3248<US>+1<RS> BC_50_100K Number of block transactions above 50K

and up to 100K shares 3249<US>+0<RS> BC_100K Number of block transactions above 100K

shares 3250<US>+32.89<RS> PMA_50D Price Moving Average for 50 days 3251<US>+31.02<RS> PMA_150D Price Moving Average for 150 days 3252<US>+29.42<RS> PMA_200D Price Moving Average for 200 days 3253<US>+621643<RS> VMA_10D Volume Moving Average for 10 days 3254<US>+510311<RS> VMA_25D Volume Moving Average for 25 days 3255<US>+650348<RS> VMA_50D Volume Moving Average for 50 days 3256<US>+0.00<RS> OPN_NETCH Difference between open price and the

previous close price 3257<US>+0.00<RS> CASH_EXDIV The latest reported cash dividend to be paid

per share to shareholders 3261<US>0<RS> MKT_VAL_SC The scaling factor for the MKT_VALUE

(FID 2150) 3262<US> <RS> CASH_EXDAT The date on which the issue will trade ex-

dividend with cash dividend 3263<US>@@@<RS> PREV_DISP Field to hold original (4 digit) display

template for DT upgrades. Same FID format

as PREF_DISP so can hold any values that

FID can. 3264<US>30<RS> PRC_QL3 Extended Price Qualifier FID. 3372<US>+0.00<RS> OFF_CLOSE Official Close 3386<US> <RS> QUOTE_DATE Quote Date 3404<US>+0<RS> VWAP VWAP 3422<US>

<RS>

PROV_SYMB Provider Symbol

3580<US> <RS> BID_ASK_DT For Equities and FI instruments globally 3655<US>

<RS>

ISIN_CODE ISIN Code

3694<US>

<RS>

MNEMONIC Exchange ID

3750<US>+0.00<RS> RTR_OPN_PR RTRS Opening Price 3756<US><0x00><0x00><0x

00><0x00><0x00><0x00><0

x00><0x00><0x00><0x00><

0x00><0x00><RS>

SEDOL SEDOL code

3830<US>+0<RS> VWAP1 VWAP1 3831<US>+0<RS> VWAP2 VWAP2 3853<US>+75912703<RS> TRDTIM_MS TRDTIM MS 3854<US>+80124639<RS> SALTIM_MS SALTIM MS 3855<US>+3600383<RS> QUOTIM_MS QUOTIM MS 3856<US>+73369846<RS> TIMCOR_MS TIMCOR MS 3888<US> <RS> FIN_STATUS Financial STAT IND 3889<US> <RS> LS_SUBIND Submarket IND LS 3890<US> <RS> IRG_SUBIND Submarket IND IRG2 4058<US>

<RS>

EXCHCODE Exchange Code

4230<US>

<RS>

ANNDIVTYPE Annual DIV Type

4232<US>

<RS>

ANNEPSTYPE Annual EPS Type

4235<US>+0<RS> ORGID ORGID 4236<US>0<RS> PR_FREQ Price Update Frequency 4238<US> <RS> RCS_AS_CLA RCS Asset Class 4241<US>

<RS>

UNDR_INDEX Underlying Index

4267<US><RS> FUTURES Futures Chain RIC 4268<US><RS> OPTIONS Options Chain RIC



Message Acronym Field Meaning 4300<US>

<RS>

STRIKES Strikes Coverage

4305<US>+0<RS> NEWSTM_MS NEWSTM MS 4345<US> <RS> TRD_THRU_X TRD Through Exempt 4346<US> <RS> IRG_TDTH_X IRG TRD Through Exempt 4373<US> <RS> FIN_ST_IND FIN STATUS IND 4374<US> <RS> IRG_SMKTID IRG SUB MKT CTR ID 4375<US> <RS> SUB_MKT_ID SUB MKT CTR ID 4377<US>0<RS> ACT_DOM_EX ACTIV DOM EXCH 4378<US>0<RS> ACT_OTH_EX ACTIV OTHR EXS 4379<US>0<RS> TRD_QUAL_2 TRD QUAL 2 4410<US> CP_EFF_DAT CAP Effective Date <FS>

Source

Application

Data Stream for a Channel

Sink

Application

Update ImageUpdateStatus

Figure 8-3 Analysis of a Typical Record_Response

Please note that the above table was correct at the time of printing but changes may occur to the

content and structure of this record.

The layout of

Source

Application

Data Stream for a Channel

Sink

Application

Update ImageUpdateStatus

Figure 8-3 is arbitrary and intended only for clarification. In practice the <RS> character introduces a

field sequence, e.g. <RS>FID<US>VALUE, instead of following the sequence as shown.

The above arrangement highlights space characters in the VALUE field.

The figure also highlights a number of other features:

Several fields serve to illustrate the variable length attributes of the logical record structure; for

example the price fields 6, 22 and 25 (TRDPRC_1, BID and ASK) can have a maximum of 17

characters but in each case use only 4 characters.

Fields 11 and 56 show how signed numerics are presented. Note that most positive fields will be

preceded by a ‗+‘ character. Also, ‗+0‘ and ‗-0‘ may appear and have different display

implications.

Example 2 - Page Record: In response to a sink application request for the page record FXFX, Edge might respond with the

following Record_Response:

<FS>340<US>l8<GS>FXFX<US>51<US>53927<RS>-8820<US>1<RS>1<US>141<RS>2<US>132

<RS>215<US><ESC>[0<HPA>1231 CCY PAGE NAME * REUTER SPOT RATES · CCY HI*EURO*LOFXFX



<RS>216<US><ESC>[0<HPA>1230 DEM BHFX BHF-BANK FFT 1.7138/48 * DEM 1.714 51.7058

<RS>217<US><ESC>[0<HPA>1230 GBP RBSX ROY SCOT LDN 1.6150/55 * GBP 1.6220 1.6138

<RS>218<US><ESC>[0<HPA>1230 CHF DNCO NORSKE OSL 1.5215/25 * CHF 1.5240 1.5160

<RS>219<US><ESC>[0<HPA>1230 JPY SBZX SWISS BK ZUR 156.90/00 * JPY 157.10 156.70

<RS>220<US><ESC>[0<HPA>1229 FRF SOGE SOC GEN PAR 5.7675/05 * FRF 5.7690 5.7430

<RS>221<US><ESC>[0<HPA>1229 NLG HOZX V.D.HOOP RTD 1.9290/95 * NLG1 1.9295 1.9204

<RS>222<US><ESC>[0<HPA>1229 ITL BCIX B.C.I. MIL 1259.75/0.25 * ITL 1260.20 1254.75

<RS>223<US><ESC>[0<HPA>1224 ECU BAXX BARCLAYS LDN 1.1930/35 * ECU 1.1976 1.1925

<RS>224<US><ESC>[0<HPA>---------------------------------------------------------------

<RS>225<US><ESC>[0<HPA>XAU SBBM 368.25/368.75 * ED3 8.31/8.43 * FED * LFDAJUN

<RS>226<US><ESC>[0<HPA>XAG CSGL 4.95/4.97 * US30Y YTM 8.45 * * A 9323

<RS>227<US><ESC>[0<HPA>

<RS>228<US><ESC>[0<HPA>

<FS>

Note the use of the positioning sequence <ESC>[0<HPA> where:

<ESC>[ Control sequence introducer. 0 The horizontal offset value (in this case it is 0). <HPA> The Horizontal Position Absolute character.

These characters enable the user to position the data in the field.

The central system has transmitted the 14-line page as 14 unique fields and positioning characters

within those fields.

8.4.2 Update_Record (316)

Format: <FS>316<US>TAG<GS>RIC<US>RTL{<RS>FID<US>VALUE}<FS>

Description: Edge sends an Update_Record when the data for a record in the cache changes. Market movement is

implied. The Update_Record information is sent using an update event (SSL_ET_ITEM_UPDATE).

The Update_Record data contains subsets of the fields in the record. The update for each field has the

following format:

<RS>FID<US>VALUE

Example 1 – Logical Record: Refer to the image of the record TRI with the Record_Response (340) message.

Suppose the following updates are received for the record:

<FS>316<US>XX<GS>TRI<US>49712<RS>22<US>+32.3200<RS>25<US>+32.92

00<FS>

The update message changes the contents of FID 22 (BID price) to 32.3200 and FID 25 (ASK price) to

32.9200. Note that because of the logical structure, the fields can be presented in any order.

Example 2 – Page Record: The following updates might be received for page record FXFX:

<FS>316<US>A1<GS>FXFX<US>53928

<RS>215<US><ESC>[0<HPA>1231

<RS>216<US><ESC>[9<HPA>BVMX BAYR VER MUN<ESC>[33<HPA>41/46

<RS>216<US><ESC>[0<HPA>1230<ESC>[19<HPA><ESC>[33<HPA>80/00<FS>

<FS>316<US>A1<GS>FXFX<US>53929

<RS>215<US><ESC>[0<HPA>1231

<RS>220<US><ESC>[33<HPA>90/10

<RS>222<US><ESC>[9<HPA>ISTX SANPAOLO

TRN<ESC>[30<HPA>9.80/0.80<FS>

Again note the use of the Escape sequence for positioning.



8.4.3 Correct_Record (317)


Description: Record corrections are similar to updates, but are sent intentionally to correct previous errors in data.

They do not imply real market movements. The Correct_Record information is sent using an update

event (SSL_ET_ITEM_UPDATE).

The Correct_Record data contains a subset of the fields in the record. The update for each field has the

following format:

<RS>FID<US>VALUE

Example: Refer to the image of the record TRI with the Record_Response (340) message.

Suppose the following corrections are received for the record:

<FS>317<US>XX<GS>TRI<US>50046<RS>1041<US>N<RS>3888<US>N<FS>

The correction message changes the contents of fields 1041 and 3888 to N.

NOTE:

Corrections will have an impact on ripple fields. Applying a correction may also require a resolution

of the contents of the relevant ripple stack. See section 8.5.

8.4.4 Close_Record (312)


Description: Close_Record messages are sent prior to the start of market trading. Typically such adjustments are:

previous night‘s last traded price is copied to the close price field. Close_Record messages are not a

reflection of market activity. The Close_Record information is sent using an update event

(SSL_ET_ITEM_UPDATE).

The Close_Record data contains a subset of the fields in the record. The update for each field has the

following format:

<RS>FID<US>VALUE

Example: Refer to the image of the record TRI with the Record_Response (340) message.

Suppose the following Close_Record message is received for the record:

<FS>312<US>XX<GS>TRI<US>3456<RS>12<US><RS>13<US><FS>

This message clears the fields High_1 and Low_1 (today‘s high and low prices) whose FIDs are 12 and

13 respectively. For clarity, this message example contains only two closing adjustments; however,

depending upon the record many more fields are likely to be transmitted in the message.

NOTE: This message does not close the data stream.

8.4.5 Verify_Record (318)

Format: <FS>318<US>TAG<GS>RIC[<RS>VER_SUB]<US>FIELD_LST_NO<US>RTL{<RS>F

ID<US>VALUE}<FS>

where:

VER_SUB is an optional field. If the field is not present or if it has a value of 3, it indicates

that the message is a full verify. If the field has a value of 4, it indicates that the

message is partial verify.

NOTE: Partial verify records may be received that contain no data fields (i.e. no FID numbers and

values). These may be ignored.



Description: Verify_Record messages are sent at any time of day to allow Edge and client applications to verify that

records are synchronized. The Verify_Record information is sent using an

SSL_ET_UNSOLICITED_IMAGE event. The partial Verify_Record information is sent using an

SSL_ET_ITEM_UPDATE event. All verify messages should be applied by the application unless they

contain no data fields.

A Verify_Record may contain:

all fields in the record (full verify 3

), in which case it replaces the current image, or

only a subset of the fields (partial verify4

), in which case it should be treated as an update.

Using the FID list for the service from which the record obtained, the application program can interpret

the message on a field-by-field basis using a simple table look-up procedure. Each field has the

following general format:

<RS>FID<US>VALUE

NOTE:

Your application should not rely upon the FID numbers being in order.

8.5 Ripple Fields

Some FIDs within the Master FID List are defined as ripple fields. That is, when their value changes,

the former value is supposed to become the new value of another FID, automatically. The change to

that FID may, in turn, cause another FID to be changed to reflect the second FID‘s former value, etc.

When an image is received, the entire ripple FIDs to be used are present in the image. In some cases,

the values delivered for the ―ripple-to‖ FIDs in an initial image may be empty or zero, but they must be

present in the record.

When an update is received, only the ―primary‖ FID (the first one in the set) is updated. None of the

secondary FIDs, which their values are to ripple, are sent.

The datafeed server ensures that the ripple FIDs are updated correctly in the server cache. When an

image is sent to an application, all the FIDs, including the ―ripple-to‖ FIDs, are sent with the cached

data. When updates are sent, only the primary FID is sent when it changes, but never the ―ripple-to‖

FIDs.

The semantics of ripple fields means that sink applications that want to keep track of the non-primary

FIDs must do the tracking internally. They must note which FIDs are ―ripple fields‖, as defined in the

Master FID List, and handle the migration of values from one to the other on their own.

3 Sometimes referred to as a VSYNC.

4 Sometimes referred to as a VNOSYNC.

IMPLEMENTATION GUIDELINES


9 IMPLEMENTATION GUIDELINES

This section provides guidelines for implementing software to handle data over Edge.

9.1 Data Enhancement Releases

Occasionally, Thomson Reuters will make changes to the formats in which it delivers data to Edge

clients. These changes are driven by the needs of clients. They may provide additional data, remove

obsoleted or unused information, or support instruments or exchanges added to Edge.

All data enhancements are published via page DNLATEST1 or CHANGES (see section 9.1.1). This

information can also be found on the Thomson Reuters Web at:

http://opensystems.session.rservices.com/opensystems/

or on the public Internet at:

http://customers.reuters.com/

NOTE: You are required to register with Thomson Reuters to access the public Internet site.

9.1.1 Administrative Messages

Specific administrative messages are available via Edge which report current changes to the datafeed

network and notifications of upcoming product and datafeed changes. These changes are available via

an index on DNLATEST1 or CHANGES. Normal page processing rules in section 9.4 apply.

Client applications are expected to process these pages, as they contain vital information to the

ongoing maintenance and support of the datafeed service.

Current network changes include detailed alerts on system problems, RIC changes, released exchanges

and significant changes in the network. These messages change dynamically as conditions permit.

Clients are encouraged to monitor these messages as they contain vital day-to-day information on the

datafeed network.

Notification of changes to the network are distributed via specific administrative messages under the

DNLATEST1 (or CHANGES) pages. These notifications will be added to the network on an as-

needed basis. Notifications will remain on the network for a minimum of one week after they are

effective.

NOTE: It is intended that official notification of all changes will be via the page DNLATEST1 (or

CHANGES); therefore, processing these messages is essential to maintain pace with upcoming

product and network changes.

The following ranges of administrative pages will also be available:

DNLATEST1 or

CHANGES

Edge Notification Pages

This page serves as the Index for official notifications expressly intended for Edge

clients.

RZKA-RZKD RIC Change Master Index Pages

These pages serve as an index to ranges of pages used to indicate changes to RICs

from stock exchanges. On the page ranges for individual exchanges information on

adding, deleting and changing RICs will be found and the data on which these changes

occurred. As space is limited, only the most recent changes will appear.

9.1.1.1 Technical Details of Implementation

These page records are 14 rows by 64 characters and use FIDs 215-228 for each row. Parsing of these

pages is the same as other pages, as detailed in section 9.4. Datafeed subscribers once permissioned for

access to these pages should query the key items from these administrative pages on a regular basis to

keep up-to-date changes to the network and datafeed products.

http://opensystems.session.rservices.com/waverunner/



9.2 Processing FIDs

Client applications should process all FIDs in the messages in an identical manner. After receiving

messages from Edge, use the Master FID List to deduce each field's type and nature.

A response message contains a complete set of data items for the record concerned. Update messages

on the other hand contain only a subset of fields to be updated on the user‘s system. In both cases,

however, the processing requirements are the same, i.e. each field has a FID number and a value. By

looking up the FID in the Master FID List, the application can determine the type and format of the

value.

It is possible, however, to receive updates to FIDs which are not yet supported in your system or which

are not in the original record response. It is recommended that in such cases the application discards

that FID and its accompanying data; however, other valid FIDs in the same message should not be

discarded.

NOTE:

Your application should not rely upon the FID numbers being in order.

The algorithm in Figure 9-1 suggests a method to process the FID numbers in a message which can be

adopted by the developer. This is a general high-level description of message processing; it does not

detail the specific requirements for each message type.

get message IF message type is unknown

THEN discard_message()

ELSE

FOR (each message_field)

DO

IF message_field is a FID

THEN

IF FID is in master field list & is in the

original record image

THEN

IF field syntax is correct

THEN

process_data (ignoring

unsupported control sequences)

ENDIF

ELSE

ignore FID

ENDIF

IF message_header_field is unknown

THEN

ignore field

ELSE

process_header_field

ENDIF

ENDIF

ENDFOR

ENDIF

Figure 9-1 Example – Suggested Message Processing Algorithm.

NOTE: Fields in a message preceding any FID/data pairs are referred to as header fields.

9.2.1 Latest Activity

The aim of Latest Activity is to provide a time-ordered sequence of market defined activities, rather

than data items held in uniquely identified FIDs that have no time ordering relationship. This is

achieved by allowing a range of different data items to update the same field; the content of the field is

identified by an associated flag.



This was first introduced in a limited form for North American Futures and Options and is now

extended to other markets.

The Latest Activity FIDs are as follow:

(Throughout this section, n=1-5).

Acronym FID range Description

PRIMACT_n 393-397 The primary activity field

ACT_TP_n 270-274 The associated activity type (enumerated FID)

ACT_FLAGn 975-979 The associated text flag

SEC_ACT_n 275-279 The secondary activity field

SC_ACT_TPn 280-284 The associated activity type (enumerated FID)

SC_AFLAGn 980-984 The associated text flag

VALUE_DTn 875-879 Date stamp field for primary and secondary fields

VALUE_TSn 1010-1014 Time stamp field for primary and secondary fields

Two associated numerical fields are allocated to encompass Latest Activity; it is recognised that the

activity can be more than a single data story. Of the two associated fields:

The first is PRIMACT_n, and for those cases where the activity involves only a single price,

usually it will be this field which updates.

The associated secondary field, holding the second half of the activity where it exists, is

SEC_ACT_n.

These two fields are always considered in pair, and an update to one must result in an update to the

other, if only to give it a null value.

In order to determine what type of fields occurs in PRIMACT_n and SEC_ACT_n, a further pair of

fields is required. ACT_TP_n is an enumerated type whose range covers all the possible types of data

in PRIMACT_n. Similarly, SC_ACT_TPn is an enumerated type whose range covers all the possible

types of data in SEC_ACT_n. For example:

PRIMACT_1 contains a bid price (16, ―B‖) and SEC_ACT_1 contains an ask price (18, ―A‖);

ACT_TP_1 would then indicate a bid price and SC_ACT_TP1 would indicate an ask price.

In order to allow further information to be held in each activity field, a set of text flags are defined;

ACT_FLAGn further describes PRIMACT_n, whilst SC_AFLAGn further describes SEC_ACT_n.

These flags are effective status fields for each activity; for example, ACT_FLAG1 could indicate a

threshold break has occurred for the value held in PRIMACT_1.

Finally, the activity fields, VALUE_TSn and VALUE_DTn, are time and date stamped respectively.

9.2.1.1 Latest Activity Related Fields

While these fields concern the Latest Activity itself, there are a number of related fields that give more

information about Latest Activity values.

RT_YIELD_n 356-360

SEC_YLD_n 970-974

YIELD_TP 969

These fields are the last yield values to be reported. As with Latest Activity there are two fields of

information: RT_YIELD_n and SEC_YLD_n. These could correspond to the yield of the prices held in

PRIMACT_n and SEC_ACT_n or to two different yield calculations of the price in PRIMACT_n.

They may even exist independently of PRIMACT_n and SEC_ACT_n.

The type of yields held in RT_YIELD_n and SEC_YLD_n is indicated by YIELD_TP.

CTBTR_n 831-835

CTB_LOCn 836-840

CTB_PAGEn 841-845

DLG_CODEn 826-830



These fields are related to contributors; CTBTR_n is the contributor name whose prices are held in

PRIMACT_n and SEC_ACT_n. CTB_LOCn is the associated contributor location, CTB_PAGEn is the

contributor Monitor page code and DLG_CODEn is the dealing code.

Open, close, high and low prices have also been defined in the same way as latest activity. Each of

these data items has a set of fields holding actual values, a value type (flag) and timestamp.

OPEN_PRC 19

OPEN_PRC2 961

OPEN_TYPE 962

OPEN_TIME 285

OPEN_PRC and OPEN_PRC2 are two open value fields, the OPEN_PRC field taking priority when

only a single open is required. The enumerated field OPEN_TYPE describes the contents of these

fields. OPEN_TIME holds the time when either OPEN_PRC or OPEN_PRC2 is set. It is up to the

market convention to determine how this field is updated e.g. only once upon the first update to

OPEN_PRC or with every update to OPEN_PRC or OPEN_PRC2.

HST_CLOSE 21

HST_CLOSE2 963

CLOSE_TYPE 964

HSTCLSDATE 79

These fields act in the same way as the open fields; HST_CLOSE and HST_CLOSE2 carry the close

value(s), CLOSE_TYPE is the enumerated field describing the contents of these two fields and

HSTCLSDATE holds the date when either close value field is set.

HIGH_1 12 SEC_HIGH 957

HIGHTP_1 196 SEC_HI_TP 958

YCHIGH_IND 110 STOP_HIGH 348

HIGH_TIME 286

HIGH_1 and SEC_HIGH are two high value fields, the HIGH_1 field is chosen when only a single

high value field is required. The contents of these fields are described in the enumerated fields

HIGHTP_1 and SEC_HI_TP respectively. The time when either high values is set is held in the field

HIGH_TIME. An additional field, STOP_HIGH, provides a text flag to further qualify the high values,

whilst YCHIGH_IND indicates whether or not a year or contract high has been set today.

LOW_1 13 SEC_LOW 957

LOWTP_1 197 SEC_LO_TP 960

YCLOW_IND 111 STOP_LOW 349

LOW_TIME 287

LOW_1 and SEC_LOW are two low value fields, the LOW_1 field is chosen when only a single low

value field is required. The contents of these fields are described in the enumerated fields LOWTP_1

and SEC_LO_TP respectively. The time when either low values is set is held in the field LOW_TIME.

An additional field, STOP_LOW, provides a text flag to further qualify the low values, whilst

YCLOW_IND indicates whether or not a year or contract low has been set today.

9.3 Processing Chains and Tiles

A chain is a linked list of records. Usually a chain contains records from a single market or relates to a

single instrument. In this instance, all the records will be of the same format, i.e. they will have the

same record template.

Chains also provide a broad market overview, carrying records that relate to different types of

instruments and consequently, having different record formats.

Chains are designed to allow users to request a series of related records from a single user request.

A chain is constructed from chain records, each of which contains up to 14 underlying RIC values. In

addition, the chain records contain references to the next and previous chain records in the series. There



are two types of templates which chain records can use: LINK_A (No. 80) and LONGLINK (No. 85).

The templates have the same content — a series of RIC reference fields, a forward chain RIC pointer, a

backward chain RIC pointer — but they use different fields to hold these values.

The first chain record in the series is always of the format 0# <RIC root>. No assumptions should be

made to the structure of the remaining chain records. Always refer to the forward pointer field for the

next chain record.

Inside the chain templates, there are two types of forward pointer fields: NEXT_LR (FID 238) and

PREF_LINK (FID 1081). If you are constructing a display trigger from the value in PREF_DISP (FID

1080), then your application should use the contents of the PREF_LINK field for the first chain record

(0#). If the PREF_LINK field is empty in the first chain record, or if you are constructing a simple

chain display, your application should use the contents of the NEXT_LR field. The contents of the

NEXT_LR field should be used for all subsequent chain records within the chain, regardless whether

you used the PREF_LINK or NEXT_LR field from the first chain record. For example:

0#.INDEXE contains 1#.INDEXE in NEXT_LR and 1#.INDEXE in PREF_LINK.

If you choose 1#.INDEXE (i.e. the contents of NEXT_LR), then the subsequent contents of the

NEXT_LR field is 2#.INDEXE.

If you choose 1# INDEXE (i.e. the contents of PREF_LINK), then you use the NEXT_LR field,

which contains 2#.INDEXE, to continue the chain.

Tiles have the same record template structure and behavior as chains. The principle difference is that

tiles allow different RIC formats; the first tile record has no 0# prefix. Subsequent tiles may have nn#

prefixes, therefore you must use the contents of the NEXT_LR field.

The processes of chains and tiles are identical. All the issues discussed in this section regarding chains

also apply to tiles.

Chains and tiles mainly contain related records which use the same template. However, the contents of

chains and tiles are becoming increasingly complex where Thomson Reuters is trying to provide a

market overview. In this instance, the chain/tile contains records from different sources and has

different templates. In addition, page records, dummy RICs, and chain records can also be found within

a chain/tile.

Page codes are used in chains/tiles either for containing display headings (e.g. DEMCMPHE) or to link

to the speed guides (e.g. MONEY). In both cases the page should not be displayed as a complete page.

In former instance, the display text should be extracted from the page and be displayed. In the alter

instance, only the page code should be retrieved. The FID 259 field should be used to identify the type

of pages used within a chain, e.g. speed guide pages all have a value of 25 in FID 259.

Dummy RICs within a chain/tile are used to provide ‗spaces‘ in the chain display, and to carry

additional News 2000 category codes relating to the chain/tile. The contents of the record should be

displayed, i.e. as a space on the screen.

Your application should provide the facility for end-users to ‗page forward/backward‘ to relating chain

references. If the user presses a designated key, the application should use the value found in either FID

1487 (SEG_FORW17) or FID 1488 (SEG_BACK17) to retrieve the next or previous chain in the

series. If FIDs 1487 and 1488 are empty or not present, then the user request should be ignored.

Field Contents

LINK LONGLINK

FID Acronym FID Acronym

Reference Counter 239 REF_COUNT 239 REF_COUNT

Forward Pointer 238 NEXT_LR 815 LONGNEXTLR

Backward Pointer 237 PREV_LR 814 LONGPREVLR

First RIC Reference 240 LINK_1 800 LONGLINK1

Second RIC Reference 241 LINK_2 801 LONGLINK2

Third RIC Reference 242 LINK_3 802 LONGLINK3

Fourth RIC Reference 243 LINK_4 803 LONGLINK4

Fifth RIC Reference 244 LINK_5 804 LONGLINK5

Sixth RIC Reference 245 LINK_6 805 LONGLINK6

Seventh RIC Reference 246 LINK_7 806 LONGLINK7

Eighth RIC Reference 247 LINK_8 807 LONGLINK8

Ninth RIC Reference 248 LINK_9 808 LONGLINK9

Tenth RIC Reference 249 LINK_10 809 LONGLINK10



Field Contents

LINK LONGLINK

FID Acronym FID Acronym

Eleventh RIC Reference 250 LINK_11 810 LONGLINK11

Twelfth RIC Reference 251 LINK_12 811 LONGLINK12

Thirteenth RIC Reference 252 LINK_13 812 LONGLINK13

Fourteenth RIC Reference 253 LINK_14 813 LONGLINK14

Table 9-1 Chain Record FIDs

Please note that some chains omit the 0# as the first chain record, notably some Money 2000 RICs and

Indices.

Examples

The SSL examples below have the format been modified to aid legibility.

The following example shows how a request is made for the list of Market Makers on Thomson

Reuters PLC stock, 0#.INDEXE

Request to Edge:

SSL_EVENT_INFO EventInfo;

memset (EventInfo, 0, sizeof SSL_EVENT_INFO);

EventInfo.ImageReq.ServiceName = “ELEKTRON_DD”;

EventInfo.ImageReq.ItemName = “0#.INDEXE”;

EventInfo.ImageReq.RequestType = SSL_RT_NORMAL;

sslInterface.sslPostEvent(Channel, SSL_ET_IMAGE_REQ, & EventInfo);

Response to user application:

<FS>

340<US>XX<GS>

0#.INDEXE<US>

80<US>1<RS>

1<US>2923<RS>

2<US>202<RS>

3<US>European Indices<RS>

4<US>0<RS>

5<US> : <RS>

15<US>826<RS>

17<US>12 APR 2003<RS>

237<US><RS> Backward Pointer

238<US>1#.INDEXE<RS> Forward Pointer

239<US>14<RS> Number of RIC references in chain

record

240<US>.AEX<RS> First RIC reference

241<US>.ATG<RS> Second RIC reference

242<US>.ATX<RS>

243<US>.BFX<RS>

244<US>.BETC<RS>

245<US>.BUX<RS>

246<US>.FCHI<RS>

247<US>.CRBEX<RS>

248<US>.STOXXE<RS>

249<US>.STOXX50E<RS>

250<US>.STOXX50<RS>

251<US>.STOXX<RS>

252<US>.FTEUEC<RS>

253<US>.FTEUXEC<RS>

259<US>120<RS>

728<US><RS>

1080<US>@@@<RS>

1081<US><RS>



1352<US><RS>

1383<US>@tD<RS>

1487<US><RS>

1488<US><RS>

1709<US>0<RS>

2130<US>0<RS>

2132<US>0<RS>

2320<US>

<FS>

Upon receipt of this the application should proceed to the next chain record, finding its RIC in the

forward pointer field.

Request toEdge:


memset(EventInfo, 0, sizeof SSL_EVENT_INFO);


EventInfo.ImageReq.ItemName = “1#.INDEXE”;


sslInterface.sslPostEvent(Channel, SSL_ET_IMAGE_REQ,

&EventInfo);

Response to user application:

<FS>340<US>XX<GS>

1#.INDEXE<US>

80<US>1<RS>

1<US>2923<RS>

2<US>202<RS>

3<US>European Indices<RS>

4<US>0<RS>

5<US> : <RS>

15<US>826<RS>

17<US>12 APR 2003<RS>

237<US>0#.INDEXE<RS> Backward Pointer

238<US>2#.INDEXE<RS> Forward Pointer

239<US>14<RS> No. of RIC references in chain

record

240<US>.FTEUXUK<RS> First RIC reference

241<US>.FTEUEB<RS> Second RIC reference

242<US>.N100<RS> Third RIC reference

243<US>.FTII<RS> Fourth RIC reference

244<US>.FTSE<RS> FifthRIC reference

245<US>.FTSES<RS> Sixth RIC reference

246<US>.FTEU1<RS> Seventh RIC reference

247<US>.IBEXL<RS> Eighth RIC reference

248<US>.FTEU3<RS> Ninth RIC reference

249<US>.IBEX<RS> Tenth RIC reference

250<US>.XU100<RS> Eleventh RIC reference

251<US>.SMSI<RS> Twelfth RIC reference

252<US>.MIB30<RS> Thirteenth RIC reference

253<US>.MIBTEL<RS> Fourteenth RIC reference

259<US>120<RS>

728<US><RS>

1080<US>@@@<RS>

1081<US><RS>

1352<US><RS>

1383<US>@tD<RS>

1487<US><RS>

1488<US><RS>

1709<US>0<RS>

2130<US>0<RS>

2132<US>0<RS>



2320<US>

<FS>

The application would then retrieve 2#.INDEXE which would provide it with all the remaining RIC

references. If this is the last chain record, the application should then proceed to the first RIC reference

in the chain (.AEX referenced in 0#.INDEXE) and request it; for example:

Request to Elektron Edge:


memset(EventInfo, 0, sizeof SSL_EVENT_INFO);


EventInfo.ImageReq.ItemName = “.AEX”;


sslInterface.sslPostEvent(Channel, SSL_ET_IMAGE_REQ, &

EventInfo);

Response to user application: <FS>340<US>XX<GS>.AEX<US>77<US>29840<RS>1<US>5433<RS>2<US>125<RS>3<US

>AEX-Index

<RS>4<US>77<RS>6<US>+468.48<RS>7<US>+468.47<RS>8<US>+468.50<RS>9<US>+

468.45<RS>10<US>+468.50<RS>11<US>+2.40<RS>12<US>+469.79<RS>13<US>+466

.45<RS>14<US>1<RS>15<US>978<RS>16<US>23 APR

2008<RS>18<US>10:17<RS>19<US>+466.64<RS>21<US>+466.08<RS>22<US>+0.00<

RS>25<US>+0.00<RS>28<US> <RS>29<US> :

<RS>32<US>+91194118<RS>36<US>+0.00<RS>53<US>2<RS>56<US>+0.51<RS>70<US

>+0.00<RS>77<US>+790<RS>78<US>NL0000000107<RS>79<US>22 APR

2008<RS>81<US>+0<RS>82<US>+0<RS>83<US>+0<RS>84<US>+0<RS>85<US>+0<RS>8

6<US>+0<RS>87<US>+0<RS>88<US>+0<RS>89<US>+0<RS>90<US>+518.27<RS>91<US

>+401.45<RS>92<US>+563.98<RS>93<US>+469.85<RS>94<US>+703.18<RS>95<US>

+69.14<RS>98<US>+515.77<RS>100<US>+6374.13<RS>104<US>185<RS>105<US>EO

EC<RS>110<US>0<RS>111<US>0<RS>118<US>0<RS>131<US>0<RS>178<US>+0<RS>20

1<US>05 SEP 2000<RS>202<US>10 NOV

1987<RS>259<US>118<RS>270<US>0<RS>275<US>+0.00<RS>280<US>0<RS>350<US>

02 JAN 2008<RS>351<US>22 JAN

2008<RS>372<US>+0.00<RS>373<US>+0<RS>374<US>0<RS>375<US> : :

<RS>379<US>10:17:30<RS>380<US>5<RS>381<US>+0.00<RS>382<US>+0.00<RS>39

3<US>+0.00<RS>728<US>.AEX

<RS>800<US>0#AEX*.E++<RS>869<US>25<RS>890<US>+0.00<RS>891<US>+0.00<RS

>892<US>+0.00<RS>893<US>+0.00<RS>894<US>+0.00<RS>895<US>+0.00<RS>896<

US> <RS>897<US>

<RS>975<US><0x00><RS>976<US><0x00><RS>977<US><0x00><RS>978<US><0x00><

RS>979<US><0x00><RS>996<US>+100.00<RS>997<US>+1075.22<RS>998<US>+24<R

S>999<US>+0.00<RS>1000<US>%Capit<RS>1001<US>Gross

<RS>1002<US>NbStck<RS>1003<US>NetIdx<RS>1006<US>2<RS>1021<US>+0<RS>10

23<US>+0<RS>1028<US>

<RS>1029<US>+0.00<RS>1030<US>+0.00<RS>1031<US>+0.00<RS>1035<US>

<RS>1036<US><0x00><0x00><0x00><0x00><0x00><0x00><RS>1037<US><0x00><0x

00><0x00><0x00><0x00><0x00><RS>1051<US>

<RS>1055<US>0<RS>1056<US>AEX <RS>1067<US> : :

<RS>1080<US>{O@<RS>1352<US>

<RS>1379<US>+0.00<RS>1383<US>@tC<RS>1501<US><0x00><0x00><0x00><RS>170

9<US>389<RS>2127<US>-

9.63<RS>2128<US>+4.11<RS>2131<US>0<RS>2139<US>+0<RS>2320<US><RS>2335<

US>+0.00<RS>3131<US>+0<RS>3132<US>+0<RS>101<US>0<RS>106<US>0<RS>108<U

S>0<RS>340<US> <RS>801<US>

<RS>1032<US>+0<RS>1033<US>+0<RS>1034<US>+0<RS>1038<US>

<RS>1039<US> <RS>1040<US>

<RS>3263<US>@@@<RS>3264<US>0<RS>3320<US>

<RS>3321<US>+0<RS>3366<US> <RS>3374<US>



<RS>3411<US>+0<RS>3412<US>+0<RS>3413<US>+0<RS>3414<US>+0<RS>3415<US>+

0<RS>3416<US>+0<RS>3417<US>+0<RS>3418<US>+0<RS>3419<US>+0<RS>3420<US>

+0<RS>3421<US>+0<RS>3573<US>0<RS>3580<US> <RS>3606<US>

<RS>3670<US>0<RS>3671<US>0<FS>

The process of retrieving each RIC reference is repeated for the whole chain. Any updates to either the

chain or the underlying RICs will be broadcasted to the server if the RICs are in the watchlist.

9.4 Processing Page Records

Essentially page records should be processed as other records (also see processing guidelines given in

section 8.2.6), however they do have certain characteristics which are described below.

Each page record is broken down into rows. Each row consists of one multi-character field. Pages with

14 rows by 64 characters use FIDs in the range 215-228 for each row of data. Pages with 25 rows by 80

characters use FIDs in the range 315-339 for each row of data.

A response for a page record will contain all the rows that make up the record, and each row will

contain all the characters that make up the row. Each row is identified by a unique FID number.

Partial field updating is used extensively for page records; this is described in section 8.2.6.

An example of a page record as it would appear in a response message is detailed in section 8.4.1

(Example 2), and an example of an update message is detailed in section 8.4.2 (Example 2).

9.5 Processing Correction Messages

Correction messages as reported from the New York, American, U.S. Regional and Canadian

exchanges, as well as all trades listed on OPRA (the Options Price Reporting Authority), are available

and are accessible by Edge. Processing of these messages in conjunction with the requisite real-time

information will provide the capability to create time and sales functionality.

The processing of this information and the appropriate display is solely the responsibility of the client

application. Correction data is passed to the application via the existing FIDs:

Acronym FID Field Type Length (Enum String)

IRGPRC 372 Price 17

IRGVOL 373 Integer 15

IRGCOND 374 Enumerated 3 (3)

TIMCOR 375 Time Seconds 8

INSPRC 376 Price 17

INSVOL 377 Integer 15

INSCOND 378 Enumerated 3 (3)

SALTIM 379 Time Seconds 8

A new set of FIDs that will be contained within a correction message can be found below. The new

FIDs enable Thomson Reuters clients to explicitly identify specific trades to be corrected where

possible, rather than just revising the contents of a particular FID. The enhancements are confined

initially to North American Equities, and will affect the data sourced from: NMTS (the NASD Market

Ticker System), CTS (the Consolidated Ticker System), OPRA, and the Canadian Equity Exchanges.

These new data elements allow Thomson Reuters clients to explicitly identify erroneous trades for

Exchanges that support this level of correction. Please note that Stock Options do NOT carry the new

FIDs denoted below. Clients will be able to track quote data more accurately. The additional FIDs

supported are described below.

Acronym FID Field Type Length (Enum String)

IRGXID 1018 Enumerated 2 (3)

IRGBUY 1019 Alphanumeric 4

IRGSELL 1020 Alphanumeric 4

SEQNUM 1021 Integer 15

PRINTYP 1022 Alphanumeric 1

PRNTBCK 1023 Integer 15



9.5.1 Consolidated Ticker System (CTS)

CTS trade reports are received as prints which may contain single, double, or triple trades. Using the

new PRINTYP field, each trade in a print received from CTS will be labeled as a double or triple trade

print with a ‗D‘ or ‗T‘ accordingly. An unlabeled print signifies that there is only one trade in the print.

All trades within a multiple trade print are assigned to the same sequence number.

On receipt of a correction message from CTS, headend will transmit the ‗print back‘ count, as derived

by CTS, using the new PRNTBCK field. PRNTBCK directly references the erroneous print received

from the participating Exchange.

By carefully maintaining a print number for each trade update, where ‗D‘ and ‗T‘ updates do not

increment print numbers, a client can locate the print on which a trade to be corrected was originally

carried by subtracting the PRNTBCK from the current print number and adding 1. The actual trade can

then be identified by matching Price / Volume. Note that Correction messages do not affect print

counts.

For Consolidated issues, a separate print number must be maintained for each Exchange ID

(TRDXID_1 / IRGXID). Location of the erroneous print for a correction must be limited to only those

prints received from the IRGXID exchange. All CTS trades that are designated as ‗not last‘ trades will

be transmitted with the accompanying Exchange Identifier in the new IRGXID field. The existing

Exchange Identifier field TRDXID_1 cannot be used because terminal display devices will replace the

Exchange Identifier for the ‗last‘ trade with an Exchange Identifier for a ‗not last‘ trade. IRGXID will

also be used to denote the regional exchange involved in the current correction message (for

Consolidated issues).

9.5.2 NASD Market Ticker System (NMTS)

The NMTS six-digit sequence number is appended, by using the new SEQNUM field, to all trades

sourced from NMS when transmitting the trade. On receipt of a correction report from NMS, the

SEQNUM field will hold the Original NMTS sequence number for the offensive trade. Note that the

NMTS sequence number applied to the correction message itself is lost.

9.5.3 Canadian Equity Exchanges

The SEQNUM field is used to transmit the time-of-trade as reported by the Canadian Exchanges with

every trade. The trade time reported by the Canadian Exchange is accurate up to a tenth of a minute.

This SEQNUM will be transmitted in addition to the trade time (TRDTIM_1 / SALTIM) for

Canadians.

SEQNUM takes the form HHMMT where:

HH hour portion of the time (24-hour clock)

MM minutes portion of the time

T numerator of the fractional 10th

portion of the minute (0 - 9)

The Canadian Exchanges identify trades to be corrected by referencing the time-of-trade as reported by

the Exchange. On receipt of a cancellation report from a Canadian Exchange, the SEQNUM field will

be used to hold the original Canadian trade time for the erroneous trade.

By carefully maintaining a sequence number for each trade update, a client can locate a trade to be

corrected by referencing the trade belonging to the SEQNUM sequence number and matching on Price

/ Volume / Buyer-Seller ID. Note that the SEQNUM for Canadian transaction are not necessarily

unique due to the 6-minute interval before SEQNUM changes.

New Buyer and Seller ID fields (IRGBUY and IRGSELL) for irregular trades are now supported to

avoid corrupting the Buyer and Seller Identifiers associated with the last trade (BUYER_ID and

SELLER_ID). IRGBUY and IRGSELL are also transmitted with cancellation messages and represent

the Buyer and Seller for the original (offensive) trade.

9.6 Time & Sales Data

Time & Sales (TAS) records provide a 14 calendar days‘ worth of trades and corrections for a

particular instrument in reverse chronological order. Time & Sales provides a definitive audit trail for

trades in an individual stock. It is traditionally used to settle disputes. If a customer or broker is

unhappy with an execution, he reads the Time & Sales log to determine the quality of the transaction

relative to other trades occurring at approximately the same time.



Time & Sales is also used by all market participants to obtain a feeling of how a particular instrument

is being traded, to get a sense of market sentiment and to look for trends in market activity.

TAS records are non-updating items which are handled in a special way by Edge. Refer to section 0.

9.6.1 Requesting Time & Sales Logs

The general TAS RIC structure consists of the following components:

t<RIC root>\<time><days back>

The only essential component for the above structure is the lower case ‗t‘ and the RIC root. Some

examples of TAS requests are:

tIBM Returns the full 14-day log for IBM, starting from the present time / day.

tIBM\10 or tIBM\1000

Returns all transactions that occurred at or before 10am Eastern Time

Zone.

tIBM\10-1or tIBM\10A

Returns all transactions that occurred at or before 10am yesterday (1 day

ago).

tIBM\1130-4 or

tIBM\1130D

Returns all transactions that occurred at or before 11:30am four days

ago.

tIBM\X Returns all the latest trade corrections, cancellations and inserts for IBM

over the 14-day log.

tIBM\V Returns all ―high value trades‖ for IBM.

The definition of a high value trade differs from exchanges to exchanges. In general they are designed

to correspond to block trades.

The <time> field in the RIC structure is optional and can be presented as either a two-digit hour

(HH) or a four-digit hour and minute (HHMM) specification. For the two-digit time format, its minute

is set to zero by default. When a time is specified, it is interpreted as requesting any log entries (trades)

for that instrument that have occurred at or before that time. If the time is omitted, the user will receive

a log starting from the latest trades for the day specified.

The <days back> field is also optional and is specified by a single letter from A to F, where A

represents one day back, B represents two days back, and so on. If the days back field is omitted, the

current day is accessed.

If the user-specified time / date log does not exist in Time & Sales, Time & Sales crosses day

boundaries to satisfy the request.

The following situations result an error status being returned:

A time field specified with an illegal time. An illegal time is defined as minutes greater than 59 or

hours greater than 23. In addition, an illegal time would be a time field that takes up 1 or 3

character positions.

The days back field containing characters other than A to F.

NOTE:

It is recommended that your application should only request enough TAS logs to fill the ‘window’ on

the user screen. In this way, only that data which is pertinent to the user is requested and the

outstanding request window will not be impacted by unnecessary requests.

9.6.2 Response Message

Upon a successful receipt and processing of a Time & Sales request, a response message containing

relevant data is returned. The message contains the following fields:



Acronym FID Meaning

PROD_PERM 1 The Time & Sales permissions code (PE).

PREV_LR 237 The record reference to the previous log segment.

NEXT_LR 238 The record reference to the next log segment.

REF_COUNT 239

The number of log entries contained within the text field (FID 258) for this

segment.

FINAL_LINE 257 The header text for the Time & Sales log.

SEG_TEXT 258

The 255-byte text field which can contain up to four log entries. There are

embedded New Line control characters within this field to assist in

displaying the log information.

RECORDTYPE 259 The type of record and type of data within the record.

SEG_FORW 260 The record reference for the log segment one hour forward.

SEG_BACK 261 The record reference for the log segment one hour backward.

9.7 News 2000

News 2000 is an enhanced system for delivering news with these key features:

Broadcast of Latest News Latest news headlines and alerts will be automatically sent to Edge client

upon the pseudo RIC N2_UBMS request.

Category Coding of News Codes attached to each story. These codes enable users to find news on their

interested topics quickly and accurately.

Directories Online directory information providing details of codes in used.

9.7.1 How a Story is Constructed

A story is a news item, filed by journalists and made available to Edge clients in several parts. All parts

of a story contain a common identifier, the Primary News Access Code (PNAC).

The first part of a story may be an alert. This is a brief item containing the most essential information

relating to an emerging story. Sometimes several alerts for the same story are filed in a quick

succession.

Alerts may be followed up by a headline and the first text piece of the story. This text together with its

associated headline is called a ‗take‘. Subsequent takes may also be filed to contain additional text as

needed.

A story is also attached to a set of category codes. These are transmitted with the alert and headline(s),

and are described in detail in next section.

A complete news story therefore consists of any alerts, the headline, the story text and the category

codes.

Each alert or take of the same story contains two time stamps: (1) the story date and time, and (2) the

take date and time. The story date and time is the time (in GMT) that the first alert or take for that story

was filed and remains the same for all alerts and takes of that story. The take date and time is the time

that a particular alert or take was filed.

9.7.2 Coding

News 2000 stories carry category codes which describe the content of the story and can be used to

assist in retrieving relevant news items by users. [4], News 2000 User Guide contains a list of all codes

currently in used. Lists of codes are also available online.

Product Codes Identify which sold product the story belongs to; for example ‗M‘ for Money

news, ‗FA‘ for the French language financial news service. News 2000 carries a

number of Thomson Reuters and third party products aimed at specific market

sectors.



Topic Codes Describe the story‘s subject matter. For example, ‗INT‘ for interest rates, ‗RES‘

for results stories, ‗IBM.N‘ for stories about IBM, ‗CN‘ for stories about China.

Named Item Codes Identify stories which users would normally want to retrieve with a fixed name.

For example, the code ‗TOP/‘ identifies the directory containing the online list of

Topic Codes; The code ‗.L‘ identifies London stock market reports.

Permanent flag This is a flag indicating that the story text will be kept available for retrieval via

Edge forever, and will not be deleted after 24 hours as is the case for most stories.

This flag is mostly used for directories, and for some market reports which are

filed less often than daily.

Attribution Specifies whether the story was supplied by Thomson Reuters, or by one of the

third party news sources available on News 2000.

9.7.3 Directories

News 2000 directory information is available in a series of permanent News 2000 stories (denoted by a

‗Z‘ or a ‗T‘ in FID 722 STORY_TYPE) with specific PNACs and Report Codes (also known as

Named Item Codes) in FID 750 TOPIC_CODE or FID 719 NAMED_ITEM. Some of this information

is designed for direct access by end-users and some is designed to be processed within applications.

9.7.3.1 User Directories

The following top level directories are currently available to be used directly by end-users when

navigating the News 2000 service.

Directory Report Code PNAC

Money/Forex M/ nDIRM

Debt D/ nDIRD

Equities E/ nDIRE

Commodities C/ nDIRC

Energy O/ nDIRO

Regional Products R/ nDIRR

General/Sports GEN/ nDIRGEN

Countries COU/ nDIRCOU

Industries IND/ nDIRIND

These directories may give access to lower level directories. For example, calling up the Regional

Products directory will give a list of directories for use with specific regional products.

9.7.3.2 System Directories

These directories provide listings of codes and their descriptions with the following format:

A number of optional spaces, followed by a code, followed by at least one space, followed by

a description, and followed by a linefeed.

Extract from a System Directory:

RSS/Diary Stock Market Diary

TOP/J Topic Code directory in Japanese

GB/O GILT OUTLOOK

EQB/ EQUITY BONDS REPORT

EUB/ EUROBONDS REPORT

The following directories are available:


Report Codes – Descriptions in English REP01033 nREP01033

Report Codes – Descriptions in Kanji REP00017 nJE1000017

Report Codes – Descriptions in Simplified Chinese REP02052 nCH1002052

Report Codes – Descriptions in Chinese REP01028 nCH1001028

Subject Codes – Descriptions in English SUB01033 nSUB01033

Subject Codes – Descriptions in Kanji SUB00017 nJE0000017

Subject Codes – Descriptions in Simplified Chinese SUB02052 nCH0002052




Subject Codes – Descriptions in Chinese SUB01028 nCH0001028

News 2000 codes may be subdivided into company codes and non-company codes which occupy

distinct and non-intersecting name spaces. Non-company codes are listed in the above directories. Any

code containing a character other than upper and lower cases ‗a‘ to ‗z‘ or the numbers ‗0‘ to ‗9‘ should

be regarded as a company code unless it is contained in the above directories.

Subject codes include all News 2000 codes used in FID 750 TOPIC_CODE.

Any code that is in FID 750 TOPIC_CODE or in FID 719 NAMED_ITEM which is in the Report Code

list should be treated as a Report Code (also known as a Named Item Code) as described in section

9.7.2 Coding.

You should be aware that while every effort is made to keep these directories up-to-date, there may be

occasions where codes are received which are not in the relevant directory. Such codes should be

processed in normal ways.

9.7.3.3 Back-Up Directory

Stories listing all recent headlines and alerts for News 2000 products are available on Edges with a

backlink connection. (See the section Faults – News Back-Up in [4], News 2000 User Guide for more

details on these listings.) News 2000 display applications should give users direct access to the back-up

directory which provides details of how to access these headline listings.

The back-up directory is a News 2000 story with a PNAC of n\BACK .

NOTE: The back-up directory is only available to sites with a backlink connection.

The back-up headline listing for a specific product is a News 2000 story with a PNAC of the form:

n\<product code>

For example:

A Money back-up headline has a PNAC of n\M

An Equity back-up headline has a PNAC of n\E

9.7.4 Broadcast Messages and Text Segments

This section will give a brief idea on broadcast messages and text segments. Figure 9-2 Representation

of Linked Text Segment Records illustrates how broadcast message (i.e. headlines, alerts) and text

segments are linked together.

HEADLINE

PNAC

SEGMENT NAME (PNAC)

POINTER TO NEXT

SEGMENT

POINTER TO PREVIOUS

SEGMENT

SEGMENT NAME (PNAC)

POINTER TO NEXT

SEGMENT

POINTER TO PREVIOUS

SEGMENT

First Text Segment

Second Text SegmentALERT

PNAC

Figure 9-2 Representation of Linked Text Segment Records



Alerts and headlines are transmitted in the form of broadcast messages. Elektron Edge converts

broadcast messages into update or full unsolicited image messages for a pseudo RIC named

―N2_UBMS‖ by default. This pseudo RIC should be accessed by your application if you wish to

receive news alerts and headlines.

NOTE: The default pseudo RIC name of News 2000 Broadcast Messages, including alerts and

headlines, is N2_UBMS.

Each broadcast message contains a set of fields, containing the text of the headline or alert, any

category codes for the story, and the story identifier (the PNAC).

The text content of a story is splited into a number of text segments, each of which is held in a record

identified by a unique name (i.e. a RIC). The RIC for the first text segment is the PNAC. Each segment

record holds up to 255 bytes of story text. Each record also has fields containing the RICs of the next

text segment and the previous text segment (if exist). Thus an application can retrieve the first segment

record from the reference in the headline, and then can retrieve each subsequent record in turn until the

end of the story is reached.

Stories are stored in Elektron Edge for retrieval for about 24 hours. A ‗drop due to expiry‘ broadcast

message is transmitted to indicate all the story text that their stories date/time are older than the

date/time specified in the message, are no longer available in Edge for retrieval.

When working with broadcast messages and text segments, you should be aware of the following:

1 Journalists may modify news stories which have been filed. The "Correction" and "Corrected"

messages are applied on news headline changes, while the "Deletion" messages are applied to

remove a headline. For text segments, journalists use the "Update" message on changes and use the

"Drop" message to remove a text segment.

2 Applications creating databases with a life span over 24 hours should use the combination of

PNAC, story date and story time as the unique key for identifying a particular story. The PNAC by

itself is not sufficient to guarantee uniqueness for time spans beyond 24 hours.

3 It is possible to receive duplicated broadcast messages. Duplicates are caused by the replay cycles

used on News 2000 host systems and by broadcast feeds, which are designed to minimize data loss

during a communications failure. Duplicated data can be detected by checking the PNAC and the

take sequence number.

4 It is possible to receive broadcast messages out of normal order, for example a first take headline

message may be received before an alert message arrives. Normally this only happens after

communications failures where messages are received for the first time in a replay cycle.

Section 9.7.9.2, Message Handling Rules contains processing rules which ensure that the above

situations are handled correctly.

9.7.5 Character Sets in News 2000

Thomson Reuters International news services are filed in English. However Elektron Edge can also

deliver News 2000 services filed in other languages. The languages delivered over any datafeeds vary

from the News 2000 products for which it is permissioned.

Many languages used in News 2000, including English and West European languages employing the

Latin script, are encoded with an 8-bit extended ASCII character set, called the Thomson Reuters Basic

Character Set. This character set is defined in [3], Thomson Reuters Multilingual Text Encoding

Standard which is obtainable from your local sales office.

Some languages require characters that are not present in the Thomson Reuters Basic Character Set.

There are currently two such languages in News 2000 — Japanese and Chinese. Others will be added

in future. These languages have their own encoding schemes which are also documented in [3],

Thomson Reuters Multilingual Text Encoding Standard and associated supplements. Both are

obtainable from your local sales office.



9.7.6 News Permissioning

9.7.6.1 Service Bank Permissioning

Thomson Reuters news products are permissioned separately from the real-time service. As news items

can impact many different markets, they cannot always be classified into a unique market sector.

Unlike other information items, news items can belong to multiple permissionable entities (PEs), while

others only belong to a single universal PE. The PE value of a RIC can be found in FID 1 (Prod_Perm).

For news RICs, there are two possibilities:

- they belong to a single PE (FID 1 only)

- they belong to multiple PEs, where the PEs are in service bank FIDs 456 and 457.

If the new RICs are with single PEs, they should be processed like normal RICs. Otherwise if the value

in FID 1 does not correspond to a permission match, then the PEs in service bank (i.e. FIDs 456 and

457) should be checked.

A method known as ‗service bank permissioning‘ is used to indicate which PEs a news RIC belongs to.

A service bank is constructed from FIDs 456 and 457 (known as REG_ID1 and REG_FIELD1

respectively).

FID 457 contains an encoding of a 32 byte bitmap (bit 0 - 255). FID 456 contains an encoding of a 2

byte single integer ranges from 1 to 65535 which defines the offset to be added to FID 457 for the

relevant PE value.

For example, when FID 456 is set to 2, this means the 256 bits carried in FID 457 are mapped to PE

values range from PE 256 to PE 511. In this example, if FID 457 has the two LSB bits turned on, this

means that PE 256 and PE 257 are enabled for this particular news item.

9.7.6.2 DACS Permissioning

Elektron Edge will compute the actual PE values from FID 1, and also from the FID 456/457 pair. The

PE values and Prod_Perm value will be posted to your application by using the SSL event

SSL_ET_PERMISSION_DATA. Please note that access locks are generated only if the permission

data function is explicitly requested by your application during the mount (see section Error!

Reference source not found.). In RFA, to subscribe for DACS Locks, the application sets the

permission data flag to true on the specific Market Data Subscriber via setPermissionData()

method. Having registered for DACS Locks, the application receives an Event containing the DACS

Lock information before receiving the Event that contains the actual data. If DACS is disabled, the

application will not receive DACS Locks.

9.7.7 Broadcast Messages

9.7.7.1 Broadcast Message Types

Various kinds of broadcast messages used by News 2000 are distinguished by their subtype field.

When Elektron Edge converts these broadcast messages, it copies the subtype (1-8) from the header of

the original message into a FID which it creates. FID 3, DSPLY_NAME, is used for this purpose since

that FID is never included in a broadcast message.

The following broadcast message types are used.

Alert Subtype = 1 DSPLY_NAME = 1

Alerts are used to notify users of breaking market moving news as quickly as

possible. They contain a short line of text summarising the emerging story.

First Take Subtype = 2 DSPLY_NAME = 2

First takes are used to deliver the story headlines and to indicate the availabilities

of the first part of the story text.

Subsequent Take Subtype = 3 DSPLY_NAME = 3

Subsequent takes indicate the availability of further story text. May add to

category codes supplied with earlier takes.

Correction Subtype = 4 DSPLY_NAME = 4

Correction changes a story headline and indicates the existence of additional text

modifying the content of the story.

Corrected Subtype = 5 DSPLY_NAME = 5



Corrected type changes the story headline and indicates that the text of the story

has been completely rewritten.

Delete Subtype = 7 DSPLY_NAME = 7

Delete type is used to delete a story before it reaches the normal 24-hour age limit,

for example, to delete a story because it was sent in error.

Drop Due to Expiry Subtype = 8 DSPLY_NAME = 8

Drop due to expiry is used to indicate all story with story date/time older than that

specified in the message, are no longer available in Edge for retrieval.

9.7.7.2 Valid Broadcast Messages

Ticks () in the following table show the FIDs that must be present for each type of the broadcast

messages.

If any of these FIDs is absent, the message should be discarded. A FID with a NULL entry should be

treated as if the FID is not present.

FID Name

PNAC PROC_D

ATE

BCAST_

TEXT

TAKE_S

EQNO

TAKE_T

IME

STORY_

TIME

STORY_

DATE

FID #

Message

Type

235 255 264 720 1015 1024 1027

ALERT FIRST TAKE

SUBSEQUENT

TAKE or

CORRECTIONS

CORRECTED

DELETE

DROP DUE TO

EXPIRY

9.7.7.3 FIDs in Broadcast Messages

This section provides the list of fields that may be used within News 2000 messages. The lists are

correct at the time of printing and valid for Record Template v3.3.1. Clients will be notified when

changes are implemented through the usual Data Notification procedures (see section 9.1.1).

Note that not all broadcast messages contain all the fields. For example, an alert message may not

contain the Topic Code field.

At least FID 1 or FIDs 456 and 457 will also be contained in broadcast messages. Read section 9.7.6

for more details..

FID # Acronym Description

3 DSPLY_NAME Identifies message subtype:

1=alert

2=first take

3=subsequent take

4=correction

5=corrected

7=delete

8=drop due to expiry

235 PNAC The PNAC allocated to the story. Max. 10 bytes. Set with first alert or

take; not modified thereafter.

255 PROC_DATE Contains the date this broadcast message was issued (see FID 1015,

TAKE_TIME).

259 RECORDTYPE Contains the value 232. Designates that the record is news.




264 BCAST_TEXT Contains the alert or headline text. Max. 255 bytes.

719 NAMED_ITEM A space-delimited list of any Named Item Codes for this story.

Each code can be up to 10 bytes.

Named Item Codes are defined with the first alert or take, and may be

added to (but not removed) by subsequent alerts and takes. Named

Item Codes are reset if a corrected is filed.

720 TAKE_SEQNO Set to 1 for the first alert and increment by 1 for each subsequent alert

message of that story.

Set to 1 for the first take and incremented by 1 for each subsequent

take, correction, or corrected of that story.

722 STORY_TYPE Indicates the type of story:

Z = Permanent Item

anything else = non-permanent.

Set by the first alert or take; not modified thereafter.

725 ATTRIBTN Contains a code of up to 4 bytes indicating the source of the story, e.g.

RNS for the London Stock Exchange Regulatory News Service. Set by

the first alert or take; not modified thereafter.

749 PROD_CODE A space-delimited list of the Product Codes associated with the story.


Product Codes are defined with the first alert, and may be added to (but

not removed) by subsequent alerts and takes.

750 TOPIC_CODE A space-delimited list of the Topic Codes associated with the story.


Topic Codes are defined with the first alert or take, and may be added

to (but not removed) by subsequent alerts and takes. Topic Codes are

reset if a corrected is filed.

751 CO_IDS A space-delimited list of the company identifiers associated with the

story.


Company identifiers are defined with the first alert or take, and may be

added to (but not removed) by subsequent alerts and takes. Company

identifiers are reset if a corrected is filed.

1015 TAKE_TIME Contains the time (in GMT) this broadcast message was issued (see

FID 255, PROC_DATE).

1024 STORY_TIME Contains the time (in GMT) that the first alert or take for this story was

filed.

Set by the first alert or take filed for this story.

Reset if a corrected is filed.

1027 STORY_DATE Contains the date that the first alert or take for this story was filed.





NOTE:

Fields other than those listed above may be transmitted with the broadcast message. These are for

internal use or for future enhancements, can be ignored.

9.7.7.4 Broadcast Message Examples

Here are examples (in MarketFeed format) of the different kinds of Broadcast Messages your

application may receive.

9.7.7.4.1 Initial Cached Message of the Broadcast Message Pseudo RIC

Until the first News 2000 alert and headline are received by Edge, FID 264 (BCAST_TEXT) for the

cached pseudo RIC contains a short dummy message ―Waiting for LBM...‖.

<FS>340<US>XX<GS>N2_UBMS<US>67<US>1<RS>1<US>431<RS>3<US>1<RS>264

<US>Waiting for LBM...<RS>235<US><RS>255<US><RS>259<US><RS>456<US>

<RS>457<US><RS>715<US><RS>719<US><RS>720<US><RS>722<US><RS>724<US>

<RS>725<US><RS>729<US><RS>749<US><RS>750<US><RS>751<US><RS>752<US>

<RS>1015<US><RS>1024<US><RS>1027<US><RS>1685<US><RS>1686<US><FS>

9.7.7.4.2 Alert

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>1<RS>1<US>443<RS>235<US>nRBNZRB349<R

S>255<US>13 JUN 2000<RS>259<US>232<RS>264<US>RBNZ-RBNZ-FORECAST CASH

INFLUENCE PRELIM<RBNZ02>

<RS>715<US>nl0000eHqH<RS>720<US>1<RS>722<US>S<RS>749<US>RBNZ

<RS>750<US>NZ CEN

LEN<RS>752<US>EN<RS>1015<US>04:18:34<RS>1024<US>04:18:34

<RS>1027<US>13 JUN 2000<RS>1685<US>LD<RS>1686<US>SP_NCS<FS>

9.7.7.4.3 First Take

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>2<RS>1<US>509<RS>235<US>nGEXD60AY8<R

S>255<US>13 JUN 2000<RS>259<US>232<RS>264<US>GEX

<ESC>o!N<j8}!O4XLgHs#G#M#OBgF&!a8e>l#1@a!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!<0x0F>

<RS>715<US>nl0000eHpH<RS>720<US>1<RS>722<US>S<RS>749<US>GEX<RS>750<US

>SOY GRA OILS MEAL JP TEG JLN

LJA<RS>752<US>JA<RS>1015<US>04:12:19<RS>1024<US>04:12:19

<RS>1027<US>13 JUN 2000<RS>1685<US>LD<RS>1686<US>SP_NCS<FS>

9.7.7.4.4 Subsequent Take

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>3<RS>1<US>438<RS>235<US>nTK5034559<R

S>255<US>13 JUN 2000<RS>259<US>232<RS>264<US>

<ESC>o%=%&%k3t<0;T>l!&CfHW!aH?Mn!”1:9„Am9g@=E4$J$I$,0B$$<RS>715<US>nl

0000eHqZ<RS>719<US>.SEJ<RS>720<US>2<RS>722<US>S<RS>749<US>RSS<RS>750<

US>KR JFOR STX EMRG JLN LJA<RS>751<US>05490.KS 0#.INX.KS 0#KS:

05930.KS<RS>752<US>JA<RS>1015<US>04:21:26<RS>1024<US>03:40:34<RS>1027

<US>13 JUN 2000<RS>1685<US>LD<RS>1686<US>TK_AES<FS>

9.7.7.4.5 Correction

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>4<RS>1<US>511<RS>235<US>nL1365673<RS

>255<US>13 JUN 2000<RS>259<US>232<RS>264<US>NYCKELTAL Kl 07.00 -

R<0xE4>ntor/valutor/b<0xF6>rser<RS>456<US>B@@<RS>457<US>@@@@@@@@@@@@@

@@@@@@@A@@@@@@@@@@@A@@@@@@@@@@<RS>715<US>nl0000eI00<RS>719<US>SW/NY<R

S>720<US>2<RS>722<US>S<RS>725<US>RTRS<RS>749<US>SW DNP<RS>750<US>SE

DBT GVD STX LSV

RTRS<RS>752<US>SV<RS>1015<US>05:21:22<RS>1024<US>05:06:27<RS>1027<US>

13 JUN 2000<RS>1685<US>LD<RS>1686<US>LD_S77<FS>

9.7.7.4.6 Corrected

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>5<RS>1<US>511<RS>235<US>nL13250957<R

S>255<US>13 JUN 2000<RS>259<US>232<RS>264<US>CORRECTED -Bahrain‟s



emir to visit Syria on

Wednesday<RS>456<US>B@@<RS>457<US>@@@@@@@@@@@@@@@@@@@A„@@@@@P@@AB@@@@

@@A@@@@@<RS>715<US>nl0000eI6q<RS>720<US>2<RS>722<US>S<RS>725<US>RTRS<

RS>749<US>G ACD MD RNP PTD PGS<RS>750<US>MEAST EMRG BH SY POL DIP

NEWS LEN

RTRS<RS>752<US>EN<RS>1015<US>06:02:19<RS>1024<US>06:02:19<RS>1027<US>

13 JUN

2000<RS>1685<US>LD<RS>1686<US>LD_S77<FS>

9.7.7.4.7 Deletion

<FS>316<US>XX<GS>N2_UBMS<RS>3<US>7<RS>1<US>314<RS>235<US>nTI1328205<R

S>255<US>13 JUN

2000<RS>715<US>nl0000eI7P<RS>1015<US>06:03:36<RS>1024<US>05:54:23<RS>

1027<US>13 JUN 2000<RS>1685<US>LD<RS>1686<US>NPM <FS>

9.7.7.4.8 Drop Due to Expiration Message

<FS>316<US>SF<GS>N2_UBMS<US>0<RS>1<US>431<RS>2<US>0<RS>3<US>8<RS>715<

US>nt00000ssu<RS>1015<US>16:50:44<RS>1024<US>02:16:06<RS>1027<US>09

JUN 2003<FS>

9.7.8 Text Segments

This section describes the content of News 2000 text segments and provides rules on how to process

them.

9.7.8.1 Text Segmentation

Each text segment contains text from one and only one take. Words are not split across text segment

boundaries. All PNACs and text segment RICs begin with the prefix character ‗n‘. All RICs that begin

with ‗n‘ are either PNACs or text segment RICs.

The default character set for all text segments is the Thomson Reuters Basic Character Set. Other

character sets will be explicitly invoked for each segment when the character sets are used. [3],

Thomson Reuters Multilingual Text Encoding Standard defines how to invoke other character sets.

More than one character set may be included within the same text segment.

9.7.8.2 New Lines

Display applications should insert new lines into non-tabular News 2000 stories (FID 723 (TABTEXT)

= ‗X‘) as required by the size of the display window. New lines should only be inserted between words,

except that a single word is longer than the display window.

9.7.8.3 Word Definition

For non-Chinese and non-Japanese characters, a word is defined as a sequence of bytes whose values

are all found within two regions: 21 hex to 7E hex (inclusive), and A1 hex to FE hex (inclusive).

For Chinese and Japanese ideographic characters, a word is defined as a character.

Words do not cross text segment boundaries unless they are longer than 255 bytes.

9.7.8.4 Control Functions in Text Segments

The following control functions may be found within text segments:

Carriage Return CR hex 0D

Linefeed LF hex 0A

Tab TAB hex 09

Null NULL hex 00

Escape ESC hex 1B

These control functions should be processed as described below.

Other control functions may be present for character sets other than the Thomson Reuters Basic

Character Set. See [3], Thomson Reuters Multilingual Text Encoding Standard, for more information.



9.7.8.5 Processing of Control Functions

Control functions other than those mentioned above should be ignored.

TAB and CR: Each TAB or CR should always be interpreted as a single space.

Linefeed: For tabular text segments (FID 723 (TABTEXT) = ‗T‘), LF should be

interpreted as a CR LF.

For non-tabular text segments (FID 723 (TABTEXT) = ‗X‘), LF should be

processed as follow:

IF LF followed by a space or by a LF

THEN

Interpret as a new paragraph

ELSE

IF Chinese or Japanese or if a space precedes

the LF

THEN Ignore the LF

ELSE Interpret the LF as a space

ENDIF

ENDIF

The above rules ensure that LFs which are only present to ensure compatibility

with older style display devices are ignored.

Escape: ESC followed by specific characters may be used to designate and/or to invoke

character sets as described in [3], Thomson Reuters Multilingual Text

Encoding Standard.

Nulls: Any characters within a segment which follow a NULL should be ignored.

9.7.8.6 Fields Embedded in Text Segments and BCAST_TEXT (FID 264)

9.7.8.6.1 Square Brackets [...]

Text inside ‗[ ]‘ should be interpreted as a News 2000 search expression as defined in section 9.7.8.6.6.

For example, a news story might contain the line:

For related news see [IBM.N]

IBM.N is the News 2000 Topic Code for IBM.

9.7.8.6.2 Angle Brackets <...>

Text inside ‗< >‘ should be interpreted as a record name. For example, a news story might contain the

line:

Woolworth Corp <Z.N> set payout

Z.N is the RIC name of the quote record for Woolworth Corp.

9.7.8.6.3 Curly Brackets {...}

Curly brackets ‗{ }‘ may be used to delimit portions of the story text that must be processed instead

of, or in addition to, being displayed to end-user. It is expected that curly brackets will be used to

implement a wide range of functionalities.

The syntax inside curly brackets is of the form:

{FT;string}

where:

FT is an alphanumeric string defining the field type,

; is a delimiter,

string is an arbitrary character string with syntax dependant on the field type.

Only field type ‗1‘ is defined and is used for News 2000 cross referencing.

The syntax of a News 2000 cross reference using curly brackets is as follow:

{1;x/tText/<?Data>;Cross_Reference}



where:

1;x Defines the syntax version number.

/t is used prior to the Text which should be displayed to user. Cross_Reference is activated by the

user selecting the text in some way, for example by double clicking on it.

NOTE: If the Text-to-display string contains the ‘/’ character, it will be enclosed in “” (double

quote marks). Please note that the entire text need not be enclosed in “ marks. Just as valid

would be: /tDate is: 01”/”05”/”04. All “ should be removed before displaying the text so

that in the above example the text displayed to end-users should be ‗Date is: 01/05/04‘.

/? may be used prior to other Data parameters to support new functionality. ‘?’ represents any

letters other than ‘t’.

; Is a delimiter.

The Cross_Reference parameter is either a record name enclosed in angle brackets, or a News 2000

search expression enclosed in square brackets.

9.7.8.6.4 Examples

{1;x/tIBM News;[IBM.N]}

The application should display ‗IBM News‘. Double click on this text, or select it in some other ways,

should cause the application to execute the News 2000 search expression ‗IBM.N‘.

{1;x/t<IBM.N>/cD;<IBM.N>}

The application should display ‗<IBM.N>‘. Double click on this text, or select it in some other ways,

should call up the full quote record of IBM.N.

NOTE:

The full quote should be called up because the Cross_Reference parameter is enclosed in angle

brackets. The text displayed should have no effect on the behavior. Also note that /cD is an undefined

parameter and should therefore be ignored.

9.7.8.6.5 Embedded Fields Syntax Processing Rules

When developing an application to process fields embedded in curly brackets, you should bear in mind

the followings:

The syntax may be extended in future for other new types of applications. Details of these

extensions will be provided to third party organisations through the standard Elektron Edge

notification channels.

The application should ignore the contents of any additional parameters that may be present. This

allows new functionalities to be added later without affecting existing applications.

The application should not assume that parameters associated with a specific field types will be in

any specific order.

The application should discard all the text within curly brackets if the field type or version number

is not recognised.

Embedded fields may appear anywhere in the text of headlines, alerts and news stories. Embedded

fields may themselves contain embedded fields, though this is not currently used for the type 1

fields described above.

9.7.8.6.6 News 2000 Search Expression

A News 2000 search expression is a character string which should be interpreted as follow:

If it begins with ‗n‘, it should be interpreted as the PNAC of a related story.

If it begins with ‗\‘, a ‗n‘ should be prepended to the text which should then be interpreted as a

PNAC of a related story.

Otherwise the text should be interpreted as a string of News 2000 category codes and operators

with the following syntax defined in BNF-style notation. The elements of the notation are:



[ ] Optional items indicator

| Separator for alternative items

― ― Double quotes delimit literals

/* */ Delimit of comments which are not part of the formal definition

search_expression ::= search_item [ [operator] search_expression]

search_item ::= category_code | left_bracket search_expression

right_bracket

category_code ::= /* any valid News 2000 category or company code*/

operator ::= ―&‖ | ―-‖ /*Boolean AND operator */

―|‖ /* Boolean OR operator */

―,‖ | ―!‖ /* Boolean NOT operator */

left_bracket ::= ―(―

right_bracket ::= ―)‖

The syntax of News 2000 search expressions may be extended in future, and applications should react

in a controlled manner if unable to interpret News 2000 search expressions according to the above

rules.

9.7.8.7 FIDs in Text Segments

This section provides the list of fields that may be used within News 2000 messages. The lists are

correct at the time of printing and valid for Record Template v3.1.0. Clients will be notified when

changes are implemented through the usual Data Notification procedures (see section 9.1.1).

At least FID 1 or FIDs 456 and 457 will also be contained in text segments. Read section 9.7.6 for

more details..


237 PREV_LR Contains the RIC name of the previous text segment.

238 NEXT_LR Contains the RIC name of the next text segment.

254 UNIQUE_SN Contains the PNAC. Max. 10 bytes.

255 PROC_DATE Contains the date that the first alert or take for this story was filed.



256 PROC_TIME Contains the time (in GMT) that the first alert or take for this story was

filed.



258 SEG_TEXT Contains up to 255 bytes of story text conforming to [3], Thomson

Reuters Multilingual Text Encoding Standard (see section 9.7.5).

259 RECORDTYPE Contains the value 232.

723 TABTEXT Set to ‗X‘ to indicate textual data which can be reformatted. Set to ‗T‘ to

indicate tabular data which should be displayed using a fixed-width font,

so that columns would line up correctly.

727 MORE_NEWS Set to ‗M‘ if more takes are expected to be filed. Set to ‗R‘ if it is

expected to be the final take and the news originated from Thomson

Reuters.

Set to ‗E‘ if it is expected to be the final take and the news originated

from some other sources.

Any other value should be ignored.

NOTE: This field value should be treated as a ‘hint’ rather than a

definitive indication. There are occasions when the filing journalist’s

expectations have to be revised for some reasons.



NOTE: Fields other than those listed above may be present in the text segment record. These are for

internal use or for future enhancements, may be ignored.

9.7.8.8 Text Segment Message Example

Here is a Marketfeed example text segment message your application may receive.

9.7.8.8.1 Story Segment (Response)

<FS>340<US>XX<GS>nN10504644<US>84<US>1<RS>1<US>436

<RS>2<US>136<RS>237<US><RS>238<US>n&0000HZsc<RS>254<US>nN10504644

<RS>255<US>10 JUN 2003<RS>256<US>18:01

<RS>258<US>U.S. SPOT CRUDE DIFFERENTIALS -JUN 10 1400 EDT

^<0A>jul WTI CUSHING SPREADS BRENT/DUBAI SPREADS

^<0A>WTI/WTI MIDL‟D -0.14/-0.11 WTI/BRENT july +1.29/+1.33

^<0A>WTI/LLS ST.JS +0.14/+0.16 WTI/BRENT AUG +1.40/+1.45

^<0A>WTI/HLS EMPIRE -0.20/-0.10N

<RS>259<US>232<RS>456<US>@@@<RS>457<US>@@@@@@@@@@@@@@@@@@

@@@@@@@@@@@@@@@@@@@@@@@@@<RS>723<US>T<RS>727<US>R<FS>

9.7.9 Recommended Processing Rules

In order to access News 2000, a database of broadcast messages must be maintained. This section

describes the recommended structure for this database and provides pseudo-code rules defining how to

update the database when broadcast messages are received. It also provides rules for processing text

segments.

NOTE:

Considerable care has been taken in formulating these rules and it is expected that they will be

applicable to a wide variety of applications. However you should ensure that these rules fit the

requirements of your specific application.

9.7.9.1 Headline Database Contents

The following are minimum fields that should be stored for each story in the headline / alert database

managed by the application:

The PNAC of the story

The text (BCAST_TEXT) for each alert and for the first take (all takes have the same

BCAST_TEXT unless altered by a corrected or correction)

The following category codes:

The product codes (PROD_CODE) for the most recent broadcast message

The topic codes (TOPIC_CODE) for the most recent broadcast message

The report codes (NAMED_ITEM) for the most recent broadcast message

The company codes (CO_IDS) for the most recent broadcast message

The date and time of the first alert or take for a story (STORY_DATE and STORY_TIME)

The source of the story (ATTRIBTN)

The TAKE_SEQNO of each alert

The TAKE_SEQNO of the most recent take, corrected or correction message

The time and date (TAKE_TIME/PROC_DATE) of each alert

The time and date (TAKE_TIME/PROC_DATE) of the most recent take, corrected or correction

message

9.7.9.2 Broadcast Message Handling Rules

Using a simple pseudo-code layout, this section defines the processing rules to be followed for each of

the different types of messages associated with the News 2000 pseudo RIC.



NOTE:

Be aware that broadcast messages may be received out of time order and duplicated broadcast

messages may be received.

Pseudo-code legend:

ADD The ADD process implies that the information should be added to existing

information in the database.

REPLACE The REPLACE process implies that the latest information should replace the

corresponding existing information in the database.

STORY_REF This is the combination of PNAC, STORY_DATE, and STORY_TIME.

CATEGORY_INFO This represents all the codes in the FIDs NAMED_ITEM, PROD_CODE,

TOPIC_CODE, and CO_IDS.

FIDs referred to in the following pseudo code appear in bold.

Alert Broadcast Messages (subtype 1, i.e. FID 3 = 1) /* How to Process an Alert Broadcast Message*/

IF STORY_REF exists in database

THEN

IF TAKE_SEQNO = TAKE_SEQNO for ALERT in database

THEN

discard ALERT; /* Alert is duplicated */

EXIT

ELSE

ADD_ALERT to database /* New Alert for existing

story */

ENDIF

ELSE

ADD_ALERT to database /* New story */

ENDIF

ADD_ALERT

/* How to Add an Alert to Database */

IF STORY_REF does not exist in database

THEN

create new entry in database for this STORY_REF

IF STORY_TYPE = „Z‟ THEN mark item as permanent

REPLACE STORY_DATE and STORY_TIME

REPLACE ATTRIBTN

ENDIF

ADD BCAST_TEXT for this ALERT

ADD TAKE_SEQNO for this ALERT

ADD CATEGORY_INFO (removing duplicates)

REPLACE PROC_DATE and TAKE_TIME

inform downstream applications (e.g. display devices, permanent

database)

First Takes (subtype 2, i.e. FID 3 = 2) /* How to Process a First Take*/


THEN

IF first take exists for this STORY_REF

THEN

discard first take /* Duplicate */

EXIT

ELSE

ADD_FIRST_TAKE to database /* First take for

existing story*/

ENDIF

ELSE



ADD_FIRST_TAKE to database /* First take for new story*/

ENDIF

ADD_FIRST_TAKE

/* How to Add a First Take to Database */

IF STORY_REF does not exist in database

THEN

create new entry in database for this STORY_REF

IF STORY_TYPE = „Z‟ THEN mark as permanent

REPLACE STORY_DATE and STORY_TIME

REPLACE ATTRIBTN

ENDIF

REPLACE BCAST_TEXT

REPLACE TAKE_SEQNO


REPLACE PROC_DATE and TAKE_TIME


database)

Subsequent Takes and Corrections (subtypes 3& 4, i.e. FID

3 = 3 & 4) /* How to Process Subsequent Take or Correction Message */

IF a first take does not exist in database for this STORY_REF

THEN

IF a first take exists in database for this PNAC but with

a different STORY_TIME or STORY_DATE

THEN

process as a corrected /* corrected as been missed

*/

ELSE

ADD_FIRST_TAKE to database using STORY_DATE and

STORY_TIME as the first take PROC_DATE and

TAKE_TIME /* a first take has been missed */

ENDIF

ENDIF

IF TAKE_SEQNO <= latest TAKE_SEQNO in database for this

STORY_REF

THEN

discard subsequent take or correction

/* a more recent subsequent take or correction has

already been received */

EXIT

ENDIF

IF correction or TAKE_SEQNO > 1 + latest TAKE_SEQNO in database

for this STORY_REF

/* correction or possible missed correction */

THEN

REPLACE first take headline text

ENDIF

IF subsequent take exists for this STORY_REF

THEN

DELETE old subsequent take from database /* leave

CATEGORY_INFO */

ENDIF

ADD_SUBSEQUENT_TAKE to database

ADD_SUBSEQUENT_TAKE

/* How to Add Subsequent Take to Database */

REPLACE latest TAKE_SEQNO in database with TAKE_SEQNO in

message


REPLACE PROC_DATE and TAKE_TIME for latest take in database


database)



Correcteds (subtype 5, i.e. FID 3 = 5) /* How to Process a Corrected Message */

IF PNAC exists in database

THEN

IF STORY_DATE and STORY_TIME <= most recent STORY_DATE and

STORY_TIME for this PNAC

THEN

discard corrected /* duplicate or later corrected already

processed */

ELSE

DELETE most recent story from database with this PNAC

(following delete rules)

ENDIF

ENDIF

process as a first take


database)

Deletion (subtype 7, i.e. FID 3 = 7) /* How to Process a Delete Message */


THEN

DELETE all HEADLINES and ALERTS for this STORY_REF

inform downstream applications (e.g. display devices. permanent

database)

ENDIF

Drop Due to Expiry (subtype 8, i.e. FID 3 = 8) /* How to Process Drop Due to Expiry Message */

DELETE each non-permanent item with STORY_DATE and STORY_TIME

<= STORY_DATE and STORY_TIME of message from database

9.7.9.3 Text Segment Handling Rules

To retrieve text from Elektron Edge, your application needs to post an SSL_ET_IMAGE_REQ event

(refer to Error! Reference source not found., Error! Reference source not found. for format), using

the PNAC found in the RIC field of the headline message. If success, this will provide a response (see

section 8.4.1 for format) containing up to 255 bytes of text. It may also contain the RIC for the next

text segment in the NEXT_LR field. If the NEXT_LR field contains a non-null reference, then a

second SSL_ET_IMAGE_REQ event should be posted using this RIC. This will provide the next text

segment. Further requests are made until the forward pointer field is null. This indicates that all the

currently available story text has been retrieved.

After an application has retrieved the available text for a story, it must retain the first and last text

segment in the watchlist. If any changes or additions are made to the story, the NEXT_LR field of one

of these segment records will receive an update message. The processing rules defined below show

how the application can use these messages to always display the latest version of the story. The

following pseudo code assumes that the story has been retrieved in order to display onto a user

workstation.

/* Processing User Request for Story Text for a Specific Headline */

LAST_SEGMENT = PNAC of headline

issue a snk_open() request for LAST_SEGMENT

/* This insures that first text segment is in watchlist */

STORY = SEG_TEXT for LAST_SEGMENT

NEXT_SEGMENT = NEXT_LR of LAST_SEGMENT

WHILE NEXT_SEGMENT not null

/* Read segments until a segment has a null pointer in NEXT_LR

*/

issue snk_open() with Snapshot Request flag set



/* No need to hold intermediate text segments in

watchlist */

STORY = STORY + SEG_TEXT for LAST_SEGMENT

LAST_SEGMENT = NEXT_SEGMENT

NEXT_SEGMENT = NEXT_LR of LAST_SEGMENT

ENDWHILE

issue a snk_open() request for LAST_SEGMENT

/* This insures that last text segment is in watchlist */

send story text to display

/* Processing an Update Message */

IF UPDATE is received for first (PNAC) segment of story on

display

THEN

/* A corrected has been issued for story on display */

Remove story from screen

Re-request story text using PNAC

Retrieve latest headline text from message database

Send new story text and headline to display

EXIT

ENDIF

IF UPDATE is received for last text segment of story on display

THEN

/* A subsequent take or correction has been issued for

story on display */

Retrieve latest headline text from message database

Send headline text to display

Request additional text segments using updated NEXT_LR

pointer

Send additional story text to display

ENDIF

/* Processing an Item Closed Event */

IF SSL_ET_ITEM_STATUS_CLOSED event received for first (PNAC)

segment of story on display

THEN

/* A drop or delete has been issued for story on display */

Remove story from display

ENDIF

9.7.9.4 Cross Referencing from Quote Records

A quote record may contain NEWS_TIME (FID 29) which defines the time of the most recent News

2000 news item related to this record, which has been sent out in the last 24 hours. It should be noted

that the user might not be permissioned to see this news item. For this reason, you are advised to create

an equivalent of the NEWS_TIME FID directly from the headlines the user has actually received.

A quote record may contain BCAST_REF (FID 728). This FID holds a News 2000 search expression

as defined in section 9.7.8.6.6. Executing a News 2000 search using this search expression will

generate news headlines related to this instrument. A chain contains multiple BCAST_REFs. In this

case, all news found from any of the search expressions is related to the chain.

These FIDs may be used to provide rapid cross referencing from quote records to related news

headlines.

If an end-user includes a RIC in his searches, then the application should replace that RIC by the

contents of the associated BCAST_REF FID, if this is available.

9.7.10 Recommended Display Application Functionalities

The following sections provide recommended features that should be included in News 2000 display

applications



9.7.10.1 Basic Headline Display

The basic display of news should be a chronologically-ordered list of headlines and alerts, which

updates quickly to show fresh headlines or alerts as they are issued.

The display should show the take time, the attribution code and the text of the headline or alert. It

should also show the date for data older than 24 hours.

The end-user should be able to see earlier or later headlines and alerts.

The latest headline received in the headline view should always be displayed.

Alerts should be displayed in a colour different from headlines.

Deleted headlines should be removed from the headline display.

Time of communications fault suffered and time of restoration should appear in the headline

display.

Headline displays should wrap to fit the available space.

In a display with all news headlines, the first and last take headlines for each story should be

shown in addition to all alerts. The TAKE_SEQNO of the last received subsequent take should be

displayed.

In any user-defined news selection, the first take headline and all alerts should be shown for all

stories. In addition, the last take headline, with its TAKE_SEQNO, should be shown for stories

which have been previously displayed.

9.7.10.2 Text Retrieval and Display

The text of stories should be easily accessed from the headline.

At the end of a story, the application should list the PNAC and all associated category codes in

such a way that they can be used to find associated information rapidly.

Applications should take note of the ‗tabular text‘ indicator field TABTEXT. If set, the text in that

segment should be displayed in a fixed-width font to ensure columns line up correctly.

Alerts should be displayed along with the headline and text of a story, so the end-user can read

alerts, headline and text together. Text filed in separate pages should be automatically joined up for

the end-user. If the text is too long to fit the window, it should be wrapped.

Story displays should be cleared down on receipt of corrected, delete or drop due to expiry

messages.

Story displays should be automatically updated when new takes are filed.

A search consists of a single Named Item Code should result in the text display of the latest story

carrying that code, rather than a list of headlines of all stories carrying that code.

9.7.10.3 Searching for News

The end-user should have easy access to the News 2000 Directories and the back-up directory.

A ―What‘s New Window‖ should be displayed each morning (see section 9.7.10.4, What’s New

Window).

The end-user should be able to search for news both by category codes and by keyword.

There should be a fast and simple means for entering search commands using individual codes or

keywords, or combinations of codes and keywords. Boolean ―AND‖, ―OR‖, and ―NOT‖ should be

supported.

The end-user should be allowed to retrieve specific stories by entering the Named Item Code.

Cross references from items in square, angle, or curly brackets (see section 9.7.8.6, Fields

Embedded in Text Segments and BCAST_TEXT (FID 264)) by using mouse or cursor device

should be supported.

Cross references from Quote records should be supported using the BCAST_REF field (see section

9.7.9.4, Cross Referencing from Quote Records).



9.7.10.4 The What’s New Window

Certain News 2000 stories carry a code INFO. These stories contain general Thomson Reuters product

news for our subscribers to reference The application should automatically display the headlines of

these stories in a What‘s New Window every morning, prior to the user starting work, and when the

display is started.

9.8 Guidelines for Processing Marketfeed Messages

The message processing rules described in this section should enable your software to function

correctly without modification following changes to Thomson Reuters Marketfeed specification.

Failure to conform to these rules may cause severe repercussions to users in future.

9.8.1 Marketfeed Template Changes

Marketfeed template and FID definitions can be changed for the following reasons:

New fields and templates may be required to accommodate new market information.

Fields already defined in the Master FID List may be added to existing templates.

Templates may be deleted because of changes in market practice making a particular specialised

template unnecessary, or because several templates are amalgamated into a single, general

definition.

Fields may be deleted due to changes in market activity or changes in the requirements for a

particular field (e.g. change in field length).

Changes to record templates and the Master FID List are categorized as backward or non-backward

compatible. The former may be implemented in data sources before the user systems (vice versa) and

can include one or more of the followings:

Existing fields (which are already defined in the Master FID List) may be added to existing record

templates.

New fields (not in the Master FID List) can be added to existing record templates.

Changes in type or length of existing fields in record templates can be accommodated by defining

the modified field as a new field. However, the old field will remain in the record template and

data sources will continue to update the old field as well as the new one.

New record templates may be included provided that they are for use with new records only.

New enumerated type values may be added to existing lists and may be sent by headend. Existing

enumerated type values may be deleted but will not be re-defined.

NOTE:

Existing template numbers will not be re-allocated to new templates in backward compatible releases.

Backward-compatibility means that, for those systems you have implemented the following rules on, no

change is needed to receive new data. (However, you will have to make changes on the systems if you

wish to manipulate the new data).

The rules are as follow:

Ignore unexpected fields in a message (for example if a new underlying record template

containing new fields is implemented by a user system before the data source).

Accept fewer fields in a message than expected.

Use the response message as the record image, and ignore any FIDs received in any

unsolicited messages that are not part of the record image.

Non-backward-compatible record template changes must be implemented by all Marketfeed users

before associated data is transmitted by the data sources. As well as possibly including backward-

compatible changes listed above, the changes may also include one or more of the following:

Deletion of existing fields from record templates. (Prior to a non-backward-compatible record

template release, fields that are obsolete cannot be removed from templates although data sources

can cease to update them.)

Re-allocation of template numbers to new templates.



Re-definition of existing enumerated type values.

9.8.2 Optional Fields

From time to time, some new fields may be introduced to a Marketfeed message; applications which do

not support the new fields must ignore them.

For example, if we start with the following basic message format:

<FS>TYPE<GS>FIELD_Z<FS>

and we may wish to add field FIELD_Y before FIELD_Z:

<FS>TYPE[<RS>FIELD_Y]<GS>FIELD_Z<FS>

Then the application should work in the way that the first field separator character expected after

TYPE is the <GS> preceding FIELD_Z, i.e. skip any unknown characters until the next expected

separator is detected.

9.8.3 New Message Types

In order to limit the dependencies when new message types are introduced, your application should

ignore messages with unknown message types.

9.8.4 Control Codes

It is highly probable that in future, new ISO control sequences will be introduced to Marketfeed.

Advance notification of these new sequences will be given before they are introduced, so that you can

make any necessary modifications to recognise (possibly ignore) new sequences.

The following approach will therefore be taken:

Marketfeed messages can contain any of the escape / control sequences / strings defined in ISO

6429.

Applications must recognize the start and end of all control sequences and should ignore the whole

data field if an unknown sequence is received. All sequences in ISO 6429 conform to the following

rules:

Escape Sequence

Start = ESC (1/11)

End = character in range 3/0 to 7/14

Control Sequence

Start = CSI (99/11)

End = character in range 4/0 to 7/14

The data field with unknown control sequences should be ignored.

Control and Character Strings

Start = APC (9/15)

DCS (9/0)

OSC (9/13)

PM (9/14)

SOS (9/8)

End = ST (9/12)

The data field with unknown control and character strings should be ignored.

9.9 Programming Guidelines

You should observe the following guidelines for your applications to conform to standard

operations of datafeed servers. For detail explanation and example applications which follow and

demonstrate these guidelines,

Guideline 1: When interpreting status information in a message, use symbolic constants rather

than integer values. This allows the status definitions to be modified in future without impact to

existing applications.

Guideline 2: Your applications must wait for the source service to correct a stale data condition.

Guideline 3: When a ―data stream closed‖ status occurs, it means that human intervention is

required to correct the condition.

Guideline 4: Your applications should expect that all data fields are contained in a record image.

The fields may be in no particular ordering.



Guideline 5: If a Marketfeed response message is received for an existing image, your application

should not assume that the new image is with the same size as the original image.

Guideline 6: If your application receives an unsolicited record image in an

SSL_ET_UNSOLICITED_IMAGE event, it should not process the image as market activity.

Unsolicited images are used to re-sync the data stream. If the data values of the unsolicited record

image are the same as your application‘s internal cache, no further action is required. Otherwise,

an update probably was missed and your application should apply the image.

Guideline 7: When updates occur, your applications will only receive updates for data fields

which may have changed but not necessarily for all fields in an image.

Guideline 8: If your application is logging time series (TS1) for data items, unsolicited images and

close update messages do not imply market movements and should not be included in the time

series UNLESS the field data values of the unsolicited record image are different from your

application‘s internal cache. In such case, the unsolicited image data fields must be treated as

updates or corrections.

Guideline 9: Assign a higher priority to the processing of messages from the Elektron Edge than

to the processing of end-user requests.

Guideline 10: Blocking (using select()) is the most suitable implementation for reading

messages in most applications. Blocking is normally more efficient than polling. In most system

environments, polling is less efficient because of the CPU overhead involved in polling is frequent

enough to achieve real-time operation.

Guideline 11: For dynamic memory allocation of data that you want to cache in string format, use

the Master FID List to get MAX_DATA_LENGTH for each field in the image and allocate them

appropriately.

9.10 Performance Requirements

Since your applications will receive unthrottled real-time market updates and images from a powerful

multiprocessor machine (the Elektron Edge), there are strict requirements on its data flow handlings.

1. Your application‘s HIGHEST priority must read the incoming data from the API. When little

traffic is present, such reading will not impose a significant processing burden.

2. Your application must GUARANTEE for never going away and failing to call the API. In

cases of single threaded APIs, this would starve the API from reading data from the network.

For some multithreaded APIs, the API may be reading the data from the network, but

memeory queues within the API may be backing up.

3. You are recommended to put counters in all callback routines with a mechanism that prints the

counts in some compact, parsable forms once per second, or at least prints on every 5 seconds.

This introduces very small overhead, but will aid in understanding the data volume your

application is seeing and troubleshooting performance problems easier. You are further

recommended to use a timestamp when calling to and returning from processing API callbacks

nd logging any cases when the previous exit timestamp and the new entering timestamp differ

by more than 2 seconds. A granularity of 1 second is sufficient for that timestamp.

4. Your application should undergo performance tests to prove its ability to process update

traffics and image traffics from Elektron Edge. This traffic rate depends highly on the number

of records in used and the type of records in used. Contact Thomson Reuters for current and

excepted figures. The occurrence of Elektron Edge buffer overflow may potentially indicate

the machine running your application is not fast enough or the client network is not fast/stable

enough to handle the traffic volume.

GLOSSARY


APPENDIX A GLOSSARY

Application See ―SSL Application or OMM-based Application‖.

Backlink The interactive channel is referred to as the backlink in cases where a

broadcast channel is the primary data delivery link. See ―Interactive

Channel‖.

Broadcast Channel The name for the satellite or terrestrial broadcast link which may be used

to deliver data to the Elektron Edge at the client site. Also see ―Interactive

Channel‖.

Broadcast Message The logical message structure used for news headlines, alerts, deletes and

corrections. The Elektron Edge converts broadcast messages into update

messages associated with a special News 2000 pseudo RIC instead of

using SSL_ET_BROADCAST event of SSL API.

Call-Back Function This function is registered as an event handler to process incoming events.

Chain Expansion An optional feature used in criteria-based data streams that firstly

identifies chain records in a criteria and secondly appends items to the

criteria that are identified by the underlying RICs in the chain records.

Client See ―sink client” and ―source client‖.

Closing Run Correction A broadcast message to reset fields within a record before commencement

of trading. Typically such adjustments are: previous night‘s last traded

price is copied to the close price field. These messages are not a reflection

of market activity. The information is sent using an update event

(SSL_ET_ITEM_UPDATE).

Corrected A broadcast message subtype; changes a News 2000 story headline and

indicates that the text of the story has been completely rewritten.

Correction A broadcast message subtype; changes a News 2000 story headline and

indicates the existence of additional text modifying the content of the

story.

DACS The Data Access Control System is a tool that allows customers to

automatically control who is permitted to use which sets of data in the

customer‘s financial information management system. In this way, the

customer can demonstrate to information providers and vendors how many

people are using which sets of data.

Daemon Process A UNIX process that runs in background, independent of a terminal, and

performs a specific task.

Data Group All records belong to a data group for the purpose of data health reporting.

Records in the same data group share the same likelihood of becoming

stale or healthy ‗en-masse‘.

Data Item Information from a specified source (e.g., YOUR_SOURCE) for a

specified item (e.g., DEM=). Data Items are identified by the name of the

source service which supplies them and the name of the individual item

within that source service.

Data Stream A logical entity, defined as a unique combination of a channel, service

name, and item name. Data streams are opened by sink applications via the

posting of the SSL_ET_IMAGE_REQ event. Data streams are opened by

source applications via the posting of an SSL_ITEM_IMAGE event.

Each data stream is independent of any other data streams. Multiple data

streams may be opened on a channel. A new feature of the watchlist in the

SSL 4.5 API is the ability to support multiple data streams for a particular

item on one channel. If multiple channels are mounted, data streams may

also be opened for the same data item on each channel5.

5 If the watchlist is disabled, only one data stream for a particular item, per channel is allowed.

GLOSSARY


The data which flows down a stream consists of image messages (both

solicited and unsolicited), update messages, and status messages. The

stream of messages is initiated by a source application posting image,

update, and status events. Sink applications receive image, update, and

status events to inform them of the change to the data stream.

Images are requested (solicited) by sink applications when they firstly join

a stream or, in the case of ―host requests‖, when the sink application

wishes to refresh the data item. Unsolicited images are sent when a

discontinuity In the stream is detected by some components of the system

or when the Source application wishes to refresh or rebuild the data items.

SSL Applications should process all images received, both solicited and

Unsolicited. Processing an image consists of replacing all stored data with

New data from the received image.

Data Stream Events A sink client receives data stream events as the result of opening a data

stream via posting a SSL_ET_IMAGE_REQ event; these events provide

data or status information pertaining to one or more data streams which the

sink client has opened.

A source client posts data stream events to supply data or status

information for one data stream, a group of data streams, or all the data

streams which the source client currently has been opened.

Drop A broadcast message notifying that a record has been removed from the

database.

Empty Character

String

A C language null-terminate character string containing no characters

other than the terminating null (‗\0‘) byte. This is typically represented by

two consecutive double quote marks (―‖).

Entitlement Code If a vendor requires subservice permissioning, a code must be provided

with each data item from that vendor. This entitlement code is used by the

permissioning system (DACS) to control access to data.

Enumerated Type An enumerated type is one of the field types defined for Marketfeed. It

consists of a set of mnemonics, each having its own specific meaning. A

displayable string is associated with each of these mnemonics.

FID Applies to record data defined by Marketfeed. A Field Identifier (FID) is a

unique identifier for a data field in a record.

Field As applied to records, a field is a constituent component of record data as

defined by Marketfeed.

Field List Number A unique number which identifies the set of fields in a record.

Field Name Applies to record data as defined by Marketfeed. This is the name given to

a component field of record data (e.g., BID, ASK). Such names are unique

across a service.

Field Type Applies to record data defined by Marketfeed. The name given to the type

of data carried in a given field of record data (e.g., INTEGER, PRICE).

First Take Broadcast message subtype; delivers News 2000 story headline and

indicates the availability of the first part of the story text.

Group ID GroupID in SSL_ET_ITEM_IMAGE and

SSL_ET_UNSOLICITED_IMAGE event indicate the data group of the

record.

IDN The Integrated Data Network (IDN) combines multiple sources of

information into a single format. As a source service, IDN is characterized

by record data and high transmission speed.

Image An image is the complete representation of a data item.

Instrument A term for a financial information record held in the database.

Interactive Channel The request/response data delivery link between the Elektron Edge on the

client site and the data center.

GLOSSARY


Item See ―Data Item‖.

Logical Data Real-time data distributed in a display-independent format. By implication,

applications can access both the syntax and semantics of all constituent

elements of the data. (Also see Record)

Marketfeed A Thomson Reuters presentation protocol providing public access to

Thomson Reuters-supplied data. It defines the syntax and semantics of

record data in order to support the transfer of data between Thomson

Reuters and user computer systems in a consistent and logical format.

Node A device connected to a network cable. This usually refers to a server or a

workstation.

Non-Updating Item An item whose value can change without Edge providing an update.

Primarily used for news and historical data (e.g. Time & Sales data).

Page Record Page-based information that is presented in record format. Each row in the

page is uniquely identified by a FID.

Permissionable Entity

(PE)

A numeric code included in each record. The PE is used to determine

which subservice(s) the record belongs to. For example, the PE value 62

indicates that the item is from the New York Stock Exchange.

PNAC Primary News Access Code. The unique story identifier.

QOS Quality of Service. The quality level of a service provided on the datafeed

core network.

Quote A term for the content of a financial instrument record containing current

prices, historical prices, and other pertinent information.

Real-time The notion of information that is available instantly as events occur.

Record A record is a type of data item encoded in a form that is convenient to be

used by computer applications. SSL record data is encoded in the

Marketfeed format.

Record Source A source that supplies data items in the form of records. Record data is

encoded in the Marketfeed format.

Record Transaction

Level (RTL)

A counter which is included in messages to facilitate record update

sequencing. Consumer is recommended not to use the RTL.

Thomson Reuters

Elektron Edge

A source application that accepts connections from SSL applications to

provide data to SSL applications.

RIC A Thomson Reuters Instrument Code (RIC) applies to record data defined

by Marketfeed. A RIC is a unique identifier for a record.

Server The SSL API is based on a server/client model. A server is a process or

several coordinating processes whose function is to satisfy client requests.

Service A logical entity, made up of one or more source applications that have

been configured to provide a single, coherent view of a set of data. Sink

applications request data from services. Elektron Edge provides data under

service either ELEKTRON_DD or ELEKTRON_AD.

Sink A consumer of data from a source application.

Sink Application An SSL application that functions as a sink client.

Sink Client A consumer of data from source applications via the SSL Library.

Snapshot A term for a one-off retrieval of a record from headend. No update

message will be received for Snapshot requests.

Source A contributor of data items to sink applications.

Source, Sink-Driven A source client whose cache is determined, within the limitations of the

application, by demand from sink clients. At any given point of time, the

cache of the source client contains a subset of all possible items available

from that source client. (Previously known as a selective source or

interactive source.)

GLOSSARY


Source, Source-Driven A source client whose cache is determined by the source client itself.

Demand from the network will not change the contents of a source-driven

source client‘s cache. At any given point of time, the cache of the source

client contains all possible items available from that source client.

(Previously known as a full cache source or non-interactive source.)

Source Application An SSL application that functions as a source client.

Source Client A contributor of data items to sink applications via the SSL Library.

Source Server A logical entity which interfaces between a vendor digital feed and the

network via the SSL Library (i.e., a source client). The source server

supplies items upon request and forwards updates to these items as they

are received.

Source Service The name by which a particular vendor or data contributor is identified on

the network. A source service is comprised of one or more source servers

on the network.

SSL A Thomson Reuters software product that provides an application

programming interface to the network.

SSL Application A program compiled and linked with the SSL Library which functions as a

sink client or source client. An SSL application may retrieve and/or

contribute market (or other) data to the network.

SSL Library This SSL component provides an interface to the underlying sink and

source components. It consists of a library of ANSI C language object

modules which is linked to the client program.

State For a given application, each channel and data stream may be in one of the

several possible defined states (e.g., open data stale). Certain events cause

a transition from one state to another.

Status A status indicates the state of a data item. For example, a status may

indicate that the item is unavailable, that the data provided may not be

complete, or that the item is now up to date.

Subsequent Take Broadcast message subtype; indicates the availability of further story text

for a News 2000 item.

Take A filed section of a News 2000 story. It consists of several text segments

―chained‖ together.

Text Segment A 255-byte segment of text that used to transmit News 2000 stories.

Update An update is a modification to the contents of a data item. A source sends

updates asynchronously as the contents of the item change.

Verify A broadcast message which serves to ensure that records held at the client

site have the same data content as those held on the database. The Elektron

Edge sends full verify record (VYSNC) as an

SSL_ET_UNSOLICITED_IMAGE event and partial verify record

(VNOSYNC) as an SSL_ET_ITEM_UPDATE event.

Watchlist The list of unique data items in the Elektron Edge which are currently in

used across a client‘s channels. For those items, the Elektron Edge would

capture and forward updates, corrections, closing run corrections, verifies,

and drops as they are broadcasted by headend. It is also an optional feature

in the SSL API for normal sessions. The watchlist provides item recovery,

request pacing, single open, group message fan-out, tagging for multiple

opens (data streams) for the same item, and buffering of item requests for

unavailable services.

ITEM STATUS TEXT TO CLIENTS


APPENDIX B ITEM STATUS TEXT TO CLIENTS

Status Text Example Scenario

Record dropped from network A drop of in used ric is received from headend.

All is well Record image in healthy state.

The record could not be found Record is unavailable from headend.

Technical error Record request timeout due to no response from headend.

Item is stale Record image is in stale state, e.g. request is made to cached

items during comms outage between Elektron Edge and

Distribution PoP.

Record not service permissioned Client is not permissioned to view the requested record.

User watchlist full Record request is rejected due to user watchlist full.

Non-updating item The requested item is non updating.

Mangle switchover Switchover of record source between IDN and Elektron.

Index


Index

A

Administrative message, 50

Alert, 61, 64, 65, 66, 67, 68, 72, 73, 74, 77

Attribution, 14, 62, 77

B

Backlink, 63, 82

BDS definition, 30, 31

Broadcast, 7, 11, 29, 31, 32, 61, 63, 64, 65, 66, 67,

68, 73, 74, 82, 83, 85, 89

Broadcast channel, 82

Broadcast data stream, 29, 31

Broadcast message, 63, 64, 65, 66, 67, 68, 73, 82,

83, 85

Brokerage characters, 13, 33

C

Chains, 10, 20, 53, 54, 55

Channel, 11, 26, 27, 29, 31, 55, 56, 57, 82, 83, 85

Character set, 9, 12, 33, 64, 69, 70

ClientItemTag, 36, 38

Close_Record, 47, 81

Company identifiers, 67

Contributor code, 20

Control functions, 69

Control sequences, 51, 80

Correct_Record, 46, 58

Corrected, 11, 58, 59, 64, 65, 66, 67, 68, 72, 73, 75,

76, 77, 78, 82

Correction, 42, 43, 47, 58, 59, 64, 65, 66, 67, 68, 73,

75, 77, 82

Country code, 15, 17

Criteria-based request, 30

CTS trade report, 59

Currency code, 15

D

Data field pairs, 36

Data field portion, 36

Data health, 10, 12, 24, 29, 82

Data item, 10, 22, 51, 53, 81, 82, 83, 84, 85

Data stream, 29, 31, 47, 80, 82, 83, 85

Data type, 36

Database, 11, 12, 13, 14, 20, 21, 23, 31, 73, 74, 75,

76, 77, 83, 85

Database query, 31

Delimiters, 20, 34

Delivery path, 12, 23, 24

Delivery period, 15, 16

Directories, 13, 16, 17, 20, 33, 61, 62, 63, 78

Drop due to expiry, 64, 66, 78

E

Edge Notification Pages, 50

Embedded fields, 71

Escape sequences, 35

Event handler, 82

Exchange identifier, 14, 20, 40, 41

F

FID, 10, 12, 21, 22, 27, 28, 34, 35, 36, 37, 38, 39,

40, 42, 43, 44, 45, 46, 47, 48, 51, 52, 54, 58, 61,

62, 63, 65, 66, 67, 68, 69, 70, 72, 74, 75, 76, 77,

78, 79, 81, 83, 84

Field Identifier, 10, 12, 21, 36, 83

Field Identifier (FID), 10, 12, 83

First take, 64, 65, 66, 67, 73, 74, 75, 76, 78

Fractional values, 33

H

Headline, 32, 61, 63, 64, 65, 66, 68, 73, 75, 76, 77,

78, 82, 83

Horizontal Position Adjust character, 34

I

Image event, 38

Instrument code, 12, 13, 14, 15

Interactive channel, 82

Intra-field positioning sequence, 34, 35

IRG, 23, 42, 44

J

Japanese characters, 69

L

Large pages, 21

Latest Activity, 51, 52, 53

Location code, 17

M

Market identifiers, 18, 20

Market maker code, 20

Marketfeed, 10, 11, 33, 34, 35, 36, 37, 38, 79, 80,

83, 84

Marketfeed message, 10, 11, 33, 35, 36, 38, 65, 79,

80

Marketfeed record, 34, 36

Master FID List, 48, 51, 79, 81

Maturity month, 19

Message processing rules, 11, 79

Message type, 34, 36, 51, 65, 80

Month codes, 14, 19

N

N2_UBMS, 32, 61, 64, 68, 69

Nagle, 25, 26

Named Item Codes, 14, 62, 67

NMTS, 42, 58, 59

Non-updating item, 24, 25, 60

P

Page records, 10, 21, 23, 50, 54, 58

Permission data, 65

Permissioning, 23, 65, 83

PNAC, 11, 32, 61, 62, 63, 64, 66, 71, 72, 73, 74, 75,

76, 77, 78, 84

Index


Product Codes, 14, 61, 67, 73

Pseudo response, 26, 27

Pseudo RIC, 26, 27, 28, 32, 61, 64, 68, 73, 82

R

Record template, 53, 54, 79

Record_Response, 38, 39, 40, 45, 46, 47, 51, 58, 60,

73, 76, 79, 80

Records, 10, 12, 19, 20, 21, 22, 23, 24, 31, 32, 34,

47, 50, 53, 54, 58, 59, 60, 63, 76, 77, 78, 79, 81,

82, 83, 84, 85

Recovery, 29, 31, 85

Report Codes, 14, 62, 73

Request rate, 10, 12

Request window, 24, 60

RequestType, 55, 56, 57

RIC Change Master Index Pages, 50

RIC references, 11, 20, 55, 56, 57

RIC root, 18, 54, 60

Ripple fields, 47, 48

S

Search expression, 70, 71, 72, 77

Separator, 20, 33, 34, 38, 40, 71, 80

Sequence number, 42, 59, 64

Service bank, 23, 65

Sink application, 24, 30, 32, 35, 38, 39, 45, 48, 82,

84, 85

Snapshot, 24, 26, 76, 84

Source application, 38, 82, 84

SSL Library, 84, 85

SSL_ET_BROADCAST, 82

SSL_ET_IMAGE_REQ, 11, 55, 56, 57, 76, 82, 83

SSL_ET_ITEM_IMAGE, 38, 83

SSL_ET_ITEM_STATUS_CLOSED, 25, 77

SSL_ET_ITEM_UPDATE, 33, 46, 47, 82, 85

SSL_ET_UNSOLICITED_IMAGE, 47, 80, 83, 85

sslSnkMount(), 11

Status event, 82

Story, 11, 32, 40, 41, 52, 61, 62, 63, 64, 65, 66, 67,

70, 71, 72, 73, 74, 76, 77, 78, 82, 83, 84, 85

Strike price code, 18

Subject Code, 62, 63

Subsequent take, 61, 65, 66, 67, 75, 77, 78

Subtype field, 65

T

Tabular text, 70, 78

Tag, 35, 36, 38

Template change, 79

Text segment, 11, 32, 63, 64, 69, 70, 72, 73, 76, 77,

85

Thomson Reuters Basic Character Set, 64, 69

Thomson Reuters Instrument Code, 10, 12, 84

Tiles, 10, 20, 22, 53, 54

Time & Sales, 13, 24, 59, 60, 61, 84

Time field, 10, 21, 43, 60

Time stamp, 22, 52, 61

Time zone, 21

Topic Code, 14, 62, 66, 67, 70

U

Update event, 46, 47, 82

Update_Record, 34, 46, 58, 64, 82

V

Valoren Number, 12

Verify_Record, 47, 64

W

Watchlist, 10, 11, 12, 23, 24, 25, 27, 28, 29, 31, 58,

76, 77, 82, 85

Index


© Thomson Reuters 2013. All rights reserved.

Republication or redistribution of Thomson Reuters content, including by framing or similar means, is prohibited without the prior written consent of Thomson Reuters.

"Thomson Reuters" and the Thomson Reuters logo are registered trademarks and trademarks of Thomson Reuters and its affiliated companies.

FOR MORE INFORMATION:

SEND US A SALES ENQUIRY AT financial.thomsonreuters.com/sales READ MORE ABOUT OUR PRODUCTS AT financial.thomsonreuters.com FIND OUT HOW TO CONTACT YOUR LOCAL OFFICE financial.thomsonreuters.com/locations ACCESS CUSTOMER SERVICE AT financial.thomsonreuters.com/customers

thomson reuters elektron edge v2.3 · 2018. 7. 6. · thomson reuters elektron edge programmer’s...

Documents