thomson reuters elektron edge v2.3 · 2018. 7. 6. · thomson reuters elektron edge programmer’s...
Post on 08-Sep-2020
14 Views
Preview:
TRANSCRIPT
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
Thomson Reuters Elektron Edge Programmer’s Guide 9
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
Thomson Reuters Elektron Edge Programmer’s Guide 10
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
Thomson Reuters Elektron Edge Programmer’s Guide 11
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
Thomson Reuters Elektron Edge Programmer’s Guide 12
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
Thomson Reuters Elektron Edge Programmer’s Guide 13
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
Thomson Reuters Elektron Edge Programmer’s Guide 14
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
Thomson Reuters Elektron Edge Programmer’s Guide 15
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
Thomson Reuters Elektron Edge Programmer’s Guide 16
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
Thomson Reuters Elektron Edge Programmer’s Guide 17
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
Thomson Reuters Elektron Edge Programmer’s Guide 18
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
Thomson Reuters Elektron Edge Programmer’s Guide 19
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
Thomson Reuters Elektron Edge Programmer’s Guide 20
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
Thomson Reuters Elektron Edge Programmer’s Guide 21
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
Thomson Reuters Elektron Edge Programmer’s Guide 22
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
Thomson Reuters Elektron Edge Programmer’s Guide 23
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
Thomson Reuters Elektron Edge Programmer’s Guide 24
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
Thomson Reuters Elektron Edge Programmer’s Guide 25
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
Thomson Reuters Elektron Edge Programmer’s Guide 26
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
Thomson Reuters Elektron Edge Programmer’s Guide 27
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
Thomson Reuters Elektron Edge Programmer’s Guide 28
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
Thomson Reuters Elektron Edge Programmer’s Guide 29
<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
Thomson Reuters Elektron Edge Programmer’s Guide 30
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.
DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE
Thomson Reuters Elektron Edge Programmer’s Guide 31
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)
DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE
Thomson Reuters Elektron Edge Programmer’s Guide 32
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.
DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE
Thomson Reuters Elektron Edge Programmer’s Guide 33
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
Thomson Reuters Elektron Edge Programmer’s Guide 34
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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 35
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>
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 36
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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 37
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 38
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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 39
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>
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 40
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<
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 41
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 42
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 43
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 1001 998<US>+0.00<RS> GEN_VAL3 General purpose numerical field, meaning
deter-mined by FID 1002 999<US>+0.00<RS> GEN_VAL4 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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 44
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 45
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 46
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
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 47
<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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 48
8.4.3 Correct_Record (317)
Format: <FS>317<US>TAG<GS>RIC<US>RTL{<RS>FID<US>VALUE}<FS>
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)
Format: <FS>312<US>TAG<GS>RIC<US>RTL{<RS>FID<US>VALUE}<FS>
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.
LOGICAL DATA FORMATS IN SSL
Thomson Reuters Elektron Edge Programmer’s Guide 49
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
Thomson Reuters Elektron Edge Programmer’s Guide 50
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 51
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 52
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 53
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 54
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 55
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>
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 56
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:
SSL_EVENT_INFO EventInfo;
memset(EventInfo, 0, sizeof SSL_EVENT_INFO);
EventInfo.ImageReq.ServiceName = “ELEKTRON_DD”;
EventInfo.ImageReq.ItemName = “1#.INDEXE”;
EventInfo.ImageReq.RequestType = SSL_RT_NORMAL;
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>
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 57
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:
SSL_EVENT_INFO EventInfo;
memset(EventInfo, 0, sizeof SSL_EVENT_INFO);
EventInfo.ImageReq.ServiceName = “ELEKTRON_DD”;
EventInfo.ImageReq.ItemName = “.AEX”;
EventInfo.ImageReq.RequestType = SSL_RT_NORMAL;
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>
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 58
<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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 59
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 60
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:
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 61
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 62
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:
Directory Report Code PNAC
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 63
Directory Report Code PNAC
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 64
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 65
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 66
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 67
FID # Acronym Description
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.
Each code can be up to 4 bytes.
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.
Each code can be up to 6 bytes.
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.
Each code can be up to 10 bytes.
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.
Set by the first alert or take filed for this story.
Reset if a corrected is filed.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 68
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 69
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 70
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}
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 71
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:
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 72
[ ] 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..
FID # Acronym Description
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.
Set by the first alert or take filed for this story.
Reset if a corrected is filed.
256 PROC_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.
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 73
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 74
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*/
IF STORY_REF exists in database
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 75
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
ADD CATEGORY_INFO (removing duplicates)
REPLACE PROC_DATE and TAKE_TIME
inform downstream applications (e.g. display devices, permanent
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
ADD CATEGORY_INFO (removing duplicates)
REPLACE PROC_DATE and TAKE_TIME for latest take in database
inform downstream applications (e.g. display devices, permanent
database)
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 76
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
inform downstream applications (e.g. display devices, permanent
database)
Deletion (subtype 7, i.e. FID 3 = 7) /* How to Process a Delete Message */
IF STORY_REF exists in database
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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 77
/* 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
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 78
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).
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 79
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 80
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.
IMPLEMENTATION GUIDELINES
Thomson Reuters Elektron Edge Programmer’s Guide 81
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
Thomson Reuters Elektron Edge Programmer’s Guide 82
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
Thomson Reuters Elektron Edge Programmer’s Guide 83
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
Thomson Reuters Elektron Edge Programmer’s Guide 84
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
Thomson Reuters Elektron Edge Programmer’s Guide 85
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
Thomson Reuters Elektron Edge Programmer’s Guide 86
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
Thomson Reuters Elektron Edge Programmer’s Guide 87
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
Thomson Reuters Elektron Edge Programmer’s Guide 88
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 Elektron Edge Programmer’s Guide 89
© 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
top related