Thomson Reuters Elektron Edge v2.3.0
Programmer’s Guide
Version: 1.0 07 May 2013
© 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 ii 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 iii 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 iv 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 v 3 List of Tables Table 9-1 Standard Marketfeed Field Types ...... 38 Table 21-1 Chain Record FIDs ...... 55
Thomson Reuters Elektron Edge Programmer’s Guide vi 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 Elektron Edge Product
Elektron Data Network
Distribution POP (DistPOP)
Elektron Edge
Client’s LAN at client site
Client Applications/Solutions 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
Thomson Reuters Elektron Edge Programmer’s Guide 8 INTRODUCTION TO THOMSON REUTERS ELEKTRON EDGE 4.1 Who should read this Guide This guide, complemented with documentation from API Product releases, provide the information required to write an OMM-based application or SSL-based applicaiton which interfaces with Elektron Edge. As such it should be read by: Managers who want an overview on Elektron Edge, along with an insight into development requirements and performance issues. Systems Designers/Analysts who want detailed knowledge of the Elektron Edge‘s capabilities, features, volumes, response times and restrictions. Systems Programmers who require guidance on using the OMM or SSL-based APIs to communicate with the Elektron Edge.
4.2 How to Use this Guide This guide is divided into three parts: Contains information about the content and format of Elektron data which is delivered to Edge; provides guidelines for implementing an application to access data. Provides guidelines for API access.
4.3 Other References [1] TRSC for Elektron Edge User Guide Provides help on TRSC to users
[2] Edge Notifications Information on data enhancements which is published via the quote pages CHANGES and DNLATEST1.
[3] Thomson Reuters Multilingual Text Encoding Standard A guide containing the Thomson Reuters basic character set and details of how to interpret ISO 2022 international character sets
[4] News 2000 User Guide A guide gives full details of the regional news services which are available on News 2000
[5] Open Message Model – White Paper A white paper focuses on the Open Message Model (OMM) and how it can be used.
Thomson Reuters Elektron Edge Programmer’s Guide 9 ABOUT THE THOMSON REUTERS ELEKTRON EDGE
5 ABOUT THE THOMSON REUTERS ELEKTRON EDGE Thomson Reuters Elektron Edge provides a window into the world of data available on Elektron. Data from Elektron Edge can be in Thomson Reuters Marketfeed as the data format. The consistency of Marketfeed ensures applications to correctly interpret data regardless of its original source. The market data can be also in RWF format which can be retrieved via any OMM-based API. Examples of OMM based APIs are the Ultra Performance API (UPA) and the Robust Foundation API (RFA) Each instrument is stored as a single record and is identified by a unique Thomson Reuters Instrument Code (RIC). Elektron currently supports both logical and page records. Logical records are arranged as discrete sets of fields which its format is predictable by type. Each field consists of a Field Identifier (FID) and a value. Page records consist of rows of data, where each row represents a FID. The logical record structure not only meets user requirements on processable data, but also simplifies record handlings. To minimize traffics in transmitting update messages through Elektron, partial records with only the updated FIDs and their corresponding values are sent out for a logical record, instead of sending out a full version. For page records, only those updated rows are sent out, instead of the entire page. When there are any changes on Elektron affecting Edge clients, you will be notified via our notification procedures. Thomson Reuters has an on-line notification method using page CHANGES or DNLATEST1 on the system. Further details are in section 9.1.1, Edge Administrative Messages.
5.1 Organisation of Document Section 6 CONCEPTS Describes Elektron and how to interpret both logical records and paginated structures; it discusses concepts such as a watchlist, data health, and request rate settings. Section 7 DESIGN GOALS AND SYSTEM Describes the goals of Elektron Edge design, as FEATURES OF ELEKTRON well as major system features. This section also EDGE 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 Thomson Reuters Elektron Edge Programmer’s Guide 10 ABOUT THE THOMSON REUTERS ELEKTRON EDGE fault (see section 6.10, Data Health), applications should monitor the data status and take appropriate actions. Stale data should be indicated clearly on the application display screen.
5.3 News 2000 Quality Guidelines and Checklist Time Ordering of The application should not rely on the time ordering of messages but should Messages 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 It is recommended that a minimum of two RIC references should be held in Management 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.:
Thomson Reuters Elektron Edge Programmer’s Guide 11 CONCEPTS
6 CONCEPTS The Elektron provides real-time information for over ten million financial records, of both logical and paginated in ultra-low latency. Elektron sources the latest information from most of the world exchanges and a large number of contributors, and simultaneously broadcasts the information to clients. To meet user requirements for processable data, logical records are arranged as discrete sets of fields and each field in the set, depending on its type, has a predictable format. Each field consists of a Field Identifier (FID) and a value, in which the value‘s type, format and maximum size can be determined by table lookup. A page record structure is different in the sense that it consists of rows of data, where each row in the page is uniquely defined by a FID. (See section 6.3, Page Records.) Complete records retrieved from one-off snapshots do not receive any updates, while normal complete records keep receiving updates. Updates only consist of partial full record, i.e. only the FID and value for fields that have changed. This optimisation not only simplifies the record interpretation, but reduces transmission time. All messages pertaining to records are classified such that your application can distinguish between and process appropriately for messages including market activity, corrections, adjustments, and verifications. The information in Elektron records is presented using the Elektron standard character set (see [3], Thomson Reuters Multilingual Text Encoding Standard), making it ideal to be inputted directly to applications such as customised screen displays, minute-by-minute portfolio evaluation, cross-rates calculators for foreign exchange dealing or real-time spreadsheets. Following sub-sections explain how RICs are constructed and how the user should interpret records and updates. Also, concepts of watchlist, delivery path, data health, and request rate throttling are presented in detail.
6.1 Thomson Reuters Instrument Code (RIC) Each record on Elektron is retrievable by using a unique Thomson Reuters Instrument Code (RIC). RICs are constructed using strict rules defined by the Elektron Quality Group. This section details the RIC constructions for all instrument types on Elektron, in which the RICs have been implemented and approved. The description is not exhaustive, you are recommended to also reference the relevant Information Product Directory. On Elektron, dual indexing (aliasing) enables the usages of a globally consistent structure and structures derived from local markets concurrently. For example, Swiss Equities can be retrieved by either its RIC name or the Valoren Number. Dual indexing ensures Thomson Reuters services are easy to access for both domestic and international users. This section describes the components of a RIC; these rules vary from instrument types to instrument types.
6.1.1 The Component Parts of a RIC RIC is a convention for naming financial instruments, such that data related to these instruments can be easily accessed from Thomson Reuters databases. The composition of each code depends on the type of instrument. The code is structured with a number of elements, and their complete combination makes up a unique RIC for each instrument. Due to the complexity and diversity of the instrument types covered, it is not possible to define an overall generic rule. As a guidance, RICs include some, but not necessarily all, of the following components: database identifier (see section 6.1.2) instrument code (see section 6.1.3) period or time interval delimiter (possibly more than one) source code (see section 6.1.5) The database identifier is blank for records retrieved from the main Elektron real-time database; the remaining values are defined in the next section.
Thomson Reuters Elektron Edge Programmer’s Guide 12 CONCEPTS Not all of these elements are required in each RIC but there can be no imbedded spaces within a RIC.
6.1.2 Database Access Rules A RIC can be used to retrieve information of an instrument from different databases. This includes the facility to retrieve historical information, such as prices from timeseries database. The first character of a RIC indicates the source it retrieves information from. Lower case characters are reserved for sources not belong to the Elektron real-time databases. Following characters are assigned to particular databases: d Thomson Reuters Timeseries Database (TSDS) Prices n News 2000 t Time & Sales
RICs sourced from the Elektron real-time database begin with the following characters: Capital A – Z Numeric 0 – 9 Period . Hash # The character % is reserved for server information. Remaining punctuation characters are reserved for special internal Elektron functions.
6.1.3 Instrument Code Constituents This section describes all the instrument code constituents which can be used to assemble a complete RIC. The instrument code has a structure of its own. The minimum structure required for an instrument description is a root. A root can be one or more characters. The simplest type of roots is the equity roots which can be a single letter, e.g. F = Ford Motor Co, or two letters, e.g. BP = British Petroleum Co PLC, and commodity roots which can also be as small as a single letter. Roots can be rather lengthy, such as a bond root which may be upwards of ten characters. The following sections will introduce all possible RIC constituents arranged in alphabetical order.
6.1.3.1 Brokerage Characters This subdivision of an equity or debt instrument code can be a combination of special characters and/or lowercase letters used to distinguish among different classes, forms or states of instruments from a single issuer. Note that you have to use the following brokerage characters instead of those published in directories: For instruments listed on NASDAQ, the fifth character is the brokerage character. It is a single uppercase letter. For capital markets instruments, the ―When Issued‖ status is denoted by upper case WI. Datafeed Chars Published Chars Preferred _p PR Rights _r RT Units _u UN When Issued _w WI Warrants _t WS
6.1.3.2 Call / Put Month This subdivision of an option instrument code denotes the month in which a call or put option will expire. The codes used are A-L for call option expiration and M-X for put option expiration:
Month Call Put January A M February B N March C O April D P May E Q June F R Thomson Reuters Elektron Edge Programmer’s Guide 13 CONCEPTS July G S August H T September I U October J V November K W December L X
These month codes are used for options which will expire in the next 12 months. For longer term options, Thomson Reuters tries to accommodate solutions provide by individual exchanges. Some exchanges provide modified root codes, in those cases, Thomson Reuters uses the exchange root. When a modified root is not provided, the following rules are used: For a 12 to 24-month expiry period, a lowercase letter is used for the expiry call / put month. For more than 24 months out, the last digit of the expiration year is used for call options, and a single letter is used, either Y, Z, y or z for the expiry year for put options. For 17-character long RICs, the structure is as per options that expire during the next 12 months, with the addition of the last digit of the expiry year before the exchange identifier.
6.1.3.3 Call / Put Year This subdivision of an option instrument code identifies the expiration year of an option. If an option expires in 2006, then the Call / Put Year is 6.
6.1.3.4 Category Codes The News 2000 service has the facility for searching headlines/alerts based on news category codes. There are five code classes:
Product Codes up to four characters Topic Codes up to six characters Named Item Codes (also known as Report Codes) up to ten characters Company Codes up to ten characters (company RICs) Attribution Codes up to four characters
News 2000 codes may be subdivided into Company Codes and non-Company Codes which occupy distinct and non-intersecting name spaces. Non-Company Codes are listed in online News 2000 directory stories (as described in section 9.7.2, Coding) and are usually composed of only alphanumeric characters. For Company Codes, allowed characters are: Upper and lower case letters Arabic numerals Period / full stop (.) Plus sign (+) Equals sign (=) Forward Slash (/) Semi-colon (;) Note that category codes do not begin with a lower case ―n‖ since this is reserved for the database indicator code for News. The following characters are not used in category codes, they are reserved for boolean logic searches of headlines/alerts within the client application: Space Asterisk * Ampersand & Question Mark ? Minus Sign - Pound / Hash Sign # Square Brackets [] Dollar Sign $ Less/Greater Signs <> ―At‖ Sign @ Apostrophe ‘ Caret ^ Back Slash \ Accent ‗ Percent Sign % Stylized Brackets {} Round Brackets () Vertical Divider | Quotation Mark ― Tilde ~ Thomson Reuters Elektron Edge Programmer’s Guide 14 CONCEPTS
For full details and listings of the News 2000 category codes please refer to [4], News 2000 User Guide.
6.1.3.5 Country Codes Any Country Code adopted within the RIC conforms to ISO 3166, including XM for Multinational and XS for Supranational.
6.1.3.6 Coupon Rate Several methods are currently employed to define coupon rates. All bonds traded in the US have a coupon component of up to four characters. This includes a one to two digit whole number component and a one to two character fractional component. The fractional component has two digits if it is decimal. If it is a fraction denominated in eighths, the first character is the digit of the numerator and the second character is a forward slash (/). For Zero Coupon issues, the coupon component is omitted. Examples coupon = 12.65% coupon code = 1265 coupon = 10-7/8% coupon code = 107/ The scheme adopted overall for debt instruments provides for a three-digit number where the context is critical. Rates are assumed to hover in a bond around 10%. Two-digit numbers other than 10 are assumed to relate a whole number and a fraction. Three-digit numbers are assumed to relate two whole numbers and a fraction. The number 10 is unique and indicates two whole numbers. 97 9 7/8% 10 10% 101 10 1/8% 102 10 1/4% 103 10 3/8% 104 10 1/2% 105 10 5/8% 106 10 3/4% 107 10 7/8%
UK Gilt issues use a code with one to three-characters. The code consists of a one to two digit integer follows by a single letter (if applicable). The integer is the integral part of the coupon rate, while the single letter is its decimal part, which is defined in this way: Letter Meaning E 1/8 Q 1/4 R 3/8 H 1/2 F 5/8 T 3/4 S 7/8 Examples coupon = 12-1/4% Coupon code = 12Q coupon = 9% Coupon code = 9
6.1.3.7 Currency Thomson Reuters uses the three letter ISO 4217 (Swift) currency code where possible (except XEU which is replaced with ECU). For Forex RICs the presence of a single currency code indicates the transaction is settled in US dollars. Where two currency codes are shown, the first is the base currency.
For domestic money market instruments, the two-letter ISO 3166 country code is used instead of the Swift code. The exception is Eurodollar issues which are identified by ―USD‖ rather than ―US‖ for domestic dollar denominated instruments.
6.1.3.8 Delivery Period Indicator This subdivision of an instrument code is used to indicate the delivery period. Delivery period is a characteristic of the transaction as opposed to maturity or expiration, which is a characteristic of the
Thomson Reuters Elektron Edge Programmer’s Guide 15 CONCEPTS instrument. In markets where delivery is highly standardized, such as most equity markets, the delivery period indicator is omitted. In other markets, such as Money, there is a wide variety of delivery periods and they must be included.
The London Metal Exchange is a special case.
Consult the respective directories for details on delivery periods for other instruments, such as cash energy and commodities.
Period Indicators Period Indicators D 10 Year for JGB xW Number of Weeks
E Early xWO Number of Weeks (Over the Weeks)
F Final (Japan) xM F Number of Months
L Late/Long term (10 xMO Number of Months (Over Year) JGB (Japan) the Months)
M Medium Term JGB xMOS Number of Months (Over (Reserved) 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: Thomson Reuters Elektron Edge Programmer’s Guide 16 CONCEPTS T Treasury E Exchequer F Funding C Conversion
6.1.3.12 Instrument Indicator A one- to four-letter code defines a subcategory of debt instrument in the Money and Capital Markets. Examples would be Treasury Bills, Certificates of Deposit, Forward Rate Agreements, Repurchase Agreements and the like. BA Bankers Acceptance DS Discount for JGB (Reserved) BNR Bank Note Rate E Ex-warrant bond (Reserved) C Convertible Bond (Japan) EB Eligible Bills CA Interest Rate Cap EX Exchange Rate Agreement CD Certificate of Deposit F Forward Rate Agreements CDCB Certificate of Deposit – Clearing FB Financing Bills Bank CDE Certificate of Deposit – FF Federal Funds Secondary(Outright, Japan) CDG Certificate of Deposit – Secondary FFAG Federal Funds Agency (Gensaki / RP, Japan) CDN Certificate of Deposit – New Issue FIX Exchange Fixing (Japan) CDOB Certificate of Deposit – Other FI Fixed Interest Banks CDP Certificate of Deposit – Primary FL Floating Rate CDS Certificate of Deposit – Secondary FR Interest Rates Floor CDT Certificate of Deposit – Secondary FS Forward Rate Agreements – Strip (Tenbai, Japan) CDBS Certificate of Deposit – Building FSR FRA Settlement Rates Society 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 RP Repurchase Agreement (Outright, Japan) CPG Commercial Paper – Secondary RPT Repurchase Agreement – Treasury (Gensaki / RP, Japan) D Deposit RPM Repurchase Agreement – Mortgage Backed DC Dollar Call RPMM Repurchase Agreement – Money Market RPGN Repurchase Agreement – Ginny TE Tax Exempt Mae RPFN Repurchase Agreement – Fanny TEMM Tax Exempt – Money Market Mae RPFH Repurchase Agreement – FHLMC TEMN Tax Exempt – Municipal Note S Swap TG Tegata SF Synthetic Agreement for Forward W Warrant Bonds Exchange 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 Thomson Reuters Elektron Edge Programmer’s Guide 17 CONCEPTS BI Brussels Interbank OI Oslo Interbank CI Copenhagen Interbank PI Paris Interbank DI Dublin Interbank RI Rome Interbank FI Frankfurt Interbank SI Singapore Interbank HEI Helsinki Interbank STI Stockholm Interbank HI Hong Kong Interbank TI Tokyo Interbank II Italian Consortium Interbank VI Vienna Interbank LI London Interbank LUI Luxembourg Interbank
6.1.3.14 Market Identifier The following market identifiers are defined for Money: Blank World A Asia E Europe N North and South America SEA South East Asia R Thomson Reuters BST Best rate -this identifier was originally BEST. XX All 2-character ISO 3166 Country Codes for Country-level contributions
6.1.3.15 Maturity Month The general scheme for most instruments is to use a single letter to indicate the debt instrument matures month. The code uses A to L to indicate January to December. The scheme for the US provides distinguishing registered versions of a bond from the bearer (coupon) form of the bonds. Registered is the most common form and under US law, no new bonds may be issued in bearer form. However, there are still many issues trading in bearer form until they mature. Months Gen US Registered US Bearer Tie Breaker January A 1 A February B 2 B March C 3 C April D 4 D May E 5 E June F 6 F July G 7 G August H 8 H September I 9 I October J O J November K N K December L D L
6.1.3.16 Maturity Year This is a two-digit number to identify the year in which a debt instrument matures. The code is the last two digits of the year; that is, for a bond maturing in 2012 the maturity year code is 12.
6.1.3.17 Root A RIC root is a set of characters denoting some basic instrument differentiations: it may identify an instrument issuer it may define a product or category of tradable items it may/may not have an internal structure In Money, the root has such a complex internal structure that the concept does not really apply.
6.1.3.18 Strike Price Code There are two separate rules for strike price codes: one for equity options and another for futures options.
6.1.3.18.1 Cash/Equity Options Thomson Reuters Elektron Edge Programmer’s Guide 18 CONCEPTS This is a two- or three- character code depending on the strike price: If the strike price is less than or equal to 10, then the two-digit code used is the integer component of the strike price multiplied by 10. For example, if the strike price is 7.3, the code will be 73. If the strike price is from 10 - 99.9, then the three-digit code used is the integer component of the price multiplied by 10. For example, if the strike price is 12.25, the code will be 122, or if the strike price is 95, the code will be 950. If the strike price is equal to or larger than 100, then the three-digit code used is the three most significant (leftmost) digits of the price. For example, if the strike price is 191.5, the code will be 191, or if the strike price is 12500, the code will be 125.
6.1.3.18.2 Futures Options This is a code up to five digits, depending on the exercise price: If the exercise price has five or less figures, then the code is the exercise price (excluding the decimal point). For example, if the exercise price is 234.5, the code will be 2345. If the exercise price has more than five figures, then the code is the five least significant (rightmost) digits (excluding the decimal point). For example, if the exercise price is 1234.75, the code will be 23475.
6.1.3.19 Size The size of the transaction is indicated in RICs for certain Japanese debt instruments traded on the Japanese Government Bond (JGB) section of the Tokyo Stock Exchange (TSE) and the Tegata of Ueda Tanshi. These indicators are included in the Period indicator for Tegata of Ueda Tanshi (see section 6.1.3.8, Delivery Period Indicator). For JGB of TSE, the size indicators are: L Large Lots – Transactions of 10 million yen or more S Small Lots – Transactions of one to 10 million yen
6.1.3.20 Trading Session The trading session on the London Metal Exchange is represented by a two-character alphanumeric code. In other futures markets, sessions refer to broad time periods of continuous trading such as a day session, an evening session or an overnight session. The futures RICs have a single digit prefix indicating a specific day portion. With this prefix, a full trading day record or all the day portion records can be provided. Sessions for North American futures markets are defined as follow: 1 = Evening (1800 local to about midnight) 2 = Overnight (Just after midnight to about 0600) 3 = Day session (0730 to late afternoon) Sessions for MATIF are defined as follow: 1 = Open outcry (MATIF) traded 2 = Globex traded The chain records for trading sessions follow the structure: session numeric contract root futures delimiter (:)
6.1.3.21 Uniqueness Identifier or Tie Breaker An alternative set of month codes for Maturity Month is used to distinguish between two or more instruments which would have the same logical RIC structure. This is necessary to ensure that the RIC does not become too lengthy. For US Treasuries, the Tie Breaker would occasionally be needed to distinguish Treasuries with identical coupon, maturity month and year, but with different middle dates (day of the month). The letter A would represent the second such occurrence in the month.
Thomson Reuters Elektron Edge Programmer’s Guide 19 CONCEPTS For JGB on the TSE, A month code would be placed in front of the RIC to distinguish the first and second issues which share the same issue number. Month Code Meaning 1 First issue using the same issue number 2 Second issue using the same issue number
6.1.4 Summary of Instrument Type Delimiters The current separator characters are: Instrument Character Instrument Character Bonds (Chain) ! Indices . (dot) Capital Markets = Marketscope , (comma) Closing/Delayed Data / (used as a prefix) Money Markets (Forex) = Equities and Equity . Options on Futures + Options (Chain) Equity Options (Chain) * (plus market Physical - separator) Commodities
Expired RICs > (plus market Pre-Packed Data , (comma) separators) 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.
Thomson Reuters Elektron Edge Programmer’s Guide 20 CONCEPTS Please note that some chains omit the 0# as the first chain record, notably some Money 2000 RICs and Indices.
For further details of processing chains please see section 9.3, Processing Chains and Tiles. The chain record construction specification within each Information Products can be found in the relevant Directory.
6.3 Page Records Page records are delivered to Edge row by row, each row is identified by a unique FID. There are several sizes available: 14 rows of 64 characters (‗Monitor Style‘ pages) 25 rows of 80 characters (Large page record) a single row of 99 characters 12 rows of 99 characters 20 rows of 99 characters
6.3.1 ‘Monitor Style’ Pages (64x14) Some pages from the Monitor database are also stored on the main Elektron database for retrieval. The RIC for a ‗Monitor Style‘ page held on Elektron is the same as the Monitor page code and is subjected to the same basic rules: RIC is four characters long. Valid characters are upper case letters (A to Z), lower case letters (a to z) and numeric (1 to 9, exclude zero). Separators are not supported. The RIC does not end at a numeric if the penultimate character is a valid futures delivery month, i.e. F, G, H, J, K, M, N, Q, U, V, X, Z.
Please note that not all monitor pages are available via Edge. Monitor pages with its data "logicised” into a logical record or a chain record, are remove from Elektron.
Some data with Monitor page structure on Elektron is not sourced from the Monitor network, its codes thus does not follow the above rules. Instead, the codes adhere to Elektron RIC structures. An Elektron data example is time series one (TS1) data.
6.3.2 Large Page Records (80x25) and 99-Character Pages RICs for Large page records have a minimum of 5 characters and a maximum of 17; there may be some specific examples of 4-character Large pages. All alphanumeric characters are supported, including lower case letters, with the following rules: The RIC does not start with a lower case letter. The RIC does not end with a numeric if the penultimate character is an upper case letter. For RICs of 5 characters in length, the final character must not be a ‗v‘. These rules also apply to 99-character pages.
6.4 Field Identifiers (FIDs) and Values Each field in a record (or each row in a page) contains a FID and a value. The FID determines its value content. This logical structure has the following advantages: Field values can have a variable length, up to the published maximum, so that Elektron network does not have to transmit superfluous characters. Only changed fields/rows are transmitted on Elektron in updates. By applying only relevant fields to applications using Thomson Reuters data, maximum flexibility and efficiency can be obtained. See also section 9.2, Processing FIDs, which provides guidelines for implementing software to handle FID numbers in record and to update messages.
Thomson Reuters Elektron Edge Programmer’s Guide 21 CONCEPTS 6.4.1 A Word About Time Fields Time fields in datafeed messages store time in 24-hour format, for example, 15:35 (or 15:35:03 for accuracy to seconds). The time zone of the reported time varies. All logical records quoted are reported in GMT; it should be noted that logical contributor records may not adhere to this rule. On pages from the Monitor network, the applicable time zone depends on the origin of the information: European, African and Middle Eastern pages use GMT; Asian and Australian pages use Tokyo time; American pages use New York time. Please consult the relevant directory to ensure the given time stamp interpretation.
6.5 Record Classification Within each record structure, there is a field helps to identify which market sector the record is from and what type of data item it is. This field (FID 259, RECORDTYPE) contains one of the values in the matrix below. This field may be used for a variety of applications. It is guaranteed that the value in the record fields do not change, unless a record changes its meaning. If it is necessary to alter the FID 259 values, the change will be subjected to Data Notification.
NOTE: The information contained in this field is useful for determining display formats.
Instrument Type Building a b c d e F g h I j k l m N o p Block 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 Thomson Reuters Elektron Edge Programmer’s Guide 22 CONCEPTS 226 Speed Guide page 227 Headings / title page 228 Product Definition page 229 Alias record 230 Permissions record 231 Program record 232 News 2000 233 Pre-packaged data 234 Editorial news / rates page 235 IRG data 236 Not yet allocated 237 Not yet allocated 238 Network status 239 Dummy record
6.6 Permissions
6.6.1 IDN Permissions Access to Elektron is controlled by an ILA permissions scheme. When Edge is installed, it is given a set of permissions, which is agreed by the client and Thomson Reuters. The permissions control the client accesses to different records. If a client attempts to request records without permission, the request would be rejected by Elektron Edge and a negative response is returned.
6.6.2 User Permissioning User permissioning can be used in your application by implementing a permissioning scheme as part of your application. To enable clients to manage site control on fee liable data, Thomson Reuters provides the permissioning details to both exchange data and specialist data services in RIC form on Elektron. The permissioning details enable clients to develop a network management and permissioning system to control data usages of individual users/applications. Permissioning is controlled through Permissionable Entities (PEs). All RICs (both logical and paginated), except news items, each is assigned a universal PE value. News items can belong to more than one PE. PE value is carried in FID1 (PROD_PERM) in each RIC. For news items, the PE values are carried in FID1 and service bank (FID456 and FID457). Currently PEs range from 0 to 11519, it is advised to make your applications to deal with PE values up to 32,767, such that your applications can adapt to new PE values in future. The PE information for fee liable entities, and for Thomson Reuters Information Products, is stored in a series of Thomson Reuters Product Definition Pages. These pages list both the administrative and the permissioning information, which its index page is PERMINDEX000.
6.7 Watchlist Edge provides an interface to Elektron through which user applications can access individual items (i.e. RICs). The list of RICs being monitored by Edge in a time instance is called a watchlist. It is important that a client is not limited to a static selection of records. Rather, the watchlist mechanism provides a window into the Elektron database of over ten million records and page records. Your application can re-arrange the window as required by issuing requests to Edge which affect the content of the watchlist. Depending on the datafeed mode, Edge can be configured with a watchlist size up to 1,000,000 RICs. Multiple Edges can be installed for sites require monitoring more than 1,000,000 RICs. The watchlist size limitation ensures an Edge has an adequate capacity to handle traffics of monitored RIC updates.
6.8 Delivery Path and Services A delivery path is a communications link used to transport data between Edge and the Elektron data center. Only one delivery path is available: Retrieval (i.e. Distribution POP) Thomson Reuters Elektron Edge Programmer’s Guide 23 CONCEPTS
Edge delivers data from Distribution POP under two services:
ELEKTRON_DD (Elektron Default Distribution) is analogous to the IDN_RDF service exposed today by the IDN_RDF. The ELEKTRON_DD service provides access to all content that is available on IDN. ELEKTRON_AD (Elektron Application Distribution) provides access to the same venues as the ―ELEKRON_DD‖ service, but it allows applications to access content from a venue which is migrated from being collected on IDN to being collected natively on Elektron at the earliest possible opportunity. From time to time, a venue migrates from IDN to Elektron, Edge may inform your application any involved item in such switch over through an item status message. See APPENDIX B for the message.
Your application would be notified the available services at the Edge. Handling of the service information in SSL- and OMM-based applications are given in sections Error! Reference source not found. and Error! Reference source not found., respectively. Sink applications can request items from different services by specifying the corresponding service name in the request.
6.9 Data Group At any time, each item delivered to the client application will associate with a one-and-only-one data group. The item‘s data group can be associated with the item‘s delivery path, but this association is not always guaranteed. There may be situations where the data group and delivery path of an item is not related in this manner. For this reason, the data group should only be used in reporting a data health change. Each service will provide its own set of data group information. As such, Edge will provide two sets of such information for services ELEKTRON_DD and ELEKTRON_AD. However, if ELEKTRON_AD is disabled (by default), only a set of group information is provided from Edge. While an item is being watched, the group ID may be changed. If Edge has to re-open items, the group ID may differ from the item‘s group ID received via a previous request. Your application would be notified for the change in group ID with an appropriate status message. Handling of the data group information in SSL- and OMM-based applications are given in sections Error! Reference source not found. and Error! Reference source not found., respectively.
6.10 Data Health Data health reflects the quality of the update stream for a particular RIC. For records accessed by Edge, there are two possible values for the data health status: OK and STALE. OK indicates that the update stream for a RIC is healthy and users can trust the data for that record. STALE is generated either when the delivery path for a record is severed or when an error has been detected in Edge or other devices. Users should avoid making decisions based on data in records that have a STALE status. When the condition that caused the STALE status restored, Edge will recover all stale instruments and forward them to your application. Handling of the data health information in SSL-, RFA- and UPA-based applications are given in sections Error! Reference source not found. and Error! Reference source not found. of this document and section 11.2.6 of Error! Reference source not found., respectively.
6.11 Snapshots Edge supports snapshot requests which provide current images without any updates to follow. The transaction to satisfy a snapshot request is completed with the image. Since a record requested as a snapshot is not cached, it is not counted against the watchlist. However, a snapshot request takes up capacity in the request window.
6.12 Non-updating Item Support Some items, such as Time & Sales (TAS) and TS1 records, do not receive updates. These are called non-updating items. Elektron Edge handles these non-updating items in a special way. That is, it treats requests of non-updating items similar to snapshots and does not cache these items, since cached data of that type may be out-dated and stale without updates.
Thomson Reuters Elektron Edge Programmer’s Guide 24 CONCEPTS
Non-updating items are identified by the first character of the RIC. For example, the RICs for TAS items always have ‗t‘, and have ‗d‘ for TS1, as the first character.
Elektron Edge will also send out non-updating items other than those listed above.
Each non-updating item image is followed by an SSL_ET_ITEM_STATUS_CLOSED event indicating that the item was closed because of its non-updating characteristics. The Text field will contain the message ―Non-updating item‖.
6.13 Support Aliases Elektron Edge is enhanced to support aliases. Aliases provide a secondary record indexing form. An Alias is essentially an intermediary RIC which maps onto another RIC which is used to access a record. Aliases satisfy two specific key business needs: Allow an alternative symbology to access exchange data held on Elektron. Create a level of indirection which allows client site applications to monitor a front contract (i.e. a generic contract that points to the next contract to rollover). This allows applications, e.g. graphical displays, to continue without being updated after a futures contract rollover. In most cases, the aliasing function is transparent to user applications. Elektron Edge will request the underlying record on behalf of the user application, and a pseudo record will be returned to user. Although these processes require Elektron Edge to keep two items in the internal watchlist, it will only be counted once from the user watchlist limit.
6.14 TCP/IP Nagle Algorithm
6.14.1 Server Side TCP/IP Nagle algorithm is disabled at Server Side due to the low latency nature of Elektron Edge. All messages to be sent to the TCP/IP stack are sent out as soon as bandwidth is available. This reduces the message latency caused by the TCP/IP stack. However, messages are sent with smaller packets and thus overall network efficiency is lower. Further, this higher packet rates can also increase the workload of your application.
6.14.2 Client Side Other than disabling Nagle on the server side, you can also choose to reduce the delayed ACK timer in your application from the default 200ms to 0ms. A sample setting for Windows based OS is described below. Windows 2000 Edit the TcpDelAckTicks registry value to adjust the delayed ACK timer. By default, the delayed ACK timer value is 2 (200 milliseconds). Add or Set the TcpDelAckTicks value to 0, delayed acknowledgments are disabled. This setting causes the computer to immediately send an ACK packet for every packet it receives. Restart Windows for this change to take effect. Information about TcpDelAckTicks: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip Key \Parameters\Interfaces\interface Value Type REG_DWORD-number Valid Range 0-6 Default 2 (200 milliseconds) 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 Description 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. Thomson Reuters Elektron Edge Programmer’s Guide 25 CONCEPTS TcpAckFrequency is a new registry entry in Microsoft Windows XP and Microsoft Windows Server 2003 that determines the number of TCP acknowledgments (ACKs) that will be outstanding before the delayed ACK timer is ignored. Set the TcpAckFrequency value to 1, every packet is then acknowledged immediately. Restart Windows for this change to take effect. Information about TcpAckFrequency: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip Subkey \Parameters\Interfaces\
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).
Thomson Reuters Elektron Edge Programmer’s Guide 26 CONCEPTS
Figure 6-1 A sample pseudo RIC response of %CSTATRIC from Kobra (Display All Fields)
The pseudo response provides the following information: 1. FID 3: User name – the username of the channel (response only). 2. FID 188: Channel‘s SSL/RSSL buffer utilization (percentage). 3. FID 189: Channel‘s message rate. 4. FID 190: Channel‘s throughput in bps. 5. FID 191: Total number of open requests that resulted in closed recoverable status messages. 6. FID 216: Server name (response only). 7. FID 995: User ILA – the ILA of the channel (response only). 8. FID 1001: Protocol type (e.g. SSL and RWF1. Response only).
User name (FID 3), User ILA (FID 995) and Protocol type (FID 1001) may not be available at the time when %CSTATRIC is requested. Those fields are blank in the response. VSYNC will be sent to client if this information becomes available. Server Name is available at the time of request. This name is carried in FID 216 which is similar as in %CCONFIG (see section 6.16). %CSTATRIC update messages only contain the fields that are changed. In most time, FID 188 (Channel‘s SSL/RSSL buffer utilization), FID 189 (channel‘s message rate), FID 190 (channel‘s
Thomson Reuters Elektron Edge Programmer’s Guide 27 CONCEPTS throughput) and FID 191 (Total number of open requests that resulted in closed recoverable status messages) are included in an update message. FID 188 would be a non-zero value only when there is some network latency/error, or when the client infrastructure is not fast enough to catch up with the update rate in that particular time.
Note: Please note that the FIDs of template 17 not shown in the above list are reserved for future use.
6.16 Support Pseudo RIC for Elektron Edge Configurations (%CCONFIG) To obtain the basic configuration and versioning information for Elektron Edge, clients can request the pseudo RIC ―%CCONFIG‖. The retrieved information helps clients to provide clearer information regarding the Elektron Edge delivery and configuration to assist speedy investigation upon support issues.
This pseudo RIC response uses template 51 (i.e. 14 rows x 64 columns page record) and display template 132. Its content contains configuration information including Product Type, Product Version, Server Name, Server ILA, Server ID, Delivery Service Name, Field Definition Version, Hardware Platform, Memory Size and Maximum Server Watchlist Size. A sample pseudo RIC response is shown below for reference.
Delivery Services provided by Elektron Edge are: - FTN – Full Tick Network - BON – Bandwidth Optimized Network
Figure 6-2 A sample pseudo RIC response of %CCONFIG from Kobra
As seen above, the pseudo RIC response provides the following information: 1. FID 215: Product Type and Product Version 2. FID 216: Server Name 3. FID 217: Server ILA 4. FID 218: Server ID 5. FID 219: Delivery Service Name 6. FID 220: Field Definition Version 7. FID 222: Hardware Platform 8. FID 223: Memory Size (MB) 9. FID 225: Maximum Server Watchlist Size
The MarketFeed of the above sample pseudo RIC response is shown below:
Thomson Reuters Elektron Edge Programmer’s Guide 28 CONCEPTS
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.
Thomson Reuters Elektron Edge Programmer’s Guide 29 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE
7 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE
7.1 Elektron Edge Design Goals Elektron Edge is a high capacity, digital datafeed product, capable of delivering full content of Thomson Reuters information products and support compatiablity with the suite of supported Real- Time APIs and products. We target users who require instant access to exchanges they deal with and who are maintaining more than 100K instruments in their real-time tick databases.
The product provides the following features: RSSL/RWF (OMM-based connections) and SSL (Market Feed-based connections) Criteria based requests(SSL/MF) / Symbol List Requests( OMM-based) for Broadcast data streams Multiple channel support Watchlist mechanism Data health and recovery Access to all real-time services
7.2 Elektron Edge Connectivity The Elektron Edge currently supports two types of connectivity. This connectivity is based on:
Our strategic Open Message Model (OMM) offerings which utilize Reuters Wire Format (RWF) technologies. Our legacy SSL/Market Feed techonoligies
Clients can use any of our Real-Time APIs that support SSL/MF or RSSL/RWF to connect, and interact directly with the Elektron Edge. Each of these APIs is part of a Developers Kit that includes its own documentation (developer‘s guides, reference manuals, config guides, etc). Each kit provides example programs with source code, which allow application developers to see how to write applications.
Clients can access the electron Edge by utilizing any of our supported Thomson Reuters Application Programming Interfaces (APIs). Examples of these APIs are:
7.2.1 Ultra Performance API (UPA) The UPA product suite contains the strategic low-level, transport APIs for multi-threaded access to subscription, publication, and contribution capabilities of Thomson Reuters Enterprise Platform. UPA was introduced in 2009. The UPA subscriber (consumer-side) can connect directly to the Elektron Edge. The UPA standardizes on the strategic Open Message Model (OMM) which allows clients to use Rich Data Models from Thomson Reuters, or create and utilize their own customs data models. The UPA is designed to take full advantage of throughput and latency benefits of the optimized Thomson Reuters Wire Format (RWF) for connectivity to the Thomson Reuters Enterprise Platform for Real Time Components (Advanced Distribution Server, Advanced Data Hub, etc), Elektron Elektron Edge, and the Thomson Reuters Data Feed Direct. Clients wishing the highest throughtput and lowest latency should consider utilizing this API. The UPA Product is currently available in C, and Java. When looking at the UPA documentation and examples, refer to using a UPA consumer. A UPA consumer is what you would write to connect to the Elektron Edge.
7.2.2 Robust Foundation API (RFA) The RFA is the strategic, message-oriented, Session Level API for multi-threaded access to subscription, publication and contribution capabilities. The RFA Market feed was introduce in 2001 and the OMM support was introduced in 2006. The RFA subscriber (consumer-side) can connect directly to the Elektron Edge. The RFA standardizes on the strategic Open Message Model (OMM) which allows clients to use Rich Data Models from Thomson Reuters, or create and utilize their own customs data models. The RFA utilizes the benefits of the optimized Thomson Reuters Wire Format (RWF) for connectivity to the Thomson Reuters Enterprise Platform for Real Time Components (Advanced Distribution Server, Advanced Data Hub, etc), Elektron Edge, and the Thomson Reuters Data Feed Direct. Certain RFA Products contain Legacy Market Data Interfaces, which support SSL. The RFA Products are available are available in C++ and Java for both OMM and SSL connectivity. RFA is also available in .Net for OMM connectivity.
Thomson Reuters Elektron Edge Programmer’s Guide 30 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE 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)
Thomson Reuters Elektron Edge Programmer’s Guide 31 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE 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.
Thomson Reuters Elektron Edge Programmer’s Guide 32 DESIGN GOALS AND SYSTEM FEATURES OF ELEKTRON EDGE 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.
Thomson Reuters Elektron Edge Programmer’s Guide 33 LOGICAL DATA FORMATS IN SSL
8 LOGICAL DATA FORMATS IN SSL
8.1 Overview Thomson Reuters uses the Marketfeed protocol for distributing logical (record) data to clients. Marketfeed defines a set of messages and the protocol syntax and semantics of those messages. This section defines the Marketfeed message structure and the specific Marketfeed messages which must be processed by an SSL-based application.
When SSL posts an Image or Update event, the Data field of its information structure points to the Marketfeed message.
8.2 Notation The notations used to describe Marketfeed messages in this document are as follow:
[ ] Square brackets1 enclose optional message elements. < > Angled brackets enclose ASCII control characters. {} Curly brackets denote 0 or more repetitions in a message.
8.2.1 ASCII Characters Obtainable from your local sales office, provides complete specifications on the character sets that are currently in use. Edge uses the extended 8-bit ASCII character set. Since the ASCII character set includes control characters which cannot be displayed or printed, the text in this manual encloses a pseudonym for each such character in angle brackets, e.g.
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. Thomson Reuters Elektron Edge Programmer’s Guide 34 LOGICAL DATA FORMATS IN SSL 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:
Messages may also contain the following control characters:
8.2.4 Message Structure Marketfeed uses the following general message structure for all functions:
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: {
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:
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):
Thomson Reuters Elektron Edge Programmer’s Guide 35 LOGICAL DATA FORMATS IN SSL 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:
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:
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:
G R U Field_ U G Status R Function U Tag RIC R_Status RTL Text S S S List_No S S Code S S
2 The actual ordering of each header field is slightly different for different ―function‖ types. Thomson Reuters Elektron Edge Programmer’s Guide 36 LOGICAL DATA FORMATS IN SSL
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
Thomson Reuters Elektron Edge Programmer’s Guide 37 LOGICAL DATA FORMATS IN SSL 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 (
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.
Thomson Reuters Elektron Edge Programmer’s Guide 38 LOGICAL DATA FORMATS IN SSL 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
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:
Thomson Reuters Elektron Edge Programmer’s Guide 39 LOGICAL DATA FORMATS IN SSL 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:
Example 1 - Logical Record: In response to a sink application request for the record TRI, Edge might respond with the following Record_Response: